Warum natives Windows IKEv2 überhaupt kein PSK-Feld hat

Die Gateway-Dokumentation sagt, der vorab geteilte Schlüssel gehöre in den Client, doch das Windows-Profil hat dafür kein Feld. Diese Lücke ist kein Fehler, den man umgeht, indem man den Schlüssel ins Passwortfeld tippt. Sie ist der Unterschied zwischen dem, was ein Protokoll kann, und dem, was eine bestimmte Implementierung bietet.

Protokollfähigkeit ist keine Client-Unterstützung

Die IKEv2-Spezifikation enthält die Authentifizierung mit gemeinsamem Schlüssel, ein Gateway darf also legitim dafür konfiguriert werden. Das native Windows-Profil für den Fernzugriff dokumentiert stattdessen Zertifikat- und EAP-Verfahren, und Protokollfähigkeit erzeugt kein Feld, keinen Parameter und keinen Registrierungswert, den der Client nie hatte.

Meist landet man bei PowerShell-Referenz zum Hinzufügen einer VPN-Verbindung, und dort ist L2tpPsk für das L2TP-Verfahren angegeben. Dieser Parameter gehört zu L2TP und ist kein allgemeines IKEv2-Geheimnis. Einstellungen zur Algorithmusauswahl wählen Schutzparameter, was ein drittes, unabhängiges Thema ist. Auch die Routingrolle von Windows Server ist nicht dasselbe Objekt. Eine Serverschnittstelle kann Konfigurationsoptionen haben, die ein Desktop-Clientprofil nicht besitzt, und eine Servereinstellung in ein Arbeitsplatzprofil zu kopieren bildet die Fähigkeit nicht nach.

Zwischen Zertifikat, EAP oder L2TP wählen

Akzeptiert der Gateway-Betreiber die Zertifikatauthentifizierung, ist das meist das sauberste Ziel: Der Client legt ein Zertifikat vor, das Gateway prüft es gegen einen vertrauenswürdigen Aussteller, und kein gemeinsames Geheimnis liegt in einem Profil, das jemand kopieren könnte. Es erfordert Registrierung, eine vertrauenswürdige Kette und eine Gateway-Konfiguration, die das Zertifikat einer Autorisierungsentscheidung zuordnet.

EAP mit einem Benutzernachweis ist der andere unterstützte Weg in diesem Client, und er verlagert die Entscheidung zu einem Identitätsanbieter. Er bringt eigene Abhängigkeiten mit, denn EAP-Verfahren, Serverzertifikat und das Vertrauen des Clients in dieses Zertifikat müssen zusammenpassen. Nur für ein vertrautes Feld auf L2TP/IPsec zu wechseln, ändert den Protokollstapel. Das ist akzeptabel, wenn es eine unterstützte Wahl mit dokumentiertem Grund ist, und ein schlechtes Ergebnis, wenn es geschieht, weil jemand ein Kästchen zum Eintippen eines Schlüssels suchte.

Prüfen, was das Gateway annimmt

Fragen Sie den Betreiber, welche Authentifizierungsmethoden der Fernzugriffsdienst heute anbietet, nicht welche das Produkt allgemein unterstützt. Ein Dienst, der für IKEv2 nur mit PSK konfiguriert ist, akzeptiert kein Zertifikat, nur weil der Client eines bevorzugt.

Get-VpnConnection -Name "Corp IKEv2" | Format-List AuthenticationMethod, TunnelType, EncryptionLevel, ServerValidation
Get-ChildItem Cert:\CurrentUser\My | Select-Object Subject, NotAfter

Lesen Sie die Authentifizierungsmethode des Profils und den Zertifikatspeicher zusammen. Ein auf EAP gesetztes Profil ohne brauchbares Zertifikat dahinter scheitert auf eine Weise, die wie ein Serverproblem aussieht.

Lautet die Antwort, es sei nur PSK verfügbar, sind die ehrlichen Optionen ein freigegebener Client, der es unterstützt, oder eine Änderung am Authentifizierungsentwurf des Gateways. Beides ist kein lokaler Notbehelf, und das Gegenteil vorzugeben erzeugt eine Verbindung, die nur derjenige nachbauen kann, der sie eingerichtet hat.

Entscheidung und Geheimnisse festhalten

Notieren Sie das gewählte Verfahren, den Vertrauensanker, die zugeordnete Identität und die Person, die die Änderung genehmigt hat. Dieser Eintrag ist es, was eine Vorfallprüfung braucht, und er hält auch den nächsten Ingenieur davon ab, dieselbe Sackgasse erneut zu durchlaufen.

Halten Sie die Geheimnisse in Ihren Notizen getrennt: Kontopasswort, Passphrase für einen privaten Schlüssel und ein vorab geteilter Gateway-Schlüssel sind drei verschiedene Dinge, selbst wenn ein Einstellungsbildschirm alle als Passwort bezeichnet. Sie zu verwechseln ist der Weg, auf dem ein Schlüssel in einem Ticket landet. Testen Sie das resultierende Profil mit einer frischen Verbindung und einer Anwendungsanfrage an eine private Ressource. Ein erfolgreicher Tunnel ohne erreichbaren Dienst ist ein Teilergebnis, und das Profil sollte nicht als fertig bezeichnet werden, bevor auch die Ressource funktioniert.