Planlæg og vedligehold en Tor-relæ på en VPS
Vælg et ikke-exit-relæ eller en bridge, budgetter båndbredde, installér vedligeholdte Tor-pakker, og drift noden ansvarligt.
Kort overblik
At køre en Tor-relay kræver en egnet udbyder, tilstrækkelig overførselskapacitet, korrekte porte og regelmæssig vedligeholdelse. En mellemrelay eller bro adskiller sig fra en exit-node i sin netværksrolle og sine ansvarsområder. Brug Tor Project's opsætningskontroller, og overvåg ressourceforbruget efter udrulning.
Vælg rollen, før du lejer ressourcer
Et offentligt ikke-exit-relæ sender krypteret trafik mellem Tor-noder i stedet for at etablere brugerens endelige forbindelse til en internettjeneste. Det kan senere få guard-status, efterhånden som netværket vurderer det. En bridge udgør et indgangspunkt, som ikke er opført som et almindeligt offentligt relæ, og hjælper brugere, hvis netværk blokerer kendte Tor-adresser.
Et exit-relæ etablerer den endelige udgående forbindelse og eksponerer derfor sin egen IP-adresse over for destinationerne. Det medfører andre krav til drift og håndtering af misbrug. For en første node er et ikke-exit-relæ eller en bridge normalt det mere overskuelige valg. Bekræft, at udbyderen tillader den præcise rolle, før du implementerer den.
Budgetter til kontinuitet og trafik
Et relæ har gavn af en stabil adresse, pålidelig oppetid og vedvarende kapacitet i begge retninger. Små VPS-ressourcer kan understøtte et begynderrelæ, men gennemstrømningen afhænger af krypteringsydelse, delt CPU-adfærd og netværksgrænser. Kravene til RAM stiger med antallet af forbindelser; overvåg den faktiske brug i stedet for at betragte den mindste instans som en universel løsning.
Månedlig overførsel er lige så vigtig som porthastigheden. En høj hastighed, der opretholdes døgnet rundt, kan hurtigt opbruge en plan med målt forbrug, især hvor både indgående og udgående trafik tælles med. Afstem båndbreddebegrænsning og regnskab med den faktiske kvote, og efterlad råderum til systemvedligeholdelse.
Installér vedligeholdt software på et hærdet system
Start med et opdateret styresystem, administrativ adgang baseret på nøgler og en firewall, der tillader den valgte relæport. Brug Tor Projects aktuelle installationsvejledning til din distribution og understøttede pakkekilde. Repositorynøgler, pakkenavne og serviceenheder bør komme fra denne vejledning i stedet for en gammel kopieret installationsfil.
På mange Linux-systemer er konfigurationen /etc/tor/torrc. Angiv et særpræget kaldenavn og en overvåget projektkontaktadresse, og konfigurér derefter relærollen eksplicit. Hold administrationsvejen adskilt fra relæets offentlige lytteport.
Brug en eksplicit ikke-exit-konfiguration
Det følgende er et illustrativt ikke-exit-oprids, ikke et komplet opsætningsscript. Erstat kontakten med en adresse, du overvåger, og vælg hastighedsværdier, der passer til abonnementet. Den viste .invalid-adresse er en pladsholder og kan ikke modtage operatørbeskeder.
Validér konfigurationen, og gennemgå opstartsdiagnostikken. Bekræft, at relæporten kan nås, og at noden med tiden vises i den offentlige fortegnelse. Et nyt relæ kan i begyndelsen bære lidt trafik, mens dets kapacitet og pålidelighed vurderes; undgå gentagne gange at ændre dets identitet blot for at fremtvinge aktivitet.
Nickname SilentNode
ORPort 9001
ContactInfo [email protected]
RelayBandwidthRate 1 MBytes
RelayBandwidthBurst 2 MBytes
ExitRelay 0
SocksPort 0En bridge har brug for en transport og en omhyggelig distribution
En obfs4-bridge slører sit trafikmønster for at hjælpe brugere med at omgå filtrering. Følg den aktuelle distributionsspecifikke bridgevejledning for dens pluggable transport-pakke; implementationsprojektet for obfs4 hedder nu lyrebird. Konfigurér transportlytteren, test tilgængeligheden, og indhent bridgeforbindelsesoplysningerne.
Offentliggør ikke en privat bridgelinje uden videre. Brug den dokumenterede distributionsmekanisme, eller del den med de tilsigtede brugere. Hvis et offentligt kendt relæ omdannes til en bridge uden at ændre identificerende detaljer, kan bridgen blive lettere at opdage og blokere.
Erklær fælles ejerskab, og vedligehold kontakt
Hvis du driver flere relæer, skal du oplyse deres fælles kontrol via den aktuelle Tor-familiemekanisme, så klienter kan undgå at vælge dine noder i flere kredsløbspositioner. Den aktuelle vejledning bruger FamilyID; ældre MyFamily-eksempler bør ikke betragtes som aktuelle konfigurationsinstruktioner.
En overvåget ContactInfo-adresse gør det muligt for andre operatører at rapportere problemer uden at kende din borgerlige identitet. Hold sikkerhedsopdateringer aktuelle, men forstå, hvordan servicerestart og pakkeændringer påvirker noden. Brug båndbredde- og regnskabsindstillinger med omtanke i stedet for at lade et relæ uventet bruge hele planen.
- Kontrollér den aktuelle familiekonfiguration for drift med flere relæer.
- Overvåg den dedikerede kontaktpostkasse.
- Gennemgå opdateringer og tilgængelighed efter en genstart.
- Hold private overvågningsoplysninger passende begrænsede.
- Vælg overførselsregnskab, der passer til udbyderens fakturering.
Behandl exits som en særskilt implementeringsbeslutning
Exittrafik kan give anledning til klager og blokering på destinationssiden. Før du aktiverer et exit, skal du sikre dig udtrykkelig udbyderstilladelse, en overvåget misbrugsproces, passende dedikeret infrastruktur og en informeret forståelse af gældende forpligtelser. Skift ikke en eksisterende node til exit-tilstand blot for at øge dens anvendelighed.
En ikke-exit-relæ eller bro bidrager allerede med nyttig kapacitet. Dens lavere eksponering for klager fra destinationer fjerner ikke behovet for vedligeholdelse eller tilladelse. Det offentlige SilentVPS websted kan ikke erstatte en bekræftet driftsmæssig politik, når produktionsinfrastrukturen bliver tilgængelig.
Bevar et sundt relay over tid
Kontrollér katalogstatus, gennemstrømning, klokkesynkronisering, hukommelse og den valgte listener efter ændringer. Et privat overvågningssystem hjælper med at opdage afbrydelser uden at offentliggøre følsomme finkornede trafikmønstre. Opbevar sikkerhedskopier af konfiguration og identitetsnøgler på et sikkert sted.
Hvis du migrerer, skal du bevare det relevante identitetsmateriale, så noden ikke behøver at genopbygge hele sin historik; verificér den aktuelle migreringsvejledning, før du kopierer filer. Kør aldrig utilsigtede dublerede instanser af samme identitet. Stabil, velvedligeholdt kapacitet gavner netværket mere end hyppig eksperimentering på en live-node.