Il rilevamento del peer morto di IKEv2 non prova la tua app

Il controllo di vitalità di IKEv2 pone una sola domanda: l'altro peer risponde ancora sulla relazione di controllo protetta. Non misura se un'applicazione interna è sana, se esiste una rotta dietro il gateway o se la navigazione sembra veloce. Il controllo può passare mentre tutto ciò che è utile dietro il tunnel fallisce.

Leggi i due tipi di prova separatamente prima di cambiare un timer.

Che cosa chiede davvero il controllo di vitalità

Uno scambio di vitalità viene inviato dentro l'associazione di sicurezza IKE stabilita e attende una risposta entro una finestra configurata. Il successo significa che l'implementazione IKE del peer è ancora lì e ancora disposta a parlare. Non dice nulla sulle associazioni di sicurezza figlie che trasportano traffico, nulla sull'instradamento oltre il gateway e nulla sul servizio per cui hai aperto il tunnel. Sono tre domande separate con tre modalità di guasto separate.

Questa distinzione decide dove guardare quando una sessione tace. Un peer che continua a rispondere mentre un percorso dati è rotto indica criteri, instradamento o un servizio a valle. Un peer che smette di rispondere indica raggiungibilità o lo stato dell'estremità remota stessa.

Leggi le associazioni di sicurezza prima del browser

Lo stato di controllo e lo stato dei dati sono elencati separatamente quando interroghi il demone, e i contatori dicono se è stato tentato qualcosa. Un'associazione figlia mai installata non somiglia affatto a una installata e poi smessa di passare pacchetti, anche se entrambe producono la stessa lamentela dell'utente.

ipsec statusall | head -n 40
swanctl --list-sas
ip xfrm state | grep -E 'proto|mode'

Annota i nomi degli stati alla lettera nel ticket, insieme ai contatori al momento della lamentela. Una descrizione come tunnel giù nasconde quale delle due associazioni è terminata, e di solito è l'unico fatto che vale la pena avere.

Un guasto di rotta sembra esattamente un peer morto

Il gateway può rispondere agli scambi di controllo mentre un server privato è offline, una rotta inoltrata manca o la risoluzione dei nomi interna fallisce del tutto. Dal punto di vista del client, ognuno di questi casi appare come una sessione attiva e una destinazione che non lo è. Controlla il percorso di ritorno con la stessa cura del percorso di andata, perché l'instradamento asimmetrico sul lato remoto produce silenzio in una sola direzione.

Prova direttamente l'applicazione prevista e nomina l'indirizzo che ha tentato, invece di verificare se il tunnel è attivo. Un ping al gateway dimostra che il gateway risponde; non ha mai dimostrato che rispondesse l'applicazione. Registra l'indirizzo esatto che l'applicazione ha tentato. Quella stringa restringe la ricerca in seguito, ed è l'unico fatto che il ticket di solito omette.

Tieni i timer fuori dalla diagnosi

Accorciare un intervallo di rilevamento non è una modifica delle prestazioni e non aggiunge capacità. In caso di perdita di pacchetti cambia quanto rapidamente un guasto viene riconosciuto, il che può far sembrare diverso un sintomo senza migliorare nulla. Registra prima il momento reale del guasto, poi decidi se la tolleranza è sbagliata per il collegamento che hai davvero.

Gli aggiornamenti della mappatura NAT rientrano nella stessa categoria. Mantengono utilizzabile un percorso tradotto e non sono prova che l'applicazione remota funzioni.

Una politica di ripristino completa dice cosa deve fare il client quando un peer viene dichiarato morto: riavviare, chiudere o attendere, e cosa può fare il resto del traffico mentre accade. Senza questo, lo stesso incidente viene diagnosticato da zero ogni trimestre.