DPD-Antworten belegen, dass der IKE-Peer lebt, nicht dass Ihre Daten fließen
Lebendigkeitsantworten, eine Padding-Benachrichtigung und verengte Selektoren beschreiben drei verschiedene Dinge. Lesen Sie sie getrennt, bevor Sie einem davon eine Stockung anlasten.
IPsec-Protokolle können Lebendigkeitsantworten zeigen, während die Anwendung davor hängt, und beide Tatsachen können gleichzeitig zutreffen. Eine DPD-Antwort belegt, dass die IKE-Verarbeitung des Peers in diesem Moment geantwortet hat; sie sagt nichts darüber aus, ob die Child-SA das Paket transportiert, das Sie interessiert. Jede Warnung in der Nähe eines Ausfalls als dessen Ursache zu behandeln, ist der Weg, auf dem ein Selektorproblem als Protokollfehler diagnostiziert wird. Drei Beobachtungen werden am häufigsten verwechselt, und sie beantworten drei verschiedene Fragen. Lesen Sie sie nach Zusammenhang und Zweck, bevor Sie sie nach Zeitstempel lesen.
Was die einzelnen Beobachtungen belegen
Die Tabelle trennt, was eine Beobachtung belegt, von dem, was sie lediglich begleitet.
| 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 |
Keine der drei ist für sich genommen ein Fehler. Jede wird erst neben dem Fluss interessant, den Sie debuggen, und eine Zeile, die sich keinem bestimmten Fluss zuordnen lässt, ist Kontext und kein Beweis.
Lebendigkeit ist keine Datengesundheit
DPD läuft als INFORMATIONAL-Austausch, als Steuerungsebenen-Gespräch zwischen IKE-Daemons. Eine Antwort belegt, dass der IKE-Prozess des Peers erreichbar und bereit zu antworten ist, und ein Timeout belegt, dass er es nicht ist. Kein Ergebnis prüft die Child-SA, die Selektoren, den Weiterleitungspfad oder die Antwort der Anwendung, daher ist ein gesundes DPD neben einem stockenden Transfer ein stimmiges Bild und kein Widerspruch.
Deshalb sind die Lebendigkeitszeilen der am wenigsten nützliche Teil eines Data-Plane-Tickets, so beruhigend sie oben im Protokoll auch aussehen.
Die Padding-Benachrichtigung ist eine Aussage über Padding
TFC-Padding ist die am häufigsten überinterpretierte Zeile in diesen Protokollen. Sie besagt, dass Padding für die Verkehrsflussvertraulichkeit für diese Child-SA nicht akzeptiert wird, was eine Aussage über eine optionale Padding-Funktion und keine Ablehnung des ESP-Schutzes ist. Sie in der Nähe eines Fehlers zu finden, ist meist ein Zufall der Ausführlichkeit, und das Ein- oder Ausschalten von Padding ändert nichts an der Selektorabdeckung.
Die IKEv2-Spezifikation definiert sowohl die Benachrichtigung als auch die Selektoraushandlung, und die Warnbezeichnung einer Implementierung ersetzt in keinem der beiden Fälle die Protokollbedeutung.
Verengung ist leiser und wahrscheinlich relevanter
Ein Responder kann eine Teilmenge der angebotenen Selektoren akzeptieren, und die akzeptierte Menge kann über mehrere Einträge ausgegeben werden, einer portqualifiziert und ein anderer, der alle Ports abdeckt. Nur die erste portqualifizierte Zeile zu lesen, unterschätzt das Akzeptierte; nur die breite Zeile zu lesen, überschätzt es. Vergleichen Sie den ausgegebenen Vorschlag mit der installierten Richtlinie, denn der Vorschlag ist das, was die Peers gesagt haben, und die Richtlinie ist das, was der Kernel abgleichen wird. Wenn sie nicht übereinstimmen, existiert der Tunnel und der Verkehr nicht, was die klassische sporadische Beschwerde ist. Drehen Sie die lokale und die entfernte Perspektive um, wenn Sie Peers vergleichen, denn das Lokale jeder Seite ist das Entfernte der anderen.
Hostspezifische Einträge mit einer Portbeschränkung sind ein zweites Lesen wert, denn sie sind es, die ICMP oder einen zweiten Port ausschließen, während ein Ping zum Gateway weiter funktioniert.
Erstellen Sie einen Datensatz für den fehlschlagenden Fluss
Erfassen Sie Quelle, Ziel, Adressfamilie, Protokoll und Port, wie sie bei der Schutzentscheidung zu sehen sind, einschließlich jeder absichtlichen Übersetzung. Das sind die Werte, die zu einem Selektor passen müssen, und es sind auch die Werte, die Menschen aus dem Gedächtnis neu tippen, wenn das Ticket bei einem dritten Paar Hände ankommt.
Identifizieren Sie dann die Child-SA und ihre gerichteten Zähler: swanctl --list-sas liefert die Assoziationsübersicht auf einem strongSwan-Host, und ip -s xfrm state liefert die Zähler. Lesen Sie sie nach einer frischen erlaubten Anfrage und nicht, während das System im Leerlauf ist. Kein Anstieg des ausgehenden Verkehrs deutet auf die Auswahl oder den lokalen Pfad hin; ausgehend ohne entsprechendes eingehend deutet auf den Peer, seine Weiterleitung oder seine Antworten hin.
Ein abgeschlossener Anwendungsaustausch wiegt schwerer als jeder der Zähler, weshalb der Test an der Anwendung enden sollte und nicht an der Tunnelanzeige.
Wählen Sie die Korrektur danach
Erst wenn dieser Datensatz existiert, gibt es eine Korrektur zu wählen: akzeptierte Selektoren, Route, Filterung, Peer-Implementierung oder eine Grenze, die Sie nun nachgewiesen haben. Ein Zurücksetzen des Peers ändert mehrere Zustände auf einmal und stellt den Verkehr oft wieder her, ohne zu erklären, welcher falsch war, sodass der Ausfall zurückkehrt. Halten Sie auch Kernel-Zustandsdumps aus Tickets heraus, denn sie können Schlüssel enthalten, und die knappe Zusammenfassung reicht für jeden, der helfen muss.
Wenn der Datensatz Ihrer ersten Theorie widerspricht, glauben Sie dem Datensatz und schreiben Sie die Theorie neu; diese Gewohnheit ist mehr wert als jede einzelne hier besprochene Protokollzeile.