Por que a ordem dos adaptadores não decide a rota VPN do laboratório

O adaptador 1 estar primeiro na lista do hipervisor é apenas uma ordem de exibição, e a tabela de roteamento do convidado não a lê. O que decide o caminho é o prefixo, a métrica e qualquer regra de política que se aplique antes de ambos. Por isso, adicionar um adaptador em ponte a uma VM de laboratório pode criar uma segunda rota padrão enquanto a antiga interface NAT continua aparecendo como presente e numerada em segundo lugar. O resultado é uma VM que às vezes usa o túnel e às vezes não, sem nenhuma mudança de configuração que explique isso.

Três condições decidem o caminho

As três condições são qual prefixo é mais específico, o que as métricas fazem quando os prefixos empatam e quais regras o convidado aplicou após a alteração de hardware. Cada uma se responde com um único comando, e nenhuma depende da numeração do hipervisor.

Esse último ponto é a decisão: se não consegue dizer qual prefixo vence para o próprio endereço do ponto de extremidade VPN, você não tem uma política de roteamento, tem uma topologia que hoje funciona por acaso.

Primeira condição: qual prefixo vence

Uma rota para 10.8.0.0/24 supera uma rota padrão para um endereço dentro dela, independentemente das métricas e da ordem dos adaptadores. É por isso que um cliente VPN que instala uma rota específica continua funcionando mesmo quando surge um segundo adaptador com métrica menor: a especificidade vence antes de o custo ser considerado. Verifique com ip route show a tabela que você acha que está em uso, e com ip route get 203.0.113.9 a resposta que o kernel daria de fato para um destino específico.

O próprio endereço do ponto de extremidade é o teste que mais importa. Se o endereço do servidor VPN for resolvido por um adaptador em ponte recém-adicionado, o túnel pode nunca ser estabelecido, ou ser estabelecido e depois perder seu próprio caminho de transporte. Consulte esse endereço especificamente em vez de supor que a interface do túnel é a resposta.

Segunda condição: o que a métrica faz e o que não faz

O papel dela é mais estreito do que a maioria espera. As métricas desempatam rotas para o mesmo prefixo; não permitem que uma rota mais ampla vença uma mais específica. Dentro de um empate, o número menor é preferido, e sistemas operacionais diferentes contam em direções opostas, por isso conselhos copiados entre Linux e Windows costumam se contradizer.

No convidado, ip route show imprime a métrica ao lado de cada rota, e Get-NetRoute no Windows imprime uma InterfaceMetric mais uma métrica de rota. Leia as duas, porque a preferência efetiva pode ser uma soma e não um único campo. Se existirem duas rotas padrão, esse é o achado: o convidado tem duas saídas, e qual vence é função de números que uma alteração de hardware pode mudar.

Terceira condição: o que o convidado realmente aplicou

Configuração não é o mesmo que estado aplicado. Os nomes de interface não são estáveis entre alterações de hardware em todas as plataformas, e uma configuração que batia por nome pode agora não se aplicar a nada.

Verifique o estado aplicado e não o previsto. ip -br link mostra as interfaces que existem agora, e em um host com NetworkManager nmcli connection show mostra qual perfil está vinculado a qual dispositivo. Um perfil que não conseguiu se vincular deixa a interface ativa sem endereçamento, o que parece um problema de roteamento e é um problema de nomes. Instantâneos restaurados pioram isso, porque o estado salvo do convidado pode referenciar identidades de adaptador que o novo hardware não fornece mais.

Mantenha a topologia do laboratório reproduzível

Salve as conexões de rede virtual previstas junto com a configuração do convidado, para que o mapeamento de papel para adaptador fique escrito em vez de inferido de uma posição na lista.

Normalmente quatro papéis bastam para nomear: enlace privado, gestão, transporte externo e túnel. Cada um deve corresponder a um adaptador específico e a uma interface de convidado específica, em um arquivo.

Depois teste a aplicação real após uma alteração de hardware, uma reinicialização ou um instantâneo restaurado, e inclua a rota até o ponto de extremidade VPN nesse teste. Se uma VM de gateway deve ser a única saída, verifique que a VM de teste não tem uma segunda rota padrão indesejada, porque uma segunda rota padrão é exatamente o que um adaptador em ponte adiciona. Teste a partir do convidado, não do console do hipervisor, já que os dois podem discordar sobre qual interface é qual.

A documentação de rede do VirtualBox descreve os modos de adaptador e a que cada um se conecta, e é a parte que vale a pena ler antes de adicionar um segundo. Um laboratório que identifica qual adaptador serve cada papel torna uma mudança de rota explicável. Um laboratório que depende da numeração do hipervisor transforma cada mudança em um experimento.