Izvorne destinacije u transparentnom prosleđivanju TCP-a na SOCKS
Objašnjava zašto transparentno prosleđivanje TCP-a na SOCKS zahteva prevodilac koji vraća izvornu destinaciju pre pregovora sa proxyjem.
Zaštitni zid može promeniti gde TCP veza završava. Ali samom tom promenom ne može naučiti izvornu aplikaciju da govori SOCKS.
Običan SOCKS server očekuje pregovor koji opisuje traženu destinaciju. Aplikacija koja ne zna za proxy umesto toga odmah šalje sopstvene bajtove protokola. Preusmerite te bajtove pravo na SOCKS osluškivač i dve strane će se razići oko prve poruke.
Komponenta koja nedostaje je prevodilac
Transparentna komponenta za prosleđivanje TCP-a na proxy stoji između tih interfejsa. Otkriva destinaciju koju je aplikacija izvorno tražila, uspostavlja odgovarajuću SOCKS ili HTTP CONNECT sesiju, a zatim prenosi podatke aplikacije preko nastalog toka.
Na svojoj Linux iptables putanji, izvorni kod redsocksa dohvata sačuvanu destinaciju pomoću SO_ORIGINAL_DST. Drugi operativni sistemi i metode preusmeravanja koriste drugačije mehanizme. To je svojstvo preusmerivača i mrežnog podešavanja, a ne obična funkcija SOCKS klijenta.
Informacija o izvornoj destinaciji objašnjava i zašto premeštanje pravila preusmeravanja sa hosta proxyja na nepovezani gateway nije uvek istovetno. Proces koji prima treba metapodatke koje zahteva njegov način presretanja. Adresa prepisana negde drugde možda više ne pruža tu informaciju u očekivanom obliku.
Držite obim prevodioca jasnim. Ispravna preusmerena TCP veza ne dokazuje podršku za proizvoljni UDP, ICMP ili svaku putanju razrešivača. Protokol nadređenog proxyja i implementacija prevodioca i dalje određuju podržane operacije.
Kada podešavanje ne uspe odmah posle povezivanja, proverite granicu protokola pre nego što proširite pravila pristupa. Savršeno dostupan SOCKS osluškivač može odbiti bajtove koji nikada nisu bili SOCKS zahtev.