Izvorne destinacije u transparentnom prosljeđivanju TCP-a na SOCKS
Objašnjava zašto transparentno prosljeđivanje TCP-a na SOCKS zahtijeva prevodilac koji vraća izvornu destinaciju prije pregovora s proxyjem.
Vatrozid može promijeniti gdje TCP veza završava. Ali samom tom promjenom 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 umjesto toga odmah šalje vlastite bajtove protokola. Preusmjerite te bajtove ravno na SOCKS osluškivač i dvije strane će se razići oko prve poruke.
Komponenta koja nedostaje je prevodilac
Transparentna komponenta za prosljeđivanje TCP-a na proxy stoji između tih sučelja. 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 dohvaća sačuvanu destinaciju pomoću SO_ORIGINAL_DST. Drugi operativni sistemi i metode preusmjeravanja koriste različite mehanizme. To je svojstvo preusmjerivača i mrežnog postavljanja, a ne obična značajka SOCKS klijenta.
Informacija o izvornoj destinaciji također objašnjava zašto premještanje pravila preusmjeravanja s hosta proxyja na nepovezani gateway nije uvijek istovjetno. Proces koji prima treba metapodatke koje zahtijeva njegov način presretanja. Adresa prepisana negdje drugdje možda više ne pruža tu informaciju u očekivanom obliku.
Držite opseg prevodioca jasnim. Ispravna preusmjerena TCP veza ne dokazuje podršku za proizvoljni UDP, ICMP ili svaku putanju razrješivača. Protokol nadređenog proxyja i implementacija prevodioca i dalje određuju podržane operacije.
Kada postavljanje ne uspije odmah nakon spajanja, provjerite granicu protokola prije nego proširite pravila pristupa. Savršeno dostupan SOCKS osluškivač može odbiti bajtove koji nikada nisu bili SOCKS zahtjev.