Il VPN si disconnette di continuo: prova la radio prima del server

Una disconnessione VPN può iniziare molto prima che qualsiasi traffico raggiunga il server. La perdita del Wi-Fi, un passaggio dal Wi-Fi alla rete mobile, la congestione dell'access point locale e un telefono che va in sospensione possono interrompere il percorso esterno mentre il software del tunnel segnala un guasto pulito. Procedi dal dispositivo verso l'esterno: prima il collegamento, poi gli eventi del client stesso, poi un confronto controllato e solo alla fine il server. Quest'ordine ti evita di cambiare nodi di uscita per un problema che vive nella stanza.

Guarda il collegamento, non l'icona del segnale

Cerca le transizioni del collegamento, non le barre. Un dispositivo può mostrare un segnale forte mentre l'access point è saturo, mentre è in corso un passaggio in roaming o mentre una politica di risparmio energetico ferma la radio a schermo spento.

Registra lo stato dell'interfaccia, il gateway corrente e l'ora di ogni cambiamento. Poi controlla se la disconnessione coincide con la transizione. Una caduta che avviene ogni volta che il telefono si sposta tra le stanze è un problema di collegamento finché non si dimostra il contrario, qualunque server mostri l'app.

Leggi gli eventi di riconnessione del client

La maggior parte dei client registra un motivo della disconnessione e un timestamp per il tentativo successivo. Un tunnel che rinegozia in pochi secondi e poi funziona è un evento diverso da uno che resta giù finché non lo riattivi a mano.

Le riconnessioni brevi ripetute indicano il percorso esterno, perché il client continua a raggiungere il server e a perdere la sessione. Un tunnel che resta giù indica l'autenticazione, un cambio di endpoint o una politica, perché il client non arriva abbastanza lontano da perdere qualcosa. Leggi i due schemi separatamente prima di toccare la configurazione.

Confronta un secondo endpoint con cautela

Un secondo endpoint è un confronto utile e non è, da solo, un esperimento controllato. Cambia la rotta, l'infrastruttura e spesso il paese, quindi una differenza tra due endpoint non dimostra che il primo server sia difettoso.

Mantieni fissi il dispositivo, la rete di accesso e il carico di lavoro e annota cos'altro è cambiato quando hai cambiato. Se entrambi gli endpoint falliscono nello stesso momento nello stesso luogo, il percorso locale è il fattore comune. Se fallisce solo uno, il server o la rotta verso di esso diventa la pista. Annota i fattori confondenti perché la conclusione non superi le prove.

Correla con il server che amministri

Se amministri l'endpoint, fai coincidere l'ora del tentativo con i registri di ascolto e di associazione. Più client non correlati che falliscono sullo stesso gateway sono una prova diversa da un solo telefono che cade ogni volta che si sposta.

Una singola risposta di un peer non stabilisce una salute continua dell'applicazione. Dopo il ripristino, prova la risorsa che ti serve davvero, perché una stretta di mano riuscita e un server raggiungibile possono coesistere con un percorso applicativo rotto.

Scrivi il rapporto che lo circoscrive

Separa quattro affermazioni: perdita del collegamento locale, raggiungibilità esterna, negoziazione del tunnel e stato proprio dell'applicazione. Ognuna ha le sue prove, e un rapporto che le tiene distinte dice alla persona successiva dove guardare.

Annota anche i limiti del confronto. Se una politica ha impedito un test del percorso diretto, dillo invece di presentare il confronto tra endpoint come prova. L'etichetta del paese nell'app non identifica la rotta completa, e un server geograficamente vicino può essere comunque raggiunto attraverso un percorso congestionato.

La pagina delle limitazioni note del progetto WireGuard è un utile promemoria che un protocollo può essere corretto e lasciare comunque il comportamento del collegamento al sistema operativo. Chiudi ripetendo lo stesso test dopo la prossima disconnessione, perché un singolo evento è un dato e uno schema è una diagnosi.