Redsocks poslouchá na loopbacku, ale provoz VPN nikdy nedorazí

Tunel se zvedne, klient dokáže pingnout bránu a každý webový požadavek přes cestu proxy zemře. Proces redsocks běží a jeho port naslouchá, takže služba vypadá zdravě přímo z brány. Selhává krok doručení: paket přesměrovaný z tunelu nedopadne na socket, který jste spustili. Adresa vazby a cíl přesměrování se musí shodovat, a obvykle se kontroluje jen jedno z toho.

Kam přesměrovaný paket skutečně dopadne

Transparentní proxy na bráně používá REDIRECT v tabulce nat v PREROUTING k přepsání cíle příchozího spojení na místní port. Přepsaný cíl je místní adresa viděná z rozhraní, na kterém paket dorazil, nikoli adresa loopbacku procesu spuštěného někde jinde. Posluchač vázaný pouze na 127.0.0.1 přijímá spojení, která už byla na hostiteli místní, a to je právě případ, který dál funguje, zatímco provoz tunelu selhává. Vlastní loopback klienta je třetí adresa a nikdy není cílem pravidla brány.

Proto než se dotknete přihlašovacích údajů proti proudu, zjistěte dvě skutečnosti: na kterou místní adresu pravidlo přepisuje a na kterou adresu je vázán socket proxy.

Čtěte posluchač a pravidlo přesměrování společně

Vypište tabulku socketů a pravidla nat v jednom průchodu, protože pravidlo ukazující na port, který nikdo nevlastní, vypadá stejně jako pravidlo ukazující na špatnou adresu. sudo ss -ltnp | grep redsocks ukazuje adresu vazby a vlastnící proces. sudo iptables -t nat -S PREROUTING ukazuje cíl REDIRECT a sudo iptables -t nat -L PREROUTING -v -n ukazuje, zda mu něco odpovídalo.

Skok do uživatelského řetězce jménem REDSOCKS nic nedokáže, pokud tento řetězec neexistuje a nenese zamýšlené výjimky a akci REDIRECT. Čtěte řetězec, do kterého skáče, pomocí sudo iptables -t nat -S REDSOCKS, místo abyste předpokládali, že jméno dělá práci.

Potom porovnejte obě hodnoty. Pokud pravidlo přesměrovává na adresu brány na portu 12345 a posluchač hlásí 127.0.0.1:12345, nesoulad vysvětluje selhání bez další diagnostiky.

Važte úzce a pak určete, co se k němu dostane

Vzorová konfigurace proti proudu dává posluchač na loopback z dobrého důvodu: transparentní proxy přijímá spojení jménem kohokoli, kdo se k němu dostane. Změna vazby na 0.0.0.0 opraví doručení a zároveň otevře port na všech rozhraních, což je bezpečnostní změna, ne neutrální oprava. Dávejte přednost vazbě na konkrétní místní adresu, kterou přesměrování cílí, a držte port zavřený na nedůvěryhodných rozhraních. Pokud je širší vazba nevyhnutelná, přidejte pravidlo hostitelského firewallu, které povolí jen rozsah zdroje tunelu a vlastní místní provoz brány.

Otevírání portu na veřejném rozhraní není pro přesměrovaný provoz VPN nikdy nutné, protože spojení po přepsání končí lokálně. Nevystavujte proxy internetu, aby místní přesměrování fungovalo.

Dokažte to novým spojením z klienta

Testujte ze skutečného klienta VPN s novým TCP spojením, ne z shellu na bráně. curl -sS -o /dev/null -w '%{http_code}\n' http://example.com na klientovi procvičí přesměrovanou cestu od začátku do konce.

Poté potvrďte, že přímé spojení k posluchači z nedůvěryhodné sítě je stále odmítáno a že odchozí spojení samotné proxy není znovu zachyceno stejným pravidlem. Rekurzivní zachycení se projeví jako proxy, která se připojuje sama k sobě a nikdy nedokončí požadavek. Přidejte cíl proxy do množiny výjimek nebo označte jeho odchozí pakety, aby je řetězec přeskočil.

Nakonec pamatujte, co tato cesta nepokrývá. Běžné přesměrování TCP v redsocks nemění UDP, QUIC ani DNS na provoz SOCKS a soukromé cíle obvykle vyžadují výslovné výjimky. Úspěšný místní test dokazuje jen cestu přes loopback, která nikdy nebyla problémem.