Redsocks hlustar á loopback en VPN-umferð kemur aldrei

Göng ganga upp, biðlarinn getur pingað gáttina, og hver vefbeiðni um proxy-slóðina deyr. redsocks ferlið keyrir og portið þess hlustar, svo þjónustan virðist heilbrigð frá gáttinni sjálfri. Það sem mistekst er afhendingarskrefið: pakki sem er vísað frá göngunum lendir ekki á socketinu sem þú ræstir. Bindifang og áfangastaður tilvísunarinnar verða að samsvara, og venjulega er aðeins önnur þeirra athuguð.

Hvar tilvísaður pakki lendir í raun

Gegnsæi proxy á gátt notar REDIRECT í nat-töflunni við PREROUTING til að endurskrifa áfangastað innkomandi tengingar á staðbundið port. Endurskrifaði áfangastaðurinn er staðbundið vistfang séð frá viðmótinu sem pakkinn kom inn á, ekki loopback-vistfang ferlis sem var ræst annars staðar. Hlustari sem er aðeins bundinn við 127.0.0.1 tekur við tengingum sem voru þegar staðbundnar á hýsilnum, og það er einmitt tilvikið sem heldur áfram að virka meðan umferð ganganna mistekst. Loopback biðlarans sjálfs er þriðja vistfang og er aldrei skotmark reglu gáttarinnar.

Svo áður en þú snertir innskráningarupplýsingar uppstreymis, festu tvær staðreyndir: hvaða staðbundna vistfang reglan endurskrifar á, og hvaða vistfang socket proxysins er bundið við.

Lestu hlustarann og tilvísunarregluna saman

Prentaðu socket-töfluna og nat-reglurnar í einni ferð, því regla sem bendir á port sem enginn á virðist nákvæmlega eins og regla sem bendir á rangt vistfang. sudo ss -ltnp | grep redsocks sýnir bindivístfang og ferlið sem á það. sudo iptables -t nat -S PREROUTING sýnir REDIRECT-skotmarkið, og sudo iptables -t nat -L PREROUTING -v -n sýnir hvort eitthvað passaði við það.

Stökk í notandakeðju að nafni REDSOCKS nær engu nema sú keðja sé til og beri fyrirhuguðu undantekningarnar og REDIRECT-aðgerðina. Lestu keðjuna sem hún stekkur í með sudo iptables -t nat -S REDSOCKS í stað þess að gera ráð fyrir að nafnið vinni verkið.

Berðu síðan saman tvö gildin. Ef reglan vísar á gáttarvistfang á porti 12345 og hlustarinn greinir frá 127.0.0.1:12345, skýrir misræmið mistökin án nokkurrar frekari greiningar.

Bindu þröngt og takmarkaðu síðan hvað getur náð til þess

Dæmigerð uppstilling uppstreymis setur hlustarann á loopback af góðri ástæðu: gegnsætt proxy tekur við tengingum fyrir hönd hvers sem getur náð til þess. Að breyta bindingu í 0.0.0.0 lagar afhendinguna og opnar portið á öllum viðmótum á sama tíma, sem er öryggisbreyting, ekki hlutlaus viðgerð. Veldu frekar að binda við tiltekið staðbundið vistfang sem tilvísunin miðar á, og haltu portinu lokuðu á ótraustum viðmótum. Ef víðari binding er óhjákvæmileg, bættu við eldveggjarreglu hýsilsins sem leyfir aðeins upprunasvið ganganna og eigin staðbundna umferð gáttarinnar.

Að opna portið á opinberu viðmóti er aldrei nauðsynlegt fyrir tilvísaða VPN-umferð, því tengingin endar staðbundið eftir endurskriftina. Ekki afhjúpa proxsið fyrir internetinu til að láta staðbundna tilvísun virka.

Sannaðu það með nýrri tengingu frá biðlara

Prófaðu frá raunverulegum VPN-biðlara með ferskri TCP-tengingu, ekki úr skel á gáttinni. curl -sS -o /dev/null -w '%{http_code}\n' http://example.com á biðlaranum prófar tilvísuðu slóðina frá upphafi til enda.

Staðfestu síðan að bein tenging við hlustarann frá ótraustu neti sé enn hafnað, og að uppstreymistenging proxsins sjálfs sé ekki gripin aftur af sömu reglu. Endurkvæm gildra birtist sem proxy sem tengist sjálfu sér og klárar aldrei beiðni. Bættu áfangastað proxsins við undantekningasettið, eða merktu útfararpakka þess svo keðjan sleppi þeim.

Að lokum, mundu hvað þessi slóð nær ekki yfir. Venjuleg redsocks TCP-tilvísun breytir ekki UDP, QUIC eða DNS í SOCKS-umferð, og einkaaðföng þurfa venjulega skýrar undantekningar. Árangursrík staðbundin prófun sannar aðeins loopback-slóðina sem var aldrei vandamálið.