Routing polityk a SOCKS: która warstwa naprawdę proxuje ruch

Dodałeś trasę polityki, która wysyła ruch klienta VPN do hosta uruchamiającego nasłuch SOCKS na porcie 1080. Pakiety docierają, nasłuch nic nie zapisuje, a połączenie wisi. Z trasą nie ma nic złego: następny skok wybiera, dokąd idzie pakiet, a SOCKS to rozmowa, którą musi rozpocząć klient. Porównaj trzy architektury, które ludzie zwykle mają na myśli, wysyłając ruch przez proxy, i stanie się jasne, którego elementu brakuje w twojej konfiguracji.

Routing, DNAT i SOCKS zmieniają różne rzeczy

Trasa polityki przepisuje decyzję warstwy 3. Dwie linie wystarczą, aby wysłać ruch jednego klienta do wybranego następnego skoku:

ip route add default via 10.50.0.2 table 101
ip rule add from 10.77.0.2 lookup 101

Następnie jądro przekazuje pakiet do 10.50.0.2, a pierwotne miejsce docelowe wciąż jest w nagłówku IP. Jeśli 10.50.0.2 jest routerem, przekazuje pakiet dalej. Jeśli jest hostem z demonem SOCKS na 1080, pakiet nie jest zaadresowany do niczego, co mogłoby go przyjąć, a DNAT na port 1080 też nie pomoże, bo przetłumaczony pakiet nadal niesie pierwotny ładunek aplikacji zamiast powitania SOCKS.

SOCKS5 zaczyna się bajtem wersji, listą metod, wymianą uwierzytelniania i żądaniem, które nazywa cel. To dane aplikacji. Żaden wpis routingu ani cel netfilter ich nie generuje, i to jest porównanie w jednej linii: routing wybiera ścieżkę, SOCKS prosi serwer o utworzenie drugiego połączenia.

Przypadek pierwszy: aplikacja sama potrafi mówić SOCKS

Gdy program ma ustawienie proxy, to najkrótsza droga i nie wymaga zmian w jądrze. Wskaż je na nasłuch, podaj dane logowania, jeśli serwer o nie poprosi, i zdecyduj, czy nazwy są rozwiązywane lokalnie, czy przekazywane proxy. W curl to różne flagi, a różnica ma znaczenie, gdy cel jest rozwiązywany tylko po stronie proxy:

curl --socks5 10.50.0.2:1080 https://docs.example.com
curl --socks5-hostname 10.50.0.2:1080 https://internal.example.com

Aplikacje, które ignorują zmienne środowiskowe proxy lub otwierają surowe gniazda, nie mogą być w ten sposób wsparte. Przeglądarki i większość narzędzi HTTP są w porządku; klient gry, demon poczty lub dowolny plik binarny dostawcy zwykle nie. Granica przebiega na aplikację i na protokół, dlatego ta opcja jest doskonała do testów i słaba jako odpowiedź dla całego VPN.

Przypadek drugi: adapter, który zamienia strumienie IP na sesje proxy

Dla programów, które nie potrafią mówić SOCKS, konwersja musi zachodzić w czymś, co kończy ruch IP i otwiera sesje proxy w ich imieniu. Ten komponent posiada interfejs tunelu, przyjmuje strumienie wybrane przez routing polityk, wykonuje uścisk dłoni SOCKS dla każdego z nich i odbudowuje odpowiedzi. Trasa kieruje ruch do niego; to adapter tworzy sesję.

Przeczytaj jego dokumentację, zanim powierzysz mu całą podsieć. Wiele adapterów dobrze przenosi TCP, a UDP obsługuje tylko przez asocjację UDP SOCKS5, i żaden z nich nie zamienia ICMP w ruch proxy, więc udany ping nic nie mówi o ścieżce proxy. DNS to druga pułapka: jeśli adapter rozwiązuje nazwy lokalnie, rekordy tylko wewnętrzne rozwiązują się na złą odpowiedź albo na nic.

Zapobieganie pętlom to ten szczegół operacyjny, który gryzie. Własne połączenia adaptera do serwera SOCKS nie mogą być rutowane z powrotem do adaptera, więc jego ruch potrzebuje wyjątku w regule albo osobnego adresu źródłowego. Zrób to źle, a sesja proxy spróbuje proxować samą siebie.

Przypadek trzeci: host jest w rzeczywistości rutowaną bramą

Czasami działająca konfiguracja nie zawiera w ogóle SOCKS. Zdalny host przekazuje pakiety lub wykonuje na nich NAT, a reguła oparta na źródle po prostu wybiera go jako wyjście. Ten projekt jest legalny i wyjaśnia, dlaczego skopiowana konfiguracja działa w jednej sieci, a w innej zawodzi: reguła jest identyczna, brakującym elementem jest usługa przekazywania po drugiej stronie.

Trzy przypadki rozdzielają się szybko. Sprawdź, co naprawdę nasłuchuje, a potem spójrz na pierwsze bajty docierające do hosta:

ss -ltnp 'sport = :1080'
tcpdump -ni eth0 -X 'tcp port 1080'

Pierwszy bajt ładunku prawdziwego klienta SOCKS to 0x05, wersja w powitaniu. Jeśli zrzut pokazuje zamiast tego pierwotne dane aplikacji, żaden demon SOCKS nie odpowie, bo negocjacje nigdy się nie zaczęły. Jeśli nic nie nasłuchuje na 1080, host jest bramą, a pytanie brzmi, czy przekazuje dalej i czy istnieje droga powrotna.

Wybierz warstwę czterema pytaniami

Czy program ma ustawienie proxy? Użyj go i na tym poprzestań. Czy ruch zawiera UDP lub ICMP, które muszą przetrwać? Tylko rutowana lub NAT-owa brama przenosi ICMP, a UDP wymaga asocjacji SOCKS5 obsługiwanej przez oba końce. Czy każdy proces na maszynie ma być objęty, łącznie z tymi, których nie możesz skonfigurować? Wtedy potrzebujesz adaptera, który posiada interfejs i kończy strumienie. Czy możesz przejąć także jego routing, DNS i wyjątki zapobiegania pętlom? Jeśli nie, zwykła brama będzie tańsza w utrzymaniu.

Jedno rozróżnienie warto utrzymać jasno. Własna opcja socks-proxy klienta VPN opisuje, jak zewnętrzne połączenie tunelu dociera do swojego serwera, i nic nie mówi o konwersji wewnętrznych strumieni klienta. Oba bywają ciągle mylone w tym samym zgłoszeniu. Zdecyduj, jakiej relacji potrzebujesz, zanim dotkniesz trasy.