Originaj celoj en travidebla TCP-al-SOCKS plusendado
Klarigas, kial travidebla TCP-al-SOCKS plusendado bezonas tradukilon, kiu rekuperas la originan celon antaŭ ol trakti kun la prokurilo.
Fajroŝirmilo povas ŝanĝi, kie TCP-konekto alteriĝas. Sed per tiu ŝanĝo sola ĝi ne povas instrui al la devena aplikaĵo paroli SOCKS.
Ordinara SOCKS-servilo atendas traktadon, kiu priskribas la petitan celon. Aplikaĵo, kiu ne scias pri la prokurilo, anstataŭe tuj sendas siajn proprajn protokolajn bitokojn. Alidirektu tiujn bitokojn rekte al SOCKS-auskultanto, kaj la du flankoj malkonsentos pri la unua mesaĝo.
La mankanta komponanto estas tradukilo
Travidebla komponanto de TCP al prokurilo staras inter tiuj interfacoj. Ĝi malkovras la celon, kiun la aplikaĵo origine petis, starigas la taŭgan seancon SOCKS aŭ HTTP CONNECT, kaj poste plusendas la aplikaĵajn datumojn tra la rezulta fluo.
Sur sia vojo per Linux iptables, la fonto de redsocks retrovas la konservitan celon per SO_ORIGINAL_DST. Aliaj operaciumoj kaj alidirektaj metodoj uzas malsamajn mekanismojn. Tio estas eco de la alidirektilo kaj de la reta agordo, ne ordinara kapablo de SOCKS-kliento.
Informo pri la origina celo ankaŭ klarigas, kial movi alidirektan regulon de la prokurila gastiganto al sendependa enirejo ne ĉiam estas ekvivalenta. La ricevanta procezo bezonas la metadatumojn, kiujn postulas ĝia interkapta reĝimo. Adreso reskribita aliloke eble ne plu liveras tiun informon en la atendata formo.
Tenu la amplekson de la tradukilo eksplicita. Funkcianta alidirektita TCP-konekto ne pruvas subtenon por arbitra UDP, ICMP aŭ por ĉiu solvila vojo. La protokolo de la supra prokurilo kaj la efektivigo de la tradukilo ankoraŭ difinas la subtenatajn operaciojn.
Kiam agordo malsukcesas tuj post la konekto, kontrolu la protokolan limon antaŭ ol vastigi la alirregulojn. Perfekte atingebla SOCKS-auskultanto povas rifuzi bitokojn, kiuj neniam estis SOCKS-peto.