Por que a orde dos adaptadores non decide a ruta VPN do laboratorio

Que o adaptador 1 sexa o primeiro da lista do hipervisor é só unha orde de visualización, e a táboa de encamiñamento do convidado non a le. O que decide a ruta é o prefixo, a métrica e calquera regra de política que se aplique antes de ambas. Por iso, engadir un adaptador ponte a unha VM de laboratorio pode crear unha segunda ruta predeterminada mentres a antiga interface NAT segue aparecendo como presente e numerada en segundo lugar. O resultado é unha VM que ás veces usa o túnel e ás veces non, sen ningún cambio de configuración que o explique.

Tres condicións deciden a ruta

As tres condicións son que prefixo é máis específico, que fan as métricas cando os prefixos empatan e que regras aplicou o convidado tras o cambio de hardware. Cada unha respóndese cun só comando, e ningunha depende da numeración do hipervisor.

Ese último punto é a decisión: se non pode dicir que prefixo gaña para o propio enderezo do punto final VPN, non ten unha política de encamiñamento, ten unha topoloxía que hoxe funciona por casualidade.

Primeira condición: que prefixo gaña

Unha ruta cara a 10.8.0.0/24 supera unha ruta predeterminada para un enderezo dentro dela, sen importar as métricas nin a orde dos adaptadores. Por iso un cliente VPN que instala unha ruta específica segue funcionando aínda que apareza un segundo adaptador cunha métrica menor: a especificidade gaña antes de considerar o custo. Comprobe con ip route show a táboa que cre que está en uso, e con ip route get 203.0.113.9 a resposta que o núcleo daría realmente para un destino concreto.

O propio enderezo do punto final é a proba que máis importa. Se o enderezo do servidor VPN se resolve a través dun adaptador ponte recén engadido, o túnel pode non establecerse nunca, ou establecerse e despois perder a súa propia ruta de transporte. Consulte ese enderezo en concreto en lugar de supor que a interface do túnel é a resposta.

Segunda condición: que fai a métrica e que non

O seu papel é máis estreito do que a maioría espera. As métricas desempatan entre rutas cara ao mesmo prefixo; non permiten que unha ruta máis ampla venza unha máis específica. Dentro dun empate prefire o número menor, e distintos sistemas operativos contan en direccións opostas, por iso os consellos copiados entre Linux e Windows a miúdo se contradín.

No convidado, ip route show imprime a métrica xunto a cada ruta, e Get-NetRoute en Windows imprime unha InterfaceMetric máis unha métrica de ruta. Lea ambas, porque a preferencia efectiva pode ser unha suma e non un único campo. Se existen dúas rutas predeterminadas, ese é o achado: o convidado ten dúas saídas, e cal gaña é función de números que un cambio de hardware pode alterar.

Terceira condición: que aplicou realmente o convidado

A configuración non é o mesmo que o estado aplicado. Os nomes de interface non son estables entre cambios de hardware en todas as plataformas, e unha configuración que coincidía por nome pode que agora non se aplique a nada.

Comprobe o estado aplicado e non o previsto. ip -br link mostra as interfaces que existen agora, e nun host con NetworkManager nmcli connection show mostra que perfil está vinculado a que dispositivo. Un perfil que non logrou vincularse deixa a interface levantada sen enderezo, o que parece un problema de encamiñamento e é un problema de nomes. As instantáneas restauradas empeorano, porque o estado gardado do convidado pode referenciar identidades de adaptador que o novo hardware xa non proporciona.

Manteña reproducible a topoloxía do laboratorio

Garde as conexións de rede virtual previstas xunto coa configuración do convidado, para que a correspondencia de rol a adaptador quede escrita en lugar de inferida dunha posición na lista.

Normalmente abonda con nomear catro roles: enlace privado, xestión, transporte exterior e túnel. Cada un debería corresponder a un adaptador concreto e a unha interface de convidado concreta, nun ficheiro.

Despois probe a aplicación real tras un cambio de hardware, un reinicio ou unha instantánea restaurada, e inclúa a ruta cara ao punto final VPN nesa proba. Se unha VM de pasarela debe ser a única saída, verifique que a VM de proba non teña unha segunda ruta predeterminada non desexada, porque unha segunda ruta predeterminada é exactamente o que engade un adaptador ponte. Probe desde o convidado, non desde a consola do hipervisor, xa que ambos poden non coincidir sobre que interface é cal.

A documentación de redes de VirtualBox describe os modos de adaptador e a que se conecta cada un, que é a parte que paga a pena ler antes de engadir un segundo. Un laboratorio que identifica que adaptador serve cada rol fai explicable un cambio de ruta. Un laboratorio que depende da numeración do hipervisor converte cada cambio nun experimento.