Un MAC non corrispondente in IKE significa che il controllo della chiave condivisa è fallito

Il tuo registro di Cloud VPN mostra un tentativo con chiave condivisa seguito da MAC mismatched, e il primo istinto è spesso cercare un problema di indirizzo. In questo ramo MAC è un codice di autenticazione del messaggio: un valore calcolato sullo scambio con la chiave negoziata. Il peer ha confrontato il proprio calcolo con il valore ricevuto, ed erano diversi. Nessuna scheda di rete è coinvolta, e nessuna impostazione dell'interfaccia cambia quel confronto.

In pratica lo producono due condizioni: i segreti dei due estremi non sono lo stesso valore, oppure le identità usate per selezionare il segreto non corrispondono. Decidi quale leggendo la coppia, non il singolo tunnel.

Cosa dimostra la fase

Il controllo viene eseguito dopo che entrambi i lati hanno scambiato i parametri iniziali e si sono identificati. Seleziona chiavi condivise candidate per le identità locale e remota e tenta di validare i dati di autenticazione ricevuti; quando nessuna valida, viene emessa la diagnostica. È un'affermazione forte sull'autenticazione e debole sulla causa, perché non dice quale lato sia sbagliato.

Il successo precedente non si trasferisce a questo controllo. Un IKE_SA_INIT completato, o un payload di rilevamento NAT che ha restituito i valori attesi, dimostra che i peer possono parlare. Non dimostra nulla sul fatto che condividano un segreto.

Due errori di configurazione, un messaggio

Il primo è una vera discrepanza del segreto, e di solito è un incidente di provisioning: un valore generato installato su una console e ridigitato sull'altra, un carattere finale sopravvissuto su un lato, o una virgoletta arrivata con un incollaggio. Il secondo è una discrepanza di identità, in cui il segreto è corretto ma l'identità presentata dal peer seleziona un'altra voce, quindi il segreto giusto non viene mai provato. Entrambi producono la stessa riga, per questo indovinare costa un pomeriggio.

Confronta la coppia prima di toccare qualsiasi segreto. Fai coincidere il tunnel, l'endpoint del peer, la finestra temporale e la configurazione remota, perché due tunnel ridondanti possono contenere segreti diversi e lo schermo davanti a te potrebbe non essere quello che ha fallito.

Il rilevamento NAT è un'altra fase

Il rilevamento NAT chiede come vengono riscritti i pacchetti, non chi sia il peer. Un gateway cliente dietro NAT si autentica ancora correttamente quando la sua identità configurata è quella che il peer si aspetta, e un problema NAT si manifesta come discrepanza di proposta o di porta anziché come confronto di autenticazione fallito.

Non trasferire un'affermazione vecchia su una versione di fornitore in una distribuzione attuale. Ciò che l'attraversamento NAT richiede nella tua versione appartiene alla sua documentazione, e la frase MAC mismatch non è una prova a favore o contro.

Decidi dalla coppia, non dallo schermo

Leggi entrambe le configurazioni fianco a fianco con il segreto oscurato, poi poni tre domande. L'identità di ciascun lato è esattamente ciò che l'altro si aspetta, carattere per carattere? Entrambi gli estremi usano la stessa versione di IKE e lo stesso metodo di autenticazione? Il tunnel che fallisce corrisponde alla configurazione che stai leggendo? Un no a una di queste decide la riparazione senza toccare il segreto.

Se tutte e tre sono pulite, sostituisci il segreto tramite il flusso di lavoro approvato invece di modificare attorno ad esso.

Dopo che il peer si autentica

Una volta riuscita l'autenticazione, la superficie di guasto successiva è l'associazione di sicurezza figlia: proposte e selettori di traffico. Ruotare un segreto già accettato non può riparare un guasto figlio e prolunga l'interruzione. Leggi lo stato della figlia, poi i selettori e gli intervalli protetti su entrambi i lati, e fai corrispondere la guida alla risoluzione dei problemi di Cloud VPN alla fase che ha effettivamente fallito.

Correla registri recenti da entrambi gli estremi per la stessa coppia e la stessa finestra. Un lato da solo dà un verdetto senza l'input dell'altro, ed è proprio questa ambiguità che ha prodotto il messaggio in origine.

Cosa non concludere

Non leggere il messaggio come una richiesta di cambiare gli indirizzi MAC, e non pubblicare il segreto condiviso mentre chiedi aiuto; un estratto che contiene la chiave deve avere la chiave rimossa, non il registro conservato. Non presumere nemmeno un guasto di routing, perché peer che non riescono a raggiungersi non producono alcun confronto di autenticazione. E non generalizzare una limitazione documentata di una famiglia di prodotti a ogni implementazione IPsec.

Registra la coppia che fallisce, lo stato del tunnel prima e dopo, e quale delle due condizioni hai modificato. Quel registro trasforma la prossima occorrenza in un controllo di cinque minuti.