Redsocks sluša na loopbacku, ali VPN promet nikad ne stiže

Tunel se podigne, klijent može pingati gateway, a svaki web zahtjev kroz proxy put umire. Proces redsocks radi i njegov port sluša, pa usluga izgleda zdravo sa samog gatewaya. Ono što pada je korak dostave: paket preusmjeren s tunela ne slijeće na socket koji ste pokrenuli. Adresa vezanja i odredište preusmjeravanja moraju se slagati, a obično se provjerava samo jedno od njih.

Gdje preusmjereni paket zapravo slijeće

Transparentno proxy posredovanje na gatewayu koristi REDIRECT u nat tablici pod PREROUTING da prepiše odredište dolazne veze na lokalni port. Prepisano odredište je lokalna adresa viđena sa sučelja na koje je paket stigao, a ne loopback adresa procesa koji je pokrenut negdje drugdje. Slušatelj vezan samo na 127.0.0.1 prihvaća veze koje su već bile lokalne na hostu, i to je upravo slučaj koji nastavlja raditi dok promet kroz tunel pada. Klijentov vlastiti loopback je treća adresa i nikad nije odredište gatewayovog pravila.

Zato prije diranja vjerodajnica na uzvodnoj strani utvrdite dvije činjenice: na koju lokalnu adresu pravilo prepisuje i na koju je adresu vezan proxy socket.

Čitajte slušatelj i pravilo preusmjeravanja zajedno

Ispišite tablicu socketa i nat pravila u istom prolazu, jer pravilo koje pokazuje na port koji nitko ne posjeduje izgleda isto kao pravilo koje pokazuje na pogrešnu adresu. sudo ss -ltnp | grep redsocks prikazuje adresu vezanja i proces koji ju posjeduje. sudo iptables -t nat -S PREROUTING prikazuje odredište REDIRECT, a sudo iptables -t nat -L PREROUTING -v -n pokazuje je li se išta podudarilo s njim.

Skok na korisnički lanac nazvan REDSOCKS ne postiže ništa ako taj lanac ne postoji i ne nosi predviđena isključenja i radnju REDIRECT. Pročitajte lanac u koji skače pomoću sudo iptables -t nat -S REDSOCKS umjesto da pretpostavljate da ime obavlja posao.

Zatim usporedite dvije vrijednosti. Ako pravilo preusmjerava na gateway adresu na portu 12345, a slušatelj prijavljuje 127.0.0.1:12345, neslaganje objašnjava kvar bez ikakve daljnje dijagnostike.

Vežite usko, zatim ograničite što do njega može doći

Uzvodna primjerena konfiguracija po defaultu stavlja slušatelj na loopback s dobrim razlogom: transparentni proxy prihvaća veze u ime svakoga tko do njega može doći. Promjena vezanja na 0.0.0.0 popravlja dostavu i istovremeno otvara port na svakom sučelju, što je sigurnosna promjena, a ne neutralan popravak. Radije vežite na konkretnu lokalnu adresu koju preusmjeravanje cilja i držite port zatvorenim na nepouzdanim sučeljima. Ako je šire vezanje neizbježno, dodajte pravilo host vatrozida koje dopušta samo raspon izvora tunela i vlastiti lokalni promet gatewaya.

Otvaranje porta na javnom sučelju nikad nije potrebno za preusmjereni VPN promet, jer veza završava lokalno nakon prepisivanja. Ne izlažite proxy internetu da bi lokalno preusmjeravanje proradilo.

Dokažite to novom vezom s klijenta

Testirajte s pravog VPN klijenta sa svježom TCP vezom, ne iz shella na gatewayu. curl -sS -o /dev/null -w '%{http_code}\n' http://example.com na klijentu vježba preusmjereni put od početka do kraja.

Zatim potvrdite da je izravna veza na slušatelj iz nepouzdane mreže još uvijek odbijena i da uzvodna veza samog proxyja nije ponovno zahvaćena istim pravilom. Rekurzivno hvatanje očituje se kao proxy koji se spaja sam sa sobom i nikad ne dovrši zahtjev. Dodajte odredište proxyja u skup isključenja ili označite njegove odlazne pakete da ih lanac preskoči.

Naposljetku, zapamtite što ovaj put ne pokriva. Obično redsocks TCP preusmjeravanje ne pretvara UDP, QUIC ili DNS u SOCKS promet, a privatna odredišta obično traže izričita isključenja. Uspješan lokalni test dokazuje samo loopback put koji nikad nije bio problem.