La VPN cau després d'una renovació DHCP? Compareu les adreces

La renovació de l'arrendament i la fallada de la VPN apareixen junts als registres prou sovint perquè la gent conclogui que un causa l'altre. La coincidència temporal és real; la causalitat normalment no. Una renovació és una sol·licitud unidifusió al servidor que va emetre l'arrendament, demanant continuar amb la mateixa vinculació, i el servidor pot ampliar-la sense que el client canviï ni una sola adreça. Revisar els valors propis del client al voltant de l'esdeveniment separa un arrendament renovat en silenci d'una xarxa que realment ha canviat sota un túnel en funcionament.

Comenceu pel client que ha caigut

Obriu primer el registre de connexions del client i anoteu l'hora de la caiguda fins al segon. Després obriu el registre de xarxa del sistema operatiu per al mateix minut i llegiu per ordre què va fer la interfície. Aquest ordre és tota la investigació: un esdeveniment DHCP abans de la desconnexió, una desconnexió abans de l'esdeveniment DHCP i dos esdeveniments sense res entremig són tres troballes diferents. Una línia de registre que només esmenta l'arrendament mentre el túnel ja es reconnectava és decoració, no prova.

Escriviu la línia temporal a mesura que avanceu en lloc de tenir-la en memòria. Les marques de temps d'eines diferents poques vegades coincideixen perfectament, i el desfasament mateix de vegades és l'explicació.

Compareu els quatre valors al voltant de l'esdeveniment

Quatre valors descriuen el costat local d'una connexió prou bé per detectar un canvi real: l'adreça de la interfície, la porta d'enllaç predeterminada, la llista de resolutors i l'estat operatiu de la interfície. Captureu-los dins del minut següent a la caiguda i compareu-los amb una captura feta mentre el túnel era sa.

ip -4 -brief addr show dev wlan0
ip -4 route show default
resolvectl status | grep -A3 'DNS Servers'
journalctl -u NetworkManager --since -10m --no-pager | grep -i dhcp

Una adreça sense canvis amb una porta d'enllaç sense canvis i una llista de resolutors canviada apunta a la resolució de noms més que a l'encaminament, i el túnel pot haver sobreviscut mentre les aplicacions deixaven de trobar els amfitrions. Una porta d'enllaç canviada significa que el camí de sortida de la xarxa local s'ha mogut, cosa suficient per invalidar una ruta que apuntava a l'anterior. Si els quatre valors coincideixen amb la captura sana, l'arrendament no és la vostra causa i la lògica de reconnexió del client passa a ser el tema. Captureu la comparació mentre la fallada és visible, perquè una captura sana feta després d'un reinici té un historial d'adreces diferent i no coincidirà.

Què pot i què no pot canviar una renovació

RFC 2131 descriu la renovació com una sol·licitud al servidor original a la meitat del temps d'arrendament, amb revinculació a qualsevol servidor a set vuitens si el primer intent queda sense resposta. Cap dels dos passos no exigeix que el client adquireixi una adreça diferent, i un servidor cooperatiu normalment amplia la vinculació existent. Un canvi real d'adreça sol arribar per un altre camí: un servidor que rebutja la renovació, un client que ha perdut el seu estat i ha començat de nou, o una xarxa que ha mogut el dispositiu a un altre segment.

El costat públic de la connexió pot canviar sense cap canvi local. Darrere d'una traducció de grau operador, l'adreça que veu el parell de la VPN pot reassignar-se independentment del que hagi fet l'arrendament local, i aquesta reassignació sembla idèntica a una fallada de xarxa local des de dins del client. Comparar una adreça informada localment amb una observació del costat del parell és l'única manera de separar-les.

Quan el client no s'adapta

Un client que ha vinculat el seu transport a l'adreça antiga, ha emmagatzemat una ruta obsoleta cap al parell o ha desat una identitat d'interfície pot seguir reintentant un camí que ja no existeix. Això és un defecte d'adaptació, i es veu com a retransmissions repetides cap a una adreça que l'amfitrió ja no pot assolir. Alguns clients ho gestionen per disseny: WireGuard, per exemple, actualitza el punt final d'un parell quan arriba un paquet correctament autenticat des d'una font nova.

Un reinici manual que restaura el servei és una pista sobre on va fallar l'adaptació, no una prova que els arrendaments i els túnels siguin incompatibles. Manteniu la política de bloqueig mentre feu proves, o la prova mateixa es converteix en una caiguda amb una altra causa. Anoteu si el client es va recuperar sol, quant de temps va trigar i quina adreça va reintentar; aquesta seqüència us diu més que el motiu de desconnexió que mostra la interfície.

Repetiu l'esdeveniment abans de culpar-lo

Reproduïu la condició en lloc d'esperar el calendari: allibereu i renoveu l'arrendament, o forceu l'esdeveniment controlat equivalent, i observeu si el túnel sobreviu. En una xarxa gestionada, coordineu qualsevol canvi d'adreça amb el propietari de la xarxa, perquè una assignació estàtica arbitrària pot xocar amb un dispositiu que ja té aquesta adreça.

Després d'una correcció suportada, repetiu el mateix esdeveniment i després proveu una aplicació i una consulta de nom, perquè un túnel que es reconnecta però trenca el DNS passa una prova més feble que la que importa. Informeu del canvi concret que heu observat, amb la seva marca de temps, en lloc de nomenar l'arrendament programat com a causa. La diferència entre aquests dos informes és si la persona següent pot reproduir la fallada o només el rumor.