Wenn IKEv2 TS_UNACCEPTABLE zurückgibt, die echten Subnetze vergleichen

Lesen Sie TS_UNACCEPTABLE als Uneinigkeit über die Abdeckung, nicht als beschädigtes Profil. Das Gateway sagt damit, dass die beiden Gegenstellen sich nicht darauf einigen konnten, welche Adressen dieser Tunnel tragen darf. Die IKE SA kann zu diesem Zeitpunkt bereits stehen, weshalb ein Client verbunden aussehen kann, ohne dass eine Child-SA dahintersteht. Sobald Sie es so rahmen, wird die Arbeit mechanisch. Notieren Sie die beabsichtigten Präfixe beider Seiten, vergleichen Sie sie in eine Richtung und verengen Sie, bis sie sich schneiden.

Schreiben Sie zuerst die beabsichtigten Paare auf

Bevor Sie die Konfiguration anfassen, listen Sie vier Werte auf: den Quellbereich des Initiators, seinen Zielbereich und dasselbe Paar aus Sicht des Responders. Halten Sie außerdem die Adressfamilie jedes Eintrags fest. Ein IPv4-Bereich und ein IPv6-Bereich sind verschiedene Selektor-Typen, und keiner lässt sich in die Nutzlast des anderen falten.

Ergänzen Sie jede Protokoll- oder Portbeschränkung, die die Richtlinie trägt. Eine Regel, die nur TCP 445 zu einem Dateiserver erlaubt, beschreibt eine engere Menge als das Subnetz, in dem sie liegt. Lassen Sie das aus Ihren Notizen weg, wirkt das Verhandlungsergebnis inkonsistent aus Gründen, die Sie nicht sehen.

Drehen Sie die Bezeichnungen um, bevor Sie sie vergleichen

Lokal und entfernt sind relative Bezeichnungen. Das lokale Präfix des Clients ist der entfernte Bereich des Gateways, und der lokale Bereich des Gateways ist der entfernte des Clients. Deshalb decken sich Screenshots von beiden Enden nie, und sie wörtlich zu vergleichen ist der übliche Weg, einen Nachmittag zu verlieren.

Ein Responder kann ein Angebot auf eine akzeptable Teilmenge verengen, statt es abzulehnen. Dieses Ergebnis ist schlechter als ein sauberer Fehlschlag, weil es halb funktioniert. Fordern Sie 10.0.0.0/16 an, während die Richtlinie 10.0.5.0/24 erlaubt, und Sie können mit einer Child-SA enden, die nur dieses /24 abdeckt. Ein Host antwortet, alles andere fällt heraus, und nichts im Client sagt es. Lesen Sie die akzeptierten Selektoren statt der angeforderten, bevor Sie schließen, dass die Verhandlung erfolgreich war.

Road-Warrior-Profile, die eine Standardroute anfordern, landen hier ständig. Ein Gateway für getrennten Zugriff verengt ein Angebot über den vollen Bereich auf seine eigenen Subnetze, und der Client muss das verengte Ergebnis akzeptieren oder laut scheitern.

Lesen Sie die Ablehnung aus einem Versuch

Sammeln Sie beide Protokolle aus demselben Verbindungsversuch. Ein gespeichertes Profil zeigt, was Sie konfiguriert haben, nicht was vorgeschlagen wurde, und unter strongSwan gibt swanctl --log die empfangene Notify zusammen mit den mitgeführten Selektoren aus.

Prüfen Sie dann, was tatsächlich installiert wurde. swanctl --list-sas zeigt die Selektoren der Child-SA, und ip xfrm policy zeigt dieselben Bereiche als Kernel-Richtlinieneinträge. Eine Child-SA in dieser Liste mit Selektoren, die Sie nicht beabsichtigt haben, ist ein Verengungsereignis; keine Child-SA plus TS_UNACCEPTABLE im Protokoll ist eine Ablehnung.

Trennen Sie die nahen Nachbarn, solange Sie dort sind. INVALID_SELECTORS beklagt einen Selektor innerhalb einer etablierten Child-SA, während INTERNAL_ADDRESS_FAILURE bedeutet, dass der Responder keine virtuelle Adresse zuweisen konnte, was ein Pool- und kein Abdeckungsproblem ist.

Prüfen Sie, was die Menge still verkleinert

Drei Dinge verkleinern eine Selektor-Menge, ohne etwas zu sagen. Die Responder-Richtlinie ist das erste, über Subnetzlisten, Gruppenregeln oder Autorisierung pro Benutzer, die das Angebot auf eine Teilmenge reduzieren. Die Adressfamilie ist das zweite: Ein Dual-Stack-Client schlägt oft IPv6 neben IPv4 vor und bekommt eine Ablehnung für Bereiche, die das Gateway nie konfiguriert hat.

Protokoll- und Portbeschränkungen sind das dritte. Wo die Richtlinie nur TCP 445 erlaubt, kann eine Child-SA hochkommen, während ICMP und UDP außerhalb bleiben, und der Benutzer meldet einen kaputten Tunnel, obwohl ein einziges Protokoll alles war, was je erlaubt wurde.

Das bloße Erweitern von Adressen kann eine portbeschränkte Richtlinie daher nicht reparieren, und genau das ist der Fall, der drei Runden Fehlersuche am wahrscheinlichsten unverändert übersteht.

Beweisen Sie die Abdeckung mit passendem Verkehr

Nachdem die Child-SA installiert ist, senden Sie eine Anfrage, die sicher in die akzeptierten Bereiche fällt. Beobachten Sie die Zähler statt des Status-Symbols: ip -s xfrm state und die Zähler hinter ip xfrm policy steigen, wenn ein Paket zugeordnet und geschützt wird. Eine Bytezahl, die nach echtem Verkehr bei null bleibt, bedeutet, dass der Kernel diese Richtlinie nie ausgewählt hat.

Diese Null ist ein Routing- oder Richtlinienreihenfolgeproblem, kein Krypto-Problem. Sie sieht aus Sicht des Benutzers auch identisch zu einer Selektor-Ablehnung aus, weshalb es sich lohnt, die Zähler zu sammeln, bevor Sie das Profil erneut öffnen. Zähler, die nur in eine Richtung steigen, deuten stattdessen auf den Rückweg hin.

Schließen Sie ab, indem Sie das akzeptierte Paar ins Ticket schreiben, neben den ursprünglich angeforderten Bereich. Halten Sie die Auswahl so eng wie die Anforderung, denn das Löschen des Fehlers durch Ersetzen eines privaten Bereichs durch alle Adressen gewährt weit mehr Zugriff, als für das Konto genehmigt wurde.