Failback pe ASA: ce se mută de fapt când ruta revine
Întoarcerea unei rute pe calea principală nu înseamnă că fluxurile vechi s-au mutat. Urmăriți împreună uplink-ul, tunelul, tabela de conexiuni și rezultatul aplicației.
Pe o ASA cu două uplink-uri, failback nu este inversul failover-ului. Ruta către peer se schimbă, iar apoi platforma trebuie să împace trei mașini de stare separate: tabela de rutare, asocierile de securitate IKE și IPsec și tabela de conexiuni. Fiecare poate rămâne în urmă față de celelalte, iar acel decalaj este ceea ce majoritatea oamenilor descriu ca un tunel care nu revine.
Ce schimbă de fapt failback
Căutarea rutei este partea vizibilă. Când obiectul monitorizat își revine, ruta monitorizată către adresa exterioară a peer-ului revine, iar următorul pachet pe care ASA îl trimite urmează din nou legătura principală. Tot ce urmează depinde de dacă starea existentă se potrivește cu noua cale.
ARP și NAT sunt dependențele tăcute. Un next hop nou are nevoie de o poartă rezolvabilă și de o traducere care încă se potrivește cu capătul îndepărtat, altfel primele pachete după failback nu ajung nicăieri și ruta arată bine în timp ce nimic nu funcționează.
Patru perspective pe o singură linie de timp
Înregistrați aceleași patru lucruri înainte, în timpul și după tranziție, pentru că o singură instantanee nu poate spune ce strat s-a mișcat.
| 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 |
O rută care nu s-a schimbat niciodată și o rută care s-a schimbat în timp ce o conexiune mai veche și-a păstrat starea de forwarding produc aceeași plângere și dovezi complet diferite.
De ce conexiunile vechi rămân pe calea de rezervă
ASA nu desființează un flux pentru că s-a schimbat o rută. Conexiunile stabilite păstrează decizia de forwarding cu care au fost create, iar platforma oferă controale separate pentru cât timp este permis acest lucru: floating-connection timeout și connection holddown. ghidul Cisco pentru setările de conexiune din ASA 9.24 de la Cisco le tratează ca întrebări distincte și exact așa se comportă. Unul guvernează supraviețuirea unui flux existent, celălalt când fluxurile noi pot folosi calea preferată.
Citiți valorile efective pentru versiunea dumneavoastră înainte de a schimba oricare dintre ele. Dacă le coborâți, închideți sesiuni pe care oamenii încă le folosesc. Dacă le ridicați, failback pare că nu s-a întâmplat niciodată, pentru că noile conexiuni continuă să ia calea veche tot timpul.
Un tunel nu renegociază cheile pentru că a revenit o rută
Asocierile de securitate IPsec poartă propria durată de viață negociată și supraviețuiesc schimbării de rută care le-a purtat. Un tunel poate deci rămâne ridicat pe parcursul unui failback în timp ce adresarea sa exterioară nu mai corespunde căii folosite, iar acesta este argumentul pentru DPD și pentru modelele care fixează adresa peer-ului în loc să o lase să floteze.
Modelele crypto-map și VTI se comportă aici diferit, iar documentația Cisco pentru 9.24 VTI descrie opțiunea bazată pe rute. Vechiul enunț general că o ASA nu poate rula VPN-uri bazate pe rute nu este valabil pentru versiunile acceptate.
Citiți dovezile în această ordine
Începeți cu planul de control: show route pentru calea selectată, show interface pentru starea legăturii și contoarele monitorului SLA pentru obiectul monitorizat. Apoi citiți show crypto ikev2 sa, sau echivalentul IKEv1, ca să vedeți care peer este activ, urmat de show crypto ipsec sa pentru fluxurile protejate. Apoi restrângeți tabela de conexiuni cu show conn address <host> și comparați coloana de interfață la intrările vechi și noi. Notați ieșirile cu marcaje de timp, pentru că ordinea lor este diagnosticul.
Încheiați cu un test de aplicație: un flux care exista deja și unul creat după ce ruta a revenit. Dacă fluxul vechi eșuează și cel nou funcționează, aveți o poveste despre starea conexiunii. Dacă ambele eșuează, tunelul sau politica sunt greșite, iar tabela de conexiuni este o distragere.
Păstrați acel registru în aceeași formă în toate cele trei faze și notați versiunea exactă. Când linia de timp indică în continuare o singură tranziție, trimiteți registrul la suport în loc să ghiciți un ID de eroare.