Il VPN cade dopo un rinnovo DHCP? Confrontate gli indirizzi

Rinnovo del lease e guasto del VPN compaiono insieme nei log abbastanza spesso che le persone concludono che uno causi l'altro. La coincidenza temporale è reale; la causalità di solito no. Un rinnovo è una richiesta unicast al server che ha emesso il lease, per continuare a usare lo stesso binding, e il server può estenderlo senza che il client cambi un solo indirizzo. Esaminare i valori del client attorno all'evento separa un lease rinnovato in silenzio da una rete che è realmente cambiata sotto un tunnel in funzione.

Partite dal client che è caduto

Aprite prima il log delle connessioni del client e annotate l'ora della caduta al secondo. Poi aprite il log di rete del sistema operativo per lo stesso minuto e leggete in ordine cosa ha fatto l'interfaccia. Questo ordine è tutta l'indagine: un evento DHCP prima della disconnessione, una disconnessione prima dell'evento DHCP e due eventi senza nulla in mezzo sono tre riscontri diversi. Una riga di log che menziona solo il lease mentre il tunnel si stava già riconnettendo è decorazione, non prova.

Scrivete la cronologia man mano invece di tenerla a mente. Le marche temporali di strumenti diversi raramente coincidono alla perfezione, e lo scarto stesso a volte è la spiegazione.

Confrontate i quattro valori attorno all'evento

Quattro valori descrivono il lato locale di una connessione abbastanza bene da cogliere un cambiamento reale: l'indirizzo dell'interfaccia, il gateway predefinito, l'elenco dei resolver e lo stato operativo dell'interfaccia. Rilevateli entro un minuto dalla caduta e confrontateli con una rilevazione fatta mentre il tunnel era sano.

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

Un indirizzo invariato con un gateway invariato e un elenco di resolver cambiato punta alla risoluzione dei nomi più che all'instradamento, e il tunnel può essere sopravvissuto mentre le applicazioni smettevano di trovare gli host. Un gateway cambiato significa che il percorso fuori dalla rete locale si è spostato, e ciò basta a invalidare una rotta che puntava al precedente. Se tutti e quattro i valori coincidono con la rilevazione sana, il lease non è la vostra causa e la logica di riconnessione del client diventa l'argomento. Rilevate il confronto mentre il guasto è visibile, perché una rilevazione sana fatta dopo un riavvio ha una storia di indirizzi diversa e non coinciderà.

Cosa può e cosa non può cambiare un rinnovo

RFC 2131 descrive il rinnovo come una richiesta al server originale a metà del tempo di lease, con riassociazione a qualsiasi server ai sette ottavi se il primo tentativo resta senza risposta. Nessuno dei due passaggi richiede che il client ottenga un indirizzo diverso, e un server collaborativo di solito estende il binding esistente. Un cambiamento reale di indirizzo di solito arriva per un'altra via: un server che rifiuta il rinnovo, un client che ha perso il proprio stato e ha ricominciato, o una rete che ha spostato il dispositivo su un altro segmento.

Il lato pubblico della connessione può cambiare senza alcun cambiamento locale. Dietro una traduzione di grado operatore, l'indirizzo che il peer VPN vede può essere riassegnato indipendentemente da ciò che ha fatto il lease locale, e quella riassegnazione appare identica a un guasto di rete locale dall'interno del client. Confrontare un indirizzo riportato localmente con un'osservazione dal lato del peer è l'unico modo per separarli.

Quando il client non riesce ad adattarsi

Un client che ha legato il proprio trasporto al vecchio indirizzo, ha messo in cache una rotta obsoleta verso il peer o ha salvato un'identità di interfaccia può continuare a ritentare un percorso che non esiste più. È un difetto di adattamento, e si vede come ritrasmissioni ripetute verso un indirizzo che l'host non riesce più a raggiungere. Alcuni client lo gestiscono per progettazione: WireGuard, per esempio, aggiorna l'endpoint di un peer quando arriva un pacchetto correttamente autenticato da una nuova fonte.

Un riavvio manuale che ripristina il servizio è un indizio su dove l'adattamento ha fallito, non una prova che lease e tunnel siano incompatibili. Mantenete la politica di blocco durante il test, altrimenti il test stesso diventa un'interruzione con un'altra causa. Annotate se il client si è ripreso da solo, quanto tempo ha impiegato e quale indirizzo ha ritentato; quella sequenza vi dice più del motivo di disconnessione mostrato nell'interfaccia.

Ripetete l'evento prima di incolparlo

Riproducete la condizione invece di aspettare il calendario: rilasciate e rinnovate il lease, oppure forzate l'evento controllato equivalente, e osservate se il tunnel sopravvive. Su una rete gestita, coordinate qualsiasi cambio di indirizzo con il proprietario della rete, perché un'assegnazione statica arbitraria può entrare in collisione con un dispositivo che già detiene quell'indirizzo.

Dopo una correzione supportata, ripetete lo stesso evento e poi provate un'applicazione e una risoluzione di nome, perché un tunnel che si riconnette ma rompe il DNS supera un test più debole di quello che conta. Riportate il cambiamento specifico che avete osservato, con la sua marca temporale, invece di indicare il lease programmato come causa. La differenza tra questi due resoconti è se la persona successiva può riprodurre il guasto o solo la voce.