VPN ട്രാഫിക്കിനായി ASA identity NAT ഉം IOS NAT ഒഴിവാക്കലും

ഒരു ശാഖ ഒരേ Cisco ഗേറ്റ്‌വേയിൽ ഇന്റർനെറ്റ് PAT ഉം സൈറ്റ്-ടു-സൈറ്റ് VPN ഉം നടത്തുന്നു, NAT ചേർക്കുന്ന നിമിഷം VPN പ്രവർത്തനം നിർത്തുന്നു. ടണലിനുള്ളിലെ വിലാസങ്ങൾ crypto ACL സംരക്ഷിക്കുന്നതുമായി ഇനി പൊരുത്തപ്പെടുന്നില്ല, അല്ലെങ്കിൽ എതിർവശത്തിന് റൂട്ടില്ലാത്ത വിവർത്തനം ചെയ്ത വിലാസങ്ങൾ കാണുന്നു. Cisco ഇത് രണ്ടിടത്ത് പരിഹരിക്കുന്നു: ASA വിലാസത്തെ അതിലേക്കുതന്നെ മാപ്പ് ചെയ്യുന്ന NAT നിയമം തിരഞ്ഞെടുക്കുന്നു, IOS ആകട്ടെ ACL-ലെ deny വഴി ഫ്ലോയെ വിവർത്തന നിയമത്തിന് പുറത്ത് നിർത്തുന്നു. രണ്ടും യഥാർത്ഥ വിലാസങ്ങൾ നിലനിർത്തുന്നു, ഒന്നും NAT പ്രോസസ്സിംഗ് ഒഴിവാക്കുന്നില്ല.

നിയമം തിരഞ്ഞെടുക്കുന്നതിന് മുൻപ് ഫ്ലോ രേഖപ്പെടുത്തുക

നിങ്ങൾ സംരക്ഷിക്കാൻ ആഗ്രഹിക്കുന്ന ഫ്ലോ എഴുതിത്തുടങ്ങുക: പ്രാദേശിക LAN ഉറവിടം, ദൂരെയുള്ള ലക്ഷ്യം, IPsec നയം സംരക്ഷിക്കുന്ന കൃത്യമായ വിലാസ ജോടി. നിയമം തിരുത്തുന്നതിന് മുൻപ് ഇത് ചെയ്യുക, കാരണം ഏത് വർഗ്ഗീകരണമോ NAT നിയമമോ പൊരുത്തപ്പെടേണ്ടതായിരുന്നു എന്ന് ഈ കൂട്ടം കാണിക്കുന്നു.

പിന്നീട് നിങ്ങൾ ഉദ്ദേശിച്ച നിയമമല്ല, യഥാർത്ഥത്തിൽ പൊരുത്തപ്പെട്ട നിയമം കണ്ടെത്തുക. രണ്ട് പ്ലാറ്റ്‌ഫോമുകളിലും NAT ഒരു ക്രമത്തിൽ വിലയിരുത്തപ്പെടുന്നു, നിങ്ങളുടെ ഒഴിവാക്കൽ പരിശോധിക്കുന്നതിന് മുൻപ് മുൻപത്തെ നിയമം വിജയിച്ചേക്കാം. ശരിയെന്ന് തോന്നുന്ന ഒഴിവാക്കൽ മറ്റൊരു നിയമത്തോട് തോൽക്കുകയാണെങ്കിൽ പ്രതീക്ഷിത പാക്കറ്റ് ഒരിക്കലും സംരക്ഷണ നയത്തിലെത്തുന്നില്ല. ലക്ഷണം ഒഴിവാക്കൽ ഇല്ലാത്തതിന് സമാനമാണ്, അതിനാൽ കോൺഫിഗറേഷൻ മാറ്റുന്നതിന് മുൻപ് നിയമങ്ങളുടെ ക്രമം വായിക്കണം.

ASA identity NAT ഒരു നിയമമാണ്, ഒഴിവാക്കലല്ല

ASA-യിൽ identity NAT എന്നത് വിവർത്തനം ചെയ്ത വിലാസം യഥാർത്ഥ വിലാസത്തിന് തുല്യമായ NAT നിയമമാണ്. മറ്റേതൊരു നിയമം പോലെയും ഇത് തിരഞ്ഞെടുക്കപ്പെടുന്നു, ഇപ്പോഴും വിവർത്തന എൻട്രി സ്ഥാപിക്കുന്നു, അതിനാൽ പാക്കറ്റ് NAT പ്രോസസ്സിംഗ് ഒഴിവാക്കുന്നില്ല. മാറുന്നത് നെറ്റ്‌വർക്കിലെ വിലാസങ്ങൾ അതേപടി നിലനിൽക്കുന്നു എന്നതാണ്, IPsec നയത്തിന് ആവശ്യമായത് അതാണ്.

