Destinații originale în redirecționarea transparentă TCP către SOCKS

Un firewall poate schimba unde ajunge o conexiune TCP. Însă doar cu această schimbare nu poate învăța aplicația de origine să vorbească SOCKS.

Un server SOCKS obișnuit așteaptă o negociere care descrie destinația cerută. O aplicație care nu știe de proxy trimite în schimb imediat propriii octeți de protocol. Redirecționați acei octeți direct către un ascultător SOCKS și cele două părți nu vor fi de acord cu privire la primul mesaj.

Componenta lipsă este un traducător

O componentă transparentă TCP-către-proxy stă între aceste interfețe. Ea descoperă destinația cerută inițial de aplicație, stabilește sesiunea SOCKS sau HTTP CONNECT potrivită și apoi retransmite datele aplicației pe fluxul rezultat.

Pe calea sa Linux iptables, sursa redsocks preia destinația păstrată folosind SO_ORIGINAL_DST. Alte sisteme de operare și metode de redirecționare folosesc mecanisme diferite. Aceasta este o proprietate a redirectorului și a configurării rețelei, nu o funcție obișnuită a unui client SOCKS.

Informația despre destinația originală explică și de ce mutarea unei reguli de redirecționare de pe gazda proxy pe o poartă fără legătură nu este întotdeauna echivalentă. Procesul care primește are nevoie de metadatele cerute de modul său de interceptare. O adresă rescrisă în altă parte poate să nu mai ofere acea informație în forma așteptată.

Păstrați explicit domeniul de aplicare al traducătorului. O conexiune TCP redirecționată care funcționează nu dovedește suport pentru UDP arbitrar, ICMP sau pentru fiecare cale de rezolvare. Protocolul proxy-ului superior și implementarea traducătorului definesc în continuare operațiile acceptate.

Când o configurare eșuează imediat după conectare, verificați granița protocolului înainte de a extinde regulile de acces. Un ascultător SOCKS perfect accesibil poate respinge octeți care nu au fost niciodată o cerere SOCKS.