Hipervisor del laboratorio doméstico inaccesible por VPN: dónde mirar

El túnel se levanta, la página web del hipervisor agota el tiempo y el cliente dice que está conectado. Esa combinación descarta muchísimo: el handshake de VPN funciona, el cliente tiene dirección y el extremo es alcanzable. Lo que queda es una lista corta de cuestiones de enrutamiento y política, y tienen un orden natural. Recórralas desde el hipervisor hacia fuera y no desde el cliente hacia dentro, porque el propio estado del hipervisor es lo más barato de confirmar.

Empiece por el segmento de gestión

Confirme la dirección de gestión del hipervisor y el servicio que escucha en ella, y confirme que la página carga desde otro host de ese segmento antes de diagnosticar nada remoto. Una prueba local que falla no es un problema de VPN, y es una comprobación de cinco minutos que ahorra una hora.

Luego los dos caminos. El cliente de VPN necesita una ruta hacia la red de gestión, lo que suele significar que AllowedIPs del cliente o las rutas empujadas incluyen esa subred. El hipervisor, o su puerta de enlace predeterminada, necesita un camino de retorno al grupo de direcciones de clientes, salvo que el diseño traduzca deliberadamente el origen a la entrada. Son dos hechos separados y la falta de cualquiera de ellos produce el mismo tiempo de espera. Compruébelos por separado: ip route get 192.168.10.20 en el cliente y una captura en el host del hipervisor que muestre si el paquete llegó siquiera.

Permita al administrador remoto real

La autorización es una cuestión distinta de la alcanzabilidad. Use política de puerta de enlace y de host limitada a las fuentes y servicios que necesitan acceso de gestión. Una cuenta de VPN de invitado que necesita una aplicación del laboratorio no debería llegar por ello al plano de gestión, y una regla plana que admite toda la subred del túnel es como ocurre eso.

Mantenga activadas la autenticación propia del hipervisor y las comprobaciones de certificado. Una ruta privada no es motivo para hacer clic a través de un aviso de identidad inesperado.

Merece la pena tratar el aviso como un hallazgo y no como un obstáculo. Si el certificado no coincide con el nombre que usó, o el nombre es incorrecto o el servicio no es el que cree, y ambas respuestas importan más en una interfaz de gestión que en cualquier otro sitio. Llegue a la página por el nombre para el que se emitió el certificado, y deje que DNS apunte ese nombre a la dirección del túnel. Un nombre privado que se resuelve de forma incoherente entre la LAN y el túnel es una causa habitual de quejas de certificado que parecen fallos de VPN.

Compruebe las conexiones secundarias

Algunas funciones usan conexiones que la página web no usa. Una sesión de consola, una carga de ISO, un proxy VNC o SPICE y un canal de migración pueden usar cada uno un puerto distinto o una dirección de host distinta. Cuando la página carga y una función falla, lea el requisito de ese producto en lugar de abrir todos los puertos del host.

Abrirlo todo es como una interfaz de gestión se convierte en una no gestionada. Cada puerto adicional es otro oyente que hay que mantener parcheado, y un hipervisor ya expone bastantes. Identifique la conexión concreta que necesita la función, confirme que es alcanzable a través del túnel y deje el resto cerrado. Si la función insiste en una conexión directa a una dirección de host que no es enrutable por su túnel, eso es una restricción de diseño que hay que sortear deliberadamente, no un motivo para reenviar un rango.

Conserve una vía de vuelta antes de tocar la red

Antes de cambiar la red virtual que transporta su propia VPN, confirme que tiene una vía de vuelta local o independiente.

Esto importa más en un laboratorio doméstico, porque el extremo de la VPN suele ser una máquina virtual en el mismísimo hipervisor al que intenta llegar. Cambiar un conmutador virtual, un puente o una regla de cortafuegos de forma remota puede eliminar el camino que está usando, y la sesión puede sobrevivir lo suficiente para verlo ocurrir.

Pruebe desde fuera del laboratorio y no desde la LAN, y verifique las denegaciones tanto como los permisos. Una red que debe seguir siendo inalcanzable desde el túnel debe seguir siéndolo después de su cambio, y eso es una afirmación separada de la carga de la página de gestión. Anote ambos resultados, porque el segundo es el que se omite y el que importa cuando el laboratorio crece.

El registro que conviene guardar es corto: la dirección y el servicio de gestión, la ruta que necesita cada lado, las identidades autorizadas a llegar y la vía de recuperación. Eso basta para que la siguiente persona reproduzca el estado de funcionamiento sin volver a deducirlo.

Si la página sigue agotando el tiempo después de todo eso, capture en el hipervisor y busque el paquete antes de cambiar otra regla. Un paquete que nunca llega es una cuestión de enrutamiento o cortafuegos; un paquete que llega y se rechaza es una cuestión de servicio o política; un paquete que llega y recibe respuesta mientras el cliente espera es una cuestión de camino de retorno. La documentación de strongSwan sobre reenvío explica cómo una puerta de enlace Linux reenvía el tráfico del túnel a un host interno. Tres capturas superan una conjetura más.