Przekaźnik Tor a serwer VPN: dlaczego nie są wymienne

Otwarty port na przekaźniku Tor nie jest punktem końcowym VPN. Najpierw sprawdź, czemu służy port, rolę przekaźnika, zasięg nasłuchu SOCKS i profil.

Masz adres, port odpowiada, a klient akceptuje go bez żadnych skarg. Nic z tego nie czyni przekaźnika Tor punktem końcowym VPN, a błąd jest kosztowny, bo profil importuje się czysto i dopiero później zawodzi na uzgadnianiu. Używam czterech kontroli poniżej po kolei; każda ma warunek zatrzymania, a wczesne zatrzymanie jest właśnie sednem. Jeśli pierwsza kontrola zawiedzie, pozostałe nie mogą ci pomóc.

Sprawdź, czemu port faktycznie służy

Otwarty port dowodzi nasłuchu, niczego więcej. ORPort przekaźnika mówi własnymi komórkami Tora po uzgodnieniu TLS, więc udana próba TLS prawie nic nie mówi o tym, czy protokół VPN jest tam akceptowany:

nc -vz 203.0.113.20 443
openssl s_client -connect 203.0.113.20:443 -brief < /dev/null

Czytaj certyfikat, a nie sam fakt, że istnieje. Przekaźniki przedstawiają samopodpisany certyfikat z celowo niepozorną nazwą, ponieważ ruch przekaźnika ma przypominać zwykły HTTPS; certyfikat serwera VPN nosi nazwę, której oczekuje twój profil. Jeśli druga strona nigdy nie odpowiada na pierwszy pakiet protokołu VPN, żadna edycja profilu nie zmieni wyniku.

Zatrzymaj się tutaj, jeśli adres nie kończy uzgadniania, które wysyła twój klient. To odpowiedź protokołu, a nie problem konfiguracji, i to najczęstsza przyczyna, dla której zaimportowany profil trwale stoi na 'connecting'.

Sprawdź rolę przekaźnika, a nie rozmiar sieci

Role przekaźnika wykonują różną pracę. Guard to pierwszy skok dla klientów, przekaźnik środkowy przekazuje obwody między innymi przekaźnikami, exit dotyka miejsc docelowych, a most to niepubliczny punkt wejścia rozdawany przez BridgeDB. Słownik Tora trzyma te definicje osobno, a osiągalność jest częścią każdej roli, podczas gdy pozwolenie na obsługę dowolnych klientów nie jest częścią żadnej z nich.

Polityka exit jest warta przeczytania, bo to jedyna część przypominająca regułę przekazywania, i reguluje ona miejsca docelowe, do których exit pozwoli wyjść, a nie klientów, którym wolno wejść. Restrykcyjna polityka exit blokująca port 25 mówi coś o kontroli nadużyć wychodzących, a nie o tym, czy wolno skierować klienta OpenVPN na maszynę.

Zatrzymaj się, jeśli rozumujesz z reputacji: ponieważ przekaźniki przekazują ruch, adres musi akceptować twój. Tor wybiera ścieżki przez konsensus i własny protokół; klient VPN nie jest uczestnikiem i nie ma obwodu, do którego mógłby dołączyć.

Sprawdź, czy nasłuch SOCKS jest lokalny czy publiczny

Klient Tora udostępnia interfejs SOCKS aplikacjom na tej samej maszynie, domyślnie na loopbacku. Ten nasłuch jest lokalną wygodą, a nie usługą, którą przekaźnik oferuje internetowi, i traktowanie go jako publicznego proxy to droga, na której ludzie kończą z otwartym przekaźnikiem, którego nie zamierzali:

ss -ltnp | grep 9050
curl --socks5-hostname 127.0.0.1:9050 https://check.torproject.org

Adres przypisania jest wskazówką. SocksPort na 127.0.0.1:9050 robi swoje; ten, który nasłuchuje na 0.0.0.0 i jest osiągalny z zewnątrz, jest otwartym proxy, a własne kontrole polityki dostępu Tora istnieją właśnie dlatego, że takie wystawienie jest problemem, a nie funkcją.

Dla aplikacji, która potrzebuje Tora, wskaż port loopback i pozwól Torowi rozwiązywać nazwy, co robi forma socks5h powyżej. Nie zastępuj adresu przekaźnika tym portem; przekaźnik nie oferuje interfejsu, o który prosi twoja aplikacja.

Sprawdź, czy profil VPN pasuje do rzeczywistego punktu końcowego

Profil VPN to wiązka oczekiwań: OpenVPN potrzebuje certyfikatu serwera lub CA, certyfikatu klienta i klucza, a zwykle także klucza TLS, natomiast WireGuard potrzebuje klucza publicznego drugiej strony, punktu końcowego i dozwolonych adresów IP. Niczego z tego nie da się wyprowadzić z adresu i otwartego portu, dlatego tak zbudowany profil zawodzi przy pierwszej wymianie, a nie przy połączeniu.

Kiedy otrzymujesz profil, zweryfikuj go wobec punktu końcowego, który kontrolujesz, lub dostawcy, którego możesz zidentyfikować:

wg show
openvpn --config client.ovpn --verb 4

W logu OpenVPN błąd negocjacji TLS wprost nazywa niezgodność; w wg show druga strona bez linii uzgadniania nigdy nie ukończyła żadnej. Oba są bardziej pouczające niż kręcący się wskaźnik klienta, i oba wskazują na materiał klucza lub protokół, a nie na Tora.

Sprawdź, jakiej ochrony naprawdę potrzebujesz

To jest kontrola, która decyduje o architekturze. Przeglądarka Tor daje izolację obwodów i obronę przed odciskami palców, której VPN nie daje; VPN zmienia adres widziany przez cel i uwierzytelnia cię u dostawcy. Wybór między nimi jest kwestią modelu zagrożeń, a nie zgodności, a mieszanie ich daje konfigurację, która wygląda prywatnie i taka nie jest.

Łańcuch ma kolejność. VPN przenoszący ruch Tora to obsługiwany układ, ponieważ klient Tora potrzebuje tylko wychodzącego TCP. Klient VPN tunelowany wewnątrz Tora to nie to samo i nie to, co implementuje klient Tora, więc nie planuj na tym.

Zanim cokolwiek zaimportujesz, potwierdź wszystkie cztery:

  • Port kończy uzgadnianie twojego protokołu, a nie tylko połączenie TCP.
  • Znasz rolę hosta i nie traktujesz przekazywania jako pozwolenia.
  • Używany nasłuch SOCKS jest loopbackiem i twoim własnym, a nie publicznym portem na cudzym przekaźniku.
  • Klucze lub certyfikaty profilu należą do punktu końcowego, z którym się łączysz.

Powiązane artykuły