Il VPN del router sembra a posto dopo un'interruzione? Verificate questi quattro livelli

Un router che si accende dopo un'interruzione ha ripristinato la sua configurazione, non la sua connettività. Dopo un'interruzione di corrente, un router può ripristinare il profilo VPN salvato prima che le dipendenze necessarie a quel profilo siano pronte: il modem a monte può ancora essere in addestramento, l'orologio può essere sbagliato e l'autenticazione può non essere completata. La spia del pannello e la configurazione salvata descrivono un'intenzione, non un tunnel funzionante. Controllate i quattro livelli seguenti nell'ordine invece di sostituire il profilo, perché è ciò che le persone fanno per seconda cosa e rimpiangono per prima.

Tutto qui presuppone che siate sul posto o che abbiate una via di accesso che non dipende dal tunnel che state testando. Se non l'avete, organizzatevela prima della prossima interruzione.

Primo livello: il WAN è davvero tornato

Cominciate dal modem, non dal pannello del router. Un router che termina l'avvio prima che il suo modem si sia addestrato mostra un'interfaccia sana senza nulla dietro, e il tunnel non ha nessun peer da raggiungere. Confermate che il modem stia davvero inoltrando, poi confermate che il router abbia ripreso le impostazioni WAN che vi aspettate. Controllate anche se l'indirizzo WAN è cambiato: un indirizzo dinamico che torna diverso può invalidare una regola basata sull'indirizzo o una lista di autorizzati remota, e dall'interno della rete questo sembra un guasto della VPN.

Alcune reti di accesso richiedono anche un nuovo passaggio di ammissione dopo un'interruzione. Leggete il registro del client per la prima fase di errore invece di indovinare: il primo errore nomina il livello, e tutto ciò che segue è conseguenza. Annotate l'indirizzo e l'esito dell'ammissione nel ticket, perché entrambi decidono se lo stesso profilo funzionerà domani. Un indirizzo cambiato è una correzione di cinque minuti e un mistero di due ore.

Secondo livello: controllate l'orologio prima del certificato

Un orologio sbagliato interferisce con la validità del certificato e con tutto ciò che dipende dal tempo, e un dispositivo integrato che si avvia senza una fonte di tempo funzionante può restare su una data vecchia per un po'. La validazione del certificato allora fallisce per un motivo che non ha nulla a che fare con la credenziale. Un errore di validità le cui date sono sbagliate di anni indica l'orologio; lo stesso errore con date attuali indica il certificato.

date -u
chronyc tracking

Usate il processo di recupero del tempo supportato e confermate l'orologio del router prima di toccare il profilo. Disattivare la validazione per aggirare l'errore trasforma un problema temporaneo di ordine in un indebolimento permanente, ed è la correzione sbagliata più comune in questo scenario. Se il dispositivo non ha un orologio a batteria, l'ordine di avvio conta: ha bisogno dell'accesso alla rete prima di sincronizzare l'ora, e dell'ora prima di validare un tunnel. È quell'ordine che va corretto se lo stesso guasto si ripete dopo ogni interruzione.

Terzo livello: leggete cosa dice il tunnel

Controllate lo stato del tunnel stesso e l'esito della sua stretta di mano o autenticazione, non il fatto che l'interfaccia sia attiva. Un'interfaccia può esistere senza un peer stabilito, e un client può mostrarsi connesso mentre il rinnovo delle chiavi fallisce. Separate i timeout di trasporto dai rifiuti espliciti: un timeout suggerisce che il percorso o il peer non sono ancora raggiungibili, mentre un rifiuto significa che l'estremità remota ha risposto e ha rifiutato, il più delle volte per credenziali, un certificato o un'identità di peer che non corrisponde più. Mandare l'utente a reimpostare la password per un timeout fa perdere il pomeriggio a tutti.

Tenete a portata di mano l'ultima configurazione buona conosciuta per confrontare i campi invece di ricostruirli. Se un campo è cambiato, quel cambiamento è la scoperta. Confrontatelo campo per campo con quella ripristinata invece di leggere solo quella ripristinata. La maggior parte delle sorprese dopo un'interruzione è un campo tornato silenziosamente a un valore predefinito del modello.

Quarto livello: provate da un dispositivo a valle

Aprite una risorsa consentita e innocua da un client dietro il router, poi confermate quale uscita o rotta privata ha effettivamente usato il traffico. Controllate il DNS e ogni famiglia di indirizzi che dite di coprire, perché la sonda del router stesso può riuscire mentre la politica del client è ancora sbagliata — la sonda spesso usa un'altra fonte, un'altra tabella o un altro percorso di risoluzione.

curl -s https://ifconfig.me
nslookup example.com

Se il tunnel è inattivo e non solo mal configurato, decidete se i client interessati devono essere bloccati o possono usare un ripiego approvato. Quella scelta appartiene al piano di failover prima di un'interruzione, non a un thread di chat durante una. Scrivete l'uscita e il resolver osservati nel ticket dell'interruzione. Due righe adesso risparmiano alla persona successiva un'ora di congetture su quale percorso fosse attivo durante la finestra.

Cosa correggere perché la prossima interruzione sia più breve

Se il guasto si ripete, la correzione è l'ordine, non la configurazione: alzate il WAN, poi l'ora, poi il tunnel, poi la politica del client. La maggior parte dei router lo esprime come dipendenza o ritardo, e un breve ritardo deliberato batte una riscrittura del profilo.

Poi ripetete la normale prova di riavvio dopo averlo modificato, inclusa la verifica sul lato client. Una prova di riavvio che guarda solo il pannello del router verifica il livello meno informativo dei quattro.