Cisco ASA ടണൽ ഡിഫോൾട്ട് റൂട്ട്: എപ്പോഴാണ് അത് യഥാർത്ഥത്തിൽ ബാധകമാകുന്നത്

റിമോട്ട് ആക്സസ് ഉപയോക്താവിന് ASA-യുടെ അപ്പുറം ഒന്നും എത്താൻ കഴിയുന്നില്ല, അതേസമയം അതേ സെർവർ അകത്തെ LAN-ൽ നിന്നുള്ള പിംഗുകൾക്ക് ഉത്തരം നൽകുന്നു. ടണൽ ഉയരുന്നു, ക്ലയന്റിന് പൂളിൽ നിന്ന് ഒരു വിലാസം ലഭിക്കുന്നു, എന്നിട്ടും പാക്കറ്റ് ഇന്റർനെറ്റ് ഡിഫോൾട്ട് വഴി തന്നെ പുറത്തുപോകുന്നു അല്ലെങ്കിൽ അപ്രത്യക്ഷമാകുന്നു. ഈ മാതൃക സാധാരണയായി അർത്ഥമാക്കുന്നത് ഡീക്രിപ്റ്റ് ചെയ്ത ട്രാഫിക്കിന് സ്വന്തം റൂട്ട് കണ്ടെത്താനായില്ല, സാധാരണ ഡിഫോൾട്ടിലേക്ക് വീണു എന്നാണ്. പരിഹാരം മറ്റൊരു NAT നിയമമല്ല; പരിഹാരം ടണൽ ഡിഫോൾട്ട് ആണ്.

കോൺഫിഗറേഷനിൽ നിന്നല്ല, ലക്ഷണത്തിൽ നിന്ന് തുടങ്ങുക

പാക്കറ്റ് എവിടെ പോകുന്നു എന്ന് നോക്കുക, എവിടെ പോകുമെന്ന് നിങ്ങൾ പ്രതീക്ഷിച്ചു എന്നല്ല. പരാജയപ്പെട്ട സെഷനിൽ പുറം ഇന്റർഫേസിൽ എടുത്ത ക്യാപ്ചർ, ഡീക്രിപ്റ്റ് ചെയ്ത പാക്കറ്റ് പൂൾ വിലാസം കേടുകൂടാതെ ISP ഗേറ്റ്‌വേയിലേക്ക് പോകുന്നത് കാണിക്കുന്നു, അല്ലെങ്കിൽ തിരച്ചിൽ പരാജയപ്പെട്ടതിനാൽ ഒന്നും കാണിക്കുന്നില്ല. രണ്ട് സാഹചര്യങ്ങളിലും ടണൽ പ്രശ്നമല്ല.

show vpn-sessiondb-യിൽ ടണൽ ആരോഗ്യകരമായി കാണുന്നു, അതുകൊണ്ടാണ് ആളുകൾ IKE ഡീബഗ് ചെയ്തുകൊണ്ടിരിക്കുന്നത്.

ACL ഡ്രോപ്പിൽ നിന്ന് ഇതിനെ വേർതിരിക്കുന്നത് ദിശയാണ്. ACL ഡ്രോപ്പ് ലോഗ് ചെയ്യപ്പെടുകയും എണ്ണപ്പെടുകയും ചെയ്യുന്നു, എന്നാൽ കാണാത്ത റൂട്ട് പൊരുത്തമുള്ള എൻട്രി ഇല്ലാതെ തിരച്ചിൽ പരാജയം ഉണ്ടാക്കുന്നു. ക്ലയന്റിന്റെ ലക്ഷ്യത്തിനായി show route പ്രവർത്തിപ്പിച്ച് ASA യഥാർത്ഥത്തിൽ എന്താണ് തിരഞ്ഞെടുത്തത് എന്ന് വായിക്കുക, ഒരു ഡിഫോൾട്ട് തിരഞ്ഞെടുത്തോ ഏതാണ് തിരഞ്ഞെടുത്തത് എന്നതും ഉൾപ്പെടെ.

ടണൽ തിരച്ചിൽ എങ്ങനെ വ്യത്യസ്തമാണ്

Cisco-യുടെ ASA 9.23 സ്റ്റാറ്റിക് റൂട്ടിംഗ് ഗൈഡ് സ്റ്റാറ്റിക് അല്ലെങ്കിൽ പഠിച്ച റൂട്ട് ഇല്ലാത്ത ഡീക്രിപ്റ്റ് ചെയ്ത VPN ട്രാഫിക്കിനായി ഒരു പ്രത്യേക ഡിഫോൾട്ട് രേഖപ്പെടുത്തുന്നു. tunneled കീവേഡ് ആ റൂട്ടിനെ അടയാളപ്പെടുത്തുന്നു, അതിനാൽ ഡീക്രിപ്റ്റ് ചെയ്ത പാക്കറ്റിന് ASA സ്വന്തം ട്രാൻസ്പോർട്ടിന് ഉപയോഗിക്കുന്ന അടുത്ത ഹോപ്പിൽ നിന്ന് വ്യത്യസ്തമായ ഒന്നിലേക്ക് പിൻവാങ്ങാം. കൂടുതൽ നിർദ്ദിഷ്ട റൂട്ടുകൾ ഇപ്പോഴും വിജയിക്കുന്നു, അതുകൊണ്ടാണ് ഒരു ക്ലയന്റിന് ആന്തരിക ഗേറ്റ്‌വേ വഴി 10.0.0.0/8 ലേക്ക് എത്താനും ബാക്കിയെല്ലാം നഷ്ടപ്പെടാനും കഴിയുന്നത്.

