A sua VM usa a VPN do host? Teste por dentro do guest

Verifica o IP público do host, ele mostra a VPN e conclui que a VM está coberta. Essa conclusão não é sustentada pelo teste. Um guest tem a sua própria tabela de rotas, o seu próprio resolver e as suas próprias interfaces, e o endereço de saída do host não diz nada sobre elas.

O teste tem de correr dentro do guest e tem de nomear o que mediu.

Comece por dentro do guest, não no navegador do host

Registe primeiro o modo de rede do hypervisor: NAT, bridged, host-only ou macvtap. No modo NAT o host encaminha o tráfego do guest, pelo que o túnel do host pode aplicar-se ou não, dependendo de como o cliente instala as rotas. No modo bridged o guest é um par na LAN física e o túnel do host é irrelevante. Estes dois modos dão respostas opostas a partir da mesma configuração do host.

Anote o modo antes de mudar seja o que for, porque é ele que determina o que o resultado pode significar.

Faça um pedido cujo destino conhece

Use um pedido inofensivo a um serviço que reporta o endereço de origem que viu. Depois verifique a decisão de encaminhamento do próprio guest para esse destino: ip route get 203.0.113.5 imprime a interface e o gateway que o guest vai usar.

Se a interface for a NIC normal do guest, o tráfego não passa por um túnel dentro do guest.

Um segundo adaptador, uma definição de proxy ou um cliente VPN do lado do guest podem mudar a resposta para uma aplicação e não para outra. Teste a aplicação que realmente lhe importa, não um pedido genérico a partir de uma shell.

Verifique o resolver em separado

Um endereço de saída alterado não lhe diz qual resolver tratou do nome do host. Consulte o nome explicitamente com a ferramenta adequada à plataforma e anote qual servidor respondeu. Split DNS significa que a pergunta sobre o resolver e a pergunta sobre o encaminhamento têm respostas diferentes.

Os dois podem divergir em qualquer direção, e essa divergência é muitas vezes o bug real.

Num host com systemd, resolvectl query nomeia a interface e o servidor DNS por trás da resposta. Configurações mais antigas mostram o servidor na saída do dig. De qualquer forma, o ponto é ver qual servidor respondeu, não apenas se chegou uma resposta.

Teste a política de falha, não apenas o sucesso

Se o requisito é que nenhum tráfego saia fora do túnel, um pedido bem-sucedido não prova nada. Use o teste de falha controlada suportado pelo cliente: pare o túnel da forma suportada e veja se um novo pedido do guest é bloqueado. Não assuma que o kill switch do cliente do host cobre todas as configurações de encaminhamento virtual. O âmbito documentado é a única coisa com que pode contar.

Um guest que recua para a NIC física quando o túnel cai está a fazer exatamente o que o modo NAT permite.

Registe o modo e o âmbito

Anote o modo do hypervisor, a interface e a rota do guest, o resolver e a aplicação que testou. Acrescente a data, porque um restauro de snapshot ou uma atualização do hypervisor podem mudar as quatro coisas.

Se o IPv4 seguiu o túnel, diga-o. Não estenda a afirmação ao IPv6, a outro namespace ou a outra VM numa rede diferente.