NAT decideix quina adreça d’origen veu realment el vostre servidor VPN

Us imagineu el servidor VPN llegint l’adreça del portàtil del paquet i escrivint-la en un registre. El que llegeix és el que l’últim salt NAT ha posat a la capçalera externa, que en un telèfon compartit com a punt d’accés sovint és una adreça compartida amb centenars d’altres abonats. L’adreça pròpia de la vostra màquina 192.168.x.x no travessa mai internet en aquesta capçalera, i l’adreça del túnel l’assigna el servidor després que la connexió ja estigui establerta. Per tant, quan el registre del servidor i ip addr al portàtil no coincideixen, cap dels dos no és incorrecte; descriuen capes diferents d’una mateixa sessió.

Tres adreces, i només una és al registre

La confusió ve de reduir tres adreces a una. Cadascuna té un propietari diferent, viu en una capçalera diferent i arriba al servidor per un camí diferent.

Només la fila del mig és desconeguda en el moment de connectar. El servidor l’escriu a la seva taula de parells, al fitxer d’estat o al registre de fluxos segons el dimoni: WireGuard l’anomena punt final, un fitxer d’estat d’OpenVPN l’etiqueta com a Real Address, i strongSwan el reporta com a host remot de l’IKE_SA. Aquest valor es refresca sempre que arriba un paquet d’una font diferent, així que canvia sense que ningú reiniciï res.

La fila de baix és el que la gent llegeix malament com una afirmació d’identitat. Marca un lloc a la configuració del servidor, no una persona, perquè el servidor el va triar del seu propi conjunt. Dos usuaris poden rebre la mateixa adreça de túnel en dies diferents, i un pot tenir-ne dues des de dos dispositius.

Per què la tupla registrada canvia mentre el túnel segueix actiu

La traducció d’adreces és una taula amb temporitzador, no una vinculació permanent. Un router domèstic conserva la seva assignació UDP una estona després de l’últim paquet, una passarel·la d’operador recicla ports segons el seu propi calendari, i un telèfon que passa de Wi-Fi a LTE torna amb una font completament diferent. Els valors per defecte de conntrack a Linux són una bona referència aquí: nf_conntrack_udp_timeout és de 30 segons i la variant per a streaming és de 120, així que un túnel tranquil pot perdre l’assignació molt abans que l’usuari ho noti.

El túnel sobreviu perquè el protocol autentica el parell, no l’adreça. WireGuard queda sense estat després de la handshake, així que qualsevol paquet autenticat actualitza el punt final desat i la revinculació es cura amb el paquet següent; per això existeix persistent-keepalive = 25, per mantenir l’assignació calenta mentre està inactiu. El --float d’OpenVPN fa la mateixa feina i permet que un client autenticat continuï des d’una adreça i un port nous. A les versions 2.4 i 2.5 on float està desactivat per defecte, una revinculació reinicia la sessió i el client es torna a connectar.

IPsec hi arriba amb més peces mòbils. IKEv2 detecta la traducció comparant els hashos d’origen i destí a les càrregues de detecció de NAT, passa a encapsulament UDP 4500 i segueix els keepalive fins a la nova tupla. Quan els keepalive estan bloquejats, la SA segueix activa sobre el paper mentre el trànsit en una direcció s’atura en silenci.

Què pot atribuir el servidor i què no

El mite que val la pena matar és que la traducció us amaga de l’operador. Canvia l’etiqueta, no l’observació. Una passarel·la darrere del NAT de l’operador veu l’espai 100.64.0.0/10 o una adreça pública compartida per molts abonats, i tot i així pot lligar el flux a un subjecte de certificat, una clau pública de WireGuard, una adreça de túnel assignada, comptadors de bytes i una finestra temporal. Res d’això no necessita la vostra adreça LAN.

Els límits també van en l’altre sentit. Una adreça compartida en un registre apunta a una passarel·la, no a una llar; dues sessions des de la mateixa adreça traduïda en ports diferents són dispositius diferents; la mateixa adreça en dos dies diferents pot ser dos abonats sense relació si el port es va reciclar. Un servidor que només enregistra claus de parells no pot associar-ne una a un client sense la base de dades de comptes, i un servidor que només enregistra adreces no pot distingir un portàtil d’un telèfon darrere del mateix router.

Compareu els dos extrems en lloc d’endevinar

Per aclarir què va passar, captureu la mateixa connexió als dos extrems al mateix moment i compareu la tupla, no l’adreça. Al client, abans de qualsevol traducció:

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

A continuació llegiu l’entrada de traducció al router o a la passarel·la CGNAT, i el que finalment arriba al servidor:

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

Tres patrons expliquen la majoria de desajustos. El port d’origen al servidor difereix del port local mentre el destí coincideix: traducció de ports ordinària. L’adreça d’origen al servidor pertany a un bloc d’ISP que no és el vostre: almenys una capa NAT addicional. Els paquets s’aturen després d’un període d’inactivitat i es reprenen amb un port nou: l’assignació ha caducat, no és una fallada d’encaminament. Si les marques de temps estan a més d’un segon o dos, esteu comparant dos intents diferents.

On la diferència trenca les coses

Les caigudes que semblen fallades del servidor solen començar aquí. Una regla d’accés fixada a la vostra adreça de casa falla després que canviï el lloguer de l’ISP. Una regla de fail2ban que coincideix amb una adreça traduïda bloqueja tots els abonats darrere d’aquella passarel·la alhora. Un parell site-to-site amb una adreça remota fixa deixa de renovar claus després que canviï un enllaç mòbil. El protocol del túnel anava bé; la suposició sobre la tupla externa no.

La mateixa confusió apareix a la banda del servidor. Si la caixa VPN mateixa és darrere de NAT, necessiteu una redirecció de port i un camí de reenviament funcional; la guia de reenviament de strongSwan cobreix aquest cas per a IPsec. Un servidor accessible només en una adreça privada no veu mai la tupla traduïda que li presenten els seus clients, i això és un problema diferent del fet que els clients estiguin traduïts.

Feu aquestes quatre comprovacions en ordre i atureu-vos a la primera que falli:

• Captureu als dos extrems alhora; confirmeu que el port d’origen, el port de destí i les marques de temps coincideixen.
• Llegiu la llista de parells del servidor per l’adreça que té ara, no per l’adreça que esperàveu.
• Comproveu la taula conntrack o NAT per l’entrada i la seva vida útil restant.
• Confirmeu que l’adreça de la interfície del túnel al client coincideix amb la que el servidor va assignar, no amb l’adreça LAN.

Si les dues captures coincideixen en la tupla i el túnel encara falla, la traducció no és el vostre problema; passeu a la handshake i a la taula d’encaminament dins del túnel.