A gazdagép forgalmának irányítása VPN-en át VM-ben: hat ellenőrzés

Hat ellenőrzés, sorrendben végrehajtva, eldönti, lehet-e egy VM a saját gazdagépe VPN-átjárója. A hypervisor ebből semmit nem tesz meg helyetted: az alagút a vendégé, az útvonal a gazdagépé, és a köztük lévő hálózat közönséges forgalomirányítás. Azért tartom ezt a listát, mert egy lépés kihagyása mindig ugyanazt a tünetet adja, a csendet, amikor a gazdagép vidáman pingeli a vendéget és semmi belsőt nem ér el.

Kezdd az okkal. Vagy csak a vendégen belül lehet telepíteni a vállalati klienst, vagy a szabályzat ott tartja, és neked mégis kell a belső build-kiszolgáló a gazdagépről. Ha a gazdagép saját klienst kaphat, inkább tedd azt: egy alagút a gazdagépen mindig veri a két hálózatot plusz egy NAT-ot.

1. ellenőrzés: a gazdagépnek olyan kapcsolat kell, amelynek címet adhat

A gazdagépnek olyan interfésszel kell rendelkeznie, amely a vendég második adapterével azonos prefixben van. Host-only a VirtualBoxban, host-only vagy egyedi VMnet a VMware Workstationben, belső híd vagy tap-eszköz a QEMU/KVM-ben, és Internal kapcsoló a Hyper-V-ben mind megfelel. Vendég 192.168.56.2, gazdagép 192.168.56.1, prefix 192.168.56.0/24 az az elrendezés, amelyet laborokban használok.

A QEMU felhasználói módú hálózatkezelése (-netdev user, az alapértelmezett SLIRP háttér) és a VirtualBox NAT teljesen megbukik ezen az ellenőrzésen. A vendég csomagjai eljutnak egy proxyfolyamathoz a gazdagépen, így a gazdagép soha nem lát olyan eszközt, amely a vendég címeit hordozza, és nincs mire útvonalat mutatnia. A Hyper-V Default Switch ugyanaz a történet. Ha a ping 192.168.56.2 a gazdagépről nem megy, állj meg: semmilyen később hozzáadott útvonal nem javítja meg.

2. ellenőrzés: a vendég továbbít és átalakít

A gazdagépről érkező csomagok host-only forráscímmel és belső céllal jönnek, ezért a vendégnek továbbítania kell őket, majd el kell rejtenie őket az alagút címe mögé. Linux vendégen ez továbbítást, egy FORWARD accept párt és az alagút felé irányuló source NAT-ot jelent:

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

A MASQUERADE szabály az a rész, amelyet az emberek kihagynak. A vállalati routerek ritkán tudják, hogy létezik a 192.168.56.0/24; a szabállyal a belső kiszolgálók látják a vendég alagút-címét és válaszolnak rá, a válasz pedig megtalálja az utat vissza a vendéghez.

Egy Windows vendég ügyetlenebb. A IPEnableRouter=1 a SYSTEM\CurrentControlSet\Services\Tcpip\Parameters alatt átalakítás nélkül kapcsolja be a továbbítást, így csak ott működik, ahol a vállalati forgalomirányítás már visszamutat a host-only prefixre. Az Internet Connection Sharing átalakít, de átszámozza a megosztott adaptert 192.168.137.1-re, ezért olvasd ki a címet, amelyet valóban felvett, mielőtt gazdagép-útvonalakat írsz.

3. ellenőrzés: a gazdagép-útvonalak a vendéget nevezik meg, nem az alagutat

Csak azokat a prefixeket küldd át a vendégen, amelyekre a gazdagépnek szüksége van. Linuxon prefixenként egy útvonal elég, és tisztán visszafordul:

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

Windowson a megfelelője a route add 10.20.0.0 mask 255.255.0.0 192.168.56.2. Hagyd ki a -p-t, amíg tesztelsz, hogy egy rossz útvonal meghaljon újraindításkor, és add hozzá, amikor az útvonal működik. Ne távolítsd el a gazdagép alapértelmezett útvonalát, hacsak nem kell minden gazdagép-alkalmazásnak az alagutat használnia; ha a teljes alagút tényleg a követelmény, add hozzá a két /1 útvonalat, és tartsd meg a hypervisor hálózata felé vezető közvetlen útvonalat:

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

