Upphaflegu áfangastaðirnir í gegnsærri TCP-til-SOCKS framsendingu

Eldveggur getur breytt því hvar TCP-tenging lendir. En með þeirri breytingu einni getur hann ekki kennt upprunalega forritinu að tala SOCKS.

Venjulegur SOCKS-þjónn væntir samningaviðræðna sem lýsa umbeðnum áfangastað. Forrit sem þekkir ekki proxyið sendir í staðinn strax sína eigin prótókólbæti. Beinið þeim bætum beint að SOCKS-hlustun og aðilarnir tveir verða ósammála um fyrstu skilaboðin.

Vantaða einingin er þýðandi

Gegnsæ TCP-til-proxy eining situr milli þessara viðmóta. Hún finnur áfangastaðinn sem forritið bað upphaflega um, kemur á viðeigandi SOCKS- eða HTTP CONNECT-lot og miðlar síðan forritsgögnum yfir strauminn sem myndast.

Á Linux iptables-leið sinni sækir redsocks-uppsprettan varðveitta áfangastaðinn með SO_ORIGINAL_DST. Önnur stýrikerfi og endurbeiningaraðferðir nota aðra kerfisferla. Þetta er eiginleiki endurbeinirans og netuppsetningarinnar, ekki venjulegur eiginleiki SOCKS-biðlara.

Upplýsingar um upphaflega áfangastaðinn skýra líka hvers vegna það er ekki alltaf jafngilt að flytja endurbeiningarreglu frá proxyhýsinu yfir á ótengda gátt. Móttökumannsferlið þarf þau lýsigögn sem hlerunaraðferð þess krefst. Heimilisfang sem er endurskrifað annars staðar veitir ef til vill ekki lengur þessar upplýsingar í væntanlegu formi.

Haltu umfangi þýðandans skýru. Virk endurbeind TCP-tenging sannar ekki stuðning við handahófskennt UDP, ICMP eða hverja lausnaleið. Prótókoll yfirproxyins og útfærsla þýðandans skilgreina enn studdar aðgerðir.

Þegar uppsetning mistekst strax eftir tengingu, athugaðu prótókólmörkin áður en aðgangsreglur eru víkkaðar. Fullkomlega aðgengilegur SOCKS-hlustun getur hafnað bætum sem voru aldrei SOCKS-beiðni.