SOCKS5 proxy pro OpenVPN: TCP tunel, nebo proxy pro aplikace?

Proxy přenáší proud bajtů, ne datagram. Porovnejte TCP tunel za socks-proxy s přesměrováním redsocks a podívejte se, kde každý návrh selže první.

Sítě, které povolují odchozí provoz jen přes proxy, jsou místem, kde funkční profil náhle umře. Adresa proxy je v tomto selhání nejméně zajímavá proměnná. Vše rozhoduje podoba provozu, který bude proxy přenášet, protože tyto proxy přenášejí bajtový proud a UDP tunel jím není. Zůstávají dvě architektury a každá padá na jiném místě.

O návrhu rozhoduje jedno omezení

SOCKS5 sice specifikuje režim UDP asociace. Podpora proxy v klientu OpenVPN je však postavena kolem proudů: socks-proxy je dokumentován pro profily TCP a proxy HTTP CONNECT nemá pro datagramy žádnou cestu. Jeden řádek dokumentace rozhodne o architektuře dřív, než se dotknete konfiguračního souboru.

Otázka tedy není, kterou proxy zvolit. Ale zda se tunel stane proudem, nebo zůstane datagramem a nechá proxyování pohltit něčím jiným.

Varianta A: udělejte z tunelu proud

To vyžaduje server s TCP posluchačem a klientský profil, který proxy pojmenuje. Obě části jsou nutné a na tu serverovou se zapomíná:

proto tcp-client
remote vpn.example.net 443
socks-proxy 127.0.0.1 1080

Nahraďte poslední řádek za http-proxy proxy.internal 8080, když proxy mluví HTTP, a přidejte soubor s přihlašovacími údaji, pokud jej vyžaduje. Proxy musí být ochotna provést CONNECT na váš port VPN a server musí odpovídat na TCP; posluchač pouze na UDP tento pokus ignoruje. Volba 443 je praktický tah, protože mnohé restriktivní sítě povolují ji a máloco jiného.

Cena je TCP naskládané na TCP. Jeden ztracený vnější segment zablokuje každý vnitřní proud, který to spojení sdílí, takže obnova, která by jindy byla nezávislá, se stává sdílenou. Nastavení také trvá déle a nestabilní vnější cesta se změní v nestabilní tunel, ne v pomalý.

Varianta B: nechte tunel na pokoji

Když musí tunel zůstat na UDP, tunel není místo, kde cokoli konfigurujete. Místo toho se odchozí TCP z aplikací přesměruje na místní posluchač SOCKS a aplikace se nikdy nedozvědí, že proxy existuje. Na Linuxu to bývá redsocks spolu s pravidlem NAT REDIRECT v tabulce nat.

Opět jen TCP. Proxy pouze pro HTTP jako privoxy nedokáže přenášet libovolné protokoly a tento návrh aplikacím nepřidá podporu datagramů.

Říct každé aplikaci o proxy přímo je obvykle lepší tam, kde to software podporuje. Snáze se to audituje a selhává to na místě, které skutečně vidíte.

Kde která varianta selhává

Varianta A selhává, když serveru chybí TCP posluchač, když proxy odmítne cíl CONNECT nebo když je vnější proud omezen pod to, co tunel potřebuje. První dvě nechají záznam v logu proxy; třetí nechá spojení, které se naváže a pak působí špatně. Přečtěte si ten log před úpravou profilu, protože odděluje problém oprávnění od problému kapacity. Dokončený CONNECT přesune vyšetřování dovnitř tunelu.

Varianta B selhává u čehokoli, co potřebuje datagramy, u protokolů, kterým proxy nerozumí, a tiše na hostitelích, kde pravidlo přesměrování existuje, ale směrování provoz posílá mimo něj.

Ani jedna varianta nemění požadavek na zařízení. Pakety stále potřebují uzel TUN nebo TAP, než je jádro nasměruje, takže proces stále potřebuje oprávnění na /dev/net/tun. Obal mění, co se stane po otevření toho uzlu, ne to, zda ho potřebujete.

Dokažte, kterou cestu jste postavili

Dívejte se na sockety, ne na ikonu v oznamovací oblasti. Proces VPN má držet navázané spojení s adresou proxy a proxy měla zalogovat cíl, na který byla požádána:

ss -tnp | grep openvpn

Pak se vydejte k cíli, který dokáže obsloužit jen tunel, a k názvu, na který umí odpovědět jen resolver tunelu. Dokončené spojení přes proxy s mrtvým tunelem obvykle znamená, že vzdálená strana nikdy nenabídla transport uvedený ve vašem profilu.

Zapište si transport a přijímající proxy na trvalé místo. Když stejný profil selže v jiné síti, ta poznámka proxy během sekund vyloučí nebo potvrdí.

Související články