Redsocks ascultă pe loopback, dar traficul VPN nu ajunge niciodată

Un tunel urcă, clientul poate da ping la gateway, iar fiecare cerere web pe calea proxy moare. Procesul redsocks rulează și portul său ascultă, așa că serviciul pare sănătos chiar de la gateway. Ceea ce eșuează este pasul de livrare: un pachet redirecționat din tunel nu aterizează pe socketul pe care l-ați pornit. Adresa de legare și ținta redirecționării trebuie să coincidă, iar de obicei se verifică doar una dintre ele.

Unde aterizează de fapt un pachet redirecționat

Proxyul transparent de pe un gateway folosește REDIRECT în tabela nat la PREROUTING pentru a rescrie destinația unei conexiuni de intrare către un port local. Destinația rescrisă este o adresă locală așa cum o vede interfața pe care a sosit pachetul, nu adresa de loopback a unui proces pornit în altă parte. Un ascultător legat doar de 127.0.0.1 acceptă conexiuni care erau deja locale pe gazdă, și exact acesta este cazul care continuă să funcționeze în timp ce traficul tunelului eșuează. Loopbackul clientului însuși este o a treia adresă și nu este niciodată ținta regulii gatewayului.

Așadar, înainte de a atinge acreditările nivelului superior, stabiliți două fapte: către ce adresă locală rescrie regula și către ce adresă este legat socketul proxyului.

Citiți ascultătorul și regula de redirecționare împreună

Tipăriți tabela de socketuri și regulile nat într-o singură trecere, pentru că o regulă care indică un port pe care nimeni nu îl deține arată identic cu o regulă care indică adresa greșită. sudo ss -ltnp | grep redsocks arată adresa de legare și procesul proprietar. sudo iptables -t nat -S PREROUTING arată ținta REDIRECT, iar sudo iptables -t nat -L PREROUTING -v -n arată dacă ceva i-a corespuns.

Un salt către un lanț de utilizator numit REDSOCKS nu realizează nimic dacă acel lanț nu există și nu poartă excluderile dorite și acțiunea REDIRECT. Citiți lanțul către care sare cu sudo iptables -t nat -S REDSOCKS în loc să presupuneți că numele face treaba.

Apoi comparați cele două valori. Dacă regula redirecționează către o adresă de gateway pe portul 12345 și ascultătorul raportează 127.0.0.1:12345, discrepanța explică eșecul fără nicio diagnosticare suplimentară.

Legați îngust, apoi limitați ce poate ajunge la el

Configurația exemplu a nivelului superior pune ascultătorul pe loopback dintr-un motiv bun: un proxy transparent acceptă conexiuni în numele oricui îl poate atinge. Schimbarea legării la 0.0.0.0 corectează livrarea și deschide simultan portul pe fiecare interfață, ceea ce este o schimbare de securitate, nu o reparație neutră. Preferați legarea la adresa locală specifică vizată de redirecționare și țineți portul închis pe interfețele neîncrezute. Dacă o legare mai largă este inevitabilă, adăugați o regulă de firewall pe gazdă care permite doar intervalul sursă al tunelului și traficul local propriu al gatewayului.

Deschiderea portului pe interfața publică nu este niciodată necesară pentru traficul VPN redirecționat, pentru că conexiunea se termină local după rescriere. Nu expuneți proxyul la internet pentru a face o redirecționare locală să funcționeze.

Dovediți-o cu o conexiune nouă de la un client

Testați de la un client VPN real cu o conexiune TCP nouă, nu dintr-un shell pe gateway. curl -sS -o /dev/null -w '%{http_code}\n' http://example.com pe client parcurge calea redirecționată de la un capăt la altul.

Apoi confirmați că o conexiune directă la ascultător dintr-o rețea neîncrezută este încă refuzată și că conexiunea ascendentă a proxyului însuși nu este capturată din nou de aceeași regulă. Capturarea recursivă se manifestă ca un proxy care se conectează la sine și nu finalizează niciodată o cerere. Adăugați destinația proxyului la mulțimea de excluderi sau marcați pachetele sale de ieșire pentru ca lanțul să le sară.

În final, amintiți-vă ce nu acoperă această cale. Redirecționarea TCP obișnuită a redsocks nu transformă UDP, QUIC sau DNS în trafic SOCKS, iar destinațiile private necesită de obicei excluderi explicite. Un test local reușit dovedește doar calea de loopback care nu a fost niciodată problema.