Sådan skriver du et IPv6-endepunkt i en VPN-konfiguration

En IPv6-adresse er fuld af koloner, og et endepunktfelt, der også bærer en port, har brug for en måde at markere, hvor adressen slutter. Tager du fejl af det, afviser klienten enten at parse profilen eller forbinder i stilhed til det forkerte. Den korrekte form er ikke universel: den afhænger af, om feltet indeholder en adresse plus port, en bar adresse eller et værtsnavn. Gå gennem runbooken i rækkefølge, for en syntaksrettelse og en tilgængelighedsrettelse ser helt forskellige ud, når først du læser klientens output.

Kontroller felttypen, før du skriver en adresse

Til et WireGuard Endpoint-felt bruger et IPv6-literal med en port kantede parenteser om adressen, som i [2001:db8::10]:51820. Dokumentationspræfikset i det eksempel er ikke en offentlig server, og parenteserne er en del af syntaksen, ikke af adressen.

Andre formater har deres egne regler. En URI kan bære et IPv6-literal i parenteser, men en VPN-konfiguration er ikke nødvendigvis en URI. En klient med separate felter til adresse og port forventer måske kun literalen i det ene felt og tallet i det andet, og at tilføje parenteser der er lige så forkert som at udelade dem i et kombineret felt.

Sæt literalen i parentes, når porten deler feltet

Reglen, der er værd at huske, er enkel: parenteser vises, når en port følger i samme streng. De vises ikke, når adressen står alene i et felt uden port.

At kopiere én protokols komplette endepunktstreng til hver klient er den sædvanlige årsag til denne fejl. OpenVPN, IPsec-profiler og applikationsgrænseflader dokumenterer hver deres syntaks, og en streng, der er korrekt for én, kan blive afvist eller fejlfortolket af en anden. Læs klientens egen dokumentation for det felt, du redigerer, og behold dokumentationspræfikset eller eksempeladressen i en kommentar, så ingen sender den som en rigtig vært. Når manualen giver to former, så brug den, der passer til felttypen foran dig.

Adskil adresse- og portfelter

Når klienten giver dig to felter, sæt adressen i det ene og porten i det andet. En kombineret form indsat i adressefeltet giver en parsefejl eller, værre, en adresse, der opløses til noget utilsigtet.

Kontroller for efterfølgende mellemrum og usynlige tegn, når en værdi ser korrekt ud. En kopieret adresse bærer ofte et hårdt mellemrum eller et nulbreddetegn, som klienten ikke kan parse, og som skærmen ikke viser. Skriv værdien igen i stedet for at indsætte den, når fejlen ikke giver mening.

Håndtér zoneidentifikatorer forsigtigt

Et link-lokalt literal kan kræve en zoneidentifikator knyttet til en grænseflade, skrevet med et procenttegn og grænsefladens navn. Den form er gyldig på den vært, der ejer grænsefladen, og den erstatter ikke et generelt tilgængeligt eksternt endepunkt.

Omfang og routing betyder stadig noget, efter parsingen lykkes. En zonekvalificeret adresse, som klienten accepterer, har måske ingen vej fra maskinen, og et eksternt endepunkt, der nås over internettet, bør slet ikke afhænge af en lokal zone. Beslut, hvilken grænseflade pakken skal forlade gennem, før du skriver zonen, ikke efter håndtrykket fejler.

Bekræft parsingen, derefter tilgængeligheden

Adskil de to fejl udtrykkeligt. En misdannet adresse giver en parsefejl eller en øjeblikkelig afvisning, mens et velformet endepunkt, der afviser godkendelse eller aldrig svarer, er et andet problem med en anden løsning.

Efter en understøttet rettelse skal du bekræfte, at tunnelen forhandler, og at den tilsigtede applikation virker. Et håndtryk alene beviser ikke stien, og et ping til endepunktet beviser ikke tunnelen. Når operatøren angiver et værtsnavn, så behold det understøttede navn og dets identitetskontroller i stedet for at erstatte det med en numerisk adresse fundet andre steder.

Notér det præcise felt, den værdi du brugte, og klientens svar i ændringsnoten. Ellers gentager den næste person, der redigerer profilen, parenteseksperimentet, og svaret står allerede i din ticket.