Policy routing versus SOCKS: která vrstva vlastně proxuje provoz
Trasa na port SOCKS není relace SOCKS. Porovnejte nastavení proxy na úrovni aplikace, adaptér IP-na-proxy a směrovanou bránu podle vrstvy, která převádí.
Přidali jste zásadovou trasu, která posílá provoz klienta VPN na hostitele, kde na portu 1080 běží SOCKS listener. Pakety dorazí, listener nic nezaloguje a spojení visí. Na trase není nic špatně: další skok určuje, kam paket jde, a SOCKS je konverzace, kterou musí klient zahájit. Porovnejte tři architektury, které lidé obvykle myslí tím, že posílají provoz přes proxy, a bude jasné, která část vaší konfiguraci chybí.
Směrování, DNAT a SOCKS mění různé věci
Zásadová trasa přepisuje rozhodnutí na vrstvě 3. Dva řádky stačí k tomu, aby se provoz jednoho klienta poslal na zvolený další skok:
ip route add default via 10.50.0.2 table 101
ip rule add from 10.77.0.2 lookup 101Poté jádro předá paket na 10.50.0.2 a původní cíl zůstává v IP hlavičce. Pokud je 10.50.0.2 router, paket přepošle. Pokud je to hostitel se SOCKS démonem na 1080, paket není adresován ničemu, co by ho mohlo přijmout, a ani DNAT na port 1080 nepomůže, protože přeložený paket stále nese původní aplikační užitečné zatížení místo SOCKS pozdravu.
SOCKS5 začíná bajtem verze, seznamem metod, výměnou autentizace a požadavkem, který pojmenovává cíl. To jsou aplikační data. Žádný záznam směrování ani cíl netfilter je negeneruje, a to je srovnání v jedné řádce: směrování vybírá cestu, SOCKS žádá server, aby vytvořil druhé spojení.
Případ první: aplikace umí mluvit SOCKS sama
Když má program nastavení proxy, je to nejkratší cesta a nevyžaduje změnu jádra. Namiřte ho na listener, poskytněte přihlašovací údaje, pokud je server vyžádá, a rozhodněte, zda se názvy překládají lokálně, nebo se předávají proxy. U curl jsou to různé přepínače a rozdíl je důležitý, když se cíl překládá jen na straně proxy:
curl --socks5 10.50.0.2:1080 https://docs.example.com
curl --socks5-hostname 10.50.0.2:1080 https://internal.example.comAplikacím, které ignorují proměnné prostředí proxy nebo otevírají surové sockety, se takto pomoci nedá. Prohlížeče a většina HTTP nástrojů jsou v pořádku; herní klient, poštovní démon nebo libovolný binární soubor dodavatele obvykle ne. Hranice je po aplikaci a po protokolu, proto je tato možnost výborná pro testování a slabá jako odpověď pro celý VPN.
Případ druhý: adaptér, který převádí IP toky na relace proxy
Pro programy, které neumí mluvit SOCKS, musí k převodu dojít v něčem, co ukončuje IP provoz a otevírá relace proxy jejich jménem. Tato komponenta vlastní tunelové rozhraní, přijímá toky, které vybralo zásadové směrování, provádí SOCKS handshake pro každý z nich a znovu sestavuje odpovědi. Trasa na ni provoz nasměruje; adaptér je to, co relaci vytváří.
Přečtěte si jeho dokumentaci, než mu svěříte celou podsíť. Mnoho adaptérů dobře přenáší TCP a UDP zpracovává jen přes SOCKS5 UDP asociaci a žádný z nich nemění ICMP na proxy provoz, takže úspěšný ping o cestě přes proxy nic neříká. DNS je druhá past: pokud adaptér překládá názvy lokálně, záznamy pouze pro interní použití se přeloží na špatnou odpověď, nebo vůbec na nic.
Prevence smyček je provozní detail, který kouše. Vlastní spojení adaptéru na server SOCKS se nesmějí směrovat zpět do adaptéru, takže jeho provoz potřebuje výjimku v pravidle nebo vyhrazenou zdrojovou adresu. Udělejte to špatně a relace proxy se bude snažit proxovat sama sebe.
Případ třetí: hostitel je ve skutečnosti směrovaná brána
Někdy funkční konfigurace neobsahuje žádné SOCKS. Vzdálený hostitel pakety přeposílá nebo jim dělá NAT a pravidlo založené na zdroji ho prostě vybere jako východ. Takový návrh je legitimní a vysvětluje, proč zkopírovaná konfigurace funguje v jedné síti a v jiné selhává: pravidlo je stejné, chybějící částí je služba přeposílání na druhé straně.
Tři případy se oddělí rychle. Zkontrolujte, co skutečně naslouchá, a pak se podívejte na první bajty, které se k hostiteli dostanou:
ss -ltnp 'sport = :1080'
tcpdump -ni eth0 -X 'tcp port 1080'První bajt užitečného zatížení skutečného klienta SOCKS je 0x05, verze v pozdravu. Pokud zachycení ukazuje místo toho původní aplikační data, žádný SOCKS démon neodpoví, protože vyjednávání nikdy nezačalo. Pokud na 1080 nic nenaslouchá, hostitel je brána a otázkou se stává, zda přeposílá a zda existuje zpáteční cesta.
Vyberte vrstvu pomocí čtyř otázek
Má program nastavení proxy? Použijte ho a tam skončete. Obsahuje provoz UDP nebo ICMP, které musí přežít? ICMP nese jen směrovaná brána nebo brána s NAT a UDP potřebuje SOCKS5 asociaci, kterou podporují obě strany. Musí být pokryt každý proces na stroji, včetně těch, které nemůžete nastavit? Pak potřebujete adaptér, který vlastní rozhraní a ukončuje toky. Můžete převzít i jeho směrování, DNS a výjimky pro prevenci smyček? Pokud ne, prostá brána bude stát na provoz méně.
Jedno rozlišení stojí za to udržet rovně. Vlastní volba socks-proxy klienta VPN popisuje, jak se vnější tunelové spojení dostane na svůj server, a nic neříká o převodu vnitřních klientských toků. Obě věci se v tomtéž tiketu neustále pletou. Rozhodněte, jaký vztah potřebujete, než se dotknete trasy.