vpnc-Gruppengeheimnis oder dein Login: Welches Feld übernimmt was?
Ein vpnc-Profil verlangt eine Gruppen-ID, ein Gruppengeheimnis und ein XAuth-Login, und Leute stecken das Kontopasswort in das falsche Feld. Ordne jedes Feld seiner Rolle zu.
Wenn dir jemand zum ersten Mal ein vpnc-Profil gibt, fragt der Anmeldedialog vier Dinge ab und liest sich, als wolle er ein einziges Passwort. Will er nicht: ein vorab geteiltes Gruppengeheimnis und ein individueller XAuth-Login sind getrennte Werte mit getrennten Eigentümern, und das Kontopasswort in das Gruppenfeld zu stecken erzeugt einen Fehler, der wie ein falsches Passwort aussieht und nicht wie ein falsches Feld. Die Zuordnung richtig hinzubekommen ist die ganze Aufgabe hier. Das Protokoll darunter ist das Migrationsprojekt von jemand anderem, weshalb nichts davon ein Argument für neue IKEv1-Tunnel ist.
Zwei Geheimnisse, zwei Eigentümer, ein Dialog
Ein Gruppengeheimnis gehört zum Gateway-Profil. Alle, die sich über dieses Profil verbinden, nutzen denselben Wert, und genau deshalb kann es keine Person identifizieren und lässt es sich nicht für ein einzelnes Notebook zurückziehen, ohne es für alle anderen Nutzer des Profils zu ändern. Der XAuth-Benutzername und das Passwort gehören stattdessen dem Menschen, und das Gateway prüft sie in einer zweiten Stufe, nachdem die IPsec-Assoziation bereits steht.
Diese zweistufige Form ist das, was Leute übersehen. Tunnelaufbau und Benutzerauthentifizierung sind verschiedene Austausche mit verschiedenen Eingaben, ein Client, der die Anmeldeabfrage nie erreicht, ist also keineswegs am Login gescheitert. Lies den Dialog als zwei Spalten statt als eine: profilweite Werte links, persönliche Werte rechts. Wenn eine Verbindung scheitert, ist die zuletzt ausgefüllte Spalte nicht automatisch die schuldige.
Ordne die Felder nach Rolle zu, nicht nach Beschriftung
vpnc benennt seine Direktiven in der Projektdokumentation, und jede grafische Oberfläche benennt sie um. Übersetze die Rolle jedes Werts, dann spielen die Beschriftungen keine Rolle mehr:
| Directive | What it carries | Who owns it |
|---|---|---|
| IPSec gateway | Address or hostname of the remote VPN endpoint | Operator |
| IPSec ID | Group identifier selecting the profile on that gateway | Operator |
| IPSec secret | Group preshared secret, not an account password | Profile, shared |
| Xauth username and password | Credentials for the per-user stage after the tunnel | Person |
Eine Oberfläche, die neben einem Gruppenfeld „Benutzername“ und „Passwort“ zeigt, ist nicht falsch — es sind dieselben drei Werte unter anderen Namen. Kaputt geht, ein Feld zu füllen, weil ein Wert hineinpasst. Ein als Benutzerpasswort eingefügtes Gruppengeheimnis authentifiziert das Profil und scheitert dann in der Benutzerstufe; ein als Gruppengeheimnis eingefügtes Kontopasswort scheitert früher, vor jeder Abfrage, und schickt Leute zu Firewalls auf der Suche nach einem Problem, das in einem Textfeld lebt.
Was eine Gruppenkennung nicht ist
Das Wort Gruppe verleitet zu einer falschen Lesart. Eine Gruppenkennung ist hier ein Selektor, der dem Gateway sagt, welche Profilkonfiguration anzuwenden ist; über Verzeichnismitgliedschaft sagt sie nichts, und ein übereinstimmender Name auf beiden Seiten ist Zufall, bis der Betreiber ihn bestätigt. Autorisierung passiert nach erfolgreichem XAuth, entschieden von dem, was das Gateway zu konsultieren konfiguriert ist, und nichts davon ist im Client-Dialog sichtbar.
Dieselbe Vorsicht gilt für das Gruppengeheimnis. Es zu kennen ist keine Identität, und ein Geheimnis im Team herumzureichen ist eine Betriebsentscheidung mit Folgen, die der Client dir nicht anzeigen kann.
Klär die mehrdeutige Anweisung, bevor du dich verbindest
Übergabenotizen aus Altbeständen enthalten oft eine Zeile wie „nutze die dedizierte öffentliche IP“. Dieser Satz kann die Adresse meinen, von der aus eine Allowlist auf der Gegenseite erwartet, dass dein Verkehr ankommt — das ist eine Ausgangseigenschaft des Betreibernetzes und hat nichts mit dem Endpunkt zu tun, den du ins Gateway-Feld tippst. Frag, welche der beiden gemeint ist, bevor der Wert irgendwohin geht. Rückwärts eingetragen schickt er jedes Paket an eine Adresse, die nie antwortet, und der resultierende Timeout liest sich wie ein blockierter Port.
Erfrage vier Dinge über den verifizierten Kanal der Organisation: welcher Client und welches Protokoll unterstützt werden, welcher Endpunkt zu verwenden ist, welche Identität das Gateway vorzeigt und wie Anmeldedaten übergeben werden. Halte echte Geheimnisse aus Screenshots, Tickets und geteilten Fehlersuchnotizen heraus. Deaktiviere keine Zertifikatsprüfungen und füge keine alte Cipher-Liste ein, damit ein anders konfigurierter Dienst kompatibel erscheint, denn eine Verbindung, die nur durch Schwächen der Prüfung funktioniert, ist nicht die Verbindung, die du bauen solltest.
Halte das Altprofil ehrlich
IKEv1 ist veraltet, und RFC 9395 ist das Dokument, das man zitiert, wenn die Migrationsfrage aufkommt. Eine erfolgreiche Feldzuordnung ist kein Beleg dafür, dass das Protokoll in ein neues Design gehört; sie erkauft eine funktionierende Verbindung, solange die Ablösung geplant wird, plus einen schriftlichen Umfang und einen Eigentümer für diese Migration.
Dann prüfe gegen die Anforderung statt gegen den Dialog. Bestätige nach dem Verbinden, dass die Tunnel-Schnittstelle die erwartete Adresse hält und dass ein internes Ziel darüber geroutet wird; wenn die ursprüngliche Anforderung eine Ausgangsadresse für eine Allowlist nannte, bestätige auch diese Adresse, denn sie ist ein anderer Fakt als der, dass der Tunnel steht. Ein Profil, das korrekt authentifiziert und nichts routet, hat die Aufgabe, für die es geschaffen wurde, trotzdem verfehlt.