Aplikace ve jmenném prostoru VPN není z LAN dostupná

Síťový jmenný prostor dává jednomu programu vlastní tunel a vlastní smyčku. Publikujte jen jeho port přes socatový skok nebo pár veth, místo abyste vystavili hostitele.

Vaše služba na stroji běží, tunel je nahoře, a přesto prohlížeč na vašem stole stále čeká na odpověď. V obvyklém smyslu nic nefunguje špatně: aplikace poslouchá uvnitř síťového jmenného prostoru a ten stack je pro LAN neviditelný. Její loopback patří jmennému prostoru, takže klient na jiném stroji nemá adresu, která by dosáhla na port. Jeden záměrný skok nebo jedna dvojice veth to spraví, aniž byste přesouvali zbytek hostitele.

Proč na adrese LAN nic neodpovídá

Jmenný prostor je kompletní síťový stack: rozhraní, trasy, pravidla firewallu a soukromý loopback. Proces spuštěný přes ip netns exec vidí tento stack a nic jiného, takže adresa, kterou naváže, se překládá jen uvnitř jmenného prostoru. Vlastní 127.0.0.1 hostitele je úplně jiný loopback.

Proto curl na hostiteli selže, zatímco stejný příkaz uvnitř jmenného prostoru uspěje. Aplikace je v pořádku; adresa ve stacku hostitele prostě neexistuje.

Publikujte jeden port skokem přes socat

socat propojuje oba stacky v uživatelském prostoru, což stačí, když má projít jediný port TCP. Strana hostitele poslouchá na LAN a pro každé přijaté spojení spustí druhý socat uvnitř jmenného prostoru, který se připojí k loopbacku aplikace. Vnitřní proces dosáhne aplikace přesně jako místní klient. Na směrování jmenného prostoru se nic nemění, takže aplikace dál používá tunel jako jediný východ.

socat TCP-LISTEN:9100,reuseaddr,fork EXEC:'ip netns exec vpn socat STDIO tcp-connect:127.0.0.1:9100',nofork

Vnější proces potřebuje root nebo schopnost vstoupit do jmenného prostoru. Pokud VPN spadne, aplikace ztratí cestu a publikovaný port selže zavřený, což je chování, které od vězení chcete.

Použijte pár veth, když prochází víc než jeden port

Pár veth je správná odpověď, když má projít několik portů nebo protokolů, nebo když mají jiní hostitelé zahajovat spojení. Jeden konec zůstane v hostiteli, druhý se přesune do jmenného prostoru a malá /30 dá oběma stranám stabilní adresu. Trasa hostitele pak posílá adresu jmenného prostoru přes pár.

ip link add veth0 type veth peer name veth1
ip link set veth1 netns vpn
ip addr add 10.77.0.1/30 dev veth0
ip link set veth0 up
ip netns exec vpn ip addr add 10.77.0.2/30 dev veth1
ip netns exec vpn ip link set veth1 up

Nepřidávejte výchozí trasu přes hostitele, pokud nechcete vězení rozbít. Tunel má zůstat východem, takže přes pár je dostupná jen publikovaná adresa služby. Dejte jmennému prostoru i vlastní soubor resolveru, protože ip netns exec čte /etc/netns/vpn/resolv.conf a bez něj je překlad jmen uvnitř vězení prázdný.

Testujte z jiného stroje, ne z hostitele

Spusťte test z druhého stroje, protože hostitel může dosáhnout místního posluchače cestami, které o LAN nic neříkají. Nejdřív zkontrolujte, na co se aplikace uvnitř jmenného prostoru skutečně navázala, a pak se zvenčí připojte k publikované adrese. Navázání na všechny adresy tam vězení nerozšíří, protože divoká karta pořád patří jmennému prostoru a LAN ji nevidí.

ip netns exec vpn ss -lntp

Pokud spojení z hostitele funguje a spojení z LAN ne, chybějícím dílem je skok nebo trasa, ne adresa navázání. Spusťte OpenVPN uvnitř jmenného prostoru, místo abyste tam přesouvali živé zařízení tun, protože přesun rozhraní ho vypne a může smazat trasy, které pak zvenčí neopravíte. Záložní příkazy mějte na konzoli, ne uvnitř vězení.

Související články