Tor klart före VPN:en: rätt ordning på startporten

Att titta efter en tor-process och sedan starta VPN:en är det vanligaste sättet att bygga den här stacken fel. Daemonen dyker upp långt innan den kan bära en klientström, och en fast väntetid är en gissning utklädd till beroende. Porten måste vara det tillstånd som nästa komponent faktiskt behöver. Gå igenom de fyra stegen nedan i ordning och behandla varje steg som ett eget villkor i stället för en fördröjning att justera.

Steg 1: välj den transport du faktiskt har

Börja med protokollet, eftersom resten av designen beror på det. Tors SOCKS-gränssnitt implementerar inte UDP ASSOCIATE, så allt som bärs över det måste vara en TCP-ström. En OpenVPN-profil som använder UDP fungerar inte den här vägen, oavsett hur övervakaren är skriven. Byt profilen till TCP och bekräfta att den fjärran partnern accepterar den innan du rör startlogiken.

Bekräfta sedan att din klient över huvud taget kan nå en SOCKS-proxy. OpenVPN 2.6 dokumenterar ett socks-proxy-alternativ för TCP-profiler, och olika klienter erbjuder olika proxy-stöd. En startare som tyst ignorerar proxy-alternativet ansluter direkt och ser ut att fungera, vilket är sämre än att misslyckas.

Skriv den valda transporten i runbooken, eftersom varje senare kontroll beror på den.

Steg 2: läs bootstrap-fasen, inte processlistan

Tors kontrollprotokoll svarar på GETINFO status/bootstrap-phase med det senaste bootstrap-tillståndet, inklusive en förloppsprocent och en sammanfattningstagg. Det svaret är användbart just därför att en kontrollant kan ansluta efter att daemonen redan har slutfört bootstrap. En övervakare som bara lyssnar på händelser missar fallet där Tor redan var klart innan övervakaren startade.

Autentisera kontrollanslutningen ordentligt. En kontrollport är ett administrativt gränssnitt, och den som kan prata med den kan konfigurera om daemonen. Håll den på localhost, håll cookie- eller lösenordsautentisering aktiverad, och ta inte bort någon av dem för att göra ett startskript enklare.

Läs fasen en gång vid start och prenumerera sedan på förloppshändelser för livevyn.

printf 'AUTHENTICATE\r\nGETINFO status/bootstrap-phase\r\nQUIT\r\n' | nc 127.0.0.1 9051
ss -ltn | grep -E '9050|9051'
tor --verify-config -f /etc/tor/torrc

Ett svar med förlopp 100 och taggen done betyder att daemonen har slutfört sin egen start. Det betyder ännu inte att det finns en användbar krets till din destination.

Steg 3: vänta på en klientkretshändelse

Tors händelseprotokoll definierar CIRCUIT_ESTABLISHED, som rapporterar att klienten har en krets som den kan använda. Det är den beredskapssignal som en bärarport vill ha, eftersom den ligger närmare den förmåga du behöver än en procentandel gör. Prenumerera på händelsen och registrera övergången, så att loggen visar när bäraren blev användbar och inte när processen dök upp.

Behandla händelsen som tillstånd att försöka, inte som en garanti för en viss destination. En utgångspolicy kan fortfarande avvisa den fjärran partnern, och VPN:ens egen handskakning kan fortfarande misslyckas av skäl som inte har något med Tor att göra.

Håll de två villkoren åtskilda i koden. En enda boolesk variabel som heter ready slår ihop dem och gör nästa incident oläsbar.

Steg 4: låt VPN:en styras av sin egen handskakning

VPN:en har sitt eget beredskapsvillkor, och bara det bevisar att tunneln kom upp. Vänta tills klienten rapporterar ett anslutet tillstånd med en tilldelad adress, och kontrollera sedan att proxy-kravet stod kvar. En återförsöksslinga som släpper socks-proxy-alternativet efter ett misslyckande ansluter direkt och besegrar tyst hela designen.

Bestäm vad som händer när partnern inte är nåbar innan du behöver veta det. Ett begränsat återförsök med ett synligt misslyckande är lättare att driva än en oändlig slinga, och det ger övervakningssystemet något att larma på. Samma beslut gäller för bäraren: om Tor startar om måste VPN:en rivas och föras genom porten igen i stället för att lämnas kvar på en död krets.

Håll slutligen applikationens egen policy på plats medan VPN:en är nere. En övervakare som väntar korrekt gör ingenting för att hindra en orelaterad process från att skicka trafik direkt.

Kontrollera de fyra övergångar du måste överleva

Fyra fall täcker designen: en kallstart där Tor kommer upp först, en övervakare som ansluter till en redan klar Tor, en otillgänglig VPN-partner och förlust av bäraren medan tunneln är uppe. Var och en har en annan förväntad övergång, och var och en ger en annan logglinje om porten är rätt skriven.

Kör dem med avsikt, en i taget, och läs tillståndsändringarna i stället för processlistan.

journalctl -u tor@default -n 30 --no-pager
systemctl status [email protected]
curl -sS --socks5-hostname 127.0.0.1:9050 https://check.torproject.org/api/ip

När bäraren faller bör VPN:en följa den ned inom ett återförsöksintervall i stället för att hänga kvar med en föråldrad tunnel. När Tor kommer tillbaka bör porten bara öppnas igen efter kretshändelsen, inte efter processens start. Logga vilket villkor som saknades vid varje misslyckande, och nästa person på jour behöver inte rekonstruera ordningen från tidsstämplar.