VPN no convidado e VPN no anfitrión: que ruta gaña de verdade

Dous clientes execútanse á vez, cada un convencido de que posúe a ruta predeterminada, e o síntoma chega como algo estraño: unha aplicación do convidado funciona e outra resólvese no lugar equivocado. Unha VPN dentro dun convidado e unha VPN no anfitrión poden convivir, pero só cando o camiño exterior e a política interior coinciden en quen transporta que. Arrancar ambas non crea unha cadea por si só. Anota primeiro a conexión e despois cambia unha cousa cada vez.

Anota primeiro a conexión do convidado

O convidado chega ao seu servidor VPN polo camiño que lle deu o hipervisor: NAT detrás do anfitrión, unha ponte cara ao segmento físico ou unha rede só para o anfitrión con encamiñamento engadido por riba. Cada conexión cambia o que o convidado pode ver e o que o anfitrión pode facer co seu tráfico. Baixo NAT os paquetes do convidado parecen vir do anfitrión, así que o propio túnel do anfitrión pode transportalos sen que o convidado saiba nada. Baixo unha ponte o convidado ten presenza propia no segmento e a súa propia porta de enlace predeterminada.

Anota a conexión antes de tocar calquera configuración, xunto con que cliente debe transportar que aplicación. Esa frase resolve a maioría destes casos, porque os dous clientes adoitan estar construídos sobre supostos distintos. Un convidado que debe usar o túnel do anfitrión non debe ter ademais unha ruta predeterminada competidora propia.

Segue o extremo do convidado cara a fóra

Unha VPN do convidado necesita un camiño utilizábel cara ao seu propio servidor antes de que nada máis funcione. Cando o túnel do anfitrión está activo e o convidado está detrás de NAT, o saúdo do convidado sae polo túnel do anfitrión, o que é ou o deseño ou un accidente que ninguén documentou. Cando o túnel do anfitrión cae e o convidado dependía del, o convidado perde conectividade sen un só cambio pola súa parte. Seguir o extremo cara a fóra diche cal deses dous casos tes en realidade.

Unha ruta ampla en calquera dos dous contextos captura tráfico que o outro cliente agardaba. Unha ruta 0.0.0.0/0 dentro do convidado e un cliente de anfitrión con túnel completo reclaman ambos todo, e gaña o que se aplique en último lugar. As superposicións entre as redes virtuais do convidado, a LAN local e as redes remotas producen o mesmo efecto para prefixos privados, con fallos que parecen problemas de autenticación; o comportamento de tradución de enderezos é o mesmo que se describe para a rede de contedores.

Compara un rexistro de antes e despois

Toma unha liña base co túnel do anfitrión apagado, ou en calquera estado controlado que permita a túa política, e anota a ruta e o resolutor do convidado. Despois aplica a configuración combinada e compara os dous rexistros, mantendo intactos os requisitos de privacidade. Se unha liña base directa non é axeitada, escribe esa limitación no rexistro en lugar de omitir a comparación.

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

A consulta de ruta nomea a interface e o enderezo de orixe que transportarían un destino concreto, e é a liña máis útil desta investigación. A listaxe de regras mostra se o encamiñamento por políticas envía algúns destinos por unha segunda táboa. A saída do resolutor mostra se o DNS seguiu o túnel do convidado ou quedou no camiño do anfitrión. Executa os mesmos tres comandos antes e despois do cambio, e o delta nomea o culpábel.

Mantén a propiedade clara entre reinicios

A restrición de acceso local dun cliente de anfitrión pode bloquear o tráfico cara a un NAT virtual ou unha ponte, e esa restrición confúndese habitualmente cun problema de credenciais do convidado. Le o comportamento documentado do cliente en lugar de desactivar a restrición para que pase unha proba. Tras unha corrección soportada, volve probar a aplicación do convidado e a política de fallo que esixes. Un anfitrión que se reconecta con éxito non demostra nada sobre a ruta ou o resolutor do convidado.

Decide que lado posúe a ruta predeterminada e escríbeo no manual de operacións. Un reinicio do convidado ou un cambio de rede no anfitrión que invirta a propiedade en silencio produce un informe de erro sobre unha VPN que nunca tivo a culpa. O arranxo debería sobrevivir a un reinicio sen que ninguén lembre por que funcionaba.