Migrazione VPN da IOS ad ASA: tradurre l'accordo, non i comandi

Una configurazione IOS che arriva come riferimento per una migrazione ad ASA descrive un accordo avvolto nella sintassi di una piattaforma. Gli indirizzi dei peer, le identità e gli intervalli protetti sono l'accordo. Il portachiavi, il profilo e la catena di mappe crypto sono il modo in cui IOS lo esprime, mentre l'ASA esprime la stessa intenzione tramite gruppi tunnel e i loro attributi. Copiare la seconda parte non funziona mai, e copiare solo la prima lascia il lavoro a metà.

Percorrete i cinque passaggi seguenti in ordine e fermatevi ovunque le due piattaforme descrivano cose diverse anziché parole diverse.

Passo 1: separate l'accordo dalla sintassi

Scrivete il passaggio di consegne come requisiti su cui entrambi gli amministratori concordano. Quattro righe coprono quasi tutto: dove si trova il peer e quale lato inizia, come ciascun lato dimostra la propria identità, quale protezione è accettabile e quali applicazioni devono sopravvivere al tunnel. Nessuna di queste righe menziona un comando.

Conservate il testo originale come prova e non come istruzioni. Una riga che esiste su una piattaforma e non sull'altra è una differenza di sintassi finché non avete verificato se lo stesso requisito può essere soddisfatto in altro modo.

Passo 2: nominate gli oggetti su ciascuna piattaforma

Su IOS XE un portachiavi IKEv2 alimenta un profilo IKEv2, e quel profilo viene collegato tramite una mappa crypto o un profilo IPsec. Sull'ASA un gruppo tunnel contiene il profilo di connessione e i suoi attributi IPsec, e la mappa crypto punta a esso, come descrive la guida del profilo di connessione. Sono grafi di oggetti diversi con eredità diversa, ed è per questo che una corrispondenza riga per riga produce una configurazione che viene analizzata e non si connette.

Costruite gli oggetti di destinazione dalle righe dei requisiti e non dalle righe di origine. Se le righe sono complete, la configurazione di destinazione è una decisione di progetto. Se non lo sono, nessuna quantità di traduzione dei comandi fornirà l'intenzione mancante.

Passo 3: trasportate l'identità, non solo gli indirizzi

L'identità è la parte che si rompe in silenzio. Un peer che si autentica per indirizzo si comporta diversamente da uno che si autentica per soggetto del certificato o per FQDN, e le due piattaforme registrano quell'aspettativa in luoghi diversi. Preservate l'identità prevista e la catena di fiducia invece di sostituire un segreto condiviso perché è più facile da testare.

Tenete il segreto precondiviso fuori dalle note di confronto e dai ticket. Annotate chi lo possiede e come si sposta attraverso un canale approvato, e ricordate che un segnaposto tratto da un esempio di documentazione non è la credenziale del cliente.

Passo 4: concordate la protezione prima della commutazione

Non trasferite vecchie impostazioni crittografiche solo perché compaiono nel testo fornito. Concordate un'intersezione di suite che entrambi i peer distribuiti supportano attualmente e confermatela con l'altro amministratore prima della finestra di modifica. Se quell'intersezione differisce da ciò che il peer esistente si aspetta, è un cambiamento coordinato e non una modifica locale.

Scrivete l'insieme concordato. Due amministratori con ricordi diversi di una telefonata è il modo in cui una commutazione produce un disallineamento di fase due.

Passo 5: verificate il servizio, non la sintassi

Controllate prima gli oggetti effettivi della destinazione, poi l'associazione accettata, poi un flusso applicativo reale e la sua risposta. Inserire un comando senza errori dimostra la sintassi e nient'altro. Un tunnel che sale e non trasporta traffico di solito significa che gli intervalli protetti o la rotta di ritorno non concordano con l'altro lato, il che è un problema di riga dei requisiti e non di comando. Confrontate gli intervalli protetti su entrambi i lati prima di toccare di nuovo la mappa crypto.

Annotate che cosa avete verificato, con quali indirizzi e da quale lato. Quel registro trasforma un'affermazione ambigua che la VPN è attiva in qualcosa che l'altro amministratore può controllare in modo indipendente.

Che cosa restituire

Inviate la matrice dei requisiti, un riepilogo della configurazione di destinazione e i risultati della verifica. Indicate esplicitamente quali impostazioni di origine non avete trasferito e perché. Quell'elenco è più utile della configurazione tradotta, perché è lì che inizierà il prossimo disaccordo.

Conservate anche il testo di origine con il ticket. Documenta ciò che è stato richiesto, mentre la matrice documenta ciò che è stato concordato.