A túa VM usa a VPN do host? Compárao desde dentro do convidado

Comprobas o IP público do host, amosa a VPN e conclúes que a VM está cuberta. Esa conclusión non a respalda a proba. Un convidado ten a súa propia táboa de enrutamento, o seu propio resolvedor e as súas propias interfaces, e o enderezo de saída do host non di nada sobre elas.

A proba debe executarse dentro do convidado e debe nomear que mediu.

Comeza dentro do convidado, non no navegador do host

Anota primeiro o modo de rede do hipervisor: NAT, bridged, host-only ou macvtap. En modo NAT o host enruta o tráfico do convidado, así que o túnel do host pode aplicarse ou non segundo como o cliente instale as rutas. En modo bridged o convidado é un par na LAN física e o túnel do host é irrelevante. Esos dous modos dan respostas opostas coa mesma configuración do host.

Anota o modo antes de cambiar nada, porque determina que pode significar o resultado.

Fai unha petición cuxo destino coñezas

Usa unha petición inocua a un servizo que informe do enderezo de orixe que viu. Despois comproba a decisión de enrutamento do propio convidado para ese destino: ip route get 203.0.113.5 imprime a interface e a porta de enlace que usará o convidado.

Se a interface é a NIC normal do convidado, o tráfico non pasa por ningún túnel dentro do convidado.

Un segundo adaptador, un axuste de proxy ou un cliente VPN do lado do convidado poden cambiar a resposta para unha aplicación e non para outra. Proba a aplicación que de verdade che importa, non unha petición xenérica desde un shell.

Comproba o resolvedor por separado

Un enderezo de saída distinto non che di que resolvedor xestionou o nome do host. Consulta o nome de forma explícita coa ferramenta que corresponda á plataforma e anota que servidor respondeu. Un DNS dividido significa que a pregunta do resolvedor e a do enrutamento teñen respostas distintas.

Esas dúas poden diverxer en calquera dirección, e a diverxencia adoita ser o fallo real.

Nun host con systemd, resolvectl query nomea a interface e o servidor DNS que hai detrás da resposta. As instalacións máis antigas amosan o servidor na saída de dig — en calquera caso, a cuestión é ver que servidor respondeu, non só se chegou unha resposta.

Proba a política de fallo, non só o éxito

Se o requisito é que ningún tráfico saia fóra do túnel, unha petición correcta non demostra nada. Usa a proba de fallo controlada compatible co cliente: detén o túnel da forma admitida e comproba se se bloquea unha nova petición do convidado. Non deas por feito que o kill switch do cliente do host cobre calquera disposición de reenvío virtual. O seu alcance documentado é o único co que podes contar.

Un convidado que volve á NIC física cando cae o túnel fai exactamente o que permite o modo NAT.

Anota o modo e o alcance

Anota o modo do hipervisor, a interface e a ruta do convidado, o resolvedor e a aplicación que probaches. Engade a data, porque restaurar unha instantánea ou actualizar o hipervisor pode cambiar as catro cousas.

Se IPv4 seguiu o túnel, díxoo. Non estendas a afirmación a IPv6, a outro espazo de nomes nin a outra VM noutra rede.