Por qué la dirección de tu túnel VPN no abre un puerto de entrada

Conéctate a la VPN de la oficina, inicia un servicio pequeño en el puerto 8443, envía la dirección del túnel a un compañero y observa cómo la conexión falla mientras el cliente sigue informando que está conectado. Nada está roto en el túnel: la dirección se asignó, la sesión está activa y los paquetes que llevarían la respuesta simplemente nunca se admiten. Ejecuta las tres comprobaciones siguientes en orden y detente en la que falle, porque cada una tiene una solución distinta y solo una de ellas tiene que ver con la VPN.

Empieza por dónde está realmente vinculado el socket

Antes de que algo se enrute, algo tiene que estar escuchando en una dirección que el llamador pueda alcanzar. Los servidores de desarrollo son el culpable habitual, porque muchos se vinculan por defecto a loopback y solo aceptan conexiones que se originan en la misma máquina. Una dirección de túnel no cambia esa vinculación, y el sistema operativo rechazará la conexión mucho antes de que la VPN intervenga.

ss -ltnp | grep 8443
netstat -ano | findstr 8443

Lee la columna de la dirección local en lugar del estado. 127.0.0.1:8443 significa solo loopback, y la solución es una vinculación a 0.0.0.0 o a la propia dirección del túnel. 0.0.0.0:8443 acepta en todas las interfaces, lo que es más amplio de lo que la mayoría pretende cuando la máquina también tiene una dirección pública; 10.64.7.15:8443 es la versión estrecha que escucha solo donde el compañero puede llegar. Fíjate también en el nombre del proceso en la misma salida, porque una instancia perdida de una prueba anterior es una causa habitual de que el puerto parezca abierto y responda con el contenido equivocado.

Después pregunta si algo puede enrutar hacia esa dirección

Una dirección de túnel solo tiene sentido para los pares configurados para enviar ese prefijo dentro del túnel. La máquina del compañero tiene su propia tabla y, si no tiene una ruta para la subred del túnel, el paquete va a la puerta de enlace predeterminada y muere en un lugar que no tiene idea de que la dirección existe. Es una cuestión de enrutamiento del lado del llamador, no un permiso del tuyo.

El servidor entre los dos clientes importa igual. En el diseño habitual de acceso remoto, cada cliente abre una conexión saliente hacia la puerta de enlace y esta mantiene el estado de esos flujos, de modo que las respuestas vuelven por un camino que ya conoce. Una conexión de un cliente a otro es un flujo nuevo que la puerta de enlace debe aceptar y reenviar, y muchos despliegues lo desactivan deliberadamente para mantener a los clientes aislados entre sí. Los servicios VPN de consumo suelen aislar por defecto; las puertas de enlace corporativas a veces lo permiten por grupo.

Comprueba la dirección antes de cambiar nada en el host. Si la dirección del túnel responde desde la propia puerta de enlace pero no desde un par, la diferencia es el ajuste de cliente a cliente de la puerta de enlace, y ninguna edición del cortafuegos local puede sustituirlo.

Por último, encuentra la política que permite el flujo

Tres capas de política se interponen entre un paquete enrutado y un servicio que responde: la decisión de reenvío del servidor VPN, el cortafuegos del host y cualquier grupo de seguridad de la nube delante de la instancia. Las tres tienen que coincidir y fallan de maneras distintas, por eso el síntoma de la tabla anterior es más útil que el mensaje de error del navegador.

El cortafuegos del host es la capa que la gente olvida después de una vinculación correcta, porque una regla que permite el puerto en la interfaz LAN no lo permite automáticamente en la interfaz del túnel. Las reglas limitadas a una interfaz son un diseño correcto y también la causa habitual de un servicio que funciona desde la oficina y no desde casa. Lee el alcance de la regla, no su número de puerto.

El filtrado con estado explica el caso inverso. Una conexión saliente de tu portátil crea estado, y las respuestas a ella se admiten sin una regla de entrada. La conexión del compañero es un flujo completamente nuevo sin estado detrás, así que necesita una autorización explícita. Esa asimetría es toda la razón por la que una sesión de navegador que funciona en tu propia máquina no dice nada sobre si el servicio es accesible desde fuera.

Cuando falla una comprobación, cambia el diseño y no el túnel

Si el requisito es que un compañero abra tu servicio local, la respuesta honesta suele ser un mecanismo pensado para el acceso de entrada. Un túnel SSH inverso es el más pequeño: tu máquina se conecta hacia fuera a un host que el compañero ya puede alcanzar, y el receptor existe en ese host.

ssh -N -R 8443:127.0.0.1:8443 [email protected]

El relé necesita GatewayPorts clientspecified en la configuración de su servidor SSH, si no el receptor reenviado se vincula a loopback en el relé y el compañero se topa con el mismo rechazo que antes. Para cualquier cosa que dure más de una tarde, un balanceador de carga o un ingress con comprobación de estado y certificado para el nombre publicado es el mejor instrumento, y un túnel de sitio a sitio con rutas para ambas subredes es la respuesta correcta cuando dos redes de verdad necesitan hablar.

Cada uno de esos diseños hace explícita la exposición, y ese es el punto. Una VPN mueve paquetes entre redes para las que ya estabas autorizado; no publica un servicio ni convierte un portátil en un host abierto a internet. Decidir cuál de las tres capas cambiar es la tarea, y el túnel rara vez es una de ellas.