nat (inside,outside) source static LAN-NET LAN-NET destination static REMOTE-NET REMOTE-NET

നിയമത്തിന്റെ ഇന്റർഫേസുകളും അതിന്റെ route-lookup ക്രമീകരണവും ഫോർവേഡിംഗ് രൂപകൽപ്പനയുമായി പൊരുത്തപ്പെടണം. വിലാസം ശരിയായി മാപ്പ് ചെയ്യുന്നുവെങ്കിലും തെറ്റായ ഇന്റർഫേസ് ജോടിയിൽ പ്രയോഗിക്കുന്ന നിയമം നിങ്ങളുടെ ഫ്ലോയ്ക്ക് തിരഞ്ഞെടുക്കപ്പെടില്ല. വിവർത്തനം ചെയ്ത പാക്കറ്റ് റൂട്ട് ചെയ്യണോ യഥാർത്ഥ ലക്ഷ്യം ഉപയോഗിക്കണോ എന്ന് route-lookup തീരുമാനിക്കുന്നു, മടങ്ങിവരുന്ന ട്രാഫിക് ടണലിലൂടെ വരുമോ എന്നും അത് തീരുമാനിക്കുന്നു.

ASA-യിലേക്കുള്ള മാനേജ്മെന്റ് പ്രവേശനം വേറിട്ട കേസാണ്. മാനേജ്മെന്റ് ട്രാഫിക്കിന് identity NAT ഉപയോഗിക്കുന്നുവെങ്കിൽ റിലീസ് അനുസരിച്ചുള്ള route-lookup ആവശ്യകത ബാധകമാണ്, VPN ഉദാഹരണത്തിൽ നിന്ന് പകർത്തിയ വിശാലമായ ഒഴിവാക്കൽ SSH ശരിയാക്കില്ല.

IOS NAT ACL-ലെ deny എന്നാൽ ഇവിടെ തിരഞ്ഞെടുക്കപ്പെട്ടില്ല

IOS-ൽ ഇന്റർനെറ്റ് NAT ഉറവിട പട്ടികയാൽ നിയന്ത്രിക്കപ്പെടുന്നു, ആ ACL ഫിൽട്ടറല്ല, വർഗ്ഗീകരണമാണ്. Permit വരി വിവർത്തനത്തിന് ട്രാഫിക് തിരഞ്ഞെടുക്കുന്നു; deny വരി പാക്കറ്റ് ഇവിടെ തിരഞ്ഞെടുക്കപ്പെട്ടില്ല എന്നർത്ഥം. ആ deny ഇന്റർഫേസ് ACL-ലെ deny പോലെ പാക്കറ്റ് ഉപേക്ഷിക്കാനുള്ള നിർദ്ദേശമല്ല.

ഇവിടെ തിരഞ്ഞെടുക്കപ്പെട്ടില്ല എന്നത് എവിടെയും വിവർത്തനം ചെയ്യപ്പെടുന്നില്ല എന്നതിനേക്കാൾ ഇടുങ്ങിയതുമാണ്. മറ്റൊരു NAT നിയമം, മറ്റൊരു ഇന്റർഫേസ് അല്ലെങ്കിൽ route-map ഇപ്പോഴും ഫ്ലോ വിവർത്തനം ചെയ്തേക്കാം, അതിനാൽ മുഴുവൻ NAT പട്ടികയും വായിക്കണം. പാക്കറ്റിന് ഇപ്പോഴും റൂട്ട്, പൊരുത്തപ്പെടുന്ന crypto ACL, യഥാർത്ഥ ആക്സസ്-കൺട്രോൾ അതിർത്തികളിൽ അനുമതി എന്നിവ വേണം.

ഏറ്റവും ചെറിയ IOS ക്രമീകരണം deny ഒരേ പട്ടികയിൽ permit-ന് മുകളിൽ വയ്ക്കുന്നു, overload നിയമം ആ പട്ടികയിലേക്ക് തിരിക്കുന്നു. അപ്പോൾ crypto ACL deny വിവർത്തനത്തിൽ നിന്ന് ഒഴിവാക്കുന്ന അതേ ജോടിയെ സംരക്ഷിക്കുന്നു.

