Izvorna odredišta u prozirnom prosljeđivanju TCP-a na SOCKS
Objašnjava zašto prozirno prosljeđivanje TCP-a na SOCKS treba prevoditelja koji vraća izvorno odredište prije pregovora s proxyjem.
Vatrozid može promijeniti gdje TCP veza završava. No samom tom promjenom ne može naučiti izvornu aplikaciju govoriti SOCKS.
Običan SOCKS poslužitelj očekuje pregovor koji opisuje traženo odredište. Aplikacija koja ne zna za proxy umjesto toga odmah šalje vlastite bajtove protokola. Preusmjerite te bajtove ravno na SOCKS osluškivač i dvije će se strane razići oko prve poruke.
Komponenta koja nedostaje jest prevoditelj
Prozirna komponenta za prosljeđivanje TCP-a na proxy stoji između tih sučelja. Otkriva odredište koje 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čuvano odredište pomoću SO_ORIGINAL_DST. Drugi operacijski sustavi i metode preusmjeravanja rabe različite mehanizme. To je svojstvo preusmjerivača i mrežnog postavljanja, a ne obična značajka SOCKS klijenta.
Podatak o izvornom odredištu također objašnjava zašto premještanje pravila preusmjeravanja s hosta proxyja na nepovezani pristupnik 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 prevoditelja jasnim. Ispravna preusmjerena TCP veza ne dokazuje podršku za proizvoljni UDP, ICMP ni svaku putanju razrješivača. Protokol nadređenog proxyja i implementacija prevoditelja i dalje određuju podržane operacije.
Kada postavljanje ne uspije odmah nakon spajanja, provjerite granicu protokola prije proširenja pravila pristupa. Posve dostupan SOCKS osluškivač može odbiti bajtove koji nikada nisu bili SOCKS zahtjev.