Encamiñar o tráfico do host por unha VPN nunha VM: seis comprobacións

Seis comprobacións, executadas en orde, deciden se unha VM pode actuar como pasarela VPN para o seu propio host. O hipervisor non fai nada disto por ti: o convidado posúe o túnel, o host posúe unha ruta, e a rede entre ambos é encamiñamento corrente. Manteno a lista porque saltar un paso sempre produce o mesmo síntoma, silencio, cando o host fai ping ao convidado sen problema e non chega a nada interno.

Comeza polo motivo. Ou o cliente corporativo só se instala dentro do convidado, ou a política manteno alí, e segues necesitando o servidor de compilación interno desde o host. Se o host pode ter o seu propio cliente, fai iso no seu lugar: un túnel no host gaña sempre a dúas redes máis un NAT.

Comprobación 1: o host necesita unha ligazón á que poida dar enderezo

O host debe ter unha interface no mesmo prefixo que o segundo adaptador do convidado. Host-only en VirtualBox, host-only ou un VMnet personalizado en VMware Workstation, unha ponte interna ou dispositivo tap en QEMU/KVM e un conmutador Internal en Hyper-V cumpren todos. Convidado 192.168.56.2, host 192.168.56.1, prefixo 192.168.56.0/24 é a disposición que uso en laboratorios.

A rede QEMU en modo usuario (-netdev user, o backend SLIRP por defecto) e o NAT de VirtualBox fallan esta comprobación de plano. Os paquetes do convidado chegan a un proceso proxy no host, así que o host nunca ve un dispositivo que leve os enderezos do convidado e non ten a que apuntar unha ruta. O Default Switch de Hyper-V é a mesma historia. Se ping 192.168.56.2 desde o host falla, detente: ningunha ruta engadida despois o arranxará.

Comprobación 2: o convidado reenvía e traduce

Os paquetes do host chegan cun enderezo de orixe da rede host-only e un destino interno, así que o convidado debe reenvialos e logo agochalos tras o enderezo do seu túnel. Nun convidado Linux iso significa reenvío, un par FORWARD accept e source NAT cara ao 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

A regra MASQUERADE é a parte que a xente omite. Os routers corporativos raramente saben que 192.168.56.0/24 existe; coa regra, os servidores internos ven o enderezo do túnel do convidado e responden a el, e a resposta atopa o camiño de volta ao convidado.

Un convidado Windows é máis torpe. IPEnableRouter=1 baixo SYSTEM\CurrentControlSet\Services\Tcpip\Parameters activa o reenvío sen tradución, así que só funciona onde o encamiñamento corporativo xa apunta de volta ao teu prefixo host-only. A compartición de conexión a Internet si traduce, pero renumera o adaptador compartido a 192.168.137.1, así que le o enderezo que realmente tomou antes de escribir rutas do host.

Comprobación 3: as rutas do host nomean o convidado, non o túnel

Envía polo convidado só os prefixos que o host necesita. En Linux abonda unha ruta por prefixo e revértese limpamente:

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

En Windows o equivalente é route add 10.20.0.0 mask 255.255.0.0 192.168.56.2. Deixa fóra -p mentres aínda probas, para que unha ruta mala morra ao reiniciar, e engádeo cando o camiño funcione. Non elimines a ruta por defecto do host salvo que todas as aplicacións do host deban usar o túnel; se o túnel completo é de verdade o requisito, engade as dúas rutas /1 e mantén a ruta directa á rede do 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

Nun host Windows, revisa tamén a métrica da interface. Unha ruta engadida mentres o adaptador host-only estaba desactivado queda na táboa pero nunca transporta tráfico, e un segundo adaptador con métrica máis baixa pode gañar a busca para o mesmo prefixo.

Comprobación 4: o DNS segue a ruta, non o defecto do túnel

As rutas moven paquetes; o resolutor decide que nomes producen paquetes. Limita o resolutor corporativo á zona corporativa en lugar de substituír o resolutor do host, e apúntao a un servidor DNS que a nova ruta xa alcanza. Con systemd-resolved no host:

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

En Windows, unha entrada na táboa de directivas de resolución de nomes fai o mesmo traballo: Add-DnsClientNrptRule -Namespace ".corp.example.com" -NameServers 10.20.0.53. Se o convidado executa o seu propio resolutor no enderezo host-only, usa ese enderezo no seu lugar, pero só despois de confirmar que responde en 192.168.56.2 e non en loopback.

Despois revisa a MTU antes de culpar o DNS de páxinas lentas. A interface do túnel é menor que a interface de 1500 bytes do host, así que un host que envía segmentos de tamaño completo co bit DF activado véndoos caer nalgún punto dentro do convidado. O síntoma clásico é un ping que funciona e unha aplicación web interna que se atasca tras o aperto de mans TLS. Aperta a MSS na ruta de reenvío do convidado:

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

Comprobación 5: verifica desde ambos extremos

Desde o host, traceroute ou tracert cara a un enderezo interno debería mostrar 192.168.56.2 como primeiro salto, non a pasarela física. No convidado, observa como sae o mesmo intento: tcpdump -ni any host 10.20.30.40 mostra a petición reenviada no lado host-only e a traducida no túnel. Unha petición que sae, volve e aínda así deixa o host mudo apunta ao camiño de volta.

Dous fallos explican a maior parte diso. Ou o túnel do convidado non leva ruta de volta para o prefixo host-only porque falta a regra NAT, ou a ruta do host apunta a un enderezo que o convidado xa non ten tras un reinicio. Volve ler os enderezos con ip -br addr e ip route get en lugar de fiarche de notas da sesión anterior.

Comprobación 6: fai que sobreviva a un reinicio e a unha actualización do hipervisor

Persiste as dúas metades: configuración de rutas con netplan ou NetworkManager no host, route add ... -p en Windows, e net.ipv4.ip_forward=1 dentro de /etc/sysctl.d/ máis un conxunto de regras de devasa que se recargue no convidado. Fai unha instantánea do convidado en canto se verifique a configuración, antes de que chegue a seguinte actualización do cliente corporativo.

As redes host-only renúmeranse cando o hipervisor recrea os seus adaptadores, o que invalida en silencio cada ruta e regra NAT construída sobre 192.168.56.0/24. Tras unha actualización, volve executar as tres primeiras comprobacións en orde; custa un minuto e atrapa o caso no que o host aínda ten a súa ruta mentres o convidado pasou a unha subrede nova.

IPv6 necesita a súa propia pasada. As regras de ip6tables, os rexistros AAAA e unha segunda familia de rutas do host non seguen a configuración IPv4, e un servizo corporativo accesible por IPv6 parecerá permanentemente roto mentres IPv4 funciona.

Pase ou falle, en orde: o host pode facer ping ao enderezo host-only do convidado; o convidado reenvía e fai MASQUERADE cara ao túnel; ip route get devolve o convidado como pasarela para o prefixo interno; os nomes corporativos resólvense polo resolutor limitado; traceroute mostra o convidado primeiro; e as mesmas seis respostas sobreviven a un reinicio.