NAT decide qué dirección de origen ve realmente tu servidor VPN

Te imaginas al servidor VPN leyendo la dirección de tu portátil del paquete y escribiéndola en un registro. Lo que lee es lo que el último salto NAT puso en la cabecera externa, y en un teléfono usado como punto de acceso suele ser una dirección compartida con cientos de otros abonados. La dirección propia de tu máquina 192.168.x.x nunca cruza internet en esa cabecera, y la dirección del túnel la asigna el servidor después de que la conexión ya está establecida. Así que, cuando el registro del servidor y ip addr en el portátil no coinciden, ninguno de los dos está mal; describen capas distintas de una misma sesión.

Tres direcciones, y solo una está en el registro

La confusión viene de reducir tres direcciones a una. Cada una tiene un propietario distinto, vive en una cabecera distinta y llega al servidor por un camino distinto.

Solo la fila central es desconocida en el momento de conectar. El servidor la escribe en su tabla de pares, su archivo de estado o su registro de flujos según el demonio: WireGuard la llama punto final, un archivo de estado de OpenVPN la etiqueta como Real Address y strongSwan la informa como host remoto del IKE_SA. Ese valor se refresca cada vez que llega un paquete de otra fuente, así que cambia sin que nadie reinicie nada.

La fila inferior es lo que la gente malinterpreta como una declaración de identidad. Marca una posición en la configuración del servidor, no a una persona, porque el servidor la eligió de su propio grupo. Dos usuarios pueden recibir la misma dirección de túnel en días distintos, y uno puede tener dos de ellas desde dos dispositivos.

Por qué la tupla registrada cambia mientras el túnel sigue activo

La traducción de direcciones es una tabla con temporizador, no una vinculación permanente. Un router doméstico conserva su asignación UDP un tiempo después del último paquete, una pasarela de operador recicla puertos según su propio calendario, y un teléfono que pasa de Wi-Fi a LTE vuelve con una fuente completamente distinta. Los valores por defecto de conntrack en Linux son una buena referencia aquí: nf_conntrack_udp_timeout es de 30 segundos y la variante para streaming es de 120, así que un túnel tranquilo puede perder su asignación mucho antes de que el usuario lo note.

El túnel sobrevive porque el protocolo autentica al par, no a la dirección. WireGuard queda sin estado tras el handshake, así que cualquier paquete autenticado actualiza el punto final guardado y la revinculación se cura con el paquete siguiente; por eso existe persistent-keepalive = 25, para mantener la asignación caliente mientras está inactivo. El --float de OpenVPN hace el mismo trabajo y permite que un cliente autenticado continúe desde una dirección y un puerto nuevos. En las compilaciones 2.4 y 2.5 donde float está desactivado por defecto, una revinculación reinicia la sesión y el cliente se reconecta.

IPsec llega ahí con más piezas móviles. IKEv2 detecta la traducción comparando los hashes de origen y destino en las cargas de detección de NAT, pasa a la encapsulación UDP 4500 y sigue los keepalive hasta la nueva tupla. Cuando los keepalive están bloqueados, la SA sigue activa sobre el papel mientras el tráfico en una dirección se detiene en silencio.

Qué puede atribuir el servidor y qué no

El mito que merece morir es que la traducción te oculta del operador. Cambia la etiqueta, no la observación. Una pasarela tras el NAT del operador ve el espacio 100.64.0.0/10 o una dirección pública compartida por muchos abonados, y aun así puede vincular el flujo a un sujeto de certificado, una clave pública de WireGuard, una dirección de túnel asignada, contadores de bytes y una ventana temporal. Nada de eso necesita tu dirección LAN.

Los límites también van en el otro sentido. Una dirección compartida en un registro apunta a una pasarela, no a un hogar; dos sesiones desde la misma dirección traducida en puertos distintos son dispositivos distintos; la misma dirección en dos días diferentes puede ser dos abonados sin relación si el puerto se recicló. Un servidor que solo registra claves de pares no puede asociar una a un cliente sin la base de datos de cuentas, y un servidor que solo registra direcciones no puede distinguir un portátil de un teléfono tras el mismo router.

Compara ambos extremos en lugar de adivinar

Para aclarar qué pasó, captura la misma conexión en ambos extremos en el mismo momento y compara la tupla, no la dirección. En el cliente, antes de cualquier traducción:

ss -uapn 'dport = :51820'
ip -4 route get 203.0.113.10
wg show wg0 endpoints

Después lee la entrada de traducción en el router o en la pasarela CGNAT, y lo que finalmente llega al servidor:

conntrack -L -p udp --dport 51820
tcpdump -ni eth0 udp port 51820

Tres patrones explican la mayoría de los desajustes. El puerto de origen en el servidor difiere del puerto local mientras el destino coincide: traducción de puertos ordinaria. La dirección de origen en el servidor pertenece a un bloque de ISP que no es el tuyo: al menos una capa NAT adicional. Los paquetes se detienen tras un periodo de inactividad y se reanudan con un puerto nuevo: la asignación caducó, no es un fallo de enrutamiento. Si las marcas de tiempo están a más de un segundo o dos, estás comparando dos intentos distintos.

Dónde la diferencia rompe cosas

Las caídas que parecen fallos del servidor suelen empezar aquí. Una regla de acceso anclada a tu dirección de casa falla cuando cambia el arrendamiento del ISP. Una regla de fail2ban que coincide con una dirección traducida bloquea a todos los abonados tras esa pasarela a la vez. Un par site-to-site con una dirección remota fija deja de renovar claves cuando cambia un enlace móvil. El protocolo del túnel estaba bien; la suposición sobre la tupla externa no.

La misma confusión aparece en el lado del servidor. Si la caja VPN está detrás de NAT, necesitas una redirección de puerto y una ruta de reenvío funcional; la guía de reenvío de strongSwan cubre ese caso para IPsec. Un servidor accesible solo en una dirección privada nunca ve la tupla traducida que presentan sus clientes, y eso es un problema distinto de que los clientes estén traducidos.

Recorre estas cuatro comprobaciones en orden y detente en la primera que falle:

• Captura en ambos extremos al mismo tiempo; confirma que el puerto de origen, el puerto de destino y las marcas de tiempo coinciden.
• Lee la lista de pares del servidor para la dirección que tiene ahora, no la que esperabas.
• Revisa la tabla conntrack o NAT para la entrada y su vida útil restante.
• Confirma que la dirección de la interfaz del túnel en el cliente coincide con la que asignó el servidor, no con la dirección LAN.

Si ambas capturas coinciden en la tupla y el túnel sigue fallando, la traducción no es tu problema; pasa al handshake y a la tabla de enrutamiento dentro del túnel.