Accorciare il timer DPD non rende più veloce il failover VPN

I tunnel cadono, il recupero richiede novanta secondi e il timer del peer morto è impostato su dieci, quindi si incolpa il timer. Questo ragionamento salta tre fasi che avvengono dopo il rilevamento e di solito consumano la maggior parte del tempo. Il rilevamento di vitalità nota il silenzio; poi la selezione del peer, l’autenticazione, l’installazione della rotta e la riconnessione dell’applicazione prendono ciascuna il proprio turno. Accorciare la prima fase non può accorciare le altre, e può aggiungere scompiglio a un sistema già in difficoltà.

Quattro fasi, una delle quali puoi cronometrare

Scrivi il recupero come quattro eventi con marche temporali. Il guasto diventa osservabile: l’ultimo traffico protetto utile e la prima richiesta fallita. Il meccanismo responsabile reagisce: rilevamento di vitalità, un monitor di rotta o un altro trigger documentato. L’alternativa diventa utilizzabile: selezione del peer, autenticazione, una nuova associazione e una rotta che trasporta davvero il traffico previsto. L’applicazione si riprende: una nuova operazione riesce e ciò che era in corso ha un esito definito.

Le regole di vitalità di IKEv2 descrivono prove sul peer e sui suoi scambi, e non dicono nulla su un database o un servizio file dietro quel peer. Leggere un timeout di vitalità come un controllo di salute dell’intero percorso è l’errore che avvia la caccia al timer.

Perché il timer è il numero meno interessante

I valori configurati non sono unità intercambiabili. Alcuni sono intervalli di nuovo tentativo, altri sono limiti superiori di un tentativo, e altri vengono eseguiti in parallelo ad altri. Sommarli produce un numero che sembra una previsione e si comporta come una voce. Leggi la documentazione del campo che stai per toccare e nota quale dei tre tipi sia.

Altre fasi non sono affatto timer. Un backoff di riconnessione, una richiesta di autenticazione interattiva o un client che rivaluta la sua configurazione solo al riavvio possono ciascuno dominare l’interruzione mentre ogni timer di protocollo resta comodamente basso.

Misura la fase che è davvero lenta

Cattura il guasto una volta, con marche temporali su entrambi i lati, poi confronta i quattro eventi invece dei contatori del protocollo stesso. Una finestra di osservazione fatta bene vale più di un mese di regolazioni.

ip -4 route get 203.0.113.10
tcpdump -ni any -c 20 "esp or icmp"

Se l’endpoint alternativo non risponde mai, nessun cambiamento del timer aiuta, perché l’irraggiungibilità non è un problema di rilevamento. Se il nuovo stato di sicurezza si forma rapidamente ma la rotta punta ancora al percorso morto, il problema è l’installazione della rotta e un altro ritocco di vitalità aggiunge solo scompiglio.

L’alternativa deve essere già utilizzabile

Un backup definito in una configurazione non è un backup che funziona. Deve essere raggiungibile dalla rete attuale del client, capace di autenticare la stessa identità e autorizzato a trasportare lo stesso traffico con la stessa politica. Scopri una di queste tre lacune durante un’interruzione e la discussione sul timer diventa irrilevante. Prova l’alternativa mentre la primaria è sana, perché è l’unico momento in cui puoi leggere entrambi i log fianco a fianco.

Predisponi l’alternativa in anticipo, provala deliberatamente mentre la primaria è sana e registra quale delle quattro fasi consuma il tempo. È quel registro che rende il cambiamento successivo una misurazione invece di una congettura.

Scompiglio di ritorno e il percorso di gestione

Ripristinare la primaria è una decisione separata. Un ritorno aggressivo può interrompere lavoro che si era già ripreso sul backup, e un percorso instabile può sembrare un tunnel instabile quando il guasto reale è una rotta che oscilla tra due opzioni uguali.

Due percorsi di pari costo senza preferenza sono la fonte abituale dell’oscillazione visibile, perché ogni monitor reagisce alla scelta dell’altro. Decidi quale percorso è preferito in condizioni normali e rendi esplicita quella preferenza nella configurazione invece di lasciarla all’ordine delle rotte. Definisci in anticipo il comportamento di ritorno desiderato e chi ne è responsabile. Conserva le impostazioni precedenti e un percorso di gestione indipendente, perché un cambiamento che rimuove il tuo accesso durante un’interruzione trasforma un incidente di rete in una visita in sede.

Poi ripeti lo stesso carico di lavoro e confronta le stesse quattro marche temporali. Un recupero più breve che lascia ancora l’applicazione in attesa della stessa rotta o dello stesso accesso mancante non è un progresso, è un numero diverso sullo stesso grafico.