Izvorni cilji pri prosojnem posredovanju TCP v SOCKS
Pojasni, zakaj prosojno posredovanje TCP v SOCKS potrebuje prevajalnik, ki obnovi izvorni cilj pred pogajanjem s posrednikom.
Požarni zid lahko spremeni, kam prispe povezava TCP. A samo s to spremembo izvirne aplikacije ne more naučiti govoriti SOCKS.
Običajni strežnik SOCKS pričakuje pogajanje, ki opisuje zahtevani cilj. Aplikacija, ki posrednika ne pozna, namesto tega takoj pošlje svoje lastne bajte protokola. Preusmerite te bajte naravnost v poslušalec SOCKS in obe strani se ne bosta strinjali glede prvega sporočila.
Manjkajoča sestavina je prevajalnik
Prosojna sestavina za posredovanje TCP v posrednika stoji med temi vmesniki. Ugotovi cilj, ki ga je aplikacija prvotno zahtevala, vzpostavi ustrezno sejo SOCKS ali HTTP CONNECT in nato podatke aplikacije pretaka po nastalem toku.
Na svoji poti Linux iptables izvorna koda redsocks pridobi ohranjeni cilj s pomočjo SO_ORIGINAL_DST. Drugi operacijski sistemi in načini preusmerjanja uporabljajo drugačne mehanizme. To je lastnost preusmerjevalnika in omrežne nastavitve, ne običajna funkcija odjemalca SOCKS.
Podatek o izvornem cilju pojasni tudi, zakaj prenos pravila preusmerjanja z gostitelja posrednika na nepovezan prehod ni vedno enakovreden. Prejemni proces potrebuje metapodatke, ki jih zahteva njegov način prestrezanja. Naslov, prepisan drugje, morda te informacije ne daje več v pričakovani obliki.
Obseg prevajalnika naj bo jasen. Delujoča preusmerjena povezava TCP ne dokazuje podpore za poljuben UDP, ICMP ali vsako pot razreševalnika. Protokol nadrejenega posrednika in izvedba prevajalnika še vedno določata podprte operacije.
Ko nastavitev ne uspe takoj po povezavi, preverite mejo protokola, preden razširite pravila dostopa. Popolnoma dosegljiv poslušalec SOCKS lahko zavrne bajte, ki nikoli niso bili zahteva SOCKS.