OpenVPN přes SOCKS5: slaďte verzi, transport a DNS

SOCKS řetěz selže, když se neshoduje verze proxy, transport nebo cesta DNS. Použijte SOCKS5, přenášejte TCP a držte řetěz v namespace.

Jedna cesta z této pracovní stanice je SOCKS proxy a OpenVPN za ní hlásí timeout připojení bez jakékoli užitečné informace. Prohlížeč na stejném stroji přes tuto proxy funguje, přihlašovací údaje jsou správné a port odpovídá. Tři věci se často liší natolik, že je třeba je zkontrolovat jako první: verze SOCKS, kterou proxy mluví, transport, který klient zvolil, a kde probíhá překlad jmen. Potvrďte každou z nich, než rozhodnete, že je na vině firewall.

Slaďte verzi SOCKS dřív než firewall

Komunitní OpenVPN mluví SOCKS5 pro socks-proxy. Namiřte ho na proxy, která nabízí jen SOCKS4, a TCP spojení se otevře, pak však ustrne, protože klient čeká na odpověď na pozdrav, který druhý konec nikdy neparsuje. Zvenku vypadá to ustrnutí přesně jako filtrovaný port, a proto otázka verze přichází před každým pravidlem firewallu. SOCKS dotaz to vyřeší jediným příkazem.

curl --socks5-hostname 127.0.0.1:9050 gw.lab.example

Dokončený požadavek dokazuje dvě věci najednou: proxy přijala SOCKS požadavek a přeložila jméno. Žádné schéma URL není potřeba, protože curl považuje holý hostitel za HTTP, což tomuto testu stačí.

Tento dotaz také vylučuje selhání, které klientský log skrývá. Proxy může prohlížeči povolit přístup a přesto odmítnout cíl VPN, přičemž odmítnutí nastane při CONNECT, před jakoukoli autentizací VPN. OpenVPN hlásí jen timeout, takže odpověď samotné proxy je důkaz, který potřebujete.

Transport musí být TCP na obou stranách

SOCKS5 zde přenáší TCP proud, takže tunel sám potřebuje proto tcp-client. Profil stále nastavený na UDP touto cestou nefunguje, protože klient nepoužívá asociativní režim UDP tohoto protokolu. Přepnutí profilu je skutečná změna, ne formalita: druhý konec musí na stejném portu poslouchat na TCP. Užitečné zatížení se pak stane TCP uvnitř TCP, kde se ztracený segment přenáší dvakrát a tempo se zhoršuje, což interaktivní relace pocítí mnohem víc než velké přenosy.

proto tcp-client
remote gw.lab.example 8443
socks-proxy 127.0.0.1 9050

Direktiva bere hostitele proxy, volitelný port a volitelný soubor s přihlašovacími údaji. Dejte je do samotného profilu, aby se kopie jinde chovala stejně.

Uzavřete celý řetěz do jednoho kontejneru

Dělat řetěz na hostiteli znamená převzít jeho výchozí trasu a nechat resolver ve stavu, který nikdo později nevysvětlí. Namespace nebo kontejner to místo toho ohraničí, takže hostitel si drží svou cestu, zatímco SOCKS skok a tunel žijí spolu. Uvnitř nic neběží bez tunelového zařízení, práv k jeho konfiguraci a dostupné proxy. Služba Compose to získá pomocí cap_add: NET_ADMIN a bindovaného /dev/net/tun.

cap_add:
  - NET_ADMIN
devices:
  - /dev/net/tun:/dev/net/tun

Tato dvojice je užší než spouštění kontejneru s privilegii a tvoří celý potřebný přístup k zařízení. Posluchače může dodat klient Tor nebo samostatný proxy kontejner. V obou případech ho připněte na loopback a z namespace se k němu dostávejte přes hostitele, místo abyste proxy vystavovali síti.

Překlad jmen je místo, kde izolace selhává

Tunel, který přenáší pakety, ale ptá se resolveru hostitele, nic neizoloval. Izolaci činí skutečnou dvě věci: namespace má vlastní resolver a jeho dotazy putují přes proxy nebo tunel, nikdy po fyzickém rozhraní. Pro test použijte dvě jména: jedno, které existuje jen za tunelem, a veřejné, které by mělo jít stejnou cestou.

docker compose exec vpn cat /etc/resolv.conf
docker compose exec vpn getent hosts internal.lab.example

Pokud se jméno na vzdálené straně přeloží a veřejné ne, řetěz je selektivní, nikoli rozbitý, a rozdíl vám řekne, kterou cestou každý dotaz šel. Pokud se obě přeloží z hostitele, ale žádné uvnitř kontejneru, kontejner si stále půjčuje resolver hostitele. Zapište soubor resolveru, který jste našli, protože to je nastavení, které se musí změnit.

Dokažte každý skok popořadě

Seznam je krátký. SOCKS5 požadavek dostane odpověď, tunel se přes proxy dostane ke svému posluchači a pakety opouštějící namespace nesou adresu, kterou vzdálená strana očekává. Potvrzujte každý jednotlivě, místo abyste přidávali další konfiguraci. Když klient hlásí připojeno a nic se nehýbe, zlom je téměř vždy ve druhé nebo třetí skutečnosti.

curl --socks5-hostname 127.0.0.1:9050 gw.lab.example
docker compose exec vpn ip route get 203.0.113.10
docker compose exec vpn getent hosts internal.lab.example

Zapište kombinaci, která fungovala: verze SOCKS, transport, resolver a nastavení namespace. Vyřešit tento řetěz podruhé z paměti stojí víc než poznámka. Držte ty čtyři skutečnosti v tiketu, ne ve vlákně chatu.

Řetěz, který hlásí připojení a nic nepropouští, obvykle selhal ve skoku, který jste ještě nedokázali. Otestujte ten skok, než přidáte další vrstvu.

Související články