Planera och underhåll en Tor-relä på en VPS
Välj ett icke-exit-relä eller en brygga, budgetera bandbredd, installera underhållna Tor-paket och driv noden ansvarsfullt.
I korthet
Att köra ett Tor-relä kräver en lämplig leverantör, tillräcklig överföringskapacitet, korrekta portar och regelbundet underhåll. Ett mellanrelä eller en bro skiljer sig från en exit-nod i sin nätverksroll och sina ansvarsområden. Använd Tor-projektets installationskontroller och övervaka resursanvändningen efter distribution.
Välj rollen innan du hyr resurser
Ett offentligt icke-exit-relä skickar krypterad trafik mellan Tor-noder i stället för att göra användarens slutliga anslutning till en internettjänst. Det kan senare få guard-status när nätverket utvärderar det. En brygga tillhandahåller en ingångspunkt som inte listas som ett vanligt offentligt relä, vilket hjälper användare vars nätverk blockerar kända Tor-adresser.
Ett exit-relä gör den slutliga utgående anslutningen och exponerar därför sin egen IP för destinationer. Det medför andra krav på drift och hantering av missbruk. För en första nod är ett icke-exit-relä eller en brygga vanligtvis det mer hanterbara valet. Bekräfta att leverantören tillåter den exakta rollen innan du driftsätter den.
Budgetera för kontinuitet och trafik
Ett relä drar nytta av en stabil adress, tillförlitlig drifttid och uthållig kapacitet i båda riktningarna. Små VPS-resurser kan stödja ett startrelä, men genomströmningen beror på krypteringsprestanda, delat CPU-beteende och nätverksgränser. RAM-krav ökar med antalet anslutningar; övervaka verklig användning i stället för att betrakta den minsta instansen som en universallösning.
Månatlig överföring spelar lika stor roll som portens hastighet. En hög hastighet som upprätthålls dygnet runt kan snabbt tömma en plan med mätning, särskilt där både inkommande och utgående trafik räknas. Anpassa bandbreddsbegränsning och redovisning till den faktiska tilldelningen, och lämna utrymme för systemunderhåll.
Installera underhållen programvara på ett härdat system
Börja med ett uppdaterat operativsystem, nyckelbaserad administrativ åtkomst och en brandvägg som tillåter den valda reläporten. Använd Tor Projects aktuella installationsanvisningar för din distribution och en paketkälla som stöds. Förrådsnycklar, paketnamn och tjänsteenheter bör komma från dessa anvisningar i stället för från en gammal kopierad installationsfil.
På många Linux-system är konfigurationen /etc/tor/torrc. Ange ett särpräglat smeknamn och en övervakad projektkontaktadress, och konfigurera sedan relärollen uttryckligen. Håll hanteringsvägen åtskild från reläets offentliga lyssnare.
Använd en uttrycklig icke-exit-konfiguration
Följande är en illustrativ icke-exit-skiss, inte ett komplett installationsskript. Ersätt kontakten med en adress som du övervakar och välj hastighetsvärden som passar abonnemanget. Den visade .invalid-adressen är en platshållare och kan inte ta emot operatörsmeddelanden.
Validera konfigurationen och granska startdiagnostiken. Bekräfta att reläporten är åtkomlig och att noden så småningom visas i den offentliga katalogen. Ett nytt relä kan till en början bära lite trafik medan dess kapacitet och tillförlitlighet utvärderas; undvik att upprepade gånger ändra dess identitet bara för att tvinga fram aktivitet.
Nickname SilentNode
ORPort 9001
ContactInfo [email protected]
RelayBandwidthRate 1 MBytes
RelayBandwidthBurst 2 MBytes
ExitRelay 0
SocksPort 0En brygga behöver en transport och noggrann distribution
En obfs4-brygga döljer sitt trafikmönster för att hjälpa användare att kringgå filtrering. Följ den aktuella distributionsspecifika bryggguiden för dess pluggbara transportpaket; implementationsprojektet för obfs4 heter nu lyrebird. Konfigurera transportlyssnaren, testa åtkomligheten och hämta bryggans anslutningsinformation.
Publicera inte en privat brygglinje urskillningslöst. Använd den dokumenterade distributionsmekanismen eller dela den med de avsedda användarna. Att omvandla ett offentligt känt relä till en brygga utan att ändra identifierande detaljer kan göra bryggan lättare att upptäcka och blockera.
Deklarera gemensamt ägande och upprätthåll kontakt
Om du kör flera reläer, redovisa deras delade kontroll genom den aktuella Tor-familjemekanismen så att klienter kan undvika att välja dina noder i flera kretspositioner. Nuvarande vägledning använder FamilyID; äldre MyFamily-exempel bör inte behandlas som aktuella konfigurationsanvisningar.
En övervakad ContactInfo-adress gör att andra operatörer kan rapportera problem utan att behöva din borgerliga identitet. Håll säkerhetsuppdateringar aktuella, men förstå hur tjänsteomstarter och paketändringar påverkar noden. Använd bandbredds- och redovisningsinställningar avsiktligt i stället för att låta ett relä oväntat förbruka hela planen.
- Kontrollera den aktuella familjekonfigurationen för drift med flera reläer.
- Övervaka den dedikerade kontaktbrevlådan.
- Granska uppdateringar och åtkomlighet efter en omstart.
- Håll privata övervakningsdetaljer lämpligt begränsade.
- Välj överföringsredovisning som matchar leverantörens fakturering.
Behandla exit-reläer som ett separat driftsättningsbeslut
Exit-trafik kan generera klagomål och blockering hos destinationer. Innan du aktiverar en exit, säkerställ uttryckligt leverantörstillstånd, en övervakad missbruksprocess, lämplig dedikerad infrastruktur och en välgrundad förståelse för tillämpliga skyldigheter. Byt inte ett befintligt relä till exit-läge bara för att öka dess användbarhet.
En icke-exit-relä eller brygga bidrar redan med användbar kapacitet. Dess lägre exponering för klagomål från destinationer tar inte bort behovet av underhåll eller tillstånd. Den offentliga SilentVPS webbplatsen kan inte ersätta en bekräftad driftsprincip när produktionsinfrastruktur blir tillgänglig.
Bevara en välmående relä över tid
Kontrollera katalogstatus, genomströmning, klocksynkronisering, minne och den valda lyssnaren efter ändringar. Ett privat övervakningssystem hjälper till att upptäcka avbrott utan att publicera känsliga finmaskiga trafikmönster. Förvara säkerhetskopior av konfiguration och identitetsnycklar på en säker plats.
Om du migrerar, bevara lämpligt identitetsmaterial så att noden inte behöver bygga upp hela sin historia på nytt; verifiera aktuell migreringsvägledning innan du kopierar filer. Kör aldrig oavsiktliga dubblerade instanser av samma identitet. Stabil, välunderhållen kapacitet gynnar nätverket mer än frekventa experiment på en aktiv nod.