Por qué un recurso de VPN funciona y otro se queda sin tiempo

Un servicio privado se carga por el túnel y el siguiente se queda sin tiempo, y la tentación es reconstruir todo el perfil del cliente. El servicio que funciona es más útil como control que como motivo para empezar de cero. Demuestra que un destino, un puerto y una ruta de autorización se cumplieron, y nada más allá.

Se puede llegar a dos servicios en la misma puerta de enlace por familias de direcciones distintas, subredes distintas y políticas distintas.

Separe el flujo que funciona del que falla

Trate cada servicio como su propio flujo y no como un síntoma de la VPN. Un cliente ilustrativo puede abrir portal.corp.example en 172.20.4.15:443 y aun así no llegar a una base de datos en 172.20.9.40:5432, porque son dos destinos con dos conjuntos de reglas. Anote las dos filas antes de cambiar nada, incluidos el puerto y el protocolo, porque una regla que permite TCP 443 en un host no dice nada sobre TCP 5432 en el mismo host.

La fila que falla es la que hay que investigar. La fila que funciona solo dice dónde está la línea base, y será el punto de comparación después de cada cambio.

Compare direcciones antes de comparar nombres

Resuelva cada nombre completo con la política que la aplicación usa realmente y luego anote la familia de direcciones que eligió. Un nombre puede devolver una dirección IPv6 mientras otro devuelve IPv4, y una respuesta antigua en caché puede enviar una petición a una dirección pública que no tiene nada que ver con el servicio privado.

ip route get 172.20.4.15
ip route get 172.20.9.40
ip -6 route get 2001:db8:60::20

La consulta responde a una pregunta estrecha: qué ruta elegiría este host para ese destino, con las tablas y reglas de política actuales. Una ruta para 172.20.4.0/24 no cubre 172.20.9.0/24, y un segundo gestor de red o una ruta local con mejor especificidad pueden anular el túnel en silencio. Repita la consulta dentro del espacio de nombres o con la marca que usa la aplicación cuando difieren de su consola. Anote también la interfaz por la que sale el paquete, porque la tabla de rutas puede nombrar una interfaz mientras el enrutamiento por política envía el flujo por otra.

Una ruta que coincide es una condición necesaria, no un permiso. Le dice que el paquete tiene adónde ir y nada sobre si un cortafuegos, un servicio de autorización o el propio host lo aceptarán.

El protocolo y la etapa de respuesta dicen dónde se detiene

Una respuesta de ping no demuestra que un puerto de base de datos esté abierto, y una página HTTPS correcta no autoriza un recurso compartido en la misma máquina. Anote qué volvió realmente en lugar de aplanar cada fallo en una sola categoría. Un tiempo de espera, un reinicio, un error de identidad TLS y un rechazo a nivel de aplicación apuntan cada uno a una capa distinta.

La distinción importa porque las correcciones divergen. El silencio suele significar un problema de ruta, de cortafuegos o de traducción en el camino. Un reinicio inmediato sugiere que algo llegó al host y rechazó el puerto. Un error de certificado significa que la conexión llegó y el nombre no coincidía, lo que es un problema de configuración y no de accesibilidad. Un rechazo de la aplicación significa que la red hizo su trabajo y la identidad se rechazó después.

Cuando un recurso se publica a través de una puerta de enlace, compare la dirección de origen que ve el destino con la que su cliente cree que usa. Una petición originada por la propia puerta de enlace puede tener éxito mientras la misma petición desde un cliente falla, porque las dos llegan desde direcciones distintas y encuentran reglas distintas.

Cambie una variable y vuelva a ejecutar ambas peticiones

La identidad es el último lugar donde la gente mira y el primero donde aparece un rechazo correcto. El inicio de sesión de la VPN, el grupo del directorio y la cuenta de la aplicación son tres identidades separadas que pueden divergir. El acceso a un portal nunca implica acceso a la base de datos que hay detrás, y un nombre en un directorio no crea una fila en otro. Si el servicio está fuera del alcance previsto del usuario, el rechazo es el sistema funcionando.

Pida al propietario del recurso que confirme el derecho previsto en lugar de añadir una ruta amplia o abrir un grupo como prueba. Ampliar la red para demostrar un punto es como un diagnóstico temporal se convierte en una exposición permanente, y destruye el control con el que empezó. Una discrepancia demostrada por iteración es suficiente: una ruta que falta, una familia de direcciones equivocada, un puerto bloqueado o una pertenencia a grupo que falta.

Después de cada cambio, repita ambas peticiones y mantenga las salidas una al lado de la otra. La investigación termina cuando el servicio que fallaba funciona bajo su propia política mientras el servicio que funciona y los rechazos que aún espera se comportan exactamente como antes.