Warum Ihr IPsec-Tunnel bis zur ersten CHILD-SA-Schlüsselerneuerung funktioniert

Der Tunnel kam hoch, der Ping antwortete, und alle gaben grünes Licht. Vier Stunden später bricht die Sitzung ab, die Peers protokollieren einen Vorschlags- oder Schlüsselaustauschfehler, und die erste Vermutung ist, dass sich im Netzwerk etwas geändert hat. Nichts hat sich geändert. Ein Tunnel, der Datenverkehr trägt, hat bewiesen, dass sich beide Peers darüber einig sind, wie authentifiziert und wie die erste untergeordnete Assoziation geschützt wird, und er hat nichts über den Schlüsselaustausch bewiesen, den sie bei der Erneuerung verlangen werden. Die Abweichung sitzt in der Lücke zwischen diesen beiden Ereignissen.

Verbunden heißt nicht, dass die PFS-Einstellungen übereinstimmen

Bei IKEv2 wird die erste untergeordnete Assoziation während des Authentifizierungsaustauschs erzeugt, und ihre Schlüssel werden aus Material abgeleitet, das die IKE-Assoziation bereits erzeugt hat. Für diese untergeordnete Assoziation findet kein separater Diffie-Hellman-Austausch statt, sodass eine Richtlinie, die einen solchen bei der Erneuerung verlangt, beim Aufbau nicht geprüft wird.

Die Erneuerung ist ein anderer Austausch. Wenn der Schlüssel einer untergeordneten Assoziation erneuert wird, können die Peers einen neuen Schlüsselaustausch mit der in ihren Vorschlägen genannten Gruppe durchführen, und das ist der erste Moment, in dem die Gruppeneinstellungen verglichen werden. Zwei Peers, die sich uneinig sind, können sich daher authentifizieren, eine untergeordnete Assoziation installieren und Datenverkehr durchlassen und dann bei der Erneuerung scheitern.

Wo sich die Abweichung in der Vorschlagszeichenfolge versteckt

In strongSwan wird die Gruppe an den untergeordneten Vorschlag angehängt, weshalb eine Zeichenfolge wie aes256gcm16-prfsha256-ecp256 wie eine Verschlüsselungswahl aussieht, aber auch eine Anforderung an den Schlüsselaustausch trägt. Ein Peer, der nur aes256gcm16-prfsha256 anbietet, hat diese Anforderung nicht, und die beiden Listen überschneiden sich bei der Verschlüsselung, während sie beim Austausch auseinandergehen.

Lesen Sie den untergeordneten Vorschlag und den IKE-Vorschlag als getrennte Listen. Eine Gruppe, die in der IKE-Liste erscheint, sagt nichts über die untergeordnete Liste aus, und das eine zu bearbeiten, während man das andere liest, ist der übliche Weg, das zu übersehen.

Lesen Sie den Fehler, nicht die Datei, die Sie bearbeitet haben

Suchen Sie die Notify, die den Austausch beendet hat. Eine untergeordnete Schlüsselerneuerung, die »kein akzeptabler Vorschlag« zurückgibt, deutet auf die Vorschlagslisten hin; eine Erneuerungsanforderung, die nie eine Antwort erhält, deutet auf den Pfad oder auf einen Peer hin, der aufgehört hat zu lauschen. Diese beiden brauchen unterschiedliche Korrekturen, und die Formulierung der Logzeile trennt sie.

Bestätigen Sie die laufende Konfiguration und nicht die auf der Festplatte. Eine Datei, die gespeichert, aber nicht geladen wurde, oder eine Verbindung, die aus einem anderen Include neu gelesen wurde, erzeugt eine Abweichung, die keine noch so gründliche Bearbeitung der sichtbaren Datei beheben kann.

Drei Ereignisse, die alle Schlüsselerneuerung genannt werden

Die Schlüsselerneuerung der IKE-Assoziation, die IKE-Reauthentifizierung und die Schlüsselerneuerung der untergeordneten Assoziation sind getrennte Vorgänge mit getrennten Vorschlagsregeln. Ein bei einem davon gemeldeter Fehler sagt nichts direkt über die anderen aus, und ein Log, das sie vermischt, liest sich wie ein einzelner wiederkehrender Fehler, obwohl es drei sind.

Notieren Sie, welches Ereignis der Peer nennt, und prüfen Sie dann nur die Vorschläge für dieses Ereignis. Ändern Sie eine Liste, laden Sie neu und erzwingen Sie dasselbe Ereignis erneut. Wenn das Log eine Reauthentifizierung nennt, ist der IKE-Vorschlag der richtige zum Lesen. Wenn es eine untergeordnete Schlüsselerneuerung nennt, trägt der untergeordnete Vorschlag die entscheidende Gruppe.

Die Erneuerung abzuschalten ist keine Lösung

Die Erneuerungszeit auf null zu setzen unterdrückt den Austausch, der scheitert, und der Tunnel überlebt dann, bis er abgebaut oder der Peer neu gestartet wird. Gekauft haben Sie einen länger lebenden Schlüssel und eine Abweichung, die Ihnen bei einer Migration, einem Audit oder einem Anbieter-Update wieder begegnen wird. Dasselbe gilt für Laufzeiten, die weit über die Richtlinie hinaus gestreckt werden, die die andere Seite erwartet.

Gleichen Sie stattdessen die Vorschläge an. Wählen Sie eine Gruppe, die beide Peers implementieren, setzen Sie sie an beiden Enden in den untergeordneten Vorschlag, und halten Sie die Erneuerungsrichtlinie in dem Bereich, den die Organisation tatsächlich verlangt.

Beweisen Sie es mit dem Austausch, der gescheitert ist

Verkürzen Sie die untergeordnete Erneuerungszeit in einem Wartungsfenster, damit das Ereignis in Minuten statt in Stunden eintritt, oder lösen Sie eine manuelle untergeordnete Schlüsselerneuerung aus. Achten Sie dann auf eine erfolgreiche Erneuerung und bestätigen Sie, dass der Datenverkehr weiter durch sie fließt, denn ein neuer Handshake, der eine untergeordnete Assoziation installiert, aber den Anwendungsfluss fallen lässt ist ein anderer Defekt.

Stellen Sie danach die normale Laufzeit wieder her und bewahren Sie beide Ereignisaufzeichnungen auf, die fehlgeschlagene und die erfolgreiche. Der Beweis, den Sie wollen, ist, dass die Verbindung ihren eigenen Lebenszyklus übersteht, nicht dass sie einen Ping überstanden hat.