NAT decide que enderezo de orixe ve realmente o teu servidor VPN

Imaxinas o servidor VPN lendo o enderezo do teu portátil do paquete e escribíndoo nun rexistro. O que le é o que o último salto NAT puxo na cabeceira externa, e nun teléfono usado como punto de acceso adoita ser un enderezo compartido con centos doutros abonados. O enderezo propio da túa máquina 192.168.x.x nunca cruza internet nesa cabeceira, e o enderezo do túnel asígnao o servidor despois de que a conexión xa estea establecida. Así que, cando o rexistro do servidor e ip addr no portátil non coinciden, ningún dos dous está mal; describen capas distintas dunha mesma sesión.

Tres enderezos, e só un está no rexistro

A confusión vén de reducir tres enderezos a un. Cada un ten un propietario distinto, vive nunha cabeceira distinta e chega ao servidor por un camiño distinto.

Só a fila central é descoñecida no momento de conectar. O servidor escríbea na súa táboa de pares, no ficheiro de estado ou no rexistro de fluxos segundo o daemon: WireGuard chámaa punto final, un ficheiro de estado de OpenVPN etiquétaa como Real Address e strongSwan infórmaa como host remoto do IKE_SA. Ese valor refréscase cada vez que chega un paquete doutra fonte, así que cambia sen que ninguén reinicie nada.

A fila inferior é o que a xente malinterpreta como unha declaración de identidade. Marca unha posición na configuración do servidor, non unha persoa, porque o servidor escolleuna do seu propio conxunto. Dous usuarios poden recibir o mesmo enderezo de túnel en días distintos, e un pode ter dous deles desde dous dispositivos.

Por que a tupla rexistrada cambia mentres o túnel segue activo

A tradución de enderezos é unha táboa cun temporizador, non unha vinculación permanente. Un router doméstico conserva a súa asignación UDP un tempo despois do último paquete, unha pasarela de operador recicla portos segundo o seu propio calendario, e un teléfono que pasa de Wi-Fi a LTE volve cunha fonte completamente distinta. Os valores por defecto de conntrack en Linux son unha boa referencia aquí: nf_conntrack_udp_timeout é de 30 segundos e a variante para streaming é de 120, así que un túnel tranquilo pode perder a súa asignación moito antes de que o usuario o note.

O túnel sobrevive porque o protocolo autentica o par, non o enderezo. WireGuard queda sen estado tras o handshake, así que calquera paquete autenticado actualiza o punto final gardado e a revinculación cúrase co paquete seguinte; por iso existe persistent-keepalive = 25, para manter a asignación quente mentres está inactivo. O --float de OpenVPN fai o mesmo traballo e permite que un cliente autenticado continúe desde un enderezo e un porto novos. Nas compilacións 2.4 e 2.5 onde float está desactivado por defecto, unha revinculación reinicia a sesión e o cliente reconéctase.

IPsec chega aí con máis pezas móbiles. IKEv2 detecta a tradución comparando os hashes de orixe e destino nas cargas de detección de NAT, pasa á encapsulación UDP 4500 e segue os keepalive ata a nova tupla. Cando os keepalive están bloqueados, a SA segue activa sobre o papel mentres o tráfico nunha dirección se detén en silencio.

Que pode atribuír o servidor e que non

O mito que merece morrer é que a tradución te oculta do operador. Cambia a etiqueta, non a observación. Unha pasarela tras o NAT do operador ve o espazo 100.64.0.0/10 ou un enderezo público compartido por moitos abonados, e aínda así pode vincular o fluxo a un suxeito de certificado, unha clave pública de WireGuard, un enderezo de túnel asignado, contadores de bytes e unha xanela temporal. Nada diso necesita o teu enderezo LAN.

Os límites tamén van no outro sentido. Un enderezo compartido nun rexistro apunta a unha pasarela, non a unha casa; dúas sesións desde o mesmo enderezo traducido en portos distintos son dispositivos distintos; o mesmo enderezo en dous días diferentes pode ser dous abonados sen relación se o porto se reciclou. Un servidor que só rexistra claves de pares non pode asociar unha a un cliente sen a base de datos de contas, e un servidor que só rexistra enderezos non pode distinguir un portátil dun teléfono tras o mesmo router.

Compara os dous extremos en lugar de adiviñar

Para aclarar que pasou, captura a mesma conexión nos dous extremos no mesmo momento e compara a tupla, non o enderezo. No cliente, antes de calquera tradución:

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

Despois le a entrada de tradución no router ou na pasarela CGNAT, e o que finalmente chega ao servidor:

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

Tres patróns explican a maioría dos desaxustes. O porto de orixe no servidor difire do porto local mentres o destino coincide: tradución de portos ordinaria. O enderezo de orixe no servidor pertence a un bloque de ISP que non é o teu: polo menos unha capa NAT adicional. Os paquetes detéñense tras un período de inactividade e retómanse cun porto novo: a asignación caducou, non é un fallo de encamiñamento. Se as marcas de tempo están a máis dun segundo ou dous, estás comparando dous intentos distintos.

Onde a diferenza rompe as cousas

As caídas que parecen fallos do servidor adoitan comezar aquí. Unha regra de acceso fixada ao teu enderezo de casa falla despois de que cambie o alugamento do ISP. Unha regra de fail2ban que coincide cun enderezo traducido bloquea todos os abonados tras esa pasarela á vez. Un par site-to-site cun enderezo remoto fixo deixa de renovar claves despois de que cambie unha ligazón móbil. O protocolo do túnel estaba ben; a suposición sobre a tupla externa non.

A mesma confusión aparece no lado do servidor. Se a caixa VPN está detrás de NAT, necesitas unha redirección de porto e unha ruta de reenvío funcional; a guía de reenvío de strongSwan cobre ese caso para IPsec. Un servidor accesible só nun enderezo privado nunca ve a tupla traducida que presentan os seus clientes, e iso é un problema distinto de que os clientes estean traducidos.

Percorre estas catro comprobacións en orde e detente na primeira que falle:

• Captura nos dous extremos ao mesmo tempo; confirma que o porto de orixe, o porto de destino e as marcas de tempo coinciden.
• Le a lista de pares do servidor para o enderezo que ten agora, non o que esperabas.
• Revisa a táboa conntrack ou NAT para a entrada e a súa vida útil restante.
• Confirma que o enderezo da interface do túnel no cliente coincide co que asignou o servidor, non co enderezo LAN.

Se ambas as capturas coinciden na tupla e o túnel segue fallando, a tradución non é o teu problema; pasa ao handshake e á táboa de encamiñamento dentro do túnel.