Windows gazdagépen az interfész metrikáját is ellenőrizd. Az az útvonal, amelyet a host-only adapter letiltott állapotában adtak hozzá, a táblában marad, de soha nem visz forgalmat, és egy alacsonyabb metrikájú második adapter megnyerheti ugyanazon prefix keresését.

4. ellenőrzés: a DNS az útvonalat követi, nem az alagút alapértelmezését

Az útvonalak csomagokat mozgatnak; a feloldó dönti el, mely nevek hoznak létre csomagokat. Korlátozd a vállalati feloldót a vállalati zónára ahelyett, hogy lecserélnéd a gazdagép feloldóját, és irányítsd olyan DNS-kiszolgálóra, amelyet az új útvonal már elér. systemd-resolved használatával a gazdagépen:

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

Windowson ugyanezt teszi egy bejegyzés a névfeloldási házirendtáblában: Add-DnsClientNrptRule -Namespace ".corp.example.com" -NameServers 10.20.0.53. Ha a vendég saját feloldót futtat a host-only címen, inkább azt a címet használd, de csak miután megerősítetted, hogy a 192.168.56.2-n válaszol, és nem a loopbacken.

Utána ellenőrizd az MTU-t, mielőtt a DNS-t hibáztatnád a lassú oldalakért. Az alagút interfésze kisebb, mint a gazdagép 1500 bájtos interfésze, ezért a DF-bittel küldött teljes méretű szegmenseket a gazdagép valahol a vendégen belül eldobja. A klasszikus tünet egy működő ping és egy belső webalkalmazás, amely a TLS-kézfogás után elakad. Szorítsd be az MSS-t a vendég továbbítási útvonalán:

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

5. ellenőrzés: mindkét végéről ellenőrizd

A gazdagépről a traceroute vagy a tracert egy belső címre az első ugrásként a 192.168.56.2-t mutassa, ne a fizikai átjárót. A vendégben figyeld, hogyan lép ki ugyanez a kísérlet: a tcpdump -ni any host 10.20.30.40 a host-only oldalon a továbbított kérést, az alagúton az átalakítottat mutatja. Az a kérés, amely kimegy, visszajön, és a gazdagépet mégis csendben hagyja, a visszaútra mutat.

Két hiba magyarázza ennek nagy részét. Vagy nem hordoz a vendég alagútja visszaútvonalat a host-only prefixhez, mert hiányzik a NAT-szabály, vagy a gazdagép-útvonal olyan címre mutat, amellyel a vendég újraindítás után már nem rendelkezik. Olvasd ki újra a címeket a ip -br addr és a ip route get segítségével, ahelyett hogy az előző munkamenet jegyzeteire hagyatkoznál.

6. ellenőrzés: tedd túlélőképessé újraindításra és hypervisor-frissítésre

Tartsd meg mindkét felét: netplan vagy NetworkManager útvonalkonfiguráció a gazdagépen, route add ... -p Windowson, és net.ipv4.ip_forward=1 a /etc/sysctl.d/-ben, valamint egy tűzfalszabály-készlet, amely a vendégben újratöltődik. Készíts pillanatképet a vendégről, amint a konfiguráció ellenőrizve van, mielőtt a következő vállalati kliensfrissítés megérkezik.

A host-only hálózatok újraszámozódnak, amikor a hypervisor újra létrehozza az adaptereit, ami csendesen érvénytelenít minden útvonalat és NAT-szabályt, amely a 192.168.56.0/24-re épült. Frissítés után futtasd újra az első három ellenőrzést sorrendben; ez egy percet vesz igénybe, és elkapja azt az esetet, amikor a gazdagépnek még megvan az útvonala, míg a vendég új alhálózatra költözött.

Az IPv6-nak saját kör kell. A ip6tables szabályai, az AAAA-rekordok és egy második gazdagép-útvonalcsalád nem követik az IPv4 beállításait, és egy IPv6-on elérhető vállalati szolgáltatás tartósan töröttnek fog látszani, miközben az IPv4 működik.

Átment vagy nem, sorrendben: a gazdagép pingelheti a vendég host-only címét; a vendég továbbít és MASQUERADE-el az alagút felé; a ip route get visszaadja a vendéget átjáróként a belső prefixhez; a vállalati nevek a korlátozott feloldón keresztül oldódnak fel; a traceroute a vendéget mutatja elsőként; és ugyanaz a hat válasz túléli az újraindítást.