Llegar a un equipo detrás de NAT sin abrir un puerto

Dos extremos detrás del NAT del operador y un router de oficina bloqueado no dejan ningún puerto entrante que redirigir, y el reflejo es pedir uno de todos modos. La mejor pregunta es qué lado puede marcar hacia fuera y qué servicio accesible tiene permiso para llevar el tráfico. Cuatro diseños responden a esa pregunta de forma distinta y fallan de forma distinta cuando se bloquea una ruta. Elegir entre ellos es una comparación de garantías, no de nombres de protocolos.

Cuatro diseños, cuatro promesas diferentes

La tabla de abajo es la versión corta. Lea la columna central como la promesa que puede probar y la columna derecha como la promesa que nadie hizo.

Qué fila se aplica depende de la tarea y no de la preferencia. Una sesión de escritorio remoto, una consola administrativa y acceso a toda una subred privada son tres requisitos que no necesitan el mismo punto de entrada, aunque casualmente afecten al mismo equipo.

Un concentrador cambia quién marca hacia fuera, no qué está permitido

En un diseño de concentrador enrutado, el portátil remoto y el equipo de trabajo, o la pasarela del sitio delante de él, abren cada uno un túnel saliente hacia un servicio que ambos pueden alcanzar. Nada acepta una conexión no solicitada en el router del equipo, y es exactamente por eso que este diseño sobrevive al NAT y sigue funcionando cuando el sitio no tiene dirección estática. Después el concentrador enruta el tráfico entre las dos direcciones internas según su propia política.

El coste es que el concentrador debe existir, debe ser accesible desde ambos lados y alguien debe operarlo. El filtrado de salida tiene que permitir el transporte, y una red que lo bloquee derrotará el diseño aunque no hiciera falta ninguna redirección de puerto.

La parte sutil es que accesibilidad y autorización son decisiones separadas tomadas en lugares distintos. Una ruta hacia un prefijo no dice nada sobre qué servicio del equipo puede usar la identidad, y una regla de cortafuegos que permite el túnel no dice nada sobre si la cuenta puede iniciar sesión. Configure ambas, pruebe ambas y mantenga la decisión de autorización en el sistema que posee el recurso y no en la tabla de enrutamiento.

El cruce solo funciona cuando ambos stacks lo implementan

El cruce entre pares es una capacidad de un sistema concreto, no un ajuste que mejora una VPN. Interactive Connectivity Establishment reúne varias direcciones candidatas y prueba parejas hasta que una funciona: candidatas de host en las interfaces locales, candidatas reflexivas del servidor construidas a partir de lo que revela un NAT y candidatas retransmitidas asignadas en un relé. Una dirección privada por sí sola no es una ruta, porque el otro lado no puede enrutar hacia ella.

Merece la pena entender el caso retransmitido antes de descartarlo. RFC 8656 describe TURN como un protocolo en el que un cliente pide a un servidor una dirección de transporte retransmitida y el servidor reenvía el tráfico entre ese cliente y sus pares. El relé lleva por tanto los datos, lo que es materialmente distinto de un directorio que solo ayuda a que los extremos se encuentren. Intercambiar la dirección del relé con el otro extremo es un paso de coordinación que la aplicación tiene que hacer.

Lo que no puede prometer es una ruta directa. El NAT simétrico y algunos cortafuegos empresariales derrotan el perforado de agujeros, y cuando lo hacen el sistema o recurre a un relé o falla. Tampoco puede concluir que dos extremos traducidos nunca puedan hablar; un stack compatible con respaldo de relé existe precisamente porque a menudo sí pueden. Decida si importa más la disponibilidad o la conexión directa y luego verifique qué ruta eligió realmente el despliegue en lugar de suponer el caso feliz.

Un bróker es más estrecho que una red

Cuando el requisito es una sola aplicación, un bróker de aplicaciones o una conexión inversa iniciada por el equipo pueden ser la respuesta más pequeña. El equipo marca hacia fuera a un bróker, el bróker autentica al usuario remoto y solo se transporta esa sesión de aplicación. No se crea ninguna ruta hacia la subred del equipo, así que un compromiso de la sesión remota no hereda un camino hacia cada dispositivo de al lado.

Esa estrechez tiene un precio: cada aplicación adicional necesita su propia integración, y cualquier cosa que la aplicación suponga sobre una red local, como un recurso compartido que abre en un servidor cercano, puede no ser accesible. Los brókers también concentran política y registro en un solo lugar, lo que resulta útil hasta que ese lugar se convierte en la caída.

Compare los límites de confianza y luego pruebe la ruta

Un concentrador que termina túneles puede leer el tráfico que enruta. Un relé puede llevar un intercambio protegido de forma independiente cuando la aplicación cifra de extremo a extremo, y un bróker normalmente termina la sesión que presenta. Establezca dónde acaba realmente la protección antes de decidir que dos diseños son equivalentes porque ambos están cifrados.

Luego compruebe a qué alcanza realmente el equipo hacia fuera, ya que todos los diseños de arriba dependen de ello. Ejecútelo en el equipo, sustituyendo el nombre de host que piensa usar.

ss -lntup
nc -vz hub.example.com 443
curl -sS -o /dev/null -w "%{http_code}\n" https://hub.example.com

Acepte el diseño solo después de que la operación remota prevista tenga éxito con la identidad permitida, se rechace una identidad no aprobada y el comportamiento cuando la ruta directa o retransmitida no esté disponible sea conocido y esté documentado. Incluya una reconexión y el contexto de arranque normal del equipo, porque una sesión que empezó en la oficina por la LAN no prueba nada de lo que depende el acceso remoto.