Redsocks kuulab loopbackil, aga VPN-liiklus ei jõua kunagi kohale

Tunnel tõuseb, klient saab lüüsi pingida, ja iga veebipäring puhverserveri teekonnal sureb. redsocksi protsess töötab ja selle port kuulab, seega tundub teenus lüüsi enda pealt terve. Ebaõnnestub tarneetapp: tunnelist ümber suunatud pakett ei maandu soklile, mille te käivitasite. Sidumisaadress ja ümbersuunamise sihtmärk peavad ühtima, ja tavaliselt kontrollitakse neist ainult ühte.

Kuhu ümbersuunatud pakett tegelikult maandub

Läbipaistev puhverserver lüüsil kasutab PREROUTINGi nat-tabelis REDIRECT-i, et kirjutada sissetuleva ühenduse sihtkoht ümber kohalikule pordile. Ümber kirjutatud sihtkoht on kohalik aadress nii, nagu seda näeb liides, millele pakett saabus, mitte mujal käivitatud protsessi loopbacki aadress. Ainult 127.0.0.1-le seotud kuulaja võtab vastu ühendusi, mis olid juba hostis kohalikud, ja just see juhtum jääb tööle siis, kui tunneli liiklus ebaõnnestub. Kliendi enda loopback on kolmas aadress ega ole kunagi lüüsi reegli sihtmärk.

Seega enne ülalvoolu mandaatide puutumist tuvastage kaks fakti: millisele kohalikule aadressile reegel ümber kirjutab ja millisele aadressile puhverserveri sokkel on seotud.

Lugege kuulajat ja ümbersuunamise reeglit koos

Printige soklitabel ja nat-reeglid ühe käiguga, sest reegel, mis osutab pordile, mida keegi ei oma, näeb välja täpselt samasugune kui vale aadressi osutav reegel. sudo ss -ltnp | grep redsocks näitab sidumisaadressi ja omavat protsessi. sudo iptables -t nat -S PREROUTING näitab REDIRECTi sihtmärki ja sudo iptables -t nat -L PREROUTING -v -n näitab, kas midagi sellega ühtis.

Hüpe kasutaja ahelasse nimega REDSOCKS ei saavuta midagi, kui seda ahelat pole olemas ja see ei kanna kavandatud välistusi ja REDIRECTi tegevust. Lugege ahelat, kuhu see hüppab, käsuga sudo iptables -t nat -S REDSOCKS, selle asemel et eeldada, nagu teeks nimi töö ära.

Seejärel võrrelge kaht väärtust. Kui reegel suunab ümber lüüsi aadressile pordil 12345 ja kuulaja teatab 127.0.0.1:12345, siis ebakõla seletab tõrke ilma igasuguse täiendava diagnostikata.

Siduge kitsalt ja piirake seejärel, mis selleni jõuab

Ülalvoolu näidiskonfiguratsioon seab kuulaja heil põhjusel loopbackile: läbipaistev puhverserver võtab ühendusi vastu igaühe nimel, kes selleni jõuab. Sidumise muutmine 0.0.0.0-ks parandab tarne ja avab samal ajal pordi igal liidesel, mis on turvamuudatus, mitte neutraalne parandus. Eelistage siduda konkreetse kohaliku aadressiga, mida ümbersuunamine sihib, ja hoidke port mitteusaldusväärsetel liidestel suletult. Kui laiem sidumine on vältimatu, lisage hosti tulemüüri reegel, mis lubab ainult tunneli lähtevahemikku ja lüüsi enda kohalikku liiklust.

Pordi avamine avalikul liidesel ei ole ümbersuunatud VPN-liikluse jaoks kunagi vajalik, sest ühendus lõpeb pärast ümberkirjutamist kohapeal. Ärge paljastage puhverserverit internetti, et kohalik ümbersuunamine töötaks.

Tõestage seda kliendi uue ühendusega

Testige päris VPN-kliendist värske TCP-ühendusega, mitte lüüsi shellist. curl -sS -o /dev/null -w '%{http_code}\n' http://example.com kliendil läbib ümbersuunatud tee algusest lõpuni.

Seejärel kinnitage, et otsene ühendus kuulajani mitteusaldusväärsest võrgust lükatakse endiselt tagasi, ja et puhverserveri enda ülalvoolu ühendust ei püüta sama reegliga uuesti kinni. Rekursiivne püüdmine ilmneb puhverserverina, mis ühendub iseendaga ega lõpeta kunagi päringut. Lisage puhverserveri sihtkoht välistuste hulka või märgistage selle väljuvad paketid, et ahel need vahele jätaks.

Lõpuks pidage meeles, mida see tee ei kata. Tavaline redsocksi TCP ümbersuunamine ei muuda UDP-d, QUIC-i ega DNS-i SOCKS-liikluseks, ja privaatsed sihtkohad vajavad tavaliselt selgesõnalisi välistusi. Õnnestunud kohalik test tõestab ainult loopbacki teed, mis ei olnud kunagi probleem.