Slik skriver du et IPv6-endepunkt i en VPN-konfigurasjon

En IPv6-adresse er full av kolon, og et endepunktfelt som også bærer en port trenger en måte å markere hvor adressen slutter. Gjør du dette feil, nekter klienten å parse profilen eller kobler stille til det gale. Den riktige formen er ikke universell: den avhenger av om feltet inneholder en adresse med port, en bar adresse eller et vertsnavn. Gå gjennom runboken i rekkefølge, for en syntaksretting og en tilgjengelighetsretting ser helt forskjellige ut når du først leser klientens utdata.

Kontroller felttypen før du skriver inn en adresse

For et WireGuard Endpoint-felt med en port bruker en IPv6-literal hakeparenteser rundt adressen, som i [2001:db8::10]:51820. Dokumentasjonsprefikset i det eksempelet er ikke en offentlig server, og parentesene er en del av syntaksen, ikke av adressen.

Andre formater har egne regler. En URI kan bære en IPv6-literal i parenteser, men en VPN-konfigurasjon er ikke nødvendigvis en URI. En klient med separate felt for adresse og port forventer kanskje bare literalen i det ene feltet og tallet i det andre, og å legge til parenteser der er like feil som å utelate dem i et kombinert felt.

Sett literalen i parenteser når porten deler feltet

Regelen som er verdt å 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 uten port.

Å kopiere den komplette endepunktstrengen til én protokoll til hver klient er den vanlige årsaken til denne feilen. OpenVPN, IPsec-profiler og applikasjonsgrensesnitt dokumenterer hver sin syntaks, og en streng som er riktig for én, kan bli avvist eller feiltolket av en annen. Les klientens egen dokumentasjon for feltet du redigerer, og hold dokumentasjonsprefikset eller eksempeladressen i en kommentar så ingen sender den som en ekte vert. Når håndboken gir to former, bruk den som passer til felttypen foran deg.

Skill adresse- og portfeltene

Når klienten gir deg to felt, sett adressen i det ene og porten i det andre. En kombinert form limt inn i adressefeltet gir en parsefeil eller, verre, en adresse som løses ut til noe utilsiktet.

Kontroller for etterfølgende mellomrom og usynlige tegn når en verdi ser riktig ut. En kopiert adresse bærer ofte et hardt mellomrom eller et nullbreddetegn som klienten ikke kan parse og skjermen ikke viser. Skriv verdien på nytt i stedet for å lime den inn når feilen ikke gir mening.

Håndter soneidentifikatorer forsiktig

En link-lokal literal kan kreve en soneidentifikator knyttet til et grensesnitt, skrevet med prosenttegn og grensesnittets navn. Den formen er gyldig på verten som eier grensesnittet, og den erstatter ikke et allment tilgjengelig eksternt endepunkt.

Omfang og ruting betyr fortsatt noe etter vellykket parsing. En sonekvalifisert adresse som klienten godtar, har kanskje ingen vei fra maskinen, og et eksternt endepunkt som nås over internett bør ikke avhenge av en lokal sone i det hele tatt. Bestem hvilket grensesnitt pakken skal gå ut gjennom før du skriver sonen, ikke etter at håndtrykket mislykkes.

Bekreft parsingen, deretter tilgjengeligheten

Skill de to feilene tydelig. En misdannet adresse gir en parsefeil eller en umiddelbar avvisning, mens et velformet endepunkt som avviser autentisering eller aldri svarer er et annet problem med en annen løsning.

Etter en støttet retting, bekreft at tunnelen forhandler og at den tiltenkte applikasjonen virker. Et håndtrykk alene beviser ikke banen, og en ping til endepunktet beviser ikke tunnelen. Når operatøren oppgir et vertsnavn, behold det støttede navnet og identitetskontrollene, i stedet for å erstatte det med en numerisk adresse funnet andre steder.

Noter det nøyaktige feltet, verdien du brukte og klientens svar i endringsnotatet. Ellers vil neste person som redigerer profilen gjenta parenteseksperimentet, og svaret står allerede i saken din.