iOS hat Ihren strongSwan-Tunnel abgelehnt: Vergleichen Sie die IKE-Vorschläge

Nichts im Zertifikat oder in der Adresse erklärt, warum ein iPhone, das sich letztes Jahr mit strongSwan verband, dieses Jahr scheitert. An Adresse, vorab geteiltem Schlüssel oder Client-Identität muss sich nichts geändert haben. Verschoben hat sich die Liste der Transformationen, über die der eingebaute Client des Telefons zu verhandeln bereit ist, und sobald sich diese Liste nicht mehr mit der des Servers überschneidet, endet der Austausch, bevor irgendeine Identität geprüft wird.

Die Logzeile, die es entscheidet

Drehen Sie die Protokollierung für diese Verbindung hoch und suchen Sie die zwei Einträge, die den Ausgang entscheiden: was das Telefon angeboten hat und was der Server gewählt hat. Endet das Protokoll ohne gewählten Vorschlag und meldet, dass nichts passte, wurde die Authentifizierung nie versucht. Ein neues Zertifikat und ein neues Passwort ändern daran nichts, weil beide erst in einer späteren Phase verbraucht werden. Keines von beiden kann ein Ergebnis beeinflussen, das entschieden war, bevor die Identität geprüft wurde.

Halten Sie die beiden Fehlerformen auseinander, bevor Sie irgendetwas bearbeiten. Keine Änderung an den Transformationen rettet abgelehnte Anmeldedaten, und keine Korrektur der Anmeldedaten rettet eine abgelehnte Transformation. Der Protokolleintrag, der einen gewählten Vorschlag nennt, sagt Ihnen, in welchem der beiden Fälle Sie stecken. Ohne diesen Eintrag raten Sie.

Die gewählte Zeile benennt den Vorschlag über sein Transformationsset statt über ein freundliches Etikett. Vergleichen Sie die Felder für Verschlüsselung, Integrität und Gruppe in dieser Zeile mit der Liste, die das Telefon gesendet hat, denn eine Abweichung in auch nur einem Feld genügt zum Verlieren.

Was sich am Telefon geändert hat

Eine iOS-Version hat die Algorithmen beschnitten, die ihr Client zu verwenden bereit ist. Schwache Integritäts-Hashes, kleine Diffie-Hellman-Gruppen und Vorschläge, die alte Optionen zuerst auflisten, sind nicht mehr akzeptabel.

Längere Listen sind hier nicht sicherer. Die Auswahl folgt der akzeptierten Menge des Telefons und seiner eigenen Präferenzreihenfolge, sodass ein Server, der einen breiten Katalog anbietet, die Verhandlung trotzdem verlieren kann, wenn die modernen Einträge nicht die gewählten sind. Bevorzugen Sie eine kurze Liste mit den modernen Einträgen zuerst. Eine lange Liste, die mit alten Optionen beginnt, lädt genau den Fehler ein, den Sie vermeiden wollen. Die akzeptierte Menge ist eine äußere Einschränkung, die sich mit jedem Client-Update verschiebt, also ist eine Konfiguration, die gestern lief, ein Beleg über gestern.

Ein Paar, das noch verhandelt

Für aktuelle Telefone genügt eine einzige moderne Kombination. Ein Paar, das verhandelt, sieht so aus:

ike=aes256-sha2_256-modp2048
esp=aes256-sha2_256

Die ike-Zeile trägt die Verschlüsselung, die Integrität und die Diffie-Hellman-Gruppe, die während des Schlüsselaustauschs gelten. Die esp-Zeile deckt nur den Datenkanal ab, weil die Gruppe festgelegt wurde, bevor sie greift. Laden Sie die Verbindung neu oder starten Sie den Daemon neu, und verbinden Sie dann das Telefon erneut. Behalten Sie diesen Gruppenwert nur, wenn jeder Client, den Sie bedienen, ihn noch akzeptiert, und erweitern Sie den Vorschlag nicht für alle, weil ein alter Peer mehr braucht.

Drei Stellen zum Reparieren, eine ist meist geschlossen

• Ein moderner Vorschlag für jeden Peer. Richtig, wenn alle Clients aktuelle Telefone und Desktops sind. Es löscht die alten Transformationen, statt um sie herum zu verhandeln.
• Eine zweite Verbindungsdefinition für Apple-Clients. Hält einen alten Peer am Leben und gibt dem Telefon einen Vorschlag, den es akzeptiert. Es kostet einen weiteren Verbindungsblock und macht die Ausnahme sichtbar.
• Den Client wechseln. Selten für Sie offen: Wenn ein Managementsystem oder eine App das Profil ausliefert, gibt es keinen Vorschlagseditor zum Anfassen, und der eingebaute Client bietet keinen an.

Wählen Sie die zweite Option, wenn ein Gerät außerhalb Ihrer Kontrolle nicht aktualisiert werden kann. Wählen Sie die erste, wenn Sie den alten Peer ausmustern können und lieber eine einzige Richtlinie tragen.

So oder so ist die Wahl in der Konfiguration sichtbar, und darum geht es. Ein stiller Rückfall, der auf eine alte Transformation herunterverhandelt, ist schlimmer als ein ausdrücklicher Block, weil keine Überprüfung ihn je aufdecken wird.

Beweisen Sie es, dann dokumentieren Sie es

Verbinden Sie erneut und prüfen Sie drei getrennte Tatsachen auf dem Server: Ein Vorschlag wurde gewählt, die Verbindung zeigt sich als hergestellt, und der Client hat eine Adresse erhalten. Ein hergestellter Handshake ohne Gegenstellenadresse deutet auf den Pool oder die Traffic-Selektoren und gehört in eine eigene Änderung. Beides zusammen zu behandeln lässt eine gelöste Verhandlung ungelöst aussehen.

Notieren Sie das akzeptierte Transformationsset, wann Sie es geändert haben und welchen Client-Build Sie verifiziert haben. Das nächste Update kann die Anforderung erneut verschieben, und die Werte, die funktionierten, sind das Erste, was Sie neben den neuen haben wollen.