Hipervisor do laboratorio doméstico inaccesible por VPN: onde mirar

O túnel levanta, a páxina web do hipervisor esgota o tempo e o cliente di que está conectado. Ese conxunto descarta moitísimo: o handshake de VPN funciona, o cliente ten enderezo e o extremo é alcanzable. O que queda é unha lista curta de cuestións de encamiñamento e política, e teñen unha orde natural. Trábaas desde o hipervisor cara a fóra e non desde o cliente cara a dentro, porque o propio estado do hipervisor é o máis barato de confirmar.

Comece polo segmento de xestión

Confirme o enderezo de xestión do hipervisor e o servizo que escoita nel, e confirme que a páxina carga desde outro hóspede nese segmento antes de diagnosticar nada remoto. Unha proba local que falla non é un problema de VPN, e é unha comprobación de cinco minutos que aforra unha hora.

Logo os dous camiños. O cliente VPN necesita unha ruta cara á rede de xestión, o que normalmente significa que AllowedIPs do cliente ou as rutas empurradas inclúen esa subrede. O hipervisor, ou a súa pasarela predeterminada, necesita un camiño de retorno ao conxunto de enderezos de clientes, salvo que o deseño traduza deliberadamente a orixe na entrada. Son dous feitos separados e a falta de calquera deles produce o mesmo tempo de espera. Compruébeos por separado: ip route get 192.168.10.20 no cliente e unha captura no hóspede do hipervisor que mostre se o paquete chegou ou non.

Permita o administrador remoto real

A autorización é unha cuestión distinta da alcanzabilidade. Use política de pasarela e de hóspede limitada ás fontes e servizos que necesitan acceso de xestión. Unha conta VPN de convidado que necesita unha aplicación do laboratorio non debería chegar por iso ao plano de xestión, e unha regra plana que admite toda a subrede do túnel é como ocorre iso.

Manteña activadas a autenticación propia do hipervisor e as comprobacións de certificado. Unha ruta privada non é motivo para facer clic a través dun aviso de identidade inesperado.

Paga a pena tratar o aviso como un achado e non como un obstáculo. Se o certificado non coincide co nome que usou, ou o nome é incorrecto ou o servizo non é o que cre, e ambas as respostas importan máis nunha interface de xestión que en calquera outro sitio. Chegue á páxina polo nome para o que se emitiu o certificado, e deixe que o DNS apunte ese nome ao enderezo do túnel. Un nome privado que se resolve de forma incoherente entre a LAN e o túnel é unha causa habitual de queixas de certificado que parecen fallos de VPN.

Comprobe as conexións secundarias

Algunhas funcións usan conexións que a páxina web non usa. Unha sesión de consola, unha carga de ISO, un proxy VNC ou SPICE e unha canle de migración poden usar cada unha un porto distinto ou un enderezo de hóspede distinto. Cando a páxina carga e unha función falla, lea o requisito dese produto en lugar de abrir todos os portos do hóspede.

Abrilo todo é como unha interface de xestión se converte nunha non xestionada. Cada porto adicional é outro oínte que hai que manter parcheado, e un hipervisor xa expón abondo. Identifique a conexión concreta que necesita a función, confirme que é alcanzable a través do túnel e deixe o resto pechado. Se a función insiste nunha conexión directa a un enderezo de hóspede que non é encamiñable polo seu túnel, iso é unha restrición de deseño que hai que sortear deliberadamente, non un motivo para reenviar un rango.

Manteña unha vía de volta antes de tocar a rede

Antes de cambiar a rede virtual que transporta a súa propia VPN, confirme que ten unha vía de volta local ou independente.

Isto importa máis nun laboratorio doméstico, porque o extremo da VPN adoita ser unha máquina virtual no propio hipervisor ao que intenta chegar. Cambiar un conmutador virtual, unha ponte ou unha regra de devasas de forma remota pode eliminar o camiño que está a usar, e a sesión pode sobrevivir o suficiente para velo ocorrer.

Probe desde fóra do laboratorio e non desde a LAN, e verifique as denegacións tanto como os permisos. Unha rede que debe seguir sendo inalcanzable desde o túnel debe seguir séndoo despois do seu cambio, e iso é unha afirmación separada da carga da páxina de xestión. Anote ambos os resultados, porque o segundo é o que se omite e o que importa cando o laboratorio medra.

O rexistro que cómpre gardar é curto: o enderezo e o servizo de xestión, a ruta que necesita cada lado, as identidades autorizadas a chegar e a vía de recuperación. Iso abonda para que a seguinte persoa reproduza o estado de funcionamento sen volver deducilo.

Se a páxina segue esgotando o tempo despois de todo iso, capture no hipervisor e busque o paquete antes de cambiar outra regra. Un paquete que nunca chega é unha cuestión de encamiñamento ou devasas; un paquete que chega e se rexeita é unha cuestión de servizo ou política; un paquete que chega e recibe resposta mentres o cliente espera é unha cuestión de camiño de retorno. A documentación de strongSwan sobre reenvío explica como unha pasarela Linux reenvía o tráfico do túnel a un hóspede interno. Tres capturas superan unha conxectura máis.