Failback në ASA: çfarë lëviz në të vërtetë kur rruga kthehet
Kthimi i një rruge në rrugën kryesore nuk do të thotë që rrjedhat e vjetra u zhvendosën. Vëzhgoni së bashku uplink-un, tunelin, tabelën e lidhjeve dhe rezultatin e aplikacionit.
Në një ASA me dy uplink-e, failback nuk është e kundërta e failover-it. Rruga drejt peer-it ndryshon, dhe më pas platforma duhet të pajtojë tre makineri të veçanta gjendjeje: tabelën e rrugëve, shoqatat e sigurisë IKE dhe IPsec, dhe tabelën e lidhjeve. Secila mund të mbetet pas të tjerave, dhe pikërisht ai vonesë është ajo që shumica e njerëzve përshkruajnë si një tunel që nuk kthehet.
Çfarë ndryshon vërtet failback
Kërkimi i rrugës është pjesa e dukshme. Kur objekti i monitoruar rikuperohet, rruga e monitoruar drejt adresës së jashtme të peer-it kthehet, dhe paketa tjetër që dërgon ASA ndjek përsëri lidhjen kryesore. Gjithçka pas kësaj varet nga fakti nëse gjendja ekzistuese pajtohet me rrugën e re.
ARP dhe NAT janë varësitë e heshtura. Një next hop i re ka nevojë për një portë të zgjidhshme dhe një përkthim që ende përputhet me skajin e largët, përndryshe paketat e para pas failback nuk shkojnë askund dhe rruga duket mirë ndërsa asgjë nuk funksionon.
Katër këndvështrime në një vijë të vetme kohore
Regjistroni të njëjtat katër gjëra para, gjatë dhe pas tranzicionit, sepse një pamje e vetme nuk mund t'ju thotë se cila shtresë lëvizi.
| 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 |
Një rrugë që nuk ndryshoi kurrë dhe një rrugë që ndryshoi ndërsa një lidhje më e vjetër ruante gjendjen e përcjelljes së saj prodhojnë të njëjtën ankesë dhe prova krejtësisht të ndryshme.
Pse lidhjet e vjetra mbeten në rrugën rezervë
ASA nuk shkëput një rrjedhë sepse ndryshoi një rrugë. Lidhjet e vendosura ruajnë vendimin e përcjelljes me të cilin u krijuan, dhe platforma ofron kontrolle të veçanta për sa kohë lejohet kjo: floating-connection timeout dhe connection holddown. udhëzuesi i konfigurimeve të lidhjes të ASA 9.24 e Cisco i trajton si pyetje të ndryshme, dhe pikërisht ashtu sillen. Njëri rregullon mbijetesën e një rrjedhe ekzistuese; tjetri rregullon kur rrjedhat e reja mund të përdorin rrugën e preferuar.
Lexoni vlerat në fuqi për versionin tuaj përpara se të ndryshoni ndonjërin. Ulja e tyre mbyll sesione që njerëzit ende i përdorin. Ngritja e tyre e bën failback të duket sikur nuk ndodhi kurrë, sepse lidhjet e reja vazhdojnë të marrin rrugën e vjetër gjatë gjithë asaj kohe.
Një tunel nuk rinegocion çelësat sepse u kthye një rrugë
Shoqatat e sigurisë IPsec mbajnë jetëgjatësinë e tyre të negociuar dhe i mbijetojnë ndryshimit të rrugës që i transportoi. Prandaj një tunel mund të mbetet lart përgjatë një failback ndërsa adresimi i tij i jashtëm nuk përputhet më me rrugën në përdorim, dhe ky është argumenti për DPD dhe për dizajnet që fiksojnë adresën e peer-it në vend që ta lënë të lëvizë.
Dizajnet crypto-map dhe VTI sillen ndryshe këtu, dhe dokumentacioni i Cisco për 9.24 VTI përshkruan opsionin e bazuar në rrugë. Pohimi i vjetër i përgjithshëm se një ASA nuk mund të ekzekutojë VPN të bazuara në rrugë nuk vlen për versionet e mbështetura.
Lexoni provat në këtë rend
Filloni nga rrafshi i kontrollit: show route për rrugën e zgjedhur, show interface për gjendjen e lidhjes dhe numëruesit e monitorit SLA për objektin e monitoruar. Pastaj lexoni show crypto ikev2 sa, ose ekuivalentin IKEv1, për të parë se cili peer është i gjallë, i ndjekur nga show crypto ipsec sa për rrjedhat e mbrojtura. Më pas ngushtoni tabelën e lidhjeve me show conn address <host> dhe krahasoni kolonën e ndërfaqes tek regjistrimet e vjetra dhe të reja. Shkruani daljet me vulat kohore, sepse rendi i tyre është diagnoza.
Përfundoni me një test aplikacioni: një rrjedhë që ekzistonte tashmë dhe një që u krijua pasi u kthye rruga. Nëse rrjedha e vjetër dështon dhe e reja funksionon, keni një histori të gjendjes së lidhjes. Nëse të dyja dështojnë, tuneli ose politika është e gabuar dhe tabela e lidhjeve është shpërqendrim.
Mbajeni atë regjistër në të njëjtën formë në të tre fazat dhe shënoni versionin e saktë. Kur vija kohore vazhdon të tregojë një tranzicion të vetëm, dërgoni regjistrin te mbështetja në vend që të hamendësoni një ID bug-u.