Eredeti célállomások átlátszó TCP–SOCKS-továbbításban

A tűzfal megváltoztathatja, hová érkezik egy TCP-kapcsolat. Ám pusztán ezzel a változtatással nem taníthatja meg a kiinduló alkalmazást SOCKS-t beszélni.

A közönséges SOCKS-kiszolgáló olyan egyeztetést vár, amely leírja a kért célállomást. A proxyt nem ismerő alkalmazás ehelyett azonnal a saját protokollbájtjait küldi. Irányítsa azokat a bájtokat egyenesen egy SOCKS-figyelőhöz, és a két fél vitatkozni fog az első üzenetről.

A hiányzó összetevő egy fordító

Az átlátszó TCP–proxy összetevő ezek között a csatolók között helyezkedik el. Felderíti a célállomást, amelyet az alkalmazás eredetileg kért, létrehozza a megfelelő SOCKS vagy HTTP CONNECT munkamenetet, majd továbbítja az alkalmazás adatait a létrejött adatfolyamon.

Linux iptables útvonalán a redsocks forráskódja SO_ORIGINAL_DST segítségével kéri le a megőrzött célállomást. Más operációs rendszerek és átirányítási módszerek eltérő mechanizmusokat használnak. Ez az átirányító és a hálózati beállítás tulajdonsága, nem egy közönséges SOCKS-kliens funkciója.

Az eredeti célállomás információja azt is megmagyarázza, miért nem mindig egyenértékű egy átirányítási szabályt a proxy gazdagépéről egy független átjáróra áthelyezni. A fogadó folyamatnak szüksége van azokra a metaadatokra, amelyeket az elfogási módja megkövetel. Egy máshol átírt cím talán már nem a várt formában nyújtja ezt az információt.

Tartsa egyértelműen a fordító hatókörét. Egy működő átirányított TCP-kapcsolat nem bizonyítja tetszőleges UDP, ICMP vagy minden névfeloldási útvonal támogatását. A felsőbb proxy protokollja és a fordító megvalósítása továbbra is meghatározza a támogatott műveleteket.

Ha egy beállítás közvetlenül a kapcsolódás után meghiúsul, ellenőrizze a protokoll határát, mielőtt kiterjesztené a hozzáférési szabályokat. Egy tökéletesen elérhető SOCKS-figyelő elutasíthat bájtokat, amelyek soha nem voltak SOCKS-kérés.