Tor gotowy przed VPN: właściwa kolejność bramki startowej

Działający proces tor nie jest nośnikiem. Zbinduj VPN na udokumentowanym sygnale gotowości klienta, potem na jego własnym partnerze, i trzymaj ścieżki zapasowe osobno.

Obserwowanie procesu tor, a następnie uruchamianie VPN to najczęstszy sposób na błędne zbudowanie tego stosu. Demon pojawia się długo zanim może przenosić strumień klienta, a stałe oczekiwanie to domysł przebrany za zależność. Bramka musi być stanem, którego naprawdę potrzebuje następny komponent. Przejdź przez cztery kroki poniżej po kolei i traktuj każdy jako osobny warunek, a nie jako opóźnienie do dostrojenia.

Krok 1: wybierz transport, który naprawdę masz

Zacznij od protokołu, bo reszta projektu od niego zależy. Interfejs SOCKS w Torze nie implementuje UDP ASSOCIATE, więc wszystko, co przez niego przechodzi, musi być strumieniem TCP. Profil OpenVPN używający UDP nie zadziała tą drogą, niezależnie od tego, jak napisany jest nadzorca. Przełącz profil na TCP i potwierdź, że zdalny partner go akceptuje, zanim dotkniesz logiki uruchamiania.

Potem potwierdź, że twój klient w ogóle dociera do proxy SOCKS. OpenVPN 2.6 dokumentuje opcję socks-proxy dla profili TCP, a różne klienty oferują różne wsparcie proxy. Launcher, który po cichu ignoruje opcję proxy, połączy się bezpośrednio i będzie wyglądał na działający, co jest gorsze od porażki.

Zapisz wybrany transport w runbooku, bo każde późniejsze sprawdzenie od niego zależy.

Krok 2: czytaj fazę bootstrap, a nie listę procesów

Protokół sterowania Tora odpowiada na GETINFO status/bootstrap-phase najnowszym stanem bootstrap, w tym procentem postępu i tagiem podsumowania. Ta odpowiedź jest przydatna właśnie dlatego, że kontroler może się podłączyć po tym, jak demon zakończył już bootstrap. Nadzorca, który słucha tylko zdarzeń, przegapi przypadek, w którym Tor był gotowy przed startem nadzorcy.

Uwierzytelnij poprawnie połączenie sterujące. Port sterowania to interfejs administracyjny i każdy, kto może z nim rozmawiać, może przekonfigurować demona. Trzymaj go na localhost, pozostaw włączone uwierzytelnianie ciasteczkiem lub hasłem i nie usuwaj żadnego z nich, żeby uprościć skrypt startowy.

Odczytaj fazę raz przy starcie, a potem subskrybuj zdarzenia postępu do widoku na żywo.

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

Odpowiedź z postępem 100 i tagiem done oznacza, że demon zakończył własny start. To jeszcze nie oznacza, że istnieje użyteczny obwód do twojego celu.

Krok 3: czekaj na zdarzenie obwodu klienta

Protokół zdarzeń Tora definiuje CIRCUIT_ESTABLISHED, który zgłasza, że klient ma obwód, którego może użyć. To sygnał gotowości, którego chce bramka nośnika, bo jest bliżej potrzebnej zdolności niż procent. Subskrybuj zdarzenie i zapisz przejście, żeby log pokazywał, kiedy nośnik stał się użyteczny, a nie kiedy pojawił się proces.

Traktuj zdarzenie jako zgodę na próbę, a nie jako gwarancję dla konkretnego celu. Polityka wyjścia nadal może odrzucić zdalnego partnera, a sam uścisk dłoni VPN nadal może się nie udać z powodów, które nie mają nic wspólnego z Torem.

Trzymaj oba warunki osobno w kodzie. Jedna wartość logiczna o nazwie ready scali je i uczyni następny incydent nieczytelnym.

Krok 4: zbinduj VPN na jego własnym uścisku dłoni

VPN ma własny warunek gotowości i tylko on dowodzi, że tunel wstał. Poczekaj, aż klient zgłosi stan połączenia z przypisanym adresem, a potem sprawdź, czy wymóg proxy pozostał w mocy. Pętla ponowień, która po jednej porażce porzuca opcję socks-proxy, połączy się bezpośrednio i po cichu pokona cały projekt.

Zdecyduj, co się dzieje, gdy partner jest nieosiągalny, zanim będziesz musiał to wiedzieć. Ograniczone ponawianie z widoczną porażką jest łatwiejsze w utrzymaniu niż nieskończona pętla i daje systemowi monitoringu coś do alarmowania. Ta sama decyzja dotyczy nośnika: jeśli Tor się restartuje, VPN trzeba zdemontować i ponownie zbindować, a nie zostawiać go na martwym obwodzie.

Na koniec utrzymuj własną politykę aplikacji, gdy VPN jest wyłączony. Nadzorca, który czeka poprawnie, nie robi nic, żeby powstrzymać niezależny proces przed wysyłaniem ruchu bezpośrednio.

Sprawdź cztery przejścia, które musisz przetrwać

Cztery przypadki pokrywają projekt: zimny start, w którym Tor wstaje pierwszy, nadzorca dołączający do już gotowego Tora, niedostępny partner VPN i utrata nośnika, gdy tunel jest w górze. Każdy ma inne oczekiwane przejście i każdy daje inną linię logu, jeśli bramka jest napisana poprawnie.

Uruchamiaj je celowo, po jednym, i czytaj zmiany stanu, a nie listę procesów.

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

Gdy nośnik pada, VPN powinien podążyć za nim w dół w ciągu jednego interwału ponowień, a nie zostawać z przestarzałym tunelem. Gdy Tor wraca, bramka powinna się otworzyć dopiero po zdarzeniu obwodu, a nie po starcie procesu. Zapisuj, którego warunku brakowało przy każdej porażce, a następna osoba na dyżurze nie będzie musiała odtwarzać kolejności ze znaczników czasu.

Powiązane artykuły