Redsocks nasłuchuje na loopbacku, ale ruch VPN nigdy nie dochodzi

Tunel się podnosi, klient może pingować bramę, a każde żądanie sieciowe przez ścieżkę proxy umiera. Proces redsocks działa, a jego port nasłuchuje, więc usługa wygląda zdrowo z samej bramy. Zawodzi etap dostarczania: pakiet przekierowany z tunelu nie ląduje na gnieździe, które uruchomiłeś. Adres powiązania i cel przekierowania muszą się zgadzać, a zwykle sprawdza się tylko jeden z nich.

Gdzie faktycznie ląduje przekierowany pakiet

Przezroczysty proxy na bramie używa REDIRECT w tabeli nat w PREROUTING, aby przepisać miejsce docelowe połączenia przychodzącego na port lokalny. Przepisane miejsce docelowe to adres lokalny widziany z interfejsu, na który pakiet przyszedł, a nie adres loopback procesu uruchomionego gdzie indziej. Nasłuchujący związany tylko z 127.0.0.1 akceptuje połączenia, które już były lokalne na hoście, i to jest dokładnie ten przypadek, który nadal działa, gdy ruch tunelu zawodzi. Własny loopback klienta to trzeci adres i nigdy nie jest celem reguły bramy.

Dlatego zanim dotkniesz danych logowania wyższej warstwy, ustal dwa fakty: na który adres lokalny reguła przepisuje i do którego adresu przypisane jest gniazdo proxy.

Czytaj nasłuchujący i regułę przekierowania razem

Wydrukuj tabelę gniazd i reguły nat w jednym przebiegu, ponieważ reguła wskazująca port, którego nikt nie posiada, wygląda identycznie jak reguła wskazująca zły adres. sudo ss -ltnp | grep redsocks pokazuje adres powiązania i proces będący właścicielem. sudo iptables -t nat -S PREROUTING pokazuje cel REDIRECT, a sudo iptables -t nat -L PREROUTING -v -n pokazuje, czy coś do niego pasowało.

Skok do łańcucha użytkownika o nazwie REDSOCKS nic nie osiąga, jeśli ten łańcuch nie istnieje i nie niesie zamierzonych wykluczeń oraz akcji REDIRECT. Czytaj łańcuch, do którego skacze, poleceniem sudo iptables -t nat -S REDSOCKS, zamiast zakładać, że nazwa wykonuje pracę.

Następnie porównaj obie wartości. Jeśli reguła przekierowuje na adres bramy na porcie 12345, a nasłuchujący zgłasza 127.0.0.1:12345, niezgodność wyjaśnia awarię bez żadnej dalszej diagnostyki.

Wiąż wąsko, a potem ogranicz, co może do niego dotrzeć

Przykładowa konfiguracja wyższej warstwy domyślnie umieszcza nasłuchujący na loopbacku z dobrego powodu: przezroczysty proxy akceptuje połączenia w imieniu każdego, kto może do niego dotrzeć. Zmiana powiązania na 0.0.0.0 naprawia dostarczanie i jednocześnie otwiera port na każdym interfejsie, co jest zmianą bezpieczeństwa, a nie neutralną naprawą. Wolę wiązanie z konkretnym adresem lokalnym, który obiera przekierowanie, i trzymaj port zamknięty na niezaufanych interfejsach. Jeśli szersze powiązanie jest nieuniknione, dodaj regułę zapory hosta, która zezwala tylko na zakres źródłowy tunelu i własny ruch lokalny bramy.

Otwieranie portu na publicznym interfejsie nigdy nie jest potrzebne dla przekierowanego ruchu VPN, ponieważ połączenie kończy się lokalnie po przepisaniu. Nie wystawiaj proxy do internetu, aby działało lokalne przekierowanie.

Udowodnij to nowym połączeniem z klienta

Testuj z prawdziwego klienta VPN nowym połączeniem TCP, a nie z powłoki na bramie. curl -sS -o /dev/null -w '%{http_code}\n' http://example.com na kliencie przechodzi przekierowaną ścieżkę od początku do końca.

Następnie potwierdź, że bezpośrednie połączenie z nasłuchującym z niezaufanej sieci nadal jest odrzucane, a połączenie wychodzące samego proxy nie jest ponownie przechwytywane przez tę samą regułę. Rekurencyjne przechwytywanie objawia się jako proxy, które łączy się samo ze sobą i nigdy nie kończy żądania. Dodaj cel proxy do zbioru wykluczeń lub oznacz jego pakiety wychodzące, aby łańcuch je pomijał.

Na koniec pamiętaj, czego ta ścieżka nie obejmuje. Zwykłe przekierowanie TCP w redsocks nie zamienia UDP, QUIC ani DNS w ruch SOCKS, a cele prywatne zwykle wymagają jawnych wykluczeń. Udany test lokalny dowodzi tylko ścieżki loopback, która nigdy nie była problemem.