Le risposte DPD dimostrano che il peer IKE è vivo, non che i vostri dati scorrono
Risposte di vitalità, una notifica di padding e selettori ristretti descrivono tre cose diverse. Leggetele separatamente prima di accusarne una di uno stallo.
I log IPsec possono mostrare risposte di vitalità mentre l'applicazione davanti a loro si blocca, ed entrambi i fatti possono essere veri allo stesso tempo. Una risposta DPD stabilisce che l'elaborazione IKE del peer ha risposto in quel momento; non dice nulla sul fatto che la SA figlia trasporti il pacchetto che vi interessa. Trattare ogni avviso vicino a un guasto come la sua causa è il modo in cui un problema di selettore viene diagnosticato come un bug di protocollo. Tre osservazioni vengono confuse più spesso, e rispondono a tre domande diverse. Leggetele per associazione e scopo prima di leggerle per marca temporale.
Cosa dimostra ciascuna osservazione
La tabella separa ciò che ogni osservazione stabilisce da ciò che essa si limita ad accompagnare.
| Observation | What it establishes | What it leaves open |
|---|---|---|
| DPD replies arrive | The peer's IKE process answered | The child SA, forwarding path and application reply |
| TFC padding notification | The peer will not accept padding for that child SA | Whether ordinary ESP protection still works, which it does |
| Selectors reported as narrowed | The accepted traffic set is a subset of the offer | Whether the subset includes the flow the user needs |
Nessuna delle tre è un errore di per sé. Ciascuna diventa interessante solo accanto al flusso che state depurando, e una riga che non può essere legata a un flusso preciso è contesto, non prova.
La vitalità non è la salute dei dati
DPD viene eseguito come scambio INFORMATIONAL, una conversazione di piano di controllo tra demoni IKE. Una risposta dimostra che il processo IKE del peer è raggiungibile e disposto a rispondere, e un timeout dimostra che non lo è. Nessuno dei due risultati mette alla prova la SA figlia, i selettori, il percorso di inoltro o la risposta dell'applicazione, quindi un DPD sano accanto a un trasferimento bloccato è un quadro coerente, non una contraddizione.
Per questo le righe di vitalità sono la parte meno utile di un ticket di piano dati, per quanto rassicuranti appaiano in cima al registro.
La notifica di padding è un'affermazione sul padding
Il padding TFC è la riga più sovrainterpretata di questi log. Dice che il padding per la riservatezza del flusso di traffico non sarà accettato per quella SA figlia, il che è un'affermazione su una funzione di padding opzionale e non un rifiuto della protezione ESP. Trovarla vicino a un guasto è di solito una coincidenza di verbosità, e attivare o disattivare il padding non cambia nulla nella copertura dei selettori.
La specifica IKEv2 definisce sia la notifica sia la negoziazione dei selettori, e l'etichetta di avvertimento di un'implementazione non sostituisce il significato del protocollo in nessuno dei due casi.
Il restringimento è più silenzioso e più probabilmente rilevante
Un risponditore può accettare un sottoinsieme dei selettori offerti, e l'insieme accettato può essere stampato su più voci, una qualificata per porta e un'altra che copre tutte le porte. Leggere solo la prima riga qualificata per porta sottostima ciò che è stato accettato; leggere solo la riga ampia lo sovrastima. Confrontate la proposta stampata con la politica installata, perché la proposta è ciò che i peer hanno detto e la politica è ciò che il kernel farà corrispondere. Quando non coincidono, il tunnel esiste e il traffico no, che è la classica lamentela intermittente. Invertite la prospettiva locale e remota quando confrontate i peer, poiché il locale di ciascun lato è il remoto dell'altro.
Le voci specifiche dell'host con una restrizione di porta meritano una doppia lettura, perché sono quelle che escludono ICMP o una seconda porta lasciando funzionante un ping verso il gateway.
Costruite un record per il flusso che fallisce
Registrate origine, destinazione, famiglia di indirizzi, protocollo e porta come appaiono alla decisione di protezione, inclusa qualsiasi traduzione deliberata. Sono i valori che devono corrispondere a un selettore, e sono anche i valori che le persone ridigitano a memoria quando il ticket arriva a un terzo paio di mani.
Poi identificate la SA figlia e i suoi contatori direzionali: swanctl --list-sas fornisce il riepilogo dell'associazione su un host strongSwan, e ip -s xfrm state fornisce i contatori. Leggeteli dopo una richiesta consentita recente e non mentre il sistema è inattivo. Nessun aumento in uscita indica la selezione o il percorso locale; l'uscita senza un ingresso corrispondente indica il peer, il suo inoltro o le sue risposte.
Uno scambio applicativo completato supera entrambi i contatori, per questo il test dovrebbe terminare all'applicazione e non all'indicatore del tunnel.
Scegliete la correzione in seguito
Solo quando quel record esiste c'è una correzione da scegliere: selettori accettati, rotta, filtraggio, implementazione del peer o un confine che ora avete dimostrato. Reimpostare il peer cambia diversi stati insieme e spesso ripristina il traffico senza spiegare quale fosse sbagliato, così il guasto ritorna. Tenete anche i dump di stato del kernel fuori dai ticket, perché possono contenere chiavi e il riepilogo ristretto basta a chiunque debba aiutare.
Quando il record contraddice la vostra prima teoria, credete al record e riscrivete la teoria; quell'abitudine vale più di qualsiasi singola riga di log discussa qui.