Ihre IKEv2-SA steht, aber es gibt keine Kind-SA: Lesen Sie den Austausch

IKE sagt, der Tunnel stehe, die Kind-SA fehle, und beide Aussagen können gleichzeitig wahr sein. Eine etablierte Steuerbeziehung ist keine Datenassoziation, und die beiden Objekte haben getrennte Lebensdauern, Verhandlungen und Fehlermodi. Das Erste als Konnektivität zu melden, ist der Weg, auf dem ein Ticket am Ende behauptet, der Tunnel stehe, während nichts funktioniert. Lesen Sie die Assoziationsliste statt des Zusammenfassungs-Labels der Verbindung, denn diese Liste ist der einzige Ort, an dem das fehlende Objekt sichtbar ist. Was folgt, ist die Reihenfolge, in der die Liste Sinn ergibt.

Zwei Assoziationen, zwei Aufgaben

Eine IKE-SA trägt den Steuerkanal: Identitäten, Schlüssel und die Vorschläge für den Steueraustausch selbst. Eine Kind-SA trägt den ESP-Schutz, mit eigenen Algorithmen und eigenen Traffic-Selektoren. Authentifizierung und Kind-Erzeugung laufen meist zusammen, weil die erste Kind-SA innerhalb von IKE_AUTH verhandelt wird, und genau diese Bündelung überrascht Menschen an der Trennung.

Das erklärt auch die zwei Fehlerformen, auf die Sie treffen werden. Eine während des ersten Austauschs abgelehnte Kind-SA nimmt die IKE-SA meist mit herunter, sodass Sie gar keinen etablierten Steuerkanal sehen. Eine alleinstehende IKE-SA bedeutet häufiger, dass die erste Kind-SA erfolgreich war und ein späterer Versuch, eine Kind-SA zu erzeugen, scheiterte, etwa während einer Schlüsselerneuerung. Zeitstempel trennen diese Fälle schneller als jede Konfigurationsprüfung.

Welche Schicht abgelehnt hat

Wird eine Kind-SA abgelehnt, benennt die Meldung die Schicht. Eine Vorschlagsablehnung bedeutet, dass sich die Gegenstellen nicht auf Algorithmen einigen konnten, häufig weil eine eine andere Perfect-Forward-Secrecy-Gruppe oder eine Chiffre verlangt, die die andere nicht akzeptiert. Eine Selektorablehnung bedeutet, dass die Traffic-Menge rundheraus abgelehnt wurde, was ein Abdeckungs- und kein Kryptografie-Argument ist.

Manchmal ist keine Kind-SA das Design. Eine kinderlose IKE-SA ist eine definierte Erweiterung für Fälle, in denen die Datenassoziation bei Bedarf erzeugt werden soll, sodass die Abwesenheit korrekt ist und die Kind-SA erscheint, wenn passender Traffic eintrifft. strongSwans IKEv2-Notizen decken sowohl den Bedarfsstil als auch die Vorschlagseinstellungen ab, die über den ersten Fall entscheiden.

Prüfen Sie auf eine Bedarfs- oder Trap-Konfiguration, bevor Sie einen Fehler diagnostizieren. Werden Kind-SAs träge erzeugt, ist keine Kind-SA im Ruhezustand der erwartete Zustand, und der eigentliche Test ist, ob Traffic eine hochbringt. Dieser Test trennt auch ein träges Design von einem stillen Fehler, weil eine gescheiterte Erzeugung den Auslöser unbeantwortet lässt statt nur ruhend.

Dann fragen Sie nach dem Datenpfad

Sobald eine Kind-SA existiert, beantworten die Zähler die nächste Frage. ip -s xfrm state meldet Paket- und Bytezahlen pro Assoziation, und eine Kind-SA, die nichts trägt, während Sie Traffic erzeugen, deutet auf Matching oder Routing statt auf eine fehlende Assoziation. swanctl --list-sas druckt die Selektoren der Kind-SA neben diesen Zählern, und das bestätigt, dass das Paket innerhalb der akzeptierten Menge liegt.

Halten Sie die erfolgreiche Authentifizierung und den gescheiterten Kind-Austausch im Bericht getrennt. Ein Bericht, der sagt, die Authentifizierung sei gescheitert, schickt den nächsten Ingenieur zum Zertifikatsspeicher, und der zutreffende Satz ist viel kürzer: Die IKE-SA kam hoch, und die Kind-SA für diesen Fluss wurde nie akzeptiert.

Beide Enden korrelieren

Holen Sie für einen Server, den Sie selbst betreiben, die Client- und Gateway-Protokolle für denselben Austausch, statt zwei Wiederverbindungsversuche eine Stunde auseinander zu vergleichen. Die Meldungen sollten auf beiden Seiten übereinstimmen, und wo sie es nicht tun, haben Sie die falsch konfigurierte Gegenstelle gefunden.

Korrigieren Sie die Kind-Verhandlung und testen Sie dann erneut mit Traffic innerhalb des beabsichtigten Selektors. Das ist der einzige Test, der beweist, dass das fehlende Objekt nun vorhanden ist, weil eine im Ruhezustand aktualisierte Assoziationsliste vor und nach der Korrektur identisch aussehen kann.