Smerovanie prevádzky hostiteľa cez VPN vo VM: šesť kontrol

Šesť kontrol vykonaných v poradí rozhoduje, či VM môže byť VPN bránou pre svojho vlastného hostiteľa. Hypervizor za vás nič z toho neurobí: tunel vlastní hosť, trasu vlastní hostiteľ a sieť medzi nimi je bežné smerovanie. Držím sa tohto zoznamu, pretože vynechanie jedného kroku vždy dá rovnaký príznak, ticho, keď hostiteľ veselo pinguje hosťa a nedostane sa k ničomu internému.

Začnite dôvodom. Buď sa firemný klient inštaluje len vnútri hosťa, alebo ho tam drží politika, a vy napriek tomu potrebujete interný build server z hostiteľa. Ak hostiteľ smie mať vlastného klienta, urobte to namiesto toho: jeden tunel na hostiteľovi vždy porazí dve siete plus NAT.

Kontrola 1: hostiteľ potrebuje spojenie, ktorému vie prideliť adresu

Hostiteľ musí mať rozhranie v tom istom prefixe ako druhý adaptér hosťa. Host-only vo VirtualBoxe, host-only alebo vlastný VMnet vo VMware Workstation, interný most alebo tap zariadenie v QEMU/KVM a Internal prepínač v Hyper-V vyhovujú všetky. Hosť 192.168.56.2, hostiteľ 192.168.56.1, prefix 192.168.56.0/24 je usporiadanie, ktoré v laboratóriách používam.

Sieť QEMU v používateľskom režime (-netdev user, predvolený backend SLIRP) a VirtualBox NAT touto kontrolou úplne prepadajú. Pakety hosťa dorazia k proxy procesu na hostiteľovi, takže hostiteľ nikdy nevidí zariadenie, ktoré nesie adresy hosťa, a nemá kam trasu nasmerovať. Default Switch v Hyper-V je rovnaký príbeh. Ak ping 192.168.56.2 z hostiteľa neprejde, zastavte sa: žiadna neskôr pridaná trasa to nespraví.

Kontrola 2: hosť preposiela a prekladá

Pakety z hostiteľa prichádzajú so zdrojovou adresou z host-only siete a interným cieľom, takže ich hosť musí preposlať a potom schovať za adresu svojho tunela. Na Linux hostovi to znamená preposielanie, dvojicu pravidiel FORWARD accept a source NAT smerom 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 tá časť, ktorú ľudia vynechávajú. Firemné routery málokedy vedia, že 192.168.56.0/24 existuje; s pravidlom interné servery vidia adresu tunela hosťa a odpovedajú na ňu, a odpoveď si nájde cestu späť k hosťovi.

Windows hosť je nemotomejší. IPEnableRouter=1 pod SYSTEM\CurrentControlSet\Services\Tcpip\Parameters zapína preposielanie bez prekladu, takže funguje len tam, kde firemné smerovanie už ukazuje späť na váš host-only prefix. Internet Connection Sharing prekladá, ale prečísluje zdieľaný adaptér na 192.168.137.1, takže si prečítajte adresu, ktorú skutočne zaujal, skôr než začnete písať trasy hostiteľa.

Kontrola 3: trasy hostiteľa pomenúvajú hosťa, nie tunel

Cez hosťa posielajte len prefixy, ktoré hostiteľ potrebuje. Na Linuxe stačí jedna trasa na prefix a vracia sa čisto:

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

Na Windows je ekvivalentom route add 10.20.0.0 mask 255.255.0.0 192.168.56.2. Nechajte -p vynechané, kým testujete, aby zlá trasa zomrela pri reštarte, a pridajte ho, keď cesta funguje. Neodstraňujte predvolenú trasu hostiteľa, ak nemá tunel používať každá aplikácia na hostiteľovi; ak je plný tunel naozaj požiadavka, pridajte dve trasy /1 a ponechajte priamu trasu do siete hypervizora:

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 hostiteľovi skontrolujte aj metriku rozhrania. Trasa pridaná, keď bol host-only adaptér vypnutý, zostane v tabuľke, ale nikdy nenesie prevádzku, a druhý adaptér s nižšou metrikou môže vyhrať vyhľadávanie pre ten istý prefix.

