VPN activada, VM inaccesible? A ruta probablemente nunca foi o problema

Conecta a VPN e a VM de desenvolvemento que respondía hai un minuto queda muda. A historia obvia escríbese soa: o túnel levou a ruta, o anfitrión agora envía o tráfico do convidado á rede corporativa, e a solución é engadir unha ruta estática ou cambiar o adaptador a modo ponte. Esa historia ás veces é certa. Pero non é a causa habitual, e actuar segundo ela primeiro adoita romper outra cousa.

A rede host-only é unha rede de software propiedade do anfitrión e compartida cos seus convidados, separada de calquera conexión física. Nada na propia interface do cliente VPN cambia esa rede, así que antes de tocala, averigua cal das catro capas fallou realmente.

A ruta normalmente segue sendo local

Pregúntalle ao núcleo en lugar de á portada da táboa de rutas. En Linux, ip route get 192.168.56.10 informa da ruta, a interface e o enderezo de orixe exactos que se usarían, o que é unha resposta distinta de ler unha ruta por defecto e adiviñar. Se a saída nomea a interface host-only, o túnel non participa en absoluto nesa ruta.

Dúas cousas si poden rompela, e ambas son problemas de enderezos e non de VPN. Unha subrede remota que se solape co prefixo host-only fai gañar a ruta máis específica, e un cliente VPN que instala unha ruta ampla cunha métrica máis baixa pode levar o prefixo. Ambas se ven no mesmo comando: a interface nomeada na saída será o túnel, e a corrección corresponde a quen posúa ese plan de enderezos.

Selección de ruta e admisión de paquetes son decisións distintas

Esta é a parte que o modelo mental adoita omitir. Incluso cunha ruta local perfecta, un cliente VPN pode rexeitar o paquete. Moitos clientes aplican unha política de acceso local á rede que decide que destinos se permiten fóra do túnel, e unha subrede conectada non actualiza esa lista automaticamente.

Así, o fallo parece idéntico a un problema de encamiñamento desde o lado da aplicación e completamente distinto desde o lado do cliente. Se ip route get nomea a interface correcta e a conexión segue esgotando o tempo, deixa de editar rutas e le en cambio o comportamento de acceso local documentado do cliente. Algúns clientes ofrecen unha lista de permitidos para subredes locais, outros bloquean todo o que non sexa o túnel, e outros só bloquean cando hai un kill switch activado.

Esa distinción importa porque as correccións non son intercambiables. Engadir unha ruta non satisfai un filtro, e desactivar un filtro para chegar a un só convidado é unha decisión moito maior do que suxire o síntoma.

O convidado ten tres formas de dicir que non

Un convidado que pode navegar por internet non demostrou nada sobre o servizo que queres. O receptor pode estar ligado a 127.0.0.1 dentro do convidado, e nese caso ningunha petición do anfitrión pode chegar, por boa que sexa a ruta. Compróbao con ss -ltn dentro do convidado e mira a columna do enderezo local, non só o porto.

Despois está a devasa do propio convidado. Unha imaxe de desenvolvemento cun valor por defecto restritivo pode aceptar os paquetes do anfitrión e descartalos no límite do servizo, o que produce un tempo de espera que parece exactamente un buraco negro de encamiñamento. Por último está a configuración do propio servizo: unha aplicación web ligada a un nome de anfitrión concreto, ou unha lista de enderezos de cliente permitidos, rexeitará unha petición da subrede host-only aínda que cheguen todos os paquetes.

Repasa eses tres puntos antes de expoñerte cambiar o modo de rede da VM. Cada un é un cambio menor que redeseñar a conexión do convidado, e cada un ten unha proba clara.

Que é realmente unha ponte, e canto custa

Cambiar o adaptador a modo ponte non é unha reparación do camiño host-only. É a decisión de pór o convidado noutra rede, normalmente a LAN física, onde se volve visible para todo o demais que vive alí. Pode ser exactamente o que queres. Pero non é o que facía a configuración orixinal.

Úsao cando o convidado realmente necesite ser un par nesa LAN e a exposición estea aprobada. Non o uses porque un só servizo deixase de responder, xa que o cambio pode sacar o convidado do illamento que o facía seguro para desenvolver.

Despois de calquera corrección aprobada, proba nunha orde fixa: unha petición nova do anfitrión ao convidado, un recurso corporativo necesario a través do túnel, e o comportamento denegado previsto co túnel baixado. Se o último xa non se cumpre, a corrección foi máis aló do problema.

A sección de VirtualBox sobre redes host-only describe a interface de software do lado do anfitrión e en que difire dunha conexión en ponte, que é a referencia que paga a pena ler antes de supor que os dous modos son intercambiables.