Il vostro tunnel muore dopo che il portatile è rimasto un po' intoccato, e torna nel momento in cui toccate il trackpad. Questo schema indica che il collegamento senza fili entra in risparmio energetico, non che il gateway VPN rifiuti le vostre credenziali. Una mattina intensa sullo stesso profilo è la prova: il tunnel sopravvive finché scorre il traffico e cade quando la radio tace. Percorrete i controlli qui sotto in ordine, fermatevi al primo che fallisce e solo allora cambiate un'impostazione.

Controllo uno: la caduta segue l'inattività?

Iniziate dimostrando la correlazione invece di darla per scontata. Annotate l'ora dell'orologio dell'ultimo pacchetto inviato, l'ora in cui il client ha segnalato il tunnel giù e se nel frattempo lo schermo si è spento. Se l'intervallo è sempre lo stesso avete un problema sul percorso di inattività; se le cadute arrivano a caso durante l'uso attivo, saltate al controllo cinque.

Un test economico che non costa nulla annullare: inviate un ping costante a basso ritmo verso il gateway per venti minuti e lasciate la macchina sola. Se il tunnel regge per tutta la prova, il traffico piccolo costante sta mascherando il sintomo invece di risolverlo, il che resta una prova utile. Tengo l'output di quel ping in un terminale di scarabocchio e poi lo confronto con il registro del client, perché i due orologi raramente concordano.

Controllo due: è solo traffico VPN?

Prima di dare la colpa al tunnel, accertatevi che il collegamento stesso sia ancora utilizzabile. Mentre il tunnel è morto ma lo schermo è ancora spento, provate a raggiungere l'indirizzo del punto di accesso e un host pubblico via IP. Se fallisce anche il ping normale, la radio o il punto di accesso vi hanno lasciato e il client VPN è solo spettatore.

Se il traffico ordinario scorre mentre il tunnel tace, il collegamento è sano e il problema sta nei timer del tunnel stesso o in come il client gestisce una ripresa. Sono due correzioni diverse, quindi non saltate questo passo. Su un portatile con Wi-Fi ed Ethernet insieme, staccate il cavo e ripetete il test di inattività: una caduta di inattività che sparisce su Ethernet cablato è una prova forte per lo strato senza fili.

Controllo tre: leggete lo stato di risparmio energetico

La maggior parte dei desktop vi dà una casella, ma la casella non è lo stato in cui si trova il driver. Leggete prima il rapporto del driver stesso, poi decidete. Su Linux con mac80211 l'interfaccia risponde direttamente:

iw dev wlan0 get power_save          # on or off, per interface
sudo iw dev wlan0 set power_save off # diagnostic only, lost on reconnect

Il secondo comando è un test, non una correzione. Non sopravvive a una disconnessione, a una sospensione o a un riavvio, il che lo rende un modo pulito di verificare l'ipotesi senza lasciare modifiche permanenti.

Su Windows powercfg /q SCHEME_CURRENT stampa lo schema attivo, e il sottoalbero dell'adattatore wireless mostra se all'adattatore si può ordinare di risparmiare energia; la stessa scelta è anche in Device Manager nella scheda di gestione energia dell'adattatore. Su macOS il risparmio energetico 802.11 per interfaccia non vi è esposto, quindi guardate invece pmset -g per il comportamento di sospensione e standby. Lì il guasto di solito si rivela essere il percorso di sospensione e risveglio, non il comportamento in inattività della radio.

Controllo quattro: cambiate una cosa, poi ritestate

Cambiate esattamente una variabile per esecuzione e ripetete lo stesso carico. Se il tunnel ora sopporta un'ora di inattività con il risparmio energetico disattivato, avete imparato qualcosa di reale. Se cade ancora, tornate indietro prima di testare l'idea successiva, altrimenti finite con tre impostazioni sovrapposte e nessuna idea di quale conti.

Il mantenimento della connessione è l'altra variabile indipendente e viene continuamente confuso con il risparmio energetico. Il valore PersistentKeepalive = 25 di WireGuard tiene calda una mappatura NAT;OpenVPN a entrambe le estremità keepalive e ping-restart usa. Entrambi generano traffico su un tunnel altrimenti silenzioso, quindi un mantenimento che sembra correggere la caduta può nascondere un problema radio invece di risolverlo. Testateli separatamente, uno alla volta:

[Peer]
PublicKey = ...
Endpoint = vpn.example.net:51820
PersistentKeepalive = 25

Controllo cinque: quando la radio è innocente

Se le cadute in inattività continuano con il risparmio energetico disattivato e il mantenimento attivo, guardate fuori dal portatile. I punti di accesso e i router domestici fanno scadere le voci NAT o di sessione inattive secondo il proprio calendario, e un server VPN può far cadere una sessione senza traffico.Il roaming tra punti di accesso che condividono lo stesso SSID può anche azzerare il collegamento senza che il client lo dica chiaramente.

Poi confrontate con un secondo dispositivo sulla stessa rete che fa lo stesso test di inattività. Due dispositivi che cadono allo stesso intervallo sono una storia di percorso o di server; uno solo che cade è una storia di driver o di energia locale. Quel confronto costa dieci minuti e vi risparmia di riscrivere la configurazione sbagliata.

Prima di renderlo permanente

Decidete cosa siete disposti a tenere. Uno script per profilo che disattiva il risparmio energetico solo sulle reti dove avete visto la caduta è difendibile. Un ritocco globale che disattiva tutto pagato con la durata della batteria su ogni rete di solito non lo è.

  • Annotate il valore originale di risparmio energetico accanto allo script perché possa essere ripristinato.
  • Ripetete il test di inattività dopo ogni aggiornamento di driver o client; i valori predefiniti cambiano.
  • Tenete insieme il registro del ping e il registro del client quando segnalate il problema.
  • Se il secondo passo è fallito, smettete di cambiare le impostazioni VPN e trattatelo come un guasto locale del collegamento.

Se fate solo una cosa, fate il controllo due. È quello che decide se il resto di questa lista vi riguarda, ed è il passo che le persone saltano quando hanno già deciso che la risposta è il risparmio energetico.

Articoli correlati