Lease di riserva dopo il ritorno del tunnel di sede: rinnovare o attendere?

Collegamento della sede attivo, tunnel stabilito, e i PC della filiale non raggiungono ancora il file server. Durante l’interruzione correvano due orologi e solo uno dei due è finito. Il tunnel si è ripristinato quando è tornato il percorso cifrato; l’indirizzo di ogni client si ripristina quando il suo lease attuale scade o viene sostituito. Confrontare queste due linee temporali spiega il divario più in fretta della lettura dei log del firewall.

Due orologi, e uno dei due non è il tunnel

Con DHCP su VPN più un fallback locale, il dispositivo può assegnare lease locali temporanei finché il percorso DHCP remoto non è disponibile. La durata temporanea si conta di solito in minuti, abbastanza breve da nascondere il problema e abbastanza lunga da sopravvivere a una breve interruzione. Quando il tunnel torna, il fallback smette di offrire quei lease. Non entra in un client per annullare il lease che ha già. Quel client conserva indirizzo, maschera, gateway e resolver fino al rinnovo o alla scadenza, ed è per questo che un tunnel sano e un desktop guasto possono convivere per il resto del lease.

Tenete l’implementazione e la versione del software legate a questa affermazione. I nomi dei timer e i valori predefiniti cambiano tra le versioni di SonicOS, e un’interfaccia più vecchia non dimostra ciò che fa una più recente.

Confrontate le due mosse di ripristino

La mossa A è attendere. Non costa nulla, non rischia nulla e lascia che ogni client rinnovi secondo il proprio calendario. La mossa B è forzare un rilascio e un rinnovo sul client colpito, che ottiene subito l’indirizzo previsto ma interrompe tutto ciò che il client sta facendo. Su un singolo desktop, forzare il rinnovo è di solito la via più rapida e facile da giustificare. In un laboratorio o su un terminale di punto vendita nel mezzo di una transazione, attendere è la scelta più sicura, e un rinnovo programmato fuori orario batte entrambe.

ipconfig /all
ipconfig /release
ipconfig /renew

Leggete l’output prima di rilasciare qualcosa. Se l’indirizzo, il gateway e il DNS corrispondono già all’ambito normale, il client si è ripristinato da solo e il problema restante è altrove. Su un client Linux l’equivalente è rilascio e rinnovo del lease tramite il gestore di rete invece di un indirizzo modificato a mano, perché altrimenti il gestore riscriverà la modifica al prossimo evento.

Leggete l’offerta, non solo l’indirizzo

L’indirizzo da solo non dice chi l’ha fornito. Contano l’identificatore del server nell’offerta, il tempo del lease, e se gateway e resolver corrispondono all’ambito di fallback o a quello normale.

tcpdump -ni any 'port 67 or port 68'

Catturate durante il rinnovo, perché un’interfaccia silenziosa vi dice che il client non ha mai chiesto. Se l’offerta arriva dal fallback locale mentre il tunnel è attivo, la logica di selezione considera ancora il percorso remoto non disponibile, e forzare i rinnovi sui client ripeterà solo lo stesso risultato. Correlate la cattura con gli eventi del tunnel sullo stesso orologio. Un rinnovo delle chiavi o una breve caduta che termina pochi secondi prima della richiesta del client è una causa plausibile; un tunnel pulito con una risposta di fallback è un problema di configurazione nel percorso di selezione.

Dove il confronto si inverte

Se molti client sono colpiti insieme, i rinnovi per client diventano una coda di interruzioni e una chiamata al supporto. In quel caso, guardate l’ambito di fallback e la procedura di ripristino invece dei client, perché la popolazione si è ripresa insieme e si riprenderà insieme di nuovo.

Se è colpito un solo client mentre i vicini stanno bene, vale il contrario: il lease di quel client, la sua prenotazione o il comportamento del suo client DHCP è la variabile, e un cambiamento sull’intera sede è lo strumento sbagliato.

Gli indirizzi statici e le prenotazioni richiedono una terza risposta. Un client fissato a un indirizzo non si salva con un rinnovo, e una prenotazione che collide con l’ambito di fallback produce un duplicato che sembra un guasto di routing finché non confrontate i due piani di indirizzamento.

Scrivete la procedura di uscita

Decidete in anticipo a cosa serve il fallback, quanto a lungo un client può tenere il suo indirizzo temporaneo e chi può forzare un rinnovo durante l’orario di lavoro. Scrivete la risposta dove l’ingegnere di turno la troverà, accanto alla definizione dell’ambito. Poi provatela una volta di proposito: staccate il tunnel, osservate cosa riceve il client, ripristinate il tunnel e annotate quanto tempo impiega il client a recuperare le impostazioni normali. Quell’unico esercizio sostituisce la maggior parte delle congetture la prossima volta che il collegamento della sede vacilla.

Chiudete confermando la risorsa, non l’indirizzo. Raggiungere il file server, risolverne il nome e raggiungere Internet sono tre controlli separati, e solo l’ultimo non è mai stato in dubbio.