Alkuperäiset kohteet läpinäkyvässä TCP–SOCKS-edelleenohjauksessa
Selittää, miksi läpinäkyvä TCP–SOCKS-edelleenohjaus tarvitsee kääntäjän, joka palauttaa alkuperäisen kohteen ennen välityspalvelimen kanssa neuvottelua.
Palomuuri voi muuttaa, mihin TCP-yhteys päätyy. Pelkällä tällä muutoksella se ei kuitenkaan voi opettaa alkuperäistä sovellusta puhumaan SOCKSia.
Tavallinen SOCKS-palvelin odottaa neuvottelua, joka kuvaa pyydetyn kohteen. Välityspalvelinta tuntematon sovellus lähettää sen sijaan heti omat protokollatavunsa. Ohjaa ne tavut suoraan SOCKS-kuuntelijalle, niin kaksi osapuolta on eri mieltä ensimmäisestä viestistä.
Puuttuva osa on kääntäjä
Läpinäkyvä TCP–välityspalvelin-osa istuu näiden rajapintojen välissä. Se löytää kohteen, jota sovellus alun perin pyysi, avaa sopivan SOCKS- tai HTTP CONNECT -istunnon ja välittää sitten sovelluksen tiedot syntyneen virran yli.
Linux iptables -polullaan redsocksin lähdekoodi hakee säilytetyn kohteen SO_ORIGINAL_DST-keinon avulla. Muut käyttöjärjestelmät ja uudelleenohjausmenetelmät käyttävät erilaisia mekanismeja. Tämä on uudelleenohjaajan ja verkkokokoonpanon ominaisuus, ei tavallisen SOCKS-asiakkaan toiminto.
Tieto alkuperäisestä kohteesta selittää myös, miksi uudelleenohjaussäännön siirtäminen välityspalvelimen isännältä erilliseen yhdyskäytävään ei ole aina samanarvoista. Vastaanottava prosessi tarvitsee metatiedot, joita sen sieppausmenetelmä edellyttää. Muualla uudelleen kirjoitettu osoite ei ehkä enää tarjoa tätä tietoa odotetussa muodossa.
Pidä kääntäjän laajuus selvänä. Toimiva uudelleenohjattu TCP-yhteys ei todista tukea mielivaltaiselle UDP:lle, ICMP:lle tai jokaiselle nimipalvelupolulle. Ylävirran välityspalvelinprotokolla ja kääntäjän toteutus määrittävät edelleen tuetut toiminnot.
Kun asennus epäonnistuu heti yhteyden jälkeen, tarkista protokollaraja ennen kuin laajennat käyttösääntöjä. Täysin tavoitettavissa oleva SOCKS-kuuntelija voi hylätä tavuja, jotka eivät koskaan olleet SOCKS-pyyntö.