Algsed sihtkohad läbipaistvas TCP-st SOCKS-iks edastamises
Selgitab, miks läbipaistev TCP-st SOCKS-iks edastamine vajab tõlkijat, mis taastab algse sihtkoha enne puhverserveriga läbirääkimist.
Tulemüür võib muuta, kuhu TCP-ühendus jõuab. Kuid ainuüksi selle muudatusega ei saa ta õpetada lähteprogrammi SOCKS-it rääkima.
Tavaline SOCKS-server ootab läbirääkimist, mis kirjeldab soovitud sihtkohta. Puhverserverist teadmatu rakendus saadab seevastu kohe oma protokollibaidid. Suunake need baidid otse SOCKS-kuulajale ja kaks poolt ei jõua esimese sõnumi osas kokkuleppele.
Puuduv komponent on tõlkija
Läbipaistev TCP-puhverserveri komponent asub nende liideste vahel. See avastab sihtkoha, mida rakendus algselt soovis, loob sobiva SOCKS- või HTTP CONNECT-seansi ja edastab seejärel rakenduse andmed tekkinud voo kaudu.
Oma Linux iptables-teekonnal hangib redsocksi lähtekood säilitatud sihtkoha vahendiga SO_ORIGINAL_DST. Teised operatsioonisüsteemid ja ümbersuunamismeetodid kasutavad teistsuguseid mehhanisme. See on ümbersuunaja ja võrguseadistuse omadus, mitte tavaline SOCKS-kliendi funktsioon.
Algse sihtkoha teave selgitab ka seda, miks ümbersuunamisreegli viimine puhverserveri hostist mitteseotud lüüsile ei ole alati samaväärne. Vastuvõttev protsess vajab metaandmeid, mida nõuab tema pealtkuulamise režiim. Mujal ümber kirjutatud aadress ei pruugi seda teavet enam oodatud kujul anda.
Hoidke tõlkija ulatus selgena. Töötav ümbersuunatud TCP-ühendus ei tõenda suvalise UDP, ICMP ega iga nimeresolveri tee toetust. Ülemvoolu puhverserveri protokoll ja tõlkija teostus määravad endiselt toetatavad toimingud.
Kui seadistus ebaõnnestub kohe pärast ühendust, kontrollige protokolli piiri enne juurdepääsureeglite laiendamist. Täiesti kättesaadav SOCKS-kuulaja võib tagasi lükata baidid, mis ei olnud kunagi SOCKS-päring.