Un indirizzo IPv6 è pieno di due punti, e un campo endpoint che porta anche una porta ha bisogno di un modo per segnare dove finisce l’indirizzo. Se sbagliate, il client rifiuta di analizzare il profilo oppure si connette silenziosamente alla cosa sbagliata. La forma corretta non è universale: dipende dal fatto che il campo contenga un indirizzo con porta, un indirizzo nudo o un nome host. Seguite la guida in ordine, perché una correzione di sintassi e una correzione di raggiungibilità non si somigliano affatto quando iniziate a leggere l’output del client.

Controllate il tipo di campo prima di digitare un indirizzo

Per un campo WireGuard Endpoint con una porta, il letterale IPv6 usa le parentesi quadre attorno all’indirizzo, come in [2001:db8::10]:51820. Il prefisso di documentazione di quell’esempio non è un server pubblico, e le parentesi fanno parte della sintassi, non dell’indirizzo.

Altri formati hanno le proprie regole. Un URI può portare un letterale IPv6 tra parentesi, ma una configurazione VPN non è necessariamente un URI. Un client con caselle separate per indirizzo e porta può aspettarsi il letterale da solo in una casella e il numero nell’altra, e aggiungere lì le parentesi è sbagliato quanto ometterle in un campo combinato.

Mettete il letterale tra parentesi quando la porta condivide il campo

La regola da ricordare è semplice: le parentesi compaiono quando una porta segue nella stessa stringa. Non compaiono quando l’indirizzo sta da solo in un campo senza porta.

Copiare la stringa completa dell’endpoint di un protocollo in ogni client è la causa abituale di questo errore. OpenVPN, i profili IPsec e le interfacce applicative documentano ciascuno la propria sintassi, e una stringa corretta per uno può essere rifiutata o interpretata male da un altro. Leggete la documentazione del client stesso per il campo che state modificando, e tenete il prefisso di documentazione o l’indirizzo d’esempio in un commento perché nessuno lo invii come host reale. Quando il manuale dà due forme, usate quella che corrisponde al tipo di campo davanti a voi.

Separate i campi di indirizzo e porta

Quando il client vi dà due caselle, mettete l’indirizzo in una e la porta nell’altra. Una forma combinata incollata nella casella dell’indirizzo produce un errore di analisi o, peggio, un indirizzo che si risolve in qualcosa di non voluto.

Controllate gli spazi finali e i caratteri invisibili quando un valore sembra corretto. Un indirizzo copiato porta spesso uno spazio unificatore o un carattere a larghezza zero che il client non riesce ad analizzare e che lo schermo non mostra. Riscrivete il valore invece di incollarlo quando l’errore non ha senso.

Gestite con cura gli identificatori di zona

Un letterale di collegamento locale può richiedere un identificatore di zona legato a un’interfaccia, scritto con un segno di percentuale e il nome dell’interfaccia. Quella forma è valida sull’host che possiede l’interfaccia, e non sostituisce un endpoint remoto raggiungibile in generale.

Ambito e instradamento contano ancora dopo un’analisi riuscita. Un indirizzo qualificato per zona che il client accetta può non avere alcun percorso dalla macchina, e un endpoint remoto raggiunto via internet non dovrebbe dipendere affatto da una zona locale. Decidete da quale interfaccia deve uscire il pacchetto prima di scrivere la zona, non dopo che la stretta di mano fallisce.

Verificate l’analisi, poi la raggiungibilità

Separate esplicitamente i due guasti. Un indirizzo malformato produce un errore di analisi o un rifiuto immediato, mentre un endpoint ben formato che rifiuta l’autenticazione o non risponde mai è un altro problema con un’altra soluzione.

Dopo una correzione supportata, confermate che il tunnel negozia e che l’applicazione prevista funziona. Una stretta di mano da sola non dimostra il percorso, e un ping verso l’endpoint non dimostra il tunnel. Quando l’operatore fornisce un nome host, mantenete il nome supportato e i suoi controlli di identità invece di sostituirlo con un indirizzo numerico trovato altrove.

Annotate il campo esatto, il valore usato e la risposta del client nella nota di modifica. Altrimenti la prossima persona che modificherà il profilo ripeterà l’esperimento delle parentesi, e la risposta è già nel vostro ticket.

Articoli correlati