Směrování provozu hostitele přes VPN ve VM: šest kontrol

Šest kontrol provedených v pořadí rozhoduje, zda VM může být VPN bránou pro svého vlastního hostitele. Hypervizor za vás nic z toho neudělá: tunel vlastní host, trasu vlastní hostitel a síť mezi nimi je běžné směrování. Seznam si držím proto, že vynechání jednoho kroku vždy dá stejný příznak, ticho, kdy hostitel vesele pinguje hosta a nedostane se k ničemu internímu.

Začněte důvodem. Buď se firemní klient instaluje jen uvnitř hosta, nebo ho tam drží politika, a vy přesto potřebujete interní build server z hostitele. Pokud hostitel smí mít vlastního klienta, udělejte to místo toho: jeden tunel na hostiteli je vždy lepší než dvě sítě plus NAT.

Kontrola 1: hostitel potřebuje spojení, kterému umí přidělit adresu

Hostitel musí mít rozhraní ve stejném prefixu jako druhý adaptér hosta. Host-only ve VirtualBoxu, host-only nebo vlastní VMnet ve VMware Workstation, interní most nebo tap zařízení v QEMU/KVM a Internal switch v Hyper-V vyhovují všechny. Host 192.168.56.2, hostitel 192.168.56.1, prefix 192.168.56.0/24 je uspořádání, které v laboratořích používám.

Síť QEMU v uživatelském režimu (-netdev user, výchozí backend SLIRP) a VirtualBox NAT touto kontrolou zcela propadají. Pakety hosta dorazí k proxy procesu na hostiteli, takže hostitel nikdy nevidí zařízení, které nese adresy hosta, a nemá kam trasu nasměrovat. Default Switch v Hyper-V je stejný příběh. Pokud ping 192.168.56.2 z hostitele neprojde, zastavte se: žádná později přidaná trasa to nespraví.

Kontrola 2: host předává a překládá

Pakety z hostitele přicházejí se zdrojovou adresou z host-only sítě a interním cílem, takže je host musí předat a pak schovat za adresu svého tunelu. Na Linux hostovi to znamená předávání, dvojici pravidel FORWARD accept a source NAT směrem k tunelu:

sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -A FORWARD -i eth1 -o tun0 -j ACCEPT
sudo iptables -A FORWARD -i tun0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -t nat -A POSTROUTING -s 192.168.56.0/24 -o tun0 -j MASQUERADE

Pravidlo MASQUERADE je ta část, kterou lidé vynechávají. Firemní routery málokdy vědí, že 192.168.56.0/24 existuje; s pravidlem interní servery vidí adresu tunelu hosta a odpovídají na ni, a odpověď si najde cestu zpět k hostovi.

Windows host je nemotornější. IPEnableRouter=1 pod SYSTEM\CurrentControlSet\Services\Tcpip\Parameters zapíná předávání bez překladu, takže funguje jen tam, kde firemní směrování už ukazuje zpět na váš host-only prefix. Internet Connection Sharing překládá, ale přečísluje sdílený adaptér na 192.168.137.1, takže si přečtěte adresu, kterou skutečně zaujal, než začnete psát trasy hostitele.

Kontrola 3: trasy hostitele jmenují hosta, ne tunel

Přes hosta posílejte jen prefixy, které hostitel potřebuje. Na Linuxu stačí jedna trasa na prefix a vrací se čistě:

sudo ip route add 10.20.0.0/16 via 192.168.56.2
ip route get 10.20.30.40

Na Windows je ekvivalentem route add 10.20.0.0 mask 255.255.0.0 192.168.56.2. Nechte -p vynechané, dokud testujete, aby špatná trasa zemřela při restartu, a přidejte ho, až cesta funguje. Neodstraňujte výchozí trasu hostitele, pokud nemá tunel používat každá aplikace na hostiteli; pokud je plný tunel opravdu požadavek, přidejte dvě trasy /1 a ponechte přímou trasu do sítě hypervizoru:

