IKE-Identität oder Endpunktadresse: nicht verwechseln

Lesen Sie ein Feld mit der Bezeichnung FQDN-Identität als wörtliche Zeichenkette, nicht als Anfrage nach dem Reverse-DNS-Namen Ihrer öffentlichen Adresse. Im Parser von strongSwan ist es genau das, eine Zeichenkette, und das Lesen löst sie nie zu einem Endpunkt auf. Allein diese Tatsache beseitigt die häufigste Ablenkung, wenn Sie Kennungen für einen Peer wählen. Die folgenden Prüfungen verhindern, dass die drei beteiligten Werte zu einem einzigen verschmelzen.

Eine Bezeichnung ist kein Lookup

Herstelleroberflächen verwenden Wörter wie FQDN und Hostname locker, und die Bezeichnung auf einem Kasten sagt nichts über die dahinterliegende Kodierung aus. Ein Gerät, das ein Feld Client-FQDN nennt, kann eine FQDN, eine e-mail-förmige Zeichenkette oder eine nackte Adresse senden. Behandeln Sie Text und Typ als zwei getrennte Entscheidungen und halten Sie beide fest.

Nichts an einer wörtlichen Identität erfordert DNS. Sie ist eine Behauptung, die die Gegenseite prüft, kein Name, den das Netzwerk auflösen muss.

Drei getrennte Werte, getrennt notiert

Drei Aufgaben stecken hinter einem Konfigurationsbildschirm, und sie zu vermischen ist der teure Fehler. Ein Wert ist die Endpunktadresse, die bestimmt, wohin die Pakete gehen. Ein anderer ist die lokale Identität, die dieser Peer vorzeigt, und der dritte ist die Identität, die Sie von der Gegenseite erwarten, bevor Sie sie authentifizieren. Schreiben Sie sie als drei Zeilen ins Change-Ticket, denn alles andere beschreibt ein VPN statt einer Beziehung.

Die Beispielidentitäten müssen als Teil der Bereitstellung gewählt und autorisiert werden. Sie sind Behauptungen, die die Authentifizierung prüft, keine Anmeldedaten, die irgendeinen Peer vertrauenswürdig machen; eine plausibel aussehende Zeichenkette autorisiert also nichts.

Der Typ ist Teil des Werts

Die strongSwan-Identitätsreferenz trennt FQDN, e-mail-förmige Werte, IP-Adressen und andere Kodierungen, daher zählt die Kodierung ebenso wie die Zeichen. Zwei Geräte können denselben Text unter verschiedenen Typen akzeptieren und sich trotzdem gegenseitig ablehnen. Eine Notiz, die den Wert ohne seinen Typ festhält, ist eine halbe Konfiguration.

Fragen Sie den Hersteller, welchen Typ das Gerät tatsächlich sendet, und bestätigen Sie ihn anhand eines Decodes statt anhand des Oberflächenlabels. Ein geratener Typ ist eine Nichtübereinstimmung, die auf die nächste Änderung wartet.

Jede Seite muss die andere erfüllen

Die lokale Identität jeder Seite muss die Authentifizierungsrichtlinie der anderen Seite passieren. Das ist nicht dasselbe, wie eine Zeichenkette in jedes Identitätsfeld auf beiden Geräten zu kleben; genau dieser Abkürzungsweg erzeugt eine Konfiguration, die niemand debuggen kann.

Die Zertifikatsauthentifizierung bringt eigene Anforderungen mit, weil die Identität des Zertifikats und die Vertrauensbedingungen neben der von Ihnen eingegebenen IKE-Identität stehen. Eine übereinstimmende IKE-Identität allein autorisiert keinen Zertifikats-Peer.

Wo DNS zählt und was Ihre Version erzwingt

Ein Gateway-Hostname, der für die Discovery verwendet wird, braucht tatsächlich funktionierendes DNS, und diese Anforderung gehört zum Finden des Endpunkts, nicht zu einem Reverse-Lookup einer eingegebenen Identität. Halten Sie beides im Ticket auseinander, denn ein Discovery-Fehler und eine Identitätsfehlpaarung lesen sich im Client-Log ähnlich und werden an verschiedenen Stellen repariert.

Lesen Sie den Parser für das Produkt und die Version, die Sie tatsächlich betreiben, bevor Sie eine Syntax kopieren, die einen Typ erzwingt, denn ältere strongSwan-Versionen verhielten sich anders und andere Hersteller fügen eigene Einschränkungen hinzu. Wenn Sie beide Enden vergleichen, halten Sie vier Dinge zusammen: erwartete Identität, vorgezeigte Identität, Typ und den Authentifizierungsfehler. Diese Menge macht aus einer Fehlpaarung einen Beleg statt einer Meinung.