La IP WAN ha canviat i el túnel ha caigut: les comprovacions per ordre

El túnel cau, el router registra una reconnexió i res de la LAN s'ha mogut. Una adreça WAN nova invalida la connexió exterior sense canviar res a dins: l'adreça d'origen del client ha canviat, l'estat NAT antic apunta a un origen que ja no existeix i el parell remot potser encara envia a l'adreça anterior. La recuperació és un comportament normal, i la pregunta útil és quin estat no s'ha actualitzat.

Anomeneu l'esdeveniment abans de llegir el registre

Comproveu què va passar realment a la capa d'accés. Una renovació de la concessió de l'ISP és un esdeveniment. Una sessió PPPoE que s'ha tornat a connectar és un altre. Un mòdem de fibra que s'ha reiniciat, o una commutació per error del WAN d'un enllaç a un altre, canvia l'adreça exterior o el seu camí d'una tercera manera. No són el mateix esdeveniment i no deixen el mateix residu.

Una línia de reconnexió al registre del VPN tampoc no prova un canvi de WAN. Un temps d'espera per inactivitat, un interval de reautenticació i la detecció de parell mort produeixen reconnexions sense cap canvi d'adreça. Compareu les marques de temps del registre d'accés amb el registre del VPN abans de concloure res, i manteniu la finestra de comparació prou ampla per atrapar un canvi que va passar durant la nit.

L'itinerància i la reconnexió són protocols diferents

WireGuard té itinerància autenticada incorporada al protocol: quan un parell rep un paquet autenticat correctament d'una adreça d'origen nova, actualitza el punt final d'aquest parell. L'inici ràpid de WireGuard descriu la configuració del parell que ho fa possible, i per això un client en una adreça canviant sovint es recupera sense un reinici visible.

OpenVPN es comporta diferent per defecte. Una sessió UDP pot acabar i tornar-se a connectar, i el comportament opcional float permet que un parell autenticat continuï des d'una adreça nova allà on la configuració ho permet. Els túnels basats en TCP són més estrictes, perquè la connexió mateixa està lligada al parell d'adreces. Aquesta diferència decideix si la recuperació sembla invisible o s'anuncia al registre cada vegada.

Cap dels dos comportaments diu res de les aplicacions de dins. Un túnel recuperat no restaura una sessió TCP que el parell ja considerava morta.

Estat que el túnel no posseeix

L'estat de traducció i d'encaminament sobreviu a la reconnexió de maneres que sorprenen la gent. Una entrada de conntrack creada per a l'origen antic manté el camí de resposta ancorat a una adreça que ja no existeix, i caduca segons el seu propi calendari i no quan el túnel ha tornat. Reiniciar el servei del túnel no escurça aquesta espera, així que un enllaç reparat encara pot semblar trencat durant un temps.

Les rutes i les regles de política poden referenciar la passarel·la o la interfície antigues. Un conjunt de regles que era correcte abans d'una commutació de WAN pot apuntar a un dispositiu que ara està caigut, cosa que produeix un túnel que informa que està connectat i un trànsit que no va enlloc. El DNS dinàmic per a un servidor que allotgeu és un problema diferent del d'un client que obté un origen nou. El registre s'ha d'actualitzar perquè els clients remots us trobin, i cap configuració del costat del client compensa una adreça que la traducció aigües amunt no reenviarà.

Ordeneu les comprovacions de fora a dins

L'ordre següent va de la connexió exterior cap a dins, i aturar-se al primer pas que falla és el que el fa útil: cada passa descarta la capa de sobre. Mantingueu aquest ordre fins i tot quan la fallada sembli òbvia.

wg show
ip -br addr show
ip route get 198.51.100.7
conntrack -L 2>/dev/null | grep -c ESTABLISHED
journalctl -u openvpn-client@home --since '-2 hours' | tail -n 40

La primera ordre mostra el punt final actual i l'edat de l'encaixada de mans per a cada parell. La segona i la tercera mostren si la interfície exterior i la ruta fins al punt final encara tenen sentit. El recompte de conntrack és una comprovació grollera de l'estat que queda de l'adreça anterior, i el registre del sistema és on s'anota el motiu de la reconnexió.

Després proveu des d'un client de la LAN i no des del router. Un ping originat pel mateix router fa servir un camí diferent del trànsit reenviat, així que un ping correcte des del router demostra que el túnel existeix i res sobre l'abast del client.

Decidiu el comportament esperat i escriviu-lo

Reconnectar-se és el comportament correcte per a la majoria de desplegaments, així que l'objectiu no és evitar-ho. Decidiu en canvi què ha de passar amb el trànsit durant el buit: aturar-lo, retenir-lo o passar a un altre camí. Aquesta decisió pertany al tallafocs i a la política d'encaminament, no al perfil del VPN.

Registreu els esdeveniments d'accés i les hores de reconnexió junts durant una setmana. Els canvis repetits sense cap esdeveniment d'accés corresponent apunten al servei d'accés, i substituir el perfil del VPN no arreglarà un enllaç que no deixa de renegociar. Un sol parell d'entrades en el mateix minut resol la qüestió per a aquest incident i dóna una línia base al següent.