Redsocks počúva na loopbacku, ale prevádzka VPN nikdy nedorazí

Tunel sa zdvihne, klient dokáže pingnúť bránu a každá webová požiadavka cez cestu proxy zomrie. Proces redsocks beží a jeho port počúva, takže služba vyzerá zdravo priamo z brány. Zlyháva krok doručenia: paket presmerovaný z tunela nedopadne na socket, ktorý ste spustili. Adresa väzby a cieľ presmerovania sa musia zhodovať, a zvyčajne sa kontroluje len jedno z toho.

Kam presmerovaný paket skutočne dopadne

Transparentná proxy na bráne používa REDIRECT v tabuľke nat v PREROUTING na prepísanie cieľa prichádzajúceho spojenia na lokálny port. Prepísaný cieľ je lokálna adresa videná z rozhrania, na ktoré paket prišiel, nie adresa loopbacku procesu spusteného inde. Prijímač viazaný len na 127.0.0.1 prijíma spojenia, ktoré už boli na hostiteľovi lokálne, a to je práve prípad, ktorý ďalej funguje, kým prevádzka tunela zlyháva. Vlastný loopback klienta je tretia adresa a nikdy nie je cieľom pravidla brány.

Preto predtým, než sa dotknete prihlasovacích údajov na vyššej úrovni, zistite dve skutočnosti: na ktorú lokálnu adresu pravidlo prepisuje a na ktorú adresu je viazaný socket proxy.

Čítajte prijímač a pravidlo presmerovania spolu

Vypíšte tabuľku socketov a pravidlá nat v jednom prechode, pretože pravidlo ukazujúce na port, ktorý nikto nevlastní, vyzerá rovnako ako pravidlo ukazujúce na nesprávnu adresu. sudo ss -ltnp | grep redsocks ukazuje adresu väzby a vlastniaci proces. sudo iptables -t nat -S PREROUTING ukazuje cieľ REDIRECT a sudo iptables -t nat -L PREROUTING -v -n ukazuje, či mu niečo zodpovedalo.

Skok do používateľského reťazca s názvom REDSOCKS nič nedosiahne, ak tento reťazec neexistuje a nenesie zamýšľané výnimky a akciu REDIRECT. Čítajte reťazec, do ktorého skáče, pomocou sudo iptables -t nat -S REDSOCKS, namiesto toho, aby ste predpokladali, že názov robí prácu.

Potom porovnajte obe hodnoty. Ak pravidlo presmerúva na adresu brány na porte 12345 a prijímač hlási 127.0.0.1:12345, nesúlad vysvetľuje zlyhanie bez ďalšej diagnostiky.

Viažte úzko a potom obmedzte, čo sa k tomu dostane

Vzorová konfigurácia na vyššej úrovni dáva prijímač na loopback z dobrého dôvodu: transparentná proxy prijíma spojenia v mene kohokoľvek, kto sa k nej dostane. Zmena väzby na 0.0.0.0 opraví doručenie a zároveň otvorí port na každom rozhraní, čo je bezpečnostná zmena, nie neutrálna oprava. Uprednostnite väzbu na konkrétnu lokálnu adresu, ktorú presmerovanie cieli, a držte port zatvorený na nedôveryhodných rozhraniach. Ak je širšia väzba nevyhnutná, pridajte pravidlo hostiteľského firewallu, ktoré povoľuje len rozsah zdroja tunela a vlastnú lokálnu prevádzku brány.

Otvorenie portu na verejnom rozhraní nie je pre presmerovanú prevádzku VPN nikdy potrebné, pretože spojenie po prepísaní končí lokálne. Nevystavujte proxy internetu, aby lokálne presmerovanie fungovalo.

Dokážte to novým spojením z klienta

Testujte zo skutočného klienta VPN s novým TCP spojením, nie z shellu na bráne. curl -sS -o /dev/null -w '%{http_code}\n' http://example.com na klientovi prejde presmerovanou cestou od začiatku do konca.

Potom potvrďte, že priame spojenie k prijímaču z nedôveryhodnej siete je stále odmietané a že odchádzajúce spojenie samotnej proxy nie je znovu zachytené tým istým pravidlom. Rekurzívne zachytenie sa prejaví ako proxy, ktorá sa pripája sama k sebe a nikdy nedokončí požiadavku. Pridajte cieľ proxy do množiny výnimiek alebo označte jej odchádzajúce pakety, aby ich reťazec preskočil.

Nakoniec pamätajte, čo táto cesta nepokrýva. Bežné presmerovanie TCP v redsocks nemení UDP, QUIC ani DNS na prevádzku SOCKS a súkromné ciele zvyčajne vyžadujú výslovné výnimky. Úspešný lokálny test dokazuje len cestu cez loopback, ktorá nikdy nebola problémom.