Så skriver du en IPv6-slutpunkt i en VPN-konfiguration

En IPv6-adress är full av kolon, och ett slutpunktsfält som också bär en port behöver ett sätt att markera var adressen slutar. Gör du fel här vägrar klienten att tolka profilen eller ansluter tyst till fel sak. Rätt form är inte universell: den beror på om fältet innehåller en adress med port, en bar adress eller ett värdnamn. Arbeta igenom runbooken i ordning, för en syntaxrättning och en nåbarhetsrättning ser helt olika ut när du väl börjar läsa klientens utdata.

Kontrollera fälttypen innan du skriver en adress

Till exempel, WireGuard Endpoint fält med en port använder en IPv6-literal hakparenteser runt adressen, som i [2001:db8::10]:51820. Dokumentationsprefixet i det exemplet är inte en offentlig server, och parenteserna är en del av syntaxen, inte av adressen.

Andra format har egna regler. En URI kan bära en IPv6-literal inom parenteser, men en VPN-konfiguration är inte nödvändigtvis en URI. En klient med separata fält för adress och port förväntar sig kanske bara literalen i det ena fältet och talet i det andra, och att lägga till parenteser där är lika fel som att utelämna dem i ett kombinerat fält.

Sätt literalen inom parenteser när porten delar fältet

Regeln som är värd att komma ihåg är enkel: parenteser dyker upp när en port följer i samma sträng. De dyker inte upp när adressen står ensam i ett fält utan port.

Att kopiera hela slutpunktssträngen för ett protokoll till varje klient är den vanliga orsaken till det här felet. OpenVPN, IPsec-profiler och applikationsgränssnitt dokumenterar var sin syntax, och en sträng som är rätt för en kan avvisas eller feltolkas av en annan. Läs klientens egen dokumentation för fältet du redigerar, och håll dokumentationsprefixet eller exempeladressen i en kommentar så att ingen skickar den som en riktig värd. När handboken ger två former, använd den som passar fälttypen framför dig.

Separera adress- och portfälten

När klienten ger dig två fält, sätt adressen i det ena och porten i det andra. En kombinerad form inklistrad i adressfältet ger ett tolkningsfel eller, värre, en adress som löses upp till något oavsiktligt.

Kontrollera efterföljande blanksteg och osynliga tecken när ett värde ser rätt ut. En kopierad adress bär ofta ett hårt blanksteg eller ett nollbreddstecken som klienten inte kan tolka och skärmen inte visar. Skriv om värdet i stället för att klistra in det när felet inte ger mening.

Hantera zonidentifierare försiktigt

En link-lokal literal kan kräva en zonidentifierare knuten till ett gränssnitt, skriven med procenttecken och gränssnittets namn. Den formen är giltig på värden som äger gränssnittet, och den ersätter inte en allmänt nåbar fjärrslutpunkt.

Omfång och routning spelar fortfarande roll efter en lyckad tolkning. En zonkvalificerad adress som klienten accepterar har kanske ingen väg från maskinen, och en fjärrslutpunkt som nås över internet bör inte alls bero på en lokal zon. Bestäm vilket gränssnitt paketet ska lämna genom innan du skriver zonen, inte efter att handskakningen misslyckas.

Verifiera tolkningen, sedan nåbarheten

Separera de två felen tydligt. En felformad adress ger ett tolkningsfel eller ett omedelbart avslag, medan en välformad slutpunkt som avvisar autentisering eller aldrig svarar är ett annat problem med en annan lösning.

Efter en stödd rättning, bekräfta att tunneln förhandlar och att den avsedda applikationen fungerar. En handskakning ensam bevisar inte vägen, och en ping till slutpunkten bevisar inte tunneln. När operatören anger ett värdnamn, behåll det stödda namnet och dess identitetskontroller i stället för att ersätta det med en numerisk adress som hittats någon annanstans.

Anteckna det exakta fältet, värdet du använde och klientens svar i ändringsanteckningen. Annars upprepar nästa person som redigerar profilen parentesexperimentet, och svaret finns redan i din biljett.