Failback sull'ASA: cosa si muove davvero quando la rotta ritorna
Il ritorno di una rotta sul percorso primario non significa che i flussi vecchi si siano spostati. Osservate insieme l'uplink, il tunnel, la tabella delle connessioni e il risultato dell'applicazione.
Su un'ASA con due uplink, il failback non è l'inverso del failover. La rotta verso il peer cambia e poi la piattaforma deve riconciliare tre macchine a stati separate: la tabella delle rotte, le associazioni di sicurezza IKE e IPsec e la tabella delle connessioni. Ognuna può restare indietro rispetto alle altre, e proprio quel ritardo è ciò che la maggior parte delle persone descrive come un tunnel che non torna.
Cosa cambia davvero il failback
La ricerca della rotta è la parte visibile. Quando l'oggetto monitorato si riprende, la rotta monitorata verso l'indirizzo esterno del peer ritorna, e il pacchetto successivo che l'ASA invia segue di nuovo il collegamento primario. Tutto ciò che segue dipende dal fatto che lo stato esistente sia coerente con il nuovo percorso.
ARP e NAT sono le dipendenze silenziose. Un nuovo next hop ha bisogno di un gateway risolvibile e di una traduzione che corrisponda ancora all'estremità remota, altrimenti i primi pacchetti dopo il failback non vanno da nessuna parte e la rotta sembra a posto mentre nulla funziona.
Quattro viste su un'unica linea temporale
Registrate le stesse quattro cose prima, durante e dopo la transizione, perché una singola istantanea non può dirvi quale strato si è mosso.
| View | What to record |
|---|---|
| Uplink and route | Interface state, the tracked object result, the route selected for the outer peer address |
| IKE and IPsec | The live peer, IKE version, security associations, protected-traffic counters |
| Connection table | Interface and endpoint pair for old flows and for flows created after the change |
| Application | One pre-existing operation and one fresh request, each marked success, reset, stall or recovered |
Una rotta che non è mai cambiata e una rotta cambiata mentre una connessione più vecchia conservava il suo stato di inoltro producono la stessa lamentela e prove completamente diverse.
Perché le vecchie connessioni restano sul percorso di riserva
L'ASA non abbatte un flusso perché è cambiata una rotta. Le connessioni stabilite conservano la decisione di inoltro con cui sono state create, e la piattaforma espone controlli separati per quanto tempo ciò è consentito: floating-connection timeout e connection holddown. la guida alle impostazioni di connessione dell'ASA 9.24 di Cisco li tratta come domande distinte, ed è esattamente così che si comportano. Uno governa la sopravvivenza di un flusso esistente, l'altro governa quando i nuovi flussi possono usare il percorso preferito.
Leggete i valori effettivi della vostra versione prima di modificare l'uno o l'altro. Abbassarli chiude sessioni che le persone stanno ancora usando. Alzarli fa sembrare che il failback non sia mai avvenuto, perché le nuove connessioni continuano a prendere il vecchio percorso per tutta la durata.
Un tunnel non rinegozia le chiavi perché è tornata una rotta
Le associazioni di sicurezza IPsec portano la propria vita utile negoziata e sopravvivono al cambio di rotta che le ha trasportate. Un tunnel può quindi restare attivo durante un failback mentre il suo indirizzamento esterno non corrisponde più al percorso in uso, ed è l'argomento a favore di DPD e dei progetti che fissano l'indirizzo del peer invece di lasciarlo fluttuare.
I progetti crypto-map e VTI si comportano qui in modo diverso, e la documentazione Cisco per 9.24 VTI descrive l'opzione basata sulle rotte. La vecchia affermazione generale che un'ASA non possa eseguire VPN basate sulle rotte non vale per le versioni supportate.
Leggete le prove in questo ordine
Iniziate dal piano di controllo: show route per il percorso scelto, show interface per lo stato del collegamento e i contatori del monitor SLA per l'oggetto monitorato. Poi leggete show crypto ikev2 sa, o l'equivalente IKEv1, per vedere quale peer è attivo, seguito da show crypto ipsec sa per i flussi protetti. Quindi restringete la tabella delle connessioni con show conn address <host> e confrontate la colonna dell'interfaccia tra le voci vecchie e quelle nuove. Annotate gli output con i timestamp, perché il loro ordine è la diagnosi.
Chiudete con un test applicativo: un flusso che già esisteva e uno creato dopo il ritorno della rotta. Se il flusso vecchio fallisce e quello nuovo funziona, avete una storia di stato della connessione. Se falliscono entrambi, il tunnel o la policy sono sbagliati e la tabella delle connessioni è una distrazione.
Mantenete quel verbale nella stessa forma in tutte e tre le fasi e annotate la versione esatta. Quando la linea temporale continua a puntare a un'unica transizione, inviate il verbale al supporto invece di indovinare un ID di bug.