ഏറ്റവും കുറഞ്ഞ ലേഔട്ട് വ്യത്യസ്ത അടുത്ത ഹോപ്പുകളുള്ള രണ്ട് ഡിഫോൾട്ടുകൾ സൂക്ഷിക്കുന്നു. ഒന്ന് ASA-യുടെ സ്വന്തം ട്രാഫിക് കൊണ്ടുപോകുന്നു, മറ്റൊന്ന് മികച്ച റൂട്ട് ഇല്ലാത്ത ഡീക്രിപ്റ്റ് ചെയ്ത ട്രാഫിക് കൊണ്ടുപോകുന്നു. രണ്ട് അടുത്ത ഹോപ്പുകളും നിങ്ങൾ അവ ബന്ധിപ്പിക്കുന്ന ഇന്റർഫേസിൽ നിന്ന് എത്താവുന്നതായിരിക്കണം.

route outside 0.0.0.0 0.0.0.0 198.51.100.1
route outside 0.0.0.0 0.0.0.0 10.20.30.1 tunneled

രണ്ട് ഡിഫോൾട്ടുകളും ഒരേ അടുത്ത ഹോപ്പിലേക്ക് ചൂണ്ടിക്കാണിച്ചാൽ, കീവേഡ് ഒന്നും മാറ്റുന്നില്ല, ലക്ഷണവും നീങ്ങില്ല.

അത് പ്രവർത്തിക്കുമോ എന്ന് തീരുമാനിക്കുന്ന നിയന്ത്രണങ്ങൾ

അതേ ഗൈഡ് ഒരു ടണൽ ഡിഫോൾട്ടിന് മാത്രം അനുവാദം നൽകുന്നു, അതിന് ECMP പിന്തുണയ്ക്കുന്നില്ലെന്ന് പറയുന്നു, അതിനാൽ ആ പാതയിൽ ലോഡ് ഷെയർ ചെയ്യാൻ കഴിയില്ല. റൂട്ട് ട്രാക്കിംഗ്, റിവേഴ്സ് പാത്ത് വെരിഫിക്കേഷൻ, ചില ഇൻസ്പെക്ഷൻ, മാനേജ്മെന്റ് ഫ്ലോകൾ എന്നിവയുമായി ബന്ധപ്പെട്ട നിയന്ത്രണങ്ങളും അത് പട്ടികപ്പെടുത്തുന്നു. ഈ ഫീച്ചറിനെ ചുറ്റിപ്പറ്റി രൂപകൽപ്പന ചെയ്യുന്നതിന് മുമ്പ് ഇൻസ്റ്റാൾ ചെയ്ത റിലീസിന് എതിരായി അവ വായിക്കുക. അവ അവഗണിക്കുന്ന രൂപകൽപ്പന സാധാരണയായി എല്ലായിടത്തുമല്ല, ഒരു പ്രത്യേക സ്ഥലത്ത് പരാജയപ്പെടുന്നു, അതുകൊണ്ടാണ് ലക്ഷണം ഇടവിട്ട് വരുന്നതായി തോന്നുന്നത്.

അസമമായ രൂപകൽപ്പനകളിൽ കടിക്കുന്നത് റിവേഴ്സ് പാത്ത് വെരിഫിക്കേഷനാണ്. ASA പ്രതീക്ഷിക്കുന്നതിൽ നിന്ന് വ്യത്യസ്തമായ ഇന്റർഫേസിലൂടെയാണ് മറുപടി വരുന്നതെങ്കിൽ, റൂട്ടിംഗ് പ്രധാനമാകുന്നതിന് മുമ്പ് തന്നെ പാക്കറ്റ് ഉപേക്ഷിക്കപ്പെടുന്നു. വെരിഫിക്കേഷൻ ഓഫ് ചെയ്ത് അടുത്ത ഹോപ്പ് നിർബന്ധിക്കുന്നതിന് പകരം ടോപ്പോളജി അല്ലെങ്കിൽ മടക്ക പാത ശരിയാക്കുക.

