Como escribir un punto final IPv6 nunha configuración de VPN

Un enderezo IPv6 está cheo de dous puntos, e un campo de punto final que tamén leva un porto necesita unha forma de marcar onde remata o enderezo. Se se equivoca, o cliente ou négase a analizar o perfil ou conéctase en silencio ao incorrecto. A forma correcta non é universal: depende de se o campo contén un enderezo con porto, un enderezo espido ou un nome de host. Percorra o manual en orde, porque unha corrección de sintaxe e unha corrección de conectividade non se parecen en nada cando comeza a ler a saída do cliente.

Comprobe o tipo de campo antes de escribir un enderezo

Para un campo WireGuard Endpoint cun porto, o literal IPv6 usa corchetes arredor do enderezo, como en [2001:db8::10]:51820. O prefixo de documentación dese exemplo non é un servidor público, e os corchetes forman parte da sintaxe, non do enderezo.

Outros formatos teñen as súas propias regras. Un URI pode levar un literal IPv6 entre corchetes, pero unha configuración de VPN non é necesariamente un URI. Un cliente con caixas separadas de enderezo e porto pode esperar o literal só nunha caixa e o número na outra, e engadir corchetes alí é tan erróneo como omitilos nun campo combinado.

Pon os corchetes cando o porto comparte o campo

A regra que hai que lembrar é simple: os corchetes aparecen cando un porto segue na mesma cadea. Non aparecen cando o enderezo está só nun campo sen porto.

Copiar a cadea completa de punto final dun protocolo en cada cliente é a causa habitual deste erro. OpenVPN, os perfís IPsec e as interfaces de aplicación documentan cada un a súa sintaxe, e unha cadea correcta para un pode ser rexeitada ou malinterpretada por outro. Lea a documentación do propio cliente para o campo que edita, e garde o prefixo de documentación ou o enderezo de exemplo nun comentario para que ninguén o envíe como host real. Cando o manual dá dúas formas, use a que encaixa co tipo de campo que ten diante.

Separe os campos de enderezo e porto

Cando o cliente lle dá dúas caixas, pon o enderezo nunha e o porto na outra. Unha forma combinada pegada na caixa de enderezo produce un erro de análise ou, peor, un enderezo que se resolve en algo non desexado.

Revise os espazos finais e os caracteres invisibles cando un valor parece correcto. Un enderezo copiado adoita levar un espazo duro ou un carácter de ancho cero que o cliente non pode analisar e que a pantalla non mostra. Volva escribir o valor en lugar de pegarlo cando o erro non teña sentido.

Manexe con coidado os identificadores de zona

Un literal de enlace local pode requirir un identificador de zona ligado a unha interface, escrito cun signo de porcentaxe e o nome da interface. Esa forma é válida no host que posúe a interface, e non substitúe un punto final remoto accesible en xeral.

O alcance e o encamiñamento seguen importando tras unha análise correcta. Un enderezo cualificado por zona que o cliente acepta pode non ter ningunha ruta desde a máquina, e un punto final remoto acadado por internet non debería depender en absoluto dunha zona local. Decida por que interface debe saír o paquete antes de escribir a zona, non despois de que falle o aperto de mans.

Verifique a análise e logo a conectividade

Separe os dous fallos de forma explícita. Un enderezo mal formado produce un erro de análise ou un rexeitamento inmediato, mentres que un punto final ben formado que rexeita a autenticación ou nunca responde é outro problema con outra solución.

Tras unha corrección admitida, confirme que o túnel negocia e que a aplicación prevista funciona. Un aperto de mans por si só non demostra a ruta, e un ping ao punto final non demostra o túnel. Cando o operador fornece un nome de host, conserve o nome admitido e as súas comprobacións de identidade en lugar de substituílo por un enderezo numérico atopado noutro sitio.

Anote o campo exacto, o valor que usou e a resposta do cliente na nota de cambio. Se non, a próxima persoa que edite o perfil repetirá o experimento dos corchetes, e a resposta xa está no seu tíquete.