Policy-Routing géint SOCKS: wéi eng Schicht proxyt den Trafic wierklech

Dir hutt eng Policy-Route dobäigefüügt, déi den Trafic vun engem VPN-Client op e Host schéckt, op deem en SOCKS-Listener op Port 1080 leeft. D'Pakete kommen un, de Listener loggt näischt, an d'Verbindung hänkt. Un der Route ass näischt falsch: en nächsten Hop wielt, wou e Paket higëtt, an SOCKS ass eng Konversatioun, déi de Client ufänke muss. Vergläicht déi dräi Architekturen, déi d'Leit normalerweis mengen, wa se Trafic duerch e Proxy schécken, an et gëtt kloer, wéi en Deel an Ärer Astellung feelt.

Routing, DNAT an SOCKS änneren ënnerschiddlech Saachen

Eng Policy-Route schreift eng Entscheedung op Schicht 3 ëm. Zwou Linnen genuch, fir den Trafic vun engem Client op en ausgewielten nächsten Hop ze schécken:

ip route add default via 10.50.0.2 table 101
ip rule add from 10.77.0.2 lookup 101

Duerno gëtt de Kernel d'Paket un 10.50.0.2, woubäi d'ursprünglech Destinatioun nach ëmmer am IP-Header steet. Wann 10.50.0.2 e Router ass, leet en d'Paket weider. Wann et en Host mat engem SOCKS-Daemon op 1080 ass, ass d'Paket un näischt adresséiert, wat et akzeptéiere kann, an och DNAT op Port 1080 hëlleft net, well en iwwersat Paket nach ëmmer déi ursprénglech Applikatiounslass dréit anstatt enger SOCKS-Begréissung.

SOCKS5 fänkt mat engem Versiounsbyte, enger Methodelëscht, engem Authentifikatiouns-Austausch an enger Ufro un, déi d'Destinatioun nennt. Dat sinn Applikatiounsdaten. Weder en Routing-Agang nach en netfilter-Zil generéiert se, an dat ass de Verglach an enger Linn: Routing wielt e Wee, SOCKS freet e Server, eng zweet Verbindung ze maachen.

Fall ee: d'Applikatioun kann selwer SOCKS schwätzen

Wann de Programm eng Proxy-Astellung huet, ass dat de kierzten Wee an et brauch keng Kernelännerung. Richt et op de Listener, gitt Umeldungsinformatiounen, wann de Server se freet, a entscheet, ob Nimm lokal opgeléist oder un de Proxy iwwergi ginn. Bei curl sinn dat ënnerschiddlech Fändelen, an den Ënnerscheed ass wichteg, wann d'Destinatioun nëmmen vun der Proxysäit opgeléist gëtt:

curl --socks5 10.50.0.2:1080 https://docs.example.com
curl --socks5-hostname 10.50.0.2:1080 https://internal.example.com

Applikatiounen, déi Proxy-Ëmweltvariabelen ignoréieren oder roh Sockets opmaachen, kënnen esou net gehollef ginn. Browseren an déi meescht HTTP-Werkzeuge sinn a Ordnung; e Spillclient, en Mail-Daemon oder eng arbiträr Vendor-Binärdatei ass et normalerweis net. D'Grenz ass pro Applikatioun a pro Protokoll, dofir ass dës Optioun exzellent fir Tester a schwaach als Äntwert fir de ganzen VPN.

Fall zwee: en Adapter, deen IP-Stréim an Proxy-Sessiounen ëmwandelt

Fir Programmer, déi net SOCKS schwätze kënnen, muss d'Ëmwandlung an eppes geschéien, wat IP-Trafic terminéiert a Proxy-Sessiounen a hirem Numm opmécht. Dee Komponent besitzt eng Tunnel-Schnittstell, akzeptéiert d'Stréim, déi Policy-Routing ausgewielt huet, mécht de SOCKS-Handshake fir jidderee wéi och baut d'Äntwerten erëm op. D'Route riicht den Trafic op hien; den Adapter ass dat, wat d'Sessioun schaaft.

Liest seng Dokumentatioun, ier Dir him en ganzt Subnetz uvertraut. Vill Adapter droen TCP gutt a behaapten UDP nëmmen duerch eng SOCKS5 UDP-Associatioun, an keen vun hinnen ëmwandelt ICMP a Proxy-Trafic, dofir seet en erfollegräiche ping näischt iwwer de Proxy-Wee. DNS ass déi aner Fal: wann den Adapter Nimm lokal opgeléist, ginn nëmmen intern Opzeechnungen op déi falsch Äntwert opgeléist, oder op guer näischt.

Schläifverhënnerung ass den operationellen Detail, dee bäisst. Dem Adapter seng eegen Verbindungen zum SOCKS-Server dierfen net zréck an den Adapter geroutet ginn, dofir brauch seng Trafic eng Ausnam an der Regel oder eng dedizéiert Quelladress. Maacht Dir dat falsch, probéiert d'Proxy-Sessioun sech selwer ze proxen.

Fall dräi: den Host ass tatsächlech en geroutete Gateway

Heiansdo enthält déi funktionéierend Astellung guer kee SOCKS. Den entfernten Host leet Pakete weider oder mécht NAT drop, an d'Quellbaséiert Regel wielt en einfach als Ausgang. Dat Design ass legitim, an et erkläert, firwat eng kopéiert Konfiguratioun an engem Netz funktionéiert an an engem aneren net: d'Regel ass identesch, de fehlenden Deel ass en Weiterleitungsservice op der anerer Säit.

Déi dräi Fäll trenne sech séier. Kontrolléiert, wat tatsächlech lauschtert, a kuckt dann op déi éischt Byten, déi den Host erreechen:

ss -ltnp 'sport = :1080'
tcpdump -ni eth0 -X 'tcp port 1080'

Den éischte Notzlaaschtbyte vun engem echte SOCKS-Client ass 0x05, d'Versioun an der Begréissung. Wann d'Opnam amplaz ursprénglech Applikatiounsdaten weist, äntwert keen SOCKS-Daemon, well d'Verhandlungen ni ugefaangen hunn. Wann op 1080 näischt lauschtert, ass den Host en Gateway, an d'Fro gëtt, ob en weiderleet an ob et en Zréckwee gëtt.

Wielt d'Schicht mat véier Froen

Huet de Programm eng Proxy-Astellung? Benotzt se a stoppt do. Enthält den Trafic UDP oder ICMP, dee muss iwwerliewen? Nëmmen en geroutete oder NAT-Gateway dréit ICMP, an UDP brauch eng SOCKS5-Associatioun, déi béid Säiten ënnerstëtzen. Muss all Prozess op der Maschinn ofgedeckt sinn, och déi Dir net konfiguréiere kënnt? Dann braucht Dir en Adapter, deen d'Schnittstell besëtzt a Stréim terminéiert. Kënnt Dir och seng Routing, DNS an Ausname fir Schläifverhënnerung iwwerhuelen? Wann net, kascht de einfache Gateway manner am Betrib.

Een Ënnerscheed ass et wäert, riicht ze halen. Dem VPN-Client seng eegen socks-proxy-Optioun beschreift, wéi d'baussen Tunnelverbindung hire Server erreecht, a seet näischt iwwer d'Ëmwandlung vun de bannenste Clientstréim. Déi zwee ginn an der selwechter Ticket stänneg verwiesselt. Entscheet, wéi eng Relatioun Dir braucht, ier Dir eng Route beréiert.