റൂട്ട് ട്രാക്കിംഗ് വേറിട്ട ഒരു കെണിയാണ്: ട്രാക്ക് ചെയ്യപ്പെടുന്ന ഒബ്ജക്റ്റ് സാധാരണയായി സാധാരണ ഡിഫോൾട്ടിനെ കാത്തുരക്ഷിക്കുന്നു, ടണൽ ഡിഫോൾട്ടിനെയല്ല.

കീവേഡ് എന്ത് ചെയ്യുന്നില്ല

ASA IKE നിർമ്മിക്കാൻ ഉപയോഗിക്കുന്ന സോഴ്സ് വിലാസം അത് തിരഞ്ഞെടുക്കുന്നില്ല. ടണലിന്റെ പുറം എൻഡ്‌പോയിന്റ് പ്ലാറ്റ്ഫോമിന്റെ സ്വന്തം ഇന്റർഫേസ്, സോഴ്സ് തിരഞ്ഞെടുപ്പ് എന്നിവ പിന്തുടരുന്നു, ആ തീരുമാനത്തിൽ ടണൽ ഡിഫോൾട്ടിന് പങ്കില്ല. അത് മാറ്റുന്നത് തെറ്റായ വിലാസത്തിൽ നിന്ന് തുടങ്ങുന്ന phase 1 ശരിയാക്കില്ല.

അടുത്ത ഹോപ്പിനെ അത് പ്രോക്സിയാക്കി മാറ്റുന്നുമില്ല. ലക്ഷ്യം HTTP CONNECT കൈമാറ്റം പ്രതീക്ഷിക്കുന്നുവെങ്കിൽ, പ്രോക്സി ഹോസ്റ്റിലേക്ക് അസംസ്കൃത IP പാക്കറ്റുകൾ അയയ്ക്കുന്നത് അവ റൂട്ട് ചെയ്യാത്ത ഒരു ഹോസ്റ്റ് മാത്രം നൽകുന്നു. പകരം ക്ലയന്റ് പിന്തുണയ്ക്കുന്ന പ്രോക്സി സംവിധാനം കോൺഫിഗർ ചെയ്യുക.

കൂടാതെ അത് താഴേക്കുള്ള ഫോർവേഡിംഗ് സൃഷ്ടിക്കുന്നുമില്ല. നിങ്ങൾ ചൂണ്ടിക്കാണിക്കുന്ന ഗേറ്റ്‌വേയ്ക്ക് ഇപ്പോഴും VPN പൂളിലേക്ക് ഒരു മടക്ക റൂട്ട് വേണം, ഒപ്പം രൂപകൽപ്പന ആവശ്യപ്പെടുന്നിടത്ത് സോഴ്സ് വിവർത്തനവും വേണം.

പാത ആദ്യം മുതൽ അവസാനം വരെ പരിശോധിക്കുക

റൂട്ട് സ്ഥാപിച്ച ശേഷം നാല് കാര്യങ്ങൾ ക്രമത്തിൽ പരിശോധിക്കുക: പൂളിന് ആവശ്യമായ ഒരു ലക്ഷ്യത്തിനായി show route, പുതിയ അടുത്ത ഹോപ്പിലേക്കുള്ള ഇന്റർഫേസിൽ ഒരു ക്യാപ്ചർ, ഗേറ്റ്‌വേയിൽ തന്നെ ഒരു ക്യാപ്ചർ, ആ ഗേറ്റ്‌വേയിൽ നിന്ന് പൂൾ വിലാസത്തിലേക്കുള്ള മടക്ക പാത. ആദ്യ രണ്ടെണ്ണം ASA ആ പാത തിരഞ്ഞെടുത്തു എന്ന് തെളിയിക്കുന്നു, അവസാന രണ്ടെണ്ണം അവിടെ ആരോ ഉത്തരം നൽകുന്നു എന്ന് തെളിയിക്കുന്നു.

ഗേറ്റ്‌വേ ഉത്തരം നൽകുന്നുവെങ്കിലും ക്ലയന്റ് ഒരിക്കലും മറുപടി കാണുന്നില്ലെങ്കിൽ, റൂട്ട് ടേബിളിൽ വീണ്ടും തൊടുന്നതിന് മുമ്പ് സോഴ്സ് വിവർത്തനവും മടക്ക റൂട്ടും നോക്കുക.

നിങ്ങൾ പരിശോധിച്ച റിലീസ് രേഖപ്പെടുത്തുക, കാരണം നിയന്ത്രണങ്ങളുടെ പട്ടിക പതിപ്പ് അനുസരിച്ച് വ്യത്യാസപ്പെടുന്നു, ഒരു ട്രെയിനിൽ പ്രവർത്തിക്കുന്ന രൂപകൽപ്പനയ്ക്ക് മറ്റൊന്നിൽ വേറെ പാത ആവശ്യമായി വന്നേക്കാം. ആ കുറിപ്പ് കോൺഫിഗ് സ്നിപ്പറ്റിനേക്കാൾ അധികകാലം ജീവിക്കുന്നു.