Canale di controllo e canale dati VPN: verificate lo strato giusto

Il client dice connesso, il server vede un pari e l'applicazione continua a non raggiungere nulla. A quel punto la domanda utile non è quale cifratura cambiare, ma quale canale ha fallito. OpenVPN nomina esplicitamente due funzioni: un canale di controllo che negozia e gestisce la sessione, e un canale dati che trasporta il traffico protetto. IKEv2 esprime una separazione simile tramite l'associazione IKE e l'associazione CHILD. Eseguite le verifiche qui sotto in ordine, perché una correzione del percorso dati applicata a un guasto del percorso di controllo spreca una finestra di modifica.

Nominate il canale prima di eseguire il debug

Il lato di controllo negozia il materiale di sicurezza, autentica i pari e gestisce la connessione. Il lato dati trasporta il traffico selezionato una volta che esiste lo stato necessario.

Falliscono in modo diverso. Un guasto di controllo di solito vi lascia senza alcuna sessione utilizzabile, oppure con una sessione che rinegozia in ciclo. Un guasto dei dati lascia una sessione che sembra sana mentre i pacchetti vengono scartati, instradati male o protetti con parametri che l'altro lato non accetterà. La riga di log che state leggendo vi dice in quale dei due casi siete, quindi leggete l'etichetta prima del testo dell'errore.

Verificate lo scambio di controllo

Confermate che l'handshake si completa e che entrambi i lati concordano su trasporto, versione di TLS e metodo di autenticazione. I log di OpenVPN stampano righe separate per il canale di controllo e per il canale dati, ed è sulla riga di controllo che compare una discrepanza di certificato, versione di TLS o tls-crypt.

Se lo scambio di controllo fallisce, guardate la porta raggiungibile, la catena di certificati e le sue date di validità, l'orologio di sistema, la sovrapposizione delle cifrature tra client e server e qualsiasi chiave tls-auth o tls-crypt. Una catena di certificati grande può fallire anche sull'MTU del percorso prima che si completi qualsiasi autenticazione, il che sembra un timeout e non un errore crittografico.

Correggete i guasti di controllo con impostazioni di controllo. Aumentare la cifratura dei dati o allentare la politica di autenticazione dei dati non completerà un handshake che non ha mai superato lo scambio dei certificati.

Verificate il canale dati separatamente

Una volta attiva la sessione, confermate la cifratura e la modalità dati negoziate, la derivazione delle chiavi e il comportamento di rinnovo della chiave. In OpenVPN, la riga del canale dati indica la cifratura e la dimensione della chiave realmente inizializzate, che possono differire dalla prima cifratura del profilo.

Poi verificate che cosa ha installato la sessione. Un PUSH_REPLY può aggiungere rotte, un server DNS e una direttiva redirect-gateway, e ciascuna di queste può inviare traffico dove l'applicazione non può usarlo. Per IKEv2, la domanda equivalente è se i selettori dell'associazione CHILD corrispondono agli indirizzi del flusso reale.

tls-auth e tls-crypt appartengono al canale di controllo. Autenticano o cifrano l'handshake e non selezionano la cifratura dei dati dell'applicazione. Se ne aggiungete uno aspettandovi un cambiamento del percorso dati, l'unica cosa che avete cambiato è l'handshake.

Collegate i nomi a IKEv2 e OpenVPN

IKEv2 ha un'associazione di sicurezza IKE e una o più associazioni CHILD. L'associazione IKE trasporta gli scambi di controllo; l'associazione CHILD trasporta il traffico protetto e i suoi selettori. Vengono negoziate e rinnovate le chiavi secondo calendari separati, quindi una può essere sana mentre l'altra non lo è.

ESP non ha al suo interno un canale di controllo in stile TLS. Il protocollo di controllo è IKE, e ESP è il carico protetto. Chiamare ESP il canale dati è un'abbreviazione lasca che diventa confusa quando si legge una cattura di pacchetti, perché la cattura mostra i messaggi IKE e i pacchetti ESP come protocolli diversi sul filo.

Mantenete la corrispondenza esplicita nelle vostre note: il canale di controllo di OpenVPN e l'IKE SA sono il lato di gestione, il canale dati di OpenVPN e il CHILD SA sono il lato del traffico, e le implementazioni non sono intercambiabili anche quando la separazione sembra simile.

Smettete di cambiare l'impostazione sbagliata

Percorrete il percorso in una sola direzione: scambio di controllo, protezione dei dati, inoltro e poi risoluzione dei nomi. Fermatevi al primo stadio che fallisce e correggete solo quello stadio. Una sessione connessa con un ping funzionante verso il gateway ma senza traffico dell'applicazione è un problema di inoltro o di selettori, non di handshake.

Scrivete le prove per ogni stadio separatamente nel ticket: la riga di log del controllo, i parametri dati negoziati, le rotte installate e una richiesta reale. Questa struttura impedisce che una verifica di identità funzionante venga indebolita per riparare un problema di routing successivo che non ha mai causato, e impedisce che un cambio di cifratura dei dati venga venduto come correzione di un errore di certificato.

La documentazione del protocollo OpenVPN è il riferimento per la separazione tra controllo e dati; usatela quando l'interfaccia di un fornitore impiega altre parole per le stesse due funzioni.