Encaminar el trànsit de l'amfitrió per una VPN en una VM: sis comprovacions

Sis comprovacions, executades en ordre, decideixen si una VM pot fer de passarel·la VPN per al seu propi amfitrió. L'hipervisor no fa res d'això per tu: el convidat posseeix el túnel, l'amfitrió posseeix una ruta, i la xarxa entre ells és encaminament corrent. Mantinc la llista perquè saltar-se un pas sempre produeix el mateix símptoma, silenci, quan l'amfitrió fa ping al convidat sense problemes i no arriba a res intern.

Comença pel motiu. O el client corporatiu només s'instal·la dins del convidat, o la política el manté allà, i encara necessites el servidor de compilació intern des de l'amfitrió. Si l'amfitrió pot tenir el seu propi client, fes-ho en lloc d'això: un túnel a l'amfitrió sempre guanya dues xarxes més un NAT.

Comprovació 1: l'amfitrió necessita un enllaç que pugui adreçar

L'amfitrió ha de tenir una interfície al mateix prefix que el segon adaptador del convidat. Host-only a VirtualBox, host-only o un VMnet personalitzat a VMware Workstation, un pont intern o dispositiu tap a QEMU/KVM, i un commutador Internal a Hyper-V compleixen tots. Convidat 192.168.56.2, amfitrió 192.168.56.1, prefix 192.168.56.0/24 és la disposició que faig servir als laboratoris.

La xarxa QEMU en mode usuari (-netdev user, el rerefons SLIRP per defecte) i el NAT de VirtualBox fallen aquesta comprovació de ple. Els paquets del convidat arriben a un procés intermediari a l'amfitrió, així que l'amfitrió mai veu un dispositiu que porti les adreces del convidat i no té on apuntar una ruta. El Default Switch d'Hyper-V és la mateixa història. Si ping 192.168.56.2 des de l'amfitrió falla, atura't: cap ruta afegida després ho arreglarà.

Comprovació 2: el convidat reenvia i tradueix

Els paquets de l'amfitrió arriben amb una adreça d'origen de la xarxa host-only i una destinació interna, així que el convidat els ha de reenviar i després amagar-los darrere l'adreça del seu túnel. En un convidat Linux això vol dir reenviament, una parella FORWARD accept i source NAT cap al túnel:

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

La regla MASQUERADE és la part que la gent deixa fora. Els encaminadors corporatius rares vegades saben que 192.168.56.0/24 existeix; amb la regla, els servidors interns veuen l'adreça del túnel del convidat i hi responen, i la resposta troba el camí de tornada al convidat.

Un convidat Windows és més maldestre. IPEnableRouter=1 sota SYSTEM\CurrentControlSet\Services\Tcpip\Parameters activa el reenviament sense traducció, així que només funciona on l'encaminament corporatiu ja apunta cap al teu prefix host-only. Internet Connection Sharing sí que tradueix, però renumera l'adaptador compartit a 192.168.137.1, així que llegeix l'adreça que realment va prendre abans d'escriure rutes a l'amfitrió.

Comprovació 3: les rutes de l'amfitrió nomenen el convidat, no el túnel

Envia pel convidat només els prefixos que l'amfitrió necessita. A Linux una ruta per prefix és suficient i es reverteix net:

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

A Windows l'equivalent és route add 10.20.0.0 mask 255.255.0.0 192.168.56.2. Deixa fora -p mentre encara proves, perquè una ruta dolenta mori al reinici, i afegeix-lo quan el camí funcioni. No eliminis la ruta per defecte de l'amfitrió tret que totes les aplicacions de l'amfitrió hagin d'usar el túnel; si el túnel complet és realment el requisit, afegeix les dues rutes /1 i mantén la ruta directa cap a la xarxa de l'hipervisor:

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

En un amfitrió Windows, comprova també la mètrica de la interfície. Una ruta afegida mentre l'adaptador host-only estava desactivat es queda a la taula però no porta mai trànsit, i un segon adaptador amb una mètrica més baixa pot guanyar la consulta per al mateix prefix.

Comprovació 4: el DNS segueix la ruta, no el defecte del túnel

Les rutes mouen paquets; el resolutor decideix quins noms produeixen paquets. Limita el resolutor corporatiu a la zona corporativa en lloc de substituir el resolutor de l'amfitrió, i apunta'l a un servidor DNS que la nova ruta ja abasti. Amb systemd-resolved a l'amfitrió:

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

A Windows, una entrada a la taula de polítiques de resolució de noms fa la mateixa feina: Add-DnsClientNrptRule -Namespace ".corp.example.com" -NameServers 10.20.0.53. Si el convidat executa el seu propi resolutor a l'adreça host-only, fes servir aquesta adreça, però només després de confirmar que respon a 192.168.56.2 i no a loopback.

Després comprova l'MTU abans de culpar el DNS de pàgines lentes. La interfície del túnel és més petita que la interfície de 1500 bytes de l'amfitrió, així que un amfitrió que envia segments de mida completa amb el bit DF activat els veu caure en algun punt dins del convidat. El símptoma clàssic és un ping que funciona i una aplicació web interna que s'encalla després de l'apretada de mans TLS. Estrèny l'MSS al camí de reenviament del convidat:

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

Comprovació 5: verifica des dels dos extrems

Des de l'amfitrió, traceroute o tracert cap a una adreça interna hauria de mostrar 192.168.56.2 com a primer salt, no la passarel·la física. Al convidat, mira com surt el mateix intent: tcpdump -ni any host 10.20.30.40 mostra la petició reenviada al costat host-only i la traduïda al túnel. Una petició que surt, torna i encara deixa l'amfitrió mut apunta al camí de tornada.

Dos errors expliquen la major part d'això. O el túnel del convidat no porta cap ruta de tornada per al prefix host-only perquè falta la regla NAT, o la ruta de l'amfitrió apunta a una adreça que el convidat ja no té després d'un reinici. Torna a llegir les adreces amb ip -br addr i ip route get en lloc de confiar en notes de la sessió anterior.

Comprovació 6: fes-ho sobreviure a un reinici i a una actualització de l'hipervisor

Persisteix les dues meitats: configuració de rutes amb netplan o NetworkManager a l'amfitrió, route add ... -p a Windows, i net.ipv4.ip_forward=1 dins de /etc/sysctl.d/ més un conjunt de regles de tallafoc que es recarregui al convidat. Fes una instantània del convidat quan la configuració es verifiqui, abans que arribi la següent actualització del client corporatiu.

Les xarxes host-only es renumeren quan l'hipervisor recrea els seus adaptadors, cosa que invalida en silenci cada ruta i regla NAT construïda sobre 192.168.56.0/24. Després d'una actualització, torna a executar les tres primeres comprovacions en ordre; costa un minut i atrapa el cas en què l'amfitrió encara té la seva ruta mentre el convidat ha passat a una subxarxa nova.

L'IPv6 necessita el seu propi pas. Les regles d'ip6tables, els registres AAAA i una segona família de rutes de l'amfitrió no segueixen la configuració IPv4, i un servei corporatiu accessible per IPv6 semblarà permanentment trencat mentre IPv4 funciona.

Passi o falli, en ordre: l'amfitrió pot fer ping a l'adreça host-only del convidat; el convidat reenvia i fa MASQUERADE cap al túnel; ip route get retorna el convidat com a passarel·la per al prefix intern; els noms corporatius es resolen pel resolutor limitat; traceroute mostra el convidat primer; i les mateixes sis respostes sobreviuen a un reinici.