VPN detrás de un NAT que no puede configurar: qué sigue funcionando

Cada extremo de túnel necesita una dirección y un puerto que el otro lado pueda alcanzar, y un router que usted no administra es la razón habitual por la que ese requisito falla. Lo interesante no es que existan trucos, sino que cada uno depende de una propiedad de una tabla de mapeo que usted no ve desde el cliente. Dos de esas propiedades deciden casi todo: cómo se crea un mapeo y si acepta paquetes de una dirección con la que el interior nunca ha contactado. Ordene el entorno por esas propiedades y las soluciones dejan de ser folclore.

La tabla de mapeo lo decide todo

La traducción de direcciones de red mantiene una tabla en la que una dirección y un puerto internos quedan registrados frente a una dirección y un puerto públicos. Las respuestas que coinciden con un registro se traducen de vuelta, y un paquete que llega de fuera sin un registro coincidente no tiene destino alguno. Ese único comportamiento explica por qué un receptor detrás del router es inalcanzable desde internet. También explica por qué el primer paquete en cada dirección tiene que originarse dentro.

Mire la tabla desde el lado del router y las soluciones se vuelven obvias: o algo crea una entrada permanente, o crea una temporal y la mantiene fresca, o el tráfico nunca toma ese camino. El resto del artículo son esos tres casos en orden. Nada aquí depende de una función del fabricante más allá de lo que registra la tabla.

Qué puede y qué no puede hacer el servicio de encuentro

El hole punching UDP usa el registro saliente como una abertura temporal en lugar de derrotar el filtro. Ambos pares contactan un servicio de encuentro, que aprende cada extremo público y devuelve al otro lado su extremo. Luego ambos envían el uno hacia el otro, y cada paquete saliente crea o refresca el registro que deja entrar la respuesta. El orden es lo que lo hace funcionar, y el orden es también lo que lo hace frágil: un par que envía antes de que el otro lado haya creado su registro simplemente se descarta, mientras que un reintento un momento después tiene éxito. El servicio no transporta tráfico VPN, así que su única palanca es el tiempo que coordina.

El comportamiento del mapeo decide el resto, y RFC 4787 nombra las tres formas: independiente del extremo, dependiente de la dirección y dependiente de la dirección y el puerto. Con la última, el puerto que un par debe atacar cambia con cada destino, así que la predicción deja de ser fiable. Ahí la técnica encuentra sus callejones sin salida, porque el NAT de nivel de operador y un cortafuegos corporativo estricto eliminan ambos la previsibilidad que el esquema necesita, y ninguna cantidad de reintentos la recupera.

Keepalives, reinicios y el extremo que se mueve

Un camino perforado es un flujo y no un receptor, así que lo que corra encima debe sobrevivir al cambio. Debe mantener vivo el mapeo con tráfico periódico, notar cuándo se mueve el extremo público y restablecerse tras reiniciarse el router o reasignarse la dirección. Los productos de mesh VPN ponen esa lógica en su propio plano de control, mientras que un servidor sencillo se la deja a usted. Los keepalives solo ayudan mientras sobrevive el mismo mapeo, y cuestan batería en un cliente móvil, por eso un intervalo agresivo no sale gratis.

Un portátil que duerme una hora suele volver en un extremo público distinto. Lo que restablece el camino tiene que ejecutarse otra vez desde dentro, lo que devuelve el mismo requisito al cliente.

Tres formas de sortear una redirección ausente

La primera forma pide al router que cree él mismo la entrada, mediante UPnP IGD, NAT-PMP o PCP, cuando la función existe y está activada. La segunda entrega el tráfico a un relé con dirección pública, que siempre funciona y siempre cuesta ancho de banda más una frontera de confianza distinta. La tercera invierte la dirección: el host interno abre un túnel saliente hacia un servidor público y todo lo demás viaja dentro.

[Peer]
PublicKey = 6yGj3kQ2wVb8sTn1pLx4dRc7hZa9mKf2uYe5oNq0iXw=
Endpoint = relay.corp.internal:51820
PersistentKeepalive = 25
AllowedIPs = 10.44.0.0/24

Un extremo de relé hace visible ese intercambio en la configuración del cliente, donde el extremo es un relé y no la dirección propia de un par. El keepalive persistente mantiene caliente el mapeo, y los prefijos permitidos deciden qué puede enviar el cliente a través de él. Un túnel inverso desde el host interno es la misma idea con otro propietario, y no necesita ningún cambio de NAT. Cada una de las tres elimina el requisito de entrada sin derrotar un cortafuegos que bloquea por diseño el tráfico no solicitado, porque el tráfico sigue empezando dentro.

Ajuste la solución a quien posee el router

Si administra el router, una redirección UDP estática es más fácil de auditar que cualquier esquema de perforación y falla de formas que usted ve. Si no, averigüe si el fabricante ofrece un relé o un plano de control alojado, y si la política permitiría usarlo. Si no hay ninguno, las opciones restantes son un túnel inverso o aceptar que el extremo no es alcanzable desde fuera. Registrar cuál usó importa más de lo que parece, porque las opciones difieren en quién puede observar el tráfico y en qué ocurre cuando un tercero cambia algo.

Anote si el camino con el que terminó era directo o a través de un relé, ya que ese solo hecho predice tanto la latencia como el comportamiento ante fallos. RFC 4787 sigue siendo la referencia del comportamiento de mapeo que hay debajo de todo esto, y leer su sección de mapeo es más rápido que probar tres soluciones en secuencia. A la tabla no le importa qué opción eligió; solo registra qué puede hacer el siguiente paquete.