Redsocks luister op loopback, maar VPN-verkeer kom nooit aan nie

’n Tonnel kom op, die kliënt kan die gateway ping, en elke webversoek deur die proxypad sterf. Die redsocks-proses loop en sy poort luister, so die diens lyk gesond vanaf die gateway self. Wat misluk, is die afleweringsstap: ’n pakket wat vanaf die tonnel herlei word, beland nie op die socket wat jy begin het nie. Die bind-adres en die herleiteiken moet ooreenstem, en gewoonlik word net een van hulle nagegaan.

Waar ’n herleide pakket werklik beland

Deursigtige proxying op ’n gateway gebruik ’n REDIRECT in die nat-tabel by PREROUTING om die bestemming van ’n inkomende verbinding na ’n plaaslike poort te herskryf. Die herskryfde bestemming is ’n plaaslike adres soos gesien vanaf die koppelvlak waarop die pakket aangekom het, nie die loopback-adres van ’n proses wat elders begin het nie. ’n Luisteraar wat net aan 127.0.0.1 bind, aanvaar verbindings wat reeds plaaslik op die gasheer was, en dit is juis die geval wat bly werk terwyl tonnelverkeer misluk. Die kliënt se eie loopback is ’n derde adres en is nooit die teiken van die gateway se reël nie.

Dus, voordat jy aan die opwaartse geloofsbriewe raak, stel twee feite vas: na watter plaaslike adres die reël herskryf, en aan watter adres die proxysocket gebind is.

Lees die luisteraar en die herleireël saam

Druk die sockettabel en die nat-reëls in dieselfde gang af, want ’n reël wat na ’n poort wys wat niemand besit nie, lyk presies soos ’n reël wat na die verkeerde adres wys. sudo ss -ltnp | grep redsocks wys die bind-adres en die eienaarproses. sudo iptables -t nat -S PREROUTING wys die REDIRECT-teiken, en sudo iptables -t nat -L PREROUTING -v -n wys of enigiets daarby gepas het.

’n Sprong na ’n gebruikersketting met die naam REDSOCKS bereik niks tensy daardie ketting bestaan en die beoogde uitsluitings en die REDIRECT-aksie dra. Lees die ketting waarna dit spring met sudo iptables -t nat -S REDSOCKS eerder as om aan te neem die naam doen die werk.

Vergelyk dan die twee waardes. As die reël na ’n gateway-adres op poort 12345 herlei en die luisteraar rapporteer 127.0.0.1:12345, verduidelik die wanverhouding die mislukking sonder enige verdere diagnose.

Bind nou, en beperk dan wat dit kan bereik

Die opwaartse voorbeeldkonfigurasie verstek die luisteraar na loopback om ’n goeie rede: ’n deursigtige proxy aanvaar verbindings namens elkeen wat dit kan bereik. Om die binding na 0.0.0.0 te verander, regstel die aflewering en open terselfdertyd die poort op elke koppelvlak, wat ’n sekuriteitsverandering is, nie ’n neutrale herstelling nie. Verkies om aan die spesifieke plaaslike adres te bind wat die herleiding teiken, en hou die poort gesluit op koppelvlakke wat nie vertrou word nie. As ’n wyer binding onvermydelik is, voeg ’n gasheer-firewallreël by wat net die tonnelbronreeks en die gateway se eie plaaslike verkeer toelaat.

Om die poort op die openbare koppelvlak oop te maak, is nooit nodig vir herleide VPN-verkeer nie, want die verbinding eindig plaaslik ná die herskrywing. Moenie die proxy aan die internet blootstel om ’n plaaslike herleiding te laat werk nie.

Bewys dit met ’n nuwe verbinding vanaf ’n kliënt

Toets vanaf ’n werklike VPN-kliënt met ’n vars TCP-verbinding, nie vanaf ’n shell op die gateway nie. curl -sS -o /dev/null -w '%{http_code}\n' http://example.com op die kliënt oefen die herleide pad van begin tot einde.

Bevestig dan dat ’n direkte verbinding na die luisteraar vanaf ’n onvertroude netwerk steeds geweier word, en dat die proxy se eie opwaartse verbinding nie weer deur dieselfde reël vasgevang word nie. Herhalende vasvang kom voor as ’n proxy wat aan homself verbind en nooit ’n versoek voltooi nie. Voeg die proxy se bestemming by die uitsluitingsversameling, of merk sy uitgaande pakkette sodat die ketting hulle oorslaan.

Onthou laastens wat hierdie pad nie dek nie. Gewone redsocks TCP-herleiding verander nie UDP, QUIC of DNS in SOCKS-verkeer nie, en private bestemmings benodig gewoonlik eksplisiete uitsluitings. ’n Suksesvolle plaaslike toets bewys net die loopback-pad wat nooit die probleem was nie.