Slik skriv du eit IPv6-endepunkt i ein VPN-konfigurasjon

Ei IPv6-adresse er full av kolon, og eit endepunktfelt som òg ber ein port treng ein måte å markere kvar adressa sluttar. Gjer du dette feil, nektar klienten å parse profilen eller koplar stille til det gale. Den rette forma er ikkje universell: ho er avhengig av om feltet inneheld ei adresse med port, ei bar adresse eller eit vertsnavn. Gå gjennom runboka i rekkjefølgje, for ei syntaksretting og ei tilgjengelegheitsretting ser heilt ulike ut når du først les utdataa frå klienten.

Kontroller felttypen før du skriv inn ei adresse

For eit WireGuard Endpoint-felt med ein port brukar ein IPv6-literal hakeparentesar rundt adressa, som i [2001:db8::10]:51820. Dokumentasjonsprefikset i det dømet er ikkje ein offentleg server, og parentesane er ein del av syntaksen, ikkje av adressa.

Andre format har eigne reglar. Ein URI kan bere ein IPv6-literal i parentesar, men ein VPN-konfigurasjon er ikkje nødvendigvis ein URI. Ein klient med separate felt for adresse og port ventar kanskje berre literalen i det eine feltet og talet i det andre, og å leggje til parentesar der er like feil som å utelate dei i eit kombinert felt.

Set literalen i parentesar når porten deler feltet

Regelen som er verdt å hugse, er enkel: parentesar viser seg når ein port følgjer i same streng. Dei viser seg ikkje når adressa står åleine i eit felt utan port.

Å kopiere den komplette endepunktstrengen til éin protokoll til kvar klient er den vanlege årsaka til denne feilen. OpenVPN, IPsec-profilane og applikasjonsgrensesnitt dokumenterer kvar sin syntaks, og ein streng som er rett for éin, kan bli avvist eller feiltolka av ein annan. Les klienten si eiga dokumentasjon for feltet du redigerer, og hald dokumentasjonsprefikset eller dømeadressa i ein kommentar så ingen sender ho som ein ekte vert. Når handboka gir to former, bruk den som passar til felttypen framfor deg.

Skil adresse- og portfelta

Når klienten gir deg to felt, set adressa i det eine og porten i det andre. Ei kombinert form limt inn i adressefeltet gir ein parsefeil eller, verre, ei adresse som blir løyst ut til noko utilsikta.

Kontroller for etterfølgjande mellomrom og usynlege teikn når ein verdi ser rett ut. Ei kopiert adresse ber ofte eit hardt mellomrom eller eit nullbreiddeteikn som klienten ikkje kan parse og skjermen ikkje viser. Skriv verdien på nytt i staden for å lime han inn når feilen ikkje gir meining.

Handter soneidentifikatorar forsiktig

Ein link-lokal literal kan krevje ein soneidentifikator knytt til eit grensesnitt, skriven med prosentteikn og namnet på grensesnittet. Den forma er gyldig på verten som eig grensesnittet, og ho erstattar ikkje eit allment tilgjengeleg eksternt endepunkt.

Omfang og ruting betyr framleis noko etter vellukka parsing. Ei sonekvalifisert adresse som klienten godtek, har kanskje ingen veg frå maskina, og eit eksternt endepunkt som blir nådd over internett bør ikkje henge saman med ei lokal sone i det heile. Avgjer kva grensesnitt pakken skal gå ut gjennom før du skriv sona, ikkje etter at handtrykket mislukkast.

Stadfest parseringa, deretter tilgjengelegheita

Skil dei to feila tydeleg. Ei misdanna adresse gir ein parsefeil eller ei umiddelbar avvising, medan eit velforma endepunkt som avviser autentisering eller aldri svarar er eit anna problem med ei anna løysing.

Etter ei støtta retting, stadfest at tunnelen forhandlar og at den tiltenkte applikasjonen verkar. Eit handtrykk åleine beviser ikkje vegen, og ein ping til endepunktet beviser ikkje tunnelen. Når operatøren oppgir eit vertsnavn, hald på det støtta namnet og identitetskontrollane, i staden for å erstatte det med ei numerisk adresse funnen andre stader.

Noter det nøyaktige feltet, verdien du brukte og svaret frå klienten i endringsnotatet. Elles vil neste person som redigerer profilen gjenta parenteseksperimentet, og svaret står allereie i saka di.