IPv6-Endpunkt in einer VPN-Konfiguration richtig schreiben
Ein IPv6-Literal enthält Doppelpunkte, deshalb braucht ein Endpunkt mit Port eckige Klammern. Richten Sie sich nach der Feldsyntax, die Ihr Client dokumentiert, und testen Sie danach den Pfad.
Eine IPv6-Adresse ist voller Doppelpunkte, und ein Endpunktfeld, das zusätzlich einen Port trägt, braucht eine Möglichkeit zu markieren, wo die Adresse endet. Machen Sie das falsch, verweigert der Client entweder das Parsen des Profils oder verbindet sich still mit dem falschen Ziel. Die korrekte Form ist nicht universell: Sie hängt davon ab, ob das Feld eine Adresse samt Port, eine reine Adresse oder einen Hostnamen aufnimmt. Arbeiten Sie das Runbook der Reihe nach durch, denn ein Syntaxfehler und ein Erreichbarkeitsfehler sehen völlig verschieden aus, sobald Sie die Ausgabe des Clients lesen.
Prüfen Sie den Feldtyp, bevor Sie eine Adresse eintippen
Für ein WireGuard Endpoint-Feld mit einem IPv6-Literal und Port setzen Sie Klammern um die Adresse, etwa [2001:db8::10]:51820. Das Dokumentationspräfix in diesem Beispiel ist kein öffentlicher Server, und die Klammern gehören zur Syntax, nicht zur Adresse.
Andere Formate haben eigene Regeln. Eine URI kann ein IPv6-Literal in Klammern tragen, aber eine VPN-Konfiguration ist nicht zwangsläufig eine URI. Ein Client mit getrennten Feldern für Adresse und Port erwartet im einen Feld vielleicht nur das Literal und im anderen die Portnummer, und dort Klammern hinzuzufügen ist genauso falsch, wie sie in einem kombinierten Feld wegzulassen.
Klammern Sie das Literal, wenn ein Port im selben Feld steht
Die Regel zum Merken ist einfach: Klammern erscheinen, wenn in derselben Zeichenkette ein Port folgt. Sie erscheinen nicht, wenn die Adresse allein in einem Feld ohne Port steht.
Die komplette Endpunkt-Zeichenkette eines Protokolls in jeden Client zu kopieren ist die übliche Ursache dieses Fehlers. OpenVPN, IPsec-Profile und Anwendungsschnittstellen dokumentieren jeweils ihre eigene Syntax, und eine Zeichenkette, die für den einen korrekt ist, kann von einem anderen abgelehnt oder falsch interpretiert werden. Lesen Sie die Dokumentation des Clients für das Feld, das Sie bearbeiten, und bewahren Sie das Dokumentationspräfix oder die Beispieladresse in einem Kommentar auf, damit niemand sie als echten Host ausliefert. Wenn das Handbuch zwei Formen nennt, nehmen Sie die, die zum Feldtyp vor Ihnen passt.
Trennen Sie Adress- und Portfeld
Wenn der Client Ihnen zwei Felder gibt, setzen Sie die Adresse in das eine und den Port in das andere. Eine kombinierte Form, die in das Adressfeld eingefügt wird, erzeugt einen Parse-Fehler oder, schlimmer, eine Adresse, die auf etwas Unbeabsichtigtes auflöst.
Prüfen Sie auf nachgestellte Leerzeichen und unsichtbare Zeichen, wenn ein Wert korrekt aussieht. Eine kopierte Adresse trägt oft ein geschütztes Leerzeichen oder ein Nullbreitenzeichen, das der Client nicht parsen kann und der Bildschirm nicht anzeigt. Tippen Sie den Wert neu ein, statt ihn einzufügen, wenn der Fehler keinen Sinn ergibt.
Behandeln Sie Zonenbezeichner sorgfältig
Ein link-lokales Literal kann einen Zonenbezeichner erfordern, der an eine Schnittstelle gebunden ist und mit einem Prozentzeichen und dem Schnittstellennamen geschrieben wird. Diese Form ist auf dem Host gültig, dem die Schnittstelle gehört, und sie ersetzt keinen allgemein erreichbaren entfernten Endpunkt.
Scope und Routing zählen auch nach erfolgreichem Parsen. Eine zonenqualifizierte Adresse, die der Client akzeptiert, hat möglicherweise keinen Pfad von der Maschine, und ein über das Internet erreichter entfernter Endpunkt sollte überhaupt nicht von einer lokalen Zone abhängen. Entscheiden Sie, über welche Schnittstelle das Paket hinausgehen soll, bevor Sie die Zone schreiben, nicht erst, nachdem der Handshake scheitert.
Prüfen Sie erst das Parsen, dann die Erreichbarkeit
Trennen Sie die beiden Fehlerarten ausdrücklich. Eine fehlerhafte Adresse erzeugt einen Parse-Fehler oder eine sofortige Ablehnung, während ein wohlgeformter Endpunkt, der die Authentifizierung ablehnt oder nie antwortet, ein anderes Problem mit einer anderen Lösung ist.
Prüfen Sie nach einer unterstützten Korrektur, ob der Tunnel aushandelt und die vorgesehene Anwendung funktioniert. Ein Handshake allein beweist den Pfad nicht, und ein Ping auf den Endpunkt beweist den Tunnel nicht. Wo der Betreiber einen Hostnamen angibt, behalten Sie den unterstützten Namen und seine Identitätsprüfungen bei, statt ihn durch eine anderswo gefundene numerische Adresse zu ersetzen.
Notieren Sie das genaue Feld, den verwendeten Wert und die Antwort des Clients im Änderungsvermerk. Die nächste Person, die das Profil bearbeitet, wiederholt sonst das Klammer-Experiment, und die Antwort steht bereits in Ihrem Ticket.