Identità IKE o indirizzo dell'endpoint: non confonderli

Leggi un campo etichettato come identità FQDN come una stringa letterale, non come una richiesta del nome DNS inverso del tuo indirizzo pubblico. Nel parser di strongSwan è esattamente questo, una stringa, e leggerlo non lo risolve mai in un endpoint. Questo fatto da solo elimina la distrazione più comune quando scegli gli identificatori per un peer. I controlli seguenti impediscono ai tre valori coinvolti di fondersi in uno.

Un'etichetta non è una ricerca

Le interfacce dei fornitori usano parole come FQDN e hostname con disinvoltura, e l'etichetta su una scatola non dice nulla sulla codifica che c'è dietro. Un apparato che chiama un campo Client FQDN può inviare un FQDN, una stringa in forma di email o un indirizzo nudo. Tratta il testo e il tipo come due decisioni separate e registra entrambe.

Niente in un'identità letterale richiede DNS. È un'affermazione che l'altro capo verifica, non un nome che la rete deve risolvere.

Tre valori separati, scritti separatamente

Tre compiti stanno dietro una sola schermata di configurazione, e fonderli è l'errore costoso. Un valore è l'indirizzo dell'endpoint, che decide dove vanno i pacchetti. Un altro è l'identità locale che questo peer presenta, e il terzo è l'identità che ti aspetti dall'altro capo prima di autenticarlo. Scrivili come tre righe nel ticket di modifica, perché qualunque cosa di meno descrive una VPN e non una relazione.

Le identità di esempio vanno scelte e autorizzate come parte della distribuzione. Sono affermazioni che l'autenticazione verifica, non credenziali che rendono affidabile un peer, quindi una stringa dall'aria plausibile non autorizza nulla.

Il tipo fa parte del valore

La referenza delle identità di strongSwan separa FQDN, valori in forma di email, indirizzi IP e altre codifiche, quindi la codifica conta quanto i caratteri. Due dispositivi possono accettare lo stesso testo con tipi diversi e rifiutarsi comunque a vicenda. Una nota che registra il valore senza il suo tipo è mezza configurazione.

Chiedi al fornitore quale tipo invia davvero l'apparato, e confermalo con una decodifica invece che con l'etichetta dell'interfaccia. Un tipo indovinato è una discrepanza in attesa del prossimo cambio.

Ogni lato deve soddisfare l'altro

L'identità locale di ciascun lato deve superare la politica di autenticazione dell'altro lato. Non è la stessa cosa che incollare una stringa in ogni casella di identità su entrambi i dispositivi, che è la scorciatoia che produce una configurazione che nessuno riesce a eseguire il debug.

L'autenticazione con certificato aggiunge requisiti propri, perché l'identità del certificato e le condizioni di fiducia stanno accanto all'identità IKE che hai digitato. Una corrispondenza dell'identità IKE da sola non autorizza un peer con certificato.

Dove conta il DNS e cosa impone la tua versione

Un hostname di gateway usato per la scoperta ha davvero bisogno di un DNS funzionante, e quel requisito appartiene alla ricerca dell'endpoint e non a una qualche ricerca inversa di un'identità digitata. Tieni le due cose separate nel ticket, perché un guasto di scoperta e una discrepanza di identità si leggono in modo simile in un log del client e si riparano in punti diversi.

Leggi il parser del prodotto e della versione che esegui davvero prima di copiare una sintassi che impone un tipo, perché le versioni più vecchie di strongSwan si comportavano diversamente e altri fornitori aggiungono vincoli propri. Quando confronti i due capi, tieni insieme quattro cose: identità attesa, identità presentata, tipo ed errore di autenticazione. Quell'insieme trasforma una discrepanza in una prova invece che in un'opinione.