La puerta de enlace aloja su propia página de administración: dirección interna o pública

Una página de administración responde desde un teléfono con datos móviles y expira desde un portátil unido a la VPN. Nada del túnel está roto, porque la petición nunca entra en él. El nombre de host se resuelve a la dirección pública de la puerta de enlace, y esa dirección solo es alcanzable desde fuera del túnel que esta termina. Arreglarlo significa dar al servicio una entrada privada en lugar de mover el extremo exterior.

La página carga desde fuera y no a través del túnel

Se comparan dos peticiones distintas. Con datos móviles, el navegador llega directamente a la dirección pública. Desde dentro del túnel, el mismo nombre se resuelve a la misma dirección pública, y el paquete ahora tiene que salir por el túnel para alcanzar una dirección en el propio lado lejano del túnel. Mismo nombre, misma dirección, dos posiciones muy distintas.

Una ruta de destino elige una dirección, no un puerto. Nada en la tabla de enrutamiento sabe que el puerto 443 es para administración y el puerto 1194 es el transporte, así que ambos se tratan como el mismo destino.

Por eso la página a veces funciona y a veces no, según qué nombre y qué red haya usado el cliente. Es un problema de ruta y no un problema de autenticación. Ambos clientes se autentican perfectamente.

Mantenga alcanzable el extremo exterior

Los perfiles de túnel completo necesitan una ruta de excepción para el extremo de la VPN, y la opción redirect-gateway de OpenVPN documenta exactamente eso: el extremo remoto conserva una ruta a través de la puerta de enlace preexistente para que el túnel no enrute hacia sí mismo. Quite esa excepción y el transporte cifrado sigue al túnel, lo que termina la sesión en un bucle. Esa excepción es la razón por la que la dirección del extremo sigue siendo alcanzable desde dentro del túnel.

La consecuencia es que la dirección pública sigue siendo alcanzable desde el cliente, y por eso una petición del navegador a esa dirección puede seguir la misma excepción y salir sin entrar en el túnel. La excepción hace su trabajo, y el nombre hace el daño.

Lea la decisión de la ruta en lugar de la lista de interfaces antes de cambiar nada. Los comandos de abajo imprimen la decisión en lugar del inventario. Ejecútelos desde el cliente que falló.

ip -4 route get 203.0.113.77
ip -4 rule show
ip -4 route show table all

Si la consulta muestra la ruta del extremo a través de la puerta de enlace física, el comportamiento es correcto y la página de administración simplemente se envía por el camino equivocado. Ese es el punto en el que la resolución de nombres se convierte en la solución.

Dé al servicio un nombre privado

El servicio necesita un nombre que se resuelva a la dirección de la puerta de enlace dentro del túnel, manteniendo a la vez la semántica de certificado y de nombre de host que la aplicación espera. Un registro de zona privado para el nombre de administración es la respuesta habitual, y deja intacto el nombre de transporte.

No reapunte el nombre de transporte a la dirección interna, porque el siguiente establecimiento del túnel intentaría entonces alcanzar una dirección que solo existe dentro de un túnel. Ese error produce una VPN que funciona exactamente una vez.

Compruebe también ambas familias de direcciones, ya que un registro AAAA que se queda atrás puede enviar el navegador a un lugar que el plan privado nunca cubrió.

dig +short admin.hq.internal
dig +short -t AAAA admin.hq.internal
curl -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://admin.hq.internal/

Ajuste la política a donde se ejecuta el proceso

Un proceso nativo que escucha en la puerta de enlace se alcanza por la ruta de entrada local, así que la cadena de entrada y el enlace del socket deciden si la petición se acepta. Las reglas de reenvío y el reenvío IP no hacen que un escucha local responda. Permita las fuentes del túnel en la política de entrada y confirme que el proceso está enlazado a una dirección que el túnel puede alcanzar.

Un contenedor publicado en un puerto del anfitrión sigue un camino distinto, porque el paquete se traduce por destino y se reenvía. Esa petición se encuentra con la política de reenvío del anfitrión y las reglas propias de Docker, y por eso un escucha nativo que funciona puede convivir con un contenedor que rechaza el mismo puerto.

El orden de arranque importa en ambos casos, porque un enlace a una dirección que solo aparece después de que el túnel suba falla en silencio al arrancar.

Compruebe el acceso privado y un camino público denegado

Haga una petición nueva y nombrada desde un cliente autorizado con las comprobaciones de identidad propias de la aplicación intactas. Luego pruebe el mismo servicio desde fuera del túnel y confirme que no responde. Un nombre privado es una comodidad y no una restricción, y un escucha aún enlazado a la dirección pública sigue expuesto. Esa última comprobación es la que más revisiones omiten.

Lea los enlaces y el estado del filtro en lugar del nombre de host que recibieron los usuarios. La exposición es una propiedad del socket y no del nombre. Esa distinción sobrevive a cada cambio de DNS.

ss -lntp | grep ':443'
nft list ruleset | grep -n 443
curl -sS -m 5 -o /dev/null -w '%{http_code}\n' https://203.0.113.77/

Cuando la petición interna devuelve la página y la petición externa expira, el servicio tiene un camino privado deliberado y el transporte sigue siendo alcanzable. Cuando la petición externa sigue respondiendo, hay que estrechar el escucha o una entrada de contenedor publicada antes de que alguien describa el servicio como solo interno.