sudo ip route add 0.0.0.0/1 via 192.168.56.2
sudo ip route add 128.0.0.0/1 via 192.168.56.2

Na Windows hostiteli zkontrolujte také metriku rozhraní. Trasa přidaná, když byl host-only adaptér vypnutý, zůstane v tabulce, ale nikdy nenese provoz, a druhý adaptér s nižší metrikou může vyhrát vyhledání pro stejný prefix.

Kontrola 4: DNS jde za trasou, ne za výchozím nastavením tunelu

Trasy posouvají pakety; překladač rozhoduje, která jména pakety vytvářejí. Omezte firemní překladač na firemní zónu místo nahrazení překladače hostitele a nasměrujte ho na DNS server, který nová trasa už dosáhne. Se systemd-resolved na hostiteli:

resolvectl dns eth1 10.20.0.53
resolvectl domain eth1 '~corp.example.com'

Na Windows totéž udělá záznam v tabulce zásad překladu jmen: Add-DnsClientNrptRule -Namespace ".corp.example.com" -NameServers 10.20.0.53. Pokud host provozuje vlastní překladač na host-only adrese, použijte tuto adresu, ale až po ověření, že odpovídá na 192.168.56.2, a ne na loopback.

Potom zkontrolujte MTU, než obviníte DNS z pomalých stránek. Rozhraní tunelu je menší než 1500bajtové rozhraní hostitele, takže hostitel, který posílá segmenty plné velikosti s nastaveným bitem DF, je nechá někde uvnitř hosta zahodit. Klasickým příznakem je fungující ping a interní webová aplikace, která se po TLS handshake zasekne. Stáhněte MSS na předávací cestě v hostovi:

sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Kontrola 5: ověřte z obou konců

Z hostitele by traceroute nebo tracert na interní adresu měly ukázat 192.168.56.2 jako první skok, ne fyzickou bránu. V hostovi sledujte, jak stejný pokus odchází: tcpdump -ni any host 10.20.30.40 ukazuje předaný požadavek na host-only straně a přeložený na tunelu. Požadavek, který odejde, vrátí se a přesto nechá hostitele němým, ukazuje na zpáteční cestu.

Většinu toho vysvětlují dvě selhání. Buď tunel hosta nenese zpáteční trasu pro host-only prefix, protože chybí pravidlo NAT, nebo trasa hostitele ukazuje na adresu, kterou host po restartu už nemá. Přečtěte adresy znovu pomocí ip -br addr a ip route get místo spoléhání na poznámky z minulé relace.

Kontrola 6: přežijte restart i upgrade hypervizoru

Zachovejte obě poloviny: konfiguraci tras netplan nebo NetworkManager na hostiteli, route add ... -p na Windows a net.ipv4.ip_forward=1 v /etc/sysctl.d/ plus sadu pravidel firewallu, která se v hostovi znovu načte. Pořiďte snapshot hosta, jakmile se konfigurace ověří, dřív než dorazí další aktualizace firemního klienta.

Host-only sítě se přečíslují, když hypervizor znovu vytvoří své adaptéry, což tiše zneplatní každou trasu a pravidlo NAT postavené na 192.168.56.0/24. Po upgradu zopakujte první tři kontroly v pořadí; zabere to minutu a zachytí případ, kdy hostitel má svou trasu dál, zatímco host přešel do nové podsítě.

IPv6 potřebuje vlastní průchod. Pravidla ip6tables, záznamy AAAA a druhá rodina tras hostitele nenásledují nastavení IPv4 a firemní služba dostupná přes IPv6 bude vypadat trvale rozbitá, zatímco IPv4 funguje.

Ať projde, nebo ne, v pořadí: hostitel umí pingnout host-only adresu hosta; host předává a dělá MASQUERADE směrem k tunelu; ip route get vrací hosta jako bránu pro interní prefix; firemní jména se překládají přes omezený překladač; traceroute ukazuje hosta jako první; a stejných šest odpovědí přežije restart.