IKEv2 Serveradresse vs. Identität: Was der Client tatsächlich überprüft

Ein Gateway, das seine Adresse ändert, kann weiterhin funktionieren, während dasselbe Gateway hinter einem neuen Zertifikat stoppt, und das Gegenteil passiert auch. Die Adresse teilt dem Client mit, wohin er Pakete senden soll; Die authentifizierte Identität teilt dem Client mit, ob der antwortende Peer derjenige ist, dem er vertrauen sollte. IKEv2 behält diese als zwei separate Felder bei, was nützlich ist, wenn Sie sie nicht mehr als eine Zeichenfolge behandeln. Sie sind auch an unterschiedlichen Stellen konfiguriert, sodass das eine richtig und das andere falsch sein kann.

Überprüfen Sie sie in dieser Reihenfolge und hören Sie bei der ersten Nichtübereinstimmung auf, da bei den späteren Prüfungen davon ausgegangen wird, dass die früheren Prüfungen erfolgreich waren.

Erstens: Welcher Wert ist die Adresse

Die Verbindungsadresse ist das, was der Client wählt: eine IP, ein DNS-Name, der in einen aufgelöst wird, oder ein Front-End mit Lastenausgleich. Das sind Transportinformationen und nichts weiter. Die Identität befindet sich in der ID-Nutzlast IKEv2 und wird dann mit dem Zertifikat des Peers abgeglichen. Ein DNS-Name im Adressfeld wird nicht zur erwarteten Identität, und eine Roh-IP wird nicht zur Identität, nur weil der Socket damit verbunden ist.

In strongSwan-Begriffen ist die Adresse right oder left und die erwartete Identität ist rightid oder leftid, und das wird in der Konfigurationsdokumentation IKEv2 beschrieben. Wenn Sie bisher nur die Adresse bearbeitet haben, haben Sie die Hälfte des Paares konfiguriert.

Zweitens, was das Zertifikat beweisen kann

Die Identität hat einen Typ und das Zertifikat muss einen passenden Namen tragen. Eine DNS-Identität wird durch einen dNSName-Eintrag in der Erweiterung des alternativen Subjektnamens erfüllt; Eine IP-Identität benötigt einen iPAddress-Eintrag. Ein für vpn.example.com ausgestelltes Zertifikat beweist nichts über die wörtliche Adresse 203.0.113.10, und ein für diese Adresse ausgestelltes Zertifikat beweist nichts über den Namen. Eine Neuausstellung unter einem anderen Namen ist daher kein Ersatz, selbst wenn derselbe Schlüssel und CA wiederverwendet werden.

Moderne Clients ignorieren den allgemeinen Namen, wenn ein alternativer Subjektname vorhanden ist, und viele ignorieren ihn vollständig. Wenn die SAN-Liste nicht den Wert enthält, den der Client überprüft, schlägt der Handshake fehl, nachdem das Zertifikat bereits als vertrauenswürdig akzeptiert wurde, weshalb das Protokoll eher wie ein Identitätsfehler als wie ein Vertrauensfehler gelesen wird.

Drittens, wie jeder Kunde seine Erwartungen formuliert

Windows übernimmt den Servernamen oder die Adresse, die Sie eingegeben haben, und erfordert, dass das Zertifikat damit übereinstimmt, Wenn Sie also eine IP eingeben, entsteht eine IP-Erwartung. Der IKEv2-Client von Android verhält sich auf die gleiche Weise und beide lehnen ein gültiges, öffentlich vertrauenswürdiges Zertifikat ab, das einen anderen Host nennt. Ein Profil kann bereits deshalb fehlschlagen, weil jemand während einer Migration den Hostnamen durch seine Adresse ersetzt hat. Schauen Sie sich an, was der Kunde verlangt hat, bevor Sie sich ansehen, was das Zertifikat enthält.

Bei strongSwan ist die Erwartung explizit: Setzen Sie rightid auf die Identität, die der Server tatsächlich präsentiert, die von rechts abweichen kann. Wenn Sie es auf %any setzen, wird alles akzeptiert, was der Peer anbietet, und es wird genau die Prüfung entfernt, die Sie behalten möchten.

Viertens trennen Sie die Benutzeranmeldung von der Peer-Identität

EAP-Authentifizierung und die Serveridentität beantworten unterschiedliche Fragen. Eine EAP-Identität wie [email protected] gibt an, wer der Benutzer ist, nachdem der Client entschieden hat, dass der Server der richtige ist. Durch Drehen dieses Kennworts kann eine Nichtübereinstimmung der Peer-Identität nicht behoben werden, da die Verbindung nie die Phase der Benutzeranmeldung erreicht.

Ein bereinigter Bericht sollte beides benennen: die vom Client erwartete Identität, die vom Server präsentierte Identität und die SAN-Einträge des Zertifikats.

Fünftens: Ändern Sie es über einen verifizierten Kanal

Wenn sich das Gateway rechtmäßig bewegt, aktualisieren Sie zuerst die Adresse und lassen Sie die Identität in Ruhe, da dies der Fall ist IKEv2 gut handhabt. Wenn sich die Identität selbst ändert, behandeln Sie dies als Vertrauensereignis und beziehen Sie den neuen Wert von einer Quelle, der Sie bereits vertrauen, und nicht vom Endpunkt, der derzeit ausfällt. Eine über die Verbindung, die Sie überprüfen möchten, übermittelte Nachricht ist kein Beweis für diese Verbindung.

Notieren Sie die endgültige Adresse, Identität und SAN-Liste zusammen in den Profilnotizen. Die nächste Person, die das Zertifikat berührt, sieht dann, welcher der drei sich bewegen darf.