ASA-യിലെ failback: റൂട്ട് തിരികെ വരുമ്പോൾ യഥാർത്ഥത്തിൽ എന്താണ് നീങ്ങുന്നത്
റൂട്ട് പ്രാഥമിക പാതയിലേക്ക് തിരികെ വരുന്നത് പഴയ ഫ്ലോകൾ നീങ്ങി എന്ന് അർത്ഥമാക്കുന്നില്ല. uplink, ടണൽ, കണക്ഷൻ പട്ടിക, ആപ്പിന്റെ ഫലം എന്നിവ ഒരുമിച്ച് നിരീക്ഷിക്കുക.
രണ്ട് uplink ഉള്ള ASA-യിൽ failback എന്നത് failover-ന്റെ വിപരീതമല്ല. peer-ലേക്കുള്ള റൂട്ട് മാറുന്നു, തുടർന്ന് പ്ലാറ്റ്ഫോം മൂന്ന് വേർതിരിച്ച സ്റ്റേറ്റ് മെഷീനുകൾ ഒത്തുചേർക്കണം: റൂട്ട് പട്ടിക, IKE, IPsec സുരക്ഷാ അസോസിയേഷനുകൾ, കണക്ഷൻ പട്ടിക. ഓരോന്നും മറ്റുള്ളവയേക്കാൾ പിന്നിലാകാം, ആ കാലതാമസത്തെയാണ് മിക്ക ആളുകളും തിരികെ വരാത്ത ടണൽ എന്ന് വിളിക്കുന്നത്.
failback യഥാർത്ഥത്തിൽ എന്താണ് മാറ്റുന്നത്
റൂട്ട് തിരയൽ കാണാവുന്ന ഭാഗമാണ്. നിരീക്ഷിക്കുന്ന ഒബ്ജക്ട് കരകയറുമ്പോൾ peer-ന്റെ പുറം വിലാസത്തിലേക്കുള്ള നിരീക്ഷിത റൂട്ട് തിരികെ വരുന്നു, ASA അയക്കുന്ന അടുത്ത പാക്കറ്റ് വീണ്ടും പ്രാഥമിക ലിങ്കിലൂടെ പോകുന്നു. അതിനുശേഷമുള്ളതെല്ലാം നിലവിലുള്ള അവസ്ഥ പുതിയ പാതയുമായി ഒത്തുപോകുന്നുണ്ടോ എന്നതിനെ ആശ്രയിച്ചിരിക്കുന്നു.
ARP, NAT എന്നിവ നിശബ്ദ ആശ്രിതത്വങ്ങളാണ്. പുതിയ next hop-ന് പരിഹരിക്കാവുന്ന ഗേറ്റ്‌വേയും ദൂരെയുള്ള അറ്റവുമായി ഇപ്പോഴും ഒത്തുപോകുന്ന വിവർത്തനവും വേണം, അല്ലാത്തപക്ഷം failback-ന് ശേഷമുള്ള ആദ്യ പാക്കറ്റുകൾ എങ്ങോട്ടും പോകുന്നില്ല, ഒന്നും പ്രവർത്തിക്കാതിരിക്കേ റൂട്ട് കുഴപ്പമില്ലെന്ന് തോന്നും.
ഒരേ സമയരേഖയിൽ നാല് കാഴ്ചകൾ
മാറ്റത്തിന് മുമ്പും ഇടയിലും ശേഷവും അതേ നാല് കാര്യങ്ങൾ രേഖപ്പെടുത്തുക, കാരണം ഒരു സ്നാപ്പ്ഷോട്ടിന് ഏത് ലേയർ നീങ്ങി എന്ന് പറയാനാവില്ല.
| 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 |
ഒരിക്കലും മാറാത്ത റൂട്ടും, പഴയ കണക്ഷൻ അതിന്റെ ഫോർവേഡിംഗ് അവസ്ഥ നിലനിർത്തിയപ്പോൾ മാറിയ റൂട്ടും ഒരേ പരാതിയും തികച്ചും വ്യത്യസ്തമായ തെളിവും നൽകുന്നു.
പഴയ കണക്ഷനുകൾ ബാക്കപ്പ് പാതയിൽ എന്തുകൊണ്ട് തുടരുന്നു
റൂട്ട് മാറിയതുകൊണ്ട് ASA ഒരു ഫ്ലോ പൊളിക്കുന്നില്ല. സ്ഥാപിത കണക്ഷനുകൾ സൃഷ്ടിക്കപ്പെട്ട ഫോർവേഡിംഗ് തീരുമാനം നിലനിർത്തുന്നു, അത് എത്രകാലം അനുവദിക്കുന്നു എന്നതിന് പ്ലാറ്റ്ഫോം വേറിട്ട നിയന്ത്രണങ്ങൾ നൽകുന്നു: floating-connection timeout, connection holddown. Cisco-യുടെ ASA 9.24 കണക്ഷൻ ക്രമീകരണ ഗൈഡ് ഇവയെ വേറിട്ട ചോദ്യങ്ങളായി കാണുന്നു, അവയുടെ പെരുമാറ്റവും കൃത്യം അതുതന്നെ. ഒന്ന് നിലവിലുള്ള ഫ്ലോയുടെ നിലനിൽപ്പ് നിയന്ത്രിക്കുന്നു; മറ്റൊന്ന് പുതിയ ഫ്ലോകൾക്ക് എപ്പോൾ മുൻഗണനാ പാത ഉപയോഗിക്കാമെന്ന് നിയന്ത്രിക്കുന്നു.
ഇവയിൽ ഏതെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് നിങ്ങളുടെ റിലീസിനുള്ള പ്രാബല്യത്തിലുള്ള മൂല്യങ്ങൾ വായിക്കുക. അവ കുറയ്ക്കുന്നത് ആളുകൾ ഇപ്പോഴും ഉപയോഗിക്കുന്ന സെഷനുകൾ അടയ്ക്കുന്നു. കൂട്ടുന്നത് failback ഒരിക്കലും സംഭവിക്കാത്തതുപോലെ തോന്നിപ്പിക്കുന്നു, കാരണം പുതിയ കണക്ഷനുകൾ ആ സമയമത്രയും പഴയ പാതയിലൂടെ പോകുന്നു.
റൂട്ട് തിരികെ വന്നതുകൊണ്ട് ടണൽ വീണ്ടും കീ ഉണ്ടാക്കുന്നില്ല
IPsec സുരക്ഷാ അസോസിയേഷനുകൾ സ്വന്തം ചർച്ച ചെയ്ത ആയുസ്സ് വഹിക്കുന്നു, അവയെ കൊണ്ടുപോയ റൂട്ട് മാറ്റത്തെ അതിജീവിക്കുന്നു. അതിനാൽ ടണൽ failback-നിടയിൽ ഉയർന്നുനിൽക്കാം, അതിന്റെ പുറം വിലാസീകരണം ഉപയോഗിക്കുന്ന പാതയുമായി ഇനി ഒത്തുപോകുന്നില്ലെങ്കിലും; ഇതാണ് DPD-യ്ക്കും peer വിലാസം ഒഴുകാൻ വിടാതെ ഉറപ്പിക്കുന്ന രൂപകൽപ്പനകൾക്കും ഉള്ള വാദം.
crypto-map, VTI രൂപകൽപ്പനകൾ ഇവിടെ വ്യത്യസ്തമായി പെരുമാറുന്നു, കൂടാതെ Cisco-യുടെ 9.24 VTI രേഖകൾ റൂട്ട് അധിഷ്ഠിത ഓപ്ഷൻ വിവരിക്കുന്നു. ASA-യ്ക്ക് റൂട്ട് അധിഷ്ഠിത VPN-കൾ ഓടിക്കാനാവില്ല എന്ന പഴയ പൊതുവായ വാദം പിന്തുണയുള്ള റിലീസുകൾക്ക് ശരിയല്ല.
തെളിവുകൾ ഈ ക്രമത്തിൽ വായിക്കുക
കൺട്രോൾ പ്ലെയ്നിൽ തുടങ്ങുക: തിരഞ്ഞെടുത്ത പാതയ്ക്ക് show route, ലിങ്ക് അവസ്ഥയ്ക്ക് show interface, നിരീക്ഷിത ഒബ്ജക്ടിന് SLA മോണിറ്ററിന്റെ കൗണ്ടറുകൾ. തുടർന്ന് ഏത് peer സജീവമാണെന്ന് കാണാൻ show crypto ikev2 sa, അല്ലെങ്കിൽ IKEv1-ന്റെ തത്തുല്യം വായിക്കുക, പിന്നീട് സംരക്ഷിത ഫ്ലോകൾക്ക് show crypto ipsec sa. അതിനുശേഷം show conn address <host> ഉപയോഗിച്ച് കണക്ഷൻ പട്ടിക ചുരുക്കി പഴയതും പുതിയതുമായ എൻട്രികളിൽ ഇന്റർഫേസ് കോളം താരതമ്യം ചെയ്യുക. ഔട്ട്പുട്ടുകൾ സമയമുദ്രകളോടെ എഴുതിവയ്ക്കുക, കാരണം അവയുടെ ക്രമമാണ് രോഗനിർണയം.
ഒരു ആപ്പ് പരീക്ഷണത്തോടെ അവസാനിപ്പിക്കുക: മുമ്പേ ഉണ്ടായിരുന്ന ഒരു ഫ്ലോയും റൂട്ട് തിരികെ വന്നതിനുശേഷം സൃഷ്ടിച്ച മറ്റൊന്നും. പഴയ ഫ്ലോ പരാജയപ്പെടുകയും പുതിയത് പ്രവർത്തിക്കുകയും ചെയ്താൽ കണക്ഷൻ അവസ്ഥയുടെ ഒരു കഥയുണ്ട്. രണ്ടും പരാജയപ്പെട്ടാൽ ടണലോ നയമോ തെറ്റാണ്, കണക്ഷൻ പട്ടിക ശ്രദ്ധ തിരിക്കലാണ്.
ആ രേഖ മൂന്ന് ഘട്ടങ്ങളിലും ഒരേ രൂപത്തിൽ സൂക്ഷിക്കുകയും കൃത്യമായ റിലീസ് രേഖപ്പെടുത്തുകയും ചെയ്യുക. സമയരേഖ ഒരു മാറ്റത്തിലേക്ക് മാത്രം വിരൽ ചൂണ്ടിക്കൊണ്ടിരുന്നാൽ ബഗ് ID ഊഹിക്കുന്നതിന് പകരം രേഖ സപ്പോർട്ടിന് അയക്കുക.