Kontrola 4: DNS ide za trasou, nie za predvoleným tunelom

Trasy posúvajú pakety; prekladač rozhoduje, ktoré názvy vytvárajú pakety. Obmedzte firemný prekladač na firemnú zónu namiesto nahradenia prekladača hostiteľa a nasmerujte ho na DNS server, ktorý nová trasa už dosahuje. So systemd-resolved na hostiteľovi:

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

Na Windows to isté urobí záznam v tabuľke zásad prekladu názvov: Add-DnsClientNrptRule -Namespace ".corp.example.com" -NameServers 10.20.0.53. Ak hosť prevádzkuje vlastný prekladač na host-only adrese, použite túto adresu, ale až po overení, že odpovedá na 192.168.56.2 a nie na loopback.

Potom skontrolujte MTU, kým obviníte DNS z pomalých stránok. Rozhranie tunela je menšie ako 1500-bajtové rozhranie hostiteľa, takže hostiteľ, ktorý posiela segmenty plnej veľkosti s nastaveným bitom DF, ich nechá niekde vnútri hosťa zahodiť. Klasickým príznakom je fungujúci ping a interná webová aplikácia, ktorá sa po TLS handshake zasekne. Stiahnite MSS na preposielacej ceste v hosťovi:

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

Kontrola 5: overte z oboch koncov

Z hostiteľa by traceroute alebo tracert na internú adresu mali ukázať 192.168.56.2 ako prvý skok, nie fyzickú bránu. V hosťovi sledujte, ako ten istý pokus odchádza: tcpdump -ni any host 10.20.30.40 ukazuje preposlanú požiadavku na host-only strane a preloženú na tuneli. Požiadavka, ktorá odíde, vráti sa a napriek tomu nechá hostiteľa nemým, ukazuje na spiatočnú cestu.

Väčšinu toho vysvetľujú dve zlyhania. Buď tunel hosťa nenesie spiatočnú trasu pre host-only prefix, pretože chýba pravidlo NAT, alebo trasa hostiteľa ukazuje na adresu, ktorú hosť po reštarte už nemá. Prečítajte adresy znova pomocou ip -br addr a ip route get namiesto spoliehania sa na poznámky z minulej relácie.

Kontrola 6: prežite reštart aj upgrade hypervizora

Zachovajte obe polovice: konfiguráciu trás netplan alebo NetworkManager na hostiteľovi, route add ... -p na Windows a net.ipv4.ip_forward=1 v /etc/sysctl.d/ plus sadu pravidiel firewallu, ktorá sa v hosťovi znova načíta. Urobte snapshot hosťa, hneď ako sa konfigurácia overí, predtým než dorazí ďalšia aktualizácia firemného klienta.

Host-only siete sa prečíslujú, keď hypervizor znova vytvorí svoje adaptéry, čo ticho zneplatní každú trasu a pravidlo NAT postavené na 192.168.56.0/24. Po upgrade zopakujte prvé tri kontroly v poradí; zaberie to minútu a zachytí prípad, keď hostiteľ má svoju trasu ešte stále, zatiaľ čo hosť prešiel do novej podsiete.

IPv6 potrebuje vlastný prechod. Pravidlá ip6tables, záznamy AAAA a druhá rodina trás hostiteľa nenasledujú nastavenie IPv4 a firemná služba dostupná cez IPv6 bude vyzerať trvalo pokazená, kým IPv4 funguje.

Prešlo alebo nie, v poradí: hostiteľ vie pingnúť host-only adresu hosťa; hosť preposiela a robí MASQUERADE smerom k tunelu; ip route get vracia hosťa ako bránu pre interný prefix; firemné názvy sa prekladajú cez obmedzený prekladač; traceroute ukazuje hosťa ako prvého; a tých istých šesť odpovedí prežije reštart.