ip access-list extended NAT-ACL
 deny ip 10.10.0.0 0.0.0.255 192.0.2.0 0.0.0.255
 permit ip 10.10.0.0 0.0.0.255 any
ip nat inside source list NAT-ACL interface GigabitEthernet0/1 overload

രണ്ട് മോഡലുകൾക്കുമുള്ള ഒരു പരിശോധിക്കാവുന്ന ചോദ്യം

രണ്ട് മോഡലുകളും ഒരേ ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു: ഏത് നിയമമാണ് ഈ ഫ്ലോയുമായി പൊരുത്തപ്പെട്ടത്, ഏത് വിലാസങ്ങളാണ് ഇന്റർഫേസ് വിട്ടത്? പുറം ഇന്റർഫേസിൽ ക്യാപ്ചർ ചെയ്ത് ഗേറ്റ്‌വേയ്ക്ക് മുൻപും ശേഷവുമുള്ള ഉറവിട വിലാസം താരതമ്യം ചെയ്യുക. പിന്നീട് ടണലിനെക്കുറിച്ചുള്ള എതിർവശത്തിന്റെ കാഴ്ച പരിശോധിക്കുക, കാരണം SA ഉയർന്നിരിക്കുമ്പോൾ സംരക്ഷിത ഫ്ലോ മറ്റെവിടെയോ വിവർത്തനം ചെയ്യപ്പെടാം.

ASA-യിൽ nat detail ഉം വിവർത്തന പട്ടികയും കാണിക്കുക; IOS-ൽ ip nat translations ഉം ബന്ധപ്പെട്ട ACL കൗണ്ടറുകളും കാണിക്കുക. ഒരിക്കലും കൂടാത്ത നിയമം ഒരിക്കലും തിരഞ്ഞെടുക്കപ്പെട്ടിട്ടില്ല, അത് crypto കോൺഫിഗറേഷനല്ല, ക്രമം, ഇന്റർഫേസ് അല്ലെങ്കിൽ ദിശയെ സൂചിപ്പിക്കുന്നു.

കോൺഫിഗറേഷൻ സാധാരണയായി എവിടെ തെറ്റുന്നു

സാധാരണ പരാജയങ്ങൾ യാന്ത്രികമാണ്. deny permit-ന്റെ താഴെയാണ്, ഒരിക്കലും പൊരുത്തപ്പെടുന്നില്ല. വർഗ്ഗീകരണം തെറ്റായ ദിശയിൽ പ്രയോഗിക്കുന്നു, അതിനാൽ മടങ്ങിവരുന്ന ഫ്ലോ വിവർത്തനം ചെയ്യപ്പെടുന്നു. Identity നിയമം ശരിയായ വിലാസങ്ങളെ എന്നാൽ തെറ്റായ ഇന്റർഫേസ് ജോടിയെ ഉൾക്കൊള്ളുന്നു. NAT നിയമം അവതരിപ്പിക്കുന്നതുമായി ഇനി പൊരുത്തപ്പെടാത്ത സബ്‌നെറ്റ് crypto ACL സംരക്ഷിക്കുന്നു.

യഥാർത്ഥവും അവതരിപ്പിച്ചതുമായ വിലാസ ജോടി നിയമത്തിന്റെ ഉടമയുടെ അടുത്ത് രേഖപ്പെടുത്തുക, അടുത്ത എൻജിനീയർക്ക് വർഗ്ഗീകരണം എന്തുകൊണ്ട് വിവർത്തനം നിരസിക്കുന്നു എന്നും ഫയർവാൾ ആപ്ലിക്കേഷനെ അനുവദിക്കുന്നു എന്നും കാണാൻ. അത് വ്യക്തിപരമായ കുറിപ്പിലല്ല, മാറ്റ ടിക്കറ്റിൽ സൂക്ഷിക്കുക. പിന്നീട് ഏതൊരു NAT മാറ്റത്തിനും ശേഷം ഫ്ലോ വീണ്ടും ഓടിക്കുക, കാരണം നിയമത്തിന്റെ പാഠം മാറാതിരുന്നാലും നിയമങ്ങളുടെ ക്രമം കോൺഫിഗറേഷന്റെ ഭാഗമാണ്. ഉയരുന്ന ടണൽ വിലാസങ്ങൾ അതിജീവിച്ചു എന്നതിന്റെ തെളിവല്ല; ക്യാപ്ചർ ചെയ്ത പാക്കറ്റും എതിർവശത്തിന്റെ ഡീകാപ്സുലേഷനു ശേഷമുള്ള കാഴ്ചയും മാത്രമാണ് തെളിവ്.