Hoe u een IPv6-eindpunt in een VPN-configuratie schrijft

Een IPv6-adres staat vol dubbele punten, en een eindpuntveld dat ook een poort draagt heeft een manier nodig om te markeren waar het adres eindigt. Doet u dit verkeerd, dan weigert de client het profiel te parsen of verbindt hij stil met het verkeerde. De juiste vorm is niet universeel: die hangt ervan af of het veld een adres plus poort, een kaal adres of een hostnaam bevat. Werk de runbook in volgorde af, want een syntaxisoplossing en een bereikbaarheidsoplossing zien er volstrekt anders uit zodra u de uitvoer van de client leest.

Controleer het veldtype voordat u een adres typt

Voor een WireGuard Endpoint-veld met een poort gebruikt een IPv6-literal vierkante haken rond het adres, zoals in [2001:db8::10]:51820. Het documentatieprefix in dat voorbeeld is geen openbare server, en de haken horen bij de syntaxis, niet bij het adres.

Andere formaten hebben hun eigen regels. Een URI kan een IPv6-literal tussen haken dragen, maar een VPN-configuratie is niet noodzakelijk een URI. Een client met aparte vakken voor adres en poort verwacht misschien alleen het literal in het ene vak en het nummer in het andere, en daar haken toevoegen is even fout als ze weglaten in een gecombineerd veld.

Zet het literal tussen haken wanneer de poort het veld deelt

De regel die u moet onthouden is eenvoudig: haken verschijnen wanneer in dezelfde tekenreeks een poort volgt. Ze verschijnen niet wanneer het adres alleen in een veld zonder poort staat.

De volledige eindpuntreeks van één protocol naar elke client kopiëren is de gebruikelijke oorzaak van deze fout. OpenVPN, IPsec-profielen en applicatie-interface documenteren elk hun eigen syntaxis, en een reeks die voor de ene correct is kan door de andere worden geweigerd of verkeerd geïnterpreteerd. Lees de eigen documentatie van de client voor het veld dat u bewerkt, en houd het documentatieprefix of het voorbeeldadres in een opmerking zodat niemand het als echte host verstuurt. Als de handleiding twee vormen geeft, gebruik dan die welke past bij het veldtype voor u.

Scheid de velden voor adres en poort

Als de client u twee vakken geeft, zet het adres in het ene en de poort in het andere. Een gecombineerde vorm die in het adresvak wordt geplakt, levert een parsefout op of, erger, een adres dat naar iets onbedoelds oplost.

Controleer op spaties aan het einde en onzichtbare tekens wanneer een waarde correct lijkt. Een gekopieerd adres draagt vaak een harde spatie of een teken met nulbreedte dat de client niet kan parsen en het scherm niet toont. Typ de waarde opnieuw in plaats van hem te plakken wanneer de fout geen zin heeft.

Behandel zone-identificaties voorzichtig

Een link-local literal kan een zone-identificatie vereisen die aan een interface is gekoppeld, geschreven met een procentteken en de interfacenaam. Die vorm is geldig op de host die de interface bezit, en hij vervangt geen algemeen bereikbaar extern eindpunt.

Bereik en routering blijven belangrijk na een geslaagde parse. Een zone-gekwalificeerd adres dat de client accepteert heeft misschien geen pad vanaf de machine, en een extern eindpunt dat via internet wordt bereikt zou helemaal niet van een lokale zone moeten afhangen. Bepaal via welke interface het pakket moet vertrekken voordat u de zone schrijft, niet nadat de handshake mislukt.

Verifieer de parse en daarna de bereikbaarheid

Scheid de twee fouten uitdrukkelijk. Een misvormd adres levert een parsefout of een onmiddellijke afwijzing op, terwijl een goed gevormd eindpunt dat de authenticatie weigert of nooit antwoordt een ander probleem met een andere oplossing is.

Na een ondersteunde correctie bevestigt u dat de tunnel onderhandelt en dat de bedoelde toepassing werkt. Een handshake alleen bewijst het pad niet, en een ping naar het eindpunt bewijst de tunnel niet. Wanneer de beheerder een hostnaam levert, houd dan de ondersteunde naam en de identiteitscontroles aan in plaats van die te vervangen door een numeriek adres dat elders is gevonden.

Noteer het exacte veld, de gebruikte waarde en het antwoord van de client in de wijzigingsnotitie. Anders herhaalt de volgende persoon die het profiel bewerkt het hakenexperiment, en het antwoord staat al in uw ticket.