VPN no convidado e VPN no host: qual rota realmente vence

Dois clientes rodam ao mesmo tempo, cada um convencido de que é dono da rota padrão, e o sintoma chega como algo estranho: um aplicativo do convidado funciona, outro resolve no lugar errado. Uma VPN dentro de um convidado e uma VPN no host podem coexistir, mas só quando o caminho externo e a política interna concordam sobre quem carrega o quê. Iniciar as duas não cria uma cadeia por si só. Anote primeiro a conexão e depois mude uma coisa por vez.

Anote primeiro a conexão do convidado

O convidado chega ao seu servidor VPN pelo caminho que o hipervisor lhe deu: NAT atrás do host, uma bridge para o segmento físico ou uma rede só do host com roteamento adicionado em cima. Cada conexão muda o que o convidado pode ver e o que o host pode fazer com o tráfego dele. Sob NAT os pacotes do convidado parecem vir do host, então o próprio túnel do host pode carregá-los sem que o convidado saiba nada. Sob uma bridge o convidado tem presença própria no segmento e seu próprio gateway padrão.

Anote a conexão antes de tocar em qualquer configuração, junto com qual cliente deve carregar qual aplicativo. Essa frase resolve a maioria desses casos, porque os dois clientes costumam ser construídos sobre premissas diferentes. Um convidado que deve usar o túnel do host não pode ter também uma rota padrão concorrente própria.

Siga o endpoint do convidado para fora

Uma VPN do convidado precisa de um caminho utilizável até o próprio servidor antes que qualquer outra coisa funcione. Quando o túnel do host está ativo e o convidado está atrás de NAT, o handshake do convidado sai pelo túnel do host, o que é ou o projeto ou um acidente que ninguém documentou. Quando o túnel do host cai e o convidado dependia dele, o convidado perde a conectividade sem uma única mudança do seu lado. Seguir o endpoint para fora diz qual desses dois casos você realmente tem.

Uma rota ampla em qualquer um dos dois contextos captura tráfego que o outro cliente esperava. Uma rota 0.0.0.0/0 dentro do convidado e um cliente de host com túnel completo reivindicam ambos tudo, e ganha o que se aplica por último. As sobreposições entre as redes virtuais do convidado, a LAN local e as redes remotas produzem o mesmo efeito para prefixos privados, com falhas que parecem problemas de autenticação; o comportamento de tradução de endereços é o mesmo descrito para redes de contêineres.

Compare um registro antes e depois

Tome uma linha de base com o túnel do host desligado, ou em qualquer estado controlado que sua política permita, e anote a rota e o resolver do convidado. Depois aplique a configuração combinada e compare os dois registros, mantendo os requisitos de privacidade intactos. Se uma linha de base direta não for apropriada, escreva essa limitação no registro em vez de pular a comparação.

ip route get 10.20.30.41
ip rule show
resolvectl status --no-pager | head -12

A consulta de rota nomeia a interface e o endereço de origem que carregariam um destino específico, e é a linha mais útil desta investigação. A lista de regras mostra se o roteamento por política envia alguns destinos por uma segunda tabela. A saída do resolver mostra se o DNS seguiu o túnel do convidado ou ficou no caminho do host. Execute os mesmos três comandos antes e depois da mudança, e o delta nomeia o culpado.

Mantenha a propriedade clara entre reinicializações

A restrição de acesso local de um cliente de host pode bloquear o tráfego para um NAT virtual ou uma bridge, e essa restrição costuma ser confundida com um problema de credenciais do convidado. Leia o comportamento documentado do cliente em vez de desativar a restrição para fazer um teste passar. Depois de uma correção suportada, teste novamente o aplicativo do convidado e a política de falha que você exige. Um host que se reconecta com sucesso não prova nada sobre a rota ou o resolver do convidado.

Decida qual lado possui a rota padrão e escreva isso no manual de operações. Uma reinicialização do convidado ou uma troca de rede no host que inverta a propriedade em silêncio produz um relatório de bug sobre uma VPN que nunca teve culpa. O arranjo deveria sobreviver a um reinício sem que ninguém lembre por que funcionava.