Proxy SOCKS5 dla OpenVPN: tunel TCP czy proxy dla aplikacji?

Proxy przekazuje strumień, nie datagram. Porównaj tunel TCP za socks-proxy z przekierowaniem redsocks i zobacz, gdzie każdy projekt zawodzi najpierw.

Sieci, które pozwalają na ruch wychodzący tylko przez proxy, to miejsce, gdzie działający profil nagle umiera. Adres proxy jest najmniej ciekawą zmienną w tej awarii. Wszystko rozstrzyga kształt ruchu, który proxy będzie przekazywać, bo te proxy przenoszą strumień bajtów, a tunel UDP nim nie jest. Zostają dwie architektury, i psują się w różnych miejscach.

Jedno ograniczenie decyduje o projekcie

SOCKS5 rzeczywiście określa tryb skojarzenia UDP. Wsparcie proxy w kliencie OpenVPN jest jednak zbudowane wokół strumieni: socks-proxy jest udokumentowany dla profili TCP, a proxy HTTP CONNECT nie ma żadnej ścieżki dla datagramów. Jedna linia dokumentacji rozstrzyga architekturę, zanim dotkniesz pliku konfiguracyjnego.

Pytanie więc nie brzmi, które proxy wybrać. Brzmi, czy tunel staje się strumieniem, czy pozostaje datagramem i pozwala czemuś innemu przejąć proxowanie.

Opcja A: zamień tunel w strumień

To wymaga serwera z nasłuchiwaczem TCP i profilu klienta, który nazywa proxy. Oba elementy są konieczne, a strona serwera to ta, o której ludzie zapominają:

proto tcp-client
remote vpn.example.net 443
socks-proxy 127.0.0.1 1080

Zastąp ostatnią linię przez http-proxy proxy.internal 8080, gdy proxy mówi po HTTP, i dodaj plik danych logowania, jeśli go wymaga. Proxy musi być gotowe wykonać CONNECT na twój port VPN, a serwer musi odpowiadać po TCP; nasłuchiwacz tylko UDP ignoruje tę próbę. Wybór 443 to praktyczny ruch, bo wiele restrykcyjnych sieci pozwala na niego i niewiele więcej.

Koszt to TCP ułożone na TCP. Jeden utracony zewnętrzny segment blokuje każdy wewnętrzny strumień dzielący to połączenie, więc odzyskiwanie, które normalnie byłoby niezależne, staje się wspólne. Konfiguracja trwa też dłużej, a niestabilna zewnętrzna ścieżka staje się niestabilnym tunelem, a nie wolnym.

Opcja B: zostaw tunel w spokoju

Gdy tunel musi zostać na UDP, tunel nie jest miejscem, w którym coś konfigurujesz. Zamiast tego wychodzący TCP z aplikacji jest przekierowywany do lokalnego nasłuchiwacza SOCKS, a aplikacje nigdy nie dowiadują się, że proxy istnieje. W Linuksie to zwykle redsocks plus reguła NAT REDIRECT w tabeli nat.

Znów tylko TCP. Proxy tylko HTTP, jak privoxy, nie potrafi przekazywać dowolnych protokołów, a ten projekt nie dodaje też obsługi datagramów dla aplikacji.

Powiedzenie każdej aplikacji o proxy bezpośrednio jest zwykle lepsze tam, gdzie oprogramowanie to obsługuje. Łatwiej to audytować, a zawodzi w miejscu, które naprawdę widzisz.

Gdzie zawodzi każda opcja

Opcja A zawodzi, gdy serwer nie ma nasłuchiwacza TCP, gdy proxy odmawia celu CONNECT lub gdy zewnętrzny strumień jest dławiony poniżej tego, czego potrzebuje tunel. Pierwsze dwa zostawiają wpis w logu proxy; trzeci zostawia połączenie, które się nawiązuje, a potem wydaje się złe. Przeczytaj ten log przed edycją profilu, bo oddziela problem uprawnień od problemu wydajności. Zakończony CONNECT przenosi śledztwo do wnętrza tunelu.

Opcja B zawodzi dla wszystkiego, co wymaga datagramów, dla protokołów, których proxy nie rozumie, i po cichu na hostach, gdzie reguła przekierowania istnieje, ale routing wysyła ruch obok niej.

Żadna opcja nie zmienia wymagania dotyczącego urządzenia. Pakiety nadal potrzebują węzła TUN lub TAP, zanim jądro je rozroutuje, więc proces nadal potrzebuje uprawnień do /dev/net/tun. Otoczka zmienia to, co dzieje się po otwarciu tego węzła, a nie to, czy go potrzebujesz.

Udowodnij, którą ścieżkę zbudowałeś

Patrz na gniazda, a nie na ikonę w zasobniku. Proces VPN powinien utrzymywać nawiązane połączenie z adresem proxy, a proxy powinien był zapisać cel, do którego poproszono go dotrzeć:

ss -tnp | grep openvpn

Potem sięgnij do miejsca docelowego, które może obsłużyć tylko tunel, i do nazwy, na którą może odpowiedzieć tylko resolver tunelu. Zakończone połączenie przez proxy przy martwym tunelu zwykle oznacza, że drugi koniec nigdy nie zaproponował transportu wskazanego w twoim profilu.

Zapisz transport i akceptujące proxy w trwałym miejscu. Gdy ten sam profil zawiedzie w innej sieci, ta notatka wyklucza lub potwierdza proxy w kilka sekund.

Powiązane artykuły