Pôvodné ciele v transparentnom preposielaní TCP na SOCKS
Vysvetľuje, prečo transparentné preposielanie TCP na SOCKS potrebuje prekladač, ktorý obnoví pôvodný cieľ pred vyjednávaním s proxy.
Brána firewall môže zmeniť, kam pripojenie TCP dorazí. Samotnou touto zmenou však nedokáže naučiť pôvodnú aplikáciu hovoriť SOCKS.
Bežný server SOCKS očakáva vyjednávanie, ktoré opisuje požadovaný cieľ. Aplikácia, ktorá o proxy nevie, namiesto toho okamžite odošle vlastné bajty protokolu. Presmerujte tie bajty priamo na poslucháč SOCKS a obe strany sa rozídu v názore na prvú správu.
Chýbajúcou súčasťou je prekladač
Transparentná súčasť na prenos TCP na proxy stojí medzi týmito rozhraniami. Zistí cieľ, ktorý aplikácia pôvodne požadovala, nadviaže príslušnú reláciu SOCKS alebo HTTP CONNECT a potom prenáša dáta aplikácie cez vzniknutý tok.
Na svojej ceste cez Linux iptables získava zdrojový kód redsocks zachovaný cieľ pomocou SO_ORIGINAL_DST. Iné operačné systémy a spôsoby presmerovania používajú odlišné mechanizmy. Je to vlastnosť presmerovača a sieťového nastavenia, nie bežná funkcia klienta SOCKS.
Informácia o pôvodnom cieli tiež vysvetľuje, prečo presunutie pravidla presmerovania z hostiteľa proxy na nesúvisiacu bránu nie je vždy rovnocenné. Prijímajúci proces potrebuje metadáta, ktoré vyžaduje jeho režim zachytávania. Adresa prepísaná inde už nemusí túto informáciu poskytovať v očakávanej podobe.
Udržujte rozsah prekladača jasný. Fungujúce presmerované pripojenie TCP nedokazuje podporu ľubovoľného UDP, ICMP ani každej cesty prekladača názvov. Protokol nadradeného proxy a implementácia prekladača stále určujú podporované operácie.
Keď nastavenie zlyhá hneď po pripojení, skontrolujte hranicu protokolu skôr, než rozšírite pravidlá prístupu. Dokonale dostupný poslucháč SOCKS môže odmietnuť bajty, ktoré nikdy neboli požiadavkou SOCKS.