IKEv2 indirizzo del server e identità: ciò che il client effettivamente controlla

Un gateway che cambia indirizzo può continuare a funzionare mentre lo stesso gateway dietro un nuovo certificato si ferma e accade anche il contrario. L'indirizzo indica al client dove inviare i pacchetti; l'identità autenticata dice al client se il peer che risponde è quello di cui dovrebbe fidarsi. IKEv2 li mantiene come due campi separati, il che è utile quando si smette di trattarli come un'unica stringa. Inoltre sono configurati in posti diversi, quindi uno può essere corretto mentre l'altro è sbagliato.

Controllali in questo ordine e fermati al primo disallineamento, perché i controlli successivi presuppongono che quelli precedenti siano stati superati.

Innanzitutto, quale valore è l'indirizzo

L'indirizzo di connessione è qualunque cosa componga il client: un IP, un nome DNS che si risolve in uno o un front-end con carico bilanciato. Queste sono informazioni sui trasporti e niente di più. L'identità viene utilizzata nel payload dell'ID IKEv2 e viene quindi confrontata con il certificato del peer. Un nome DNS nella casella dell'indirizzo non diventa l'identità prevista e un IP grezzo non diventa l'identità solo perché il socket è connesso ad esso.

In termini di strongSwan, l'indirizzo è right o left e l'identità prevista è rightid o leftid, e questo è ciò che descrive la documentazione di configurazione IKEv2. Se hai modificato solo l'indirizzo, hai configurato metà della coppia.

In secondo luogo, cosa può dimostrare il certificato

L'identità ha un tipo e il certificato deve avere un nome corrispondente. Un'identità DNS è soddisfatta da una voce dNSName nell'estensione del nome alternativo del soggetto; un'identità IP necessita di una voce iPAddress. Un certificato emesso per vpn.example.com non prova nulla riguardo all'indirizzo letterale 203.0.113.10, e uno rilasciato per quell'indirizzo non prova nulla riguardo al nome. La riemissione con un nome diverso quindi non è una sostituzione immediata, anche quando vengono riutilizzati la stessa chiave e CA.

I client moderni ignorano il nome comune quando esiste un nome alternativo al soggetto e molti lo ignorano completamente. Se l'elenco SAN non contiene il valore controllato dal client, l'handshake fallisce dopo che il certificato è già stato accettato come affidabile, motivo per cui il registro viene letto come un errore di identità anziché come un errore di attendibilità.

Terzo, come ogni cliente esprime le proprie aspettative

Windows prende il nome o l'indirizzo del server digitato e richiede che il certificato corrisponda, quindi digitare un IP crea un'aspettativa IP. Il client IKEv2 di Android si comporta allo stesso modo ed entrambi rifiutano un certificato valido e pubblicamente attendibile che nomina un host diverso. Un profilo può iniziare a fallire semplicemente perché qualcuno ha sostituito il nome host con il suo indirizzo durante una migrazione. Guarda cosa ha chiesto il cliente prima di guardare cosa contiene il certificato.

Su strongSwan l'aspettativa è esplicita: impostare rightid sull'identità effettivamente presentata dal server, che può differire da destra. Impostandolo su %any accetti qualunque cosa offra il peer e rimuovi esattamente l'assegno che stai cercando di trattenere.

In quarto luogo, separare il login dell'utente dall'identità del peer

L'autenticazione EAP e l'identità del server rispondono a domande diverse. Un'identità EAP come [email protected] dice chi è l'utente, dopo che il client ha deciso che il server è quello giusto. La rotazione della password non può risolvere una mancata corrispondenza dell'identità del peer, perché la connessione non raggiunge mai la fase di accesso dell'utente.

Un report ripulito dovrebbe nominare entrambi: l'identità prevista dal client, l'identità presentata dal server e le voci SAN del certificato.

Quinto, cambialo attraverso un canale verificato

Quando il gateway si sposta legittimamente, aggiorna prima l'indirizzo e lascia stare l'identità, perché in questo caso IKEv2 si gestisce bene. Quando l'identità stessa cambia, trattala come un evento di fiducia e ottieni il nuovo valore da una fonte di cui ti fidi già, non dall'endpoint che attualmente sta fallendo. Un messaggio consegnato tramite la connessione che stai tentando di convalidare non costituisce una prova di tale connessione.

Registra insieme l'indirizzo finale, l'identità e l'elenco SAN nelle note del profilo. La prossima persona che toccherà il certificato vedrà quale dei tre può muoversi.