Cambiare l'indirizzo di peer IPsec su un ASA senza rompere il tunnel
Spostare un indirizzo di peer tocca l'elenco dei candidati, la corrispondenza del profilo, l'underlay e le sessioni attive. Seguite la lista di controllo in ordine.
Un cambio di indirizzo di peer sembra una riga e si comporta come una migrazione. Ciò che si sposta davvero è un insieme di oggetti: l'elenco dei peer candidati sulla crypto map, il profilo o la mappatura di autenticazione che identifica l'estremità remota, l'underlay che lo raggiunge, e le associazioni attive costruite sui vecchi valori. Trattate la modifica di configurazione come l'ultimo passo di questo insieme, non il primo.
1. Registrate lo stato attuale prima di toccare qualsiasi cosa
Partite dall'intero elenco dei candidati della voce di crypto map interessata, in ordine, non solo dall'indirizzo che pensate sia in uso. L'ordine conta perché è quello che il dispositivo prova davvero.
Catturatelo con show run crypto map e leggete la voce effettiva con show crypto map, poi salvate entrambi gli output accanto al nuovo valore previsto. Annotate anche quale peer ha scelto ogni associazione esistente, finché siete lì.
Fate lo stesso per il livello sessioni, usando show vpn-sessiondb l2l e show crypto ipsec sa peer <old-address>. Questi due output sono la vostra immagine prima, quando qualcuno chiede perché un tunnel è caduto alle 02:10.
2. Dimostrate che il nuovo peer è raggiungibile con la stessa politica
Dimostrate la raggiungibilità prima di pianificare il taglio. Un'esecuzione di packet-tracer dall'interfaccia interna verso la rete protetta del nuovo peer mostra se routing, esenzione NAT e politica di accesso concordano. Poi confermate il percorso di trasporto, perché IKE e IPsec richiedono UDP 500 e 4500 per attraversare qualsiasi filtro tra i gateway. Un ping riuscito non dimostra nulla di tutto ciò da solo.
Se l'underlay richiede una route o un cambio di traduzione, è un secondo cambiamento con il suo rischio. Raggruppatelo nella stessa finestra o pianificatelo a parte, ma decidete quale, invece di scoprirlo a metà del taglio.
3. Spostate la mappatura del profilo, non solo l'indirizzo
La selezione del peer e la selezione del profilo sono due ricerche diverse. Un profilo di connessione LAN-to-LAN contiene attributi generali e può corrispondere a un indirizzo, a un'identità di certificato o a un nome di gruppo. Cambiare l'IP non cambia quale profilo corrisponde quando il profilo si basa sul soggetto di un certificato.
| Oggetto | Su cosa è indicizzato | Cosa tocca un nuovo indirizzo di peer |
|---|---|---|
| Elenco dei candidati della crypto map | Voci di peer configurate e il loro ordine | Dove l'ASA invia i suoi pacchetti iniziali |
| Profilo di connessione | Indirizzo, identità di certificato o gruppo | Solo i profili indicizzati sull'indirizzo |
| Prefissi protetti | Oggetti di rete locali e remoti | Niente, a meno che non li cambiate anche voi |
Mantenete intatto il contratto delle credenziali. Un cambio di indirizzo non è un motivo per allentare i controlli di identità, né per incollare una chiave pre-condivisa di esempio in un ticket.
4. Osservate le sessioni attive finché esistono entrambi i candidati
Finché entrambi gli indirizzi stanno nell'elenco dei candidati, decidete per iscritto se il vecchio è un fallback o un residuo. Una configurazione che contiene entrambi è valida, e non dimostra nulla su quale peer abbia portato l'ultima sessione.
Cancellate le associazioni di sicurezza obsolete solo con la forma limitata al peer della vostra versione, clear crypto ipsec sa peer <address>, e aspettatevi che i tunnel interessati rinegozino. Un reset globale fa cadere ogni sessione sull'appliance e non sarà perdonato in orario di lavoro.
Poi fate passare un flusso applicativo reale da un host protetto e confermate che la risposta torna attraverso l'endpoint previsto. show vpn-sessiondb l2l dovrebbe indicare il nuovo peer per quella sessione, e i contatori di byte dovrebbero muoversi.
5. Chiudete o tornate indietro
Scrivete il rollback prima del cambiamento: il vecchio elenco dei candidati, la vecchia mappatura del profilo e la vecchia voce di underlay. Tenete un percorso di gestione indipendente verso l'ASA, perché una modifica dell'indirizzo di peer che vi costa anche l'accesso è una serata lunga. Rimuovete il peer obsoleto e le credenziali solo dopo l'accettazione e dopo aver registrato la decisione di fallback. Verificate anche che la politica di accesso sulle reti protette non sia andata alla deriva.
La migrazione è finita quando il peer previsto si autentica e trasporta il servizio richiesto sotto la politica conservata. Un nuovo indirizzo nella configurazione in esecuzione è prova di battitura, non di successo.