സ്പ്ലിറ്റ് ടണൽ ഒരു പൊതു ഹോസ്റ്റിനെ ASA യുടെ NAT നിയമങ്ങളിൽ നിന്ന് ഒഴിവാക്കുന്നില്ല

സ്പ്ലിറ്റ് ടണലിംഗിനെ സാധാരണയായി കോർപ്പറേറ്റ് ട്രാഫിക് ടണലിനുള്ളിലും ബാക്കി ഇന്റർനെറ്റ് ഫയർവാളിന് പുറത്തും നിർത്താനുള്ള മാർഗമായി വിവരിക്കുന്നു. ആ വിവരണത്തിന്റെ രണ്ട് പകുതികളും ഒരേ രീതിയിൽ തെറ്റാണ്. സ്പ്ലിറ്റ് ടണലിംഗ് ക്ലയന്റ് എടുക്കുന്ന ഒരു റൂട്ട് തീരുമാനമാണ്, റൂട്ട് തീരുമാനം പാക്കറ്റ് headend-ൽ എത്തിയതിന് ശേഷം എന്ത് സംഭവിക്കുന്നു എന്നതിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല.

പൊതു വിലാസത്തിലുള്ള ഒരു പങ്കാളി സേവനം, നിങ്ങളുടെ ആസ്ഥാന വിലാസം കാണണമെന്ന് ശഠിക്കുന്നത്, ഈ കഥ തകർക്കാൻ മതി.

കെട്ടുകഥ: സ്പ്ലിറ്റ് ടണൽ ഫയർവാളിനെ വഴിയിൽ നിന്ന് ഒഴിവാക്കുന്നു

സ്വകാര്യ ശ്രേണികൾക്ക് പുറത്തുള്ള ഏത് ലക്ഷ്യവും പ്രാദേശിക ഇന്റർനെറ്റ് കണക്ഷനിൽ തന്നെ നിൽക്കുന്നു, അതിനാൽ ഫയർവാൾ അത് ഒരിക്കലും കാണുന്നില്ല, അതിന് ഒരിക്കലും നിയമം ആവശ്യമില്ല എന്നതാണ് വിശ്വാസം. ലക്ഷ്യം ടണൽ പട്ടികയിൽ ഇല്ലാത്തിടത്തോളം മാത്രമേ ഇത് ശരിയാകൂ. ഓപ്പറേറ്റർ ഒരു പൊതു ഹോസ്റ്റ് split-include ACL-ൽ ചേർക്കുന്ന നിമിഷം, ക്ലയന്റ് ആ ട്രാഫിക് ടണലിലേക്ക് അയയ്ക്കുന്നു, ASA അത് മറ്റേതെങ്കിലും ഡീക്രിപ്റ്റ് ചെയ്ത ഫ്ലോ പോലെ റൂട്ട് ചെയ്യുകയും ഫിൽട്ടർ ചെയ്യുകയും വിവർത്തനം ചെയ്യുകയും വേണം. ലക്ഷ്യ പട്ടികയല്ലാതെ ക്ലയന്റിൽ ഒന്നും മാറിയിട്ടില്ല.

ക്ലയന്റ് ഒരു റൂട്ടർ ആയില്ല. നിങ്ങൾ നൽകിയ നയം അത് പിന്തുടർന്നു.

split-include റൂട്ട് യഥാർത്ഥത്തിൽ എന്ത് ചെയ്യുന്നു

Cisco ASA റിമോട്ട് ആക്സസ് ക്രമീകരണത്തിൽ ഗ്രൂപ്പ് പോളിസി split-tunnel-policy tunnelspecified ഉം ഒരു സ്റ്റാൻഡേർഡ് ACL-നെ പേരിടുന്ന split-tunnel-network-list ഉം വഹിക്കുന്നു. ആ ACL-ലെ ഓരോ permit വരിയും ക്ലയന്റ് ടണലിലേക്ക് അയയ്ക്കേണ്ട ലക്ഷ്യമാണ്, ബാക്കിയെല്ലാം പ്രാദേശിക ഡിഫോൾട്ട് റൂട്ട് തുടർന്നും ഉപയോഗിക്കുന്നു.

ഒരു ഹോസ്റ്റ് ചേർക്കുന്നത് ഒരു വരിയാണ്, ക്ലയന്റിന് കാണാനാകുന്ന മാറ്റത്തിന്റെ ഏക ഭാഗവും അതാണ്: access-list RA-SPLIT standard permit host 203.0.113.20.

അതിന് ശേഷം ക്ലയന്റ് വീണ്ടും ബന്ധിപ്പിക്കുക. നയം കണക്ഷൻ സമയത്ത് കൈമാറ്റം ചെയ്യപ്പെടുന്നു, അതിനാൽ സ്ഥാപിത സെഷൻ പഴയ പട്ടിക നിലനിർത്തുകയും മാറ്റം ഒന്നും ചെയ്യാത്തതുപോലെ തോന്നിപ്പിക്കുകയും ചെയ്യുന്നു.

പാക്കറ്റ് ഒരേ ഇന്റർഫേസിൽ വന്ന് പോകുന്നു

ഇപ്പോൾ ഡീക്രിപ്ഷന് ശേഷമുള്ള ഫ്ലോ പിന്തുടരുക. പാക്കറ്റ് VPN ടണലിലൂടെ പുറം ഇന്റർഫേസിൽ വന്നു, അതിന്റെ ലക്ഷ്യം ഒരു പൊതു വിലാസമാണ്, റൂട്ടിംഗ് പട്ടിക അതിനെ അതേ പുറം ഇന്റർഫേസിലൂടെ ഇന്റർനെറ്റിലേക്ക് തിരികെ അയയ്ക്കുന്നു. ഒരു ഇന്റർഫേസിൽ കയറി പുറത്തുപോകുന്ന ട്രാഫിക് ASA അനുവദിച്ചില്ലെങ്കിൽ ഉപേക്ഷിക്കപ്പെടും, same-security-traffic permit intra-interface അതാണ് ചെയ്യുന്നത്. അതില്ലാതെ കണക്ഷൻ ഒരു റൂട്ടിംഗ് പ്രശ്നം പോലെ തോന്നിക്കുന്ന രീതിയിൽ പരാജയപ്പെടും, പക്ഷേ അതല്ല.

ആ ക്രമീകരണം ആഗോളമാണ്. ആവശ്യമുള്ള ഓരോ ഫ്ലോയ്ക്കും ഇത് ഹെയർപിന്നിംഗ് അനുവദിക്കുന്നു, ഈ പങ്കാളി ഹോസ്റ്റിന് മാത്രമല്ല, അതിനാൽ അത് വേഗത്തിലുള്ള പരിശോധനയിലല്ല, അവലോകനം ചെയ്ത മാറ്റത്തിൽ വരണം.

ലക്ഷ്യ-പരിമിതമായ PAT ഓപ്ഷണൽ അല്ലാത്തത് എന്തുകൊണ്ട്

ഡീക്രിപ്റ്റ് ചെയ്ത പാക്കറ്റിന്റെ ഉറവിട വിലാസം ഇപ്പോഴും ക്ലയന്റിന്റെ VPN വിലാസമാണ്, സാധാരണയായി 10.77.0.0/24 പോലുള്ള ഒരു പൂളിൽ നിന്ന്. ആ വിലാസത്തിന് പൊതു ഇന്റർനെറ്റിൽ റൂട്ട് ഇല്ല, അതിനാൽ പങ്കാളി ഒരിക്കലും മറുപടി നൽകുന്നില്ല അല്ലെങ്കിൽ എങ്ങോട്ടും മറുപടി നൽകുന്നില്ല.

വിവർത്തനം ഉറവിടം ശരിയാക്കുകയും ലക്ഷ്യം അസ്പർശമായി വിടുകയും ചെയ്യുന്നു. ഒബ്ജക്റ്റുകൾ ഇതിനകം മറ്റൊരിടത്ത് നിർവചിച്ചിരിക്കുന്നതിനാൽ, ഈ ലക്ഷ്യത്തിൽ പരിമിതപ്പെടുത്തിയ ഒരു മാനുവൽ നിയമത്തിന് ഈ രൂപമാണ്:

same-security-traffic permit intra-interface

object network RA_POOL
 subnet 10.77.0.0 255.255.255.0
object network PARTNER_HOST
 host 203.0.113.20

nat (outside,outside) source dynamic RA_POOL interface destination static PARTNER_HOST PARTNER_HOST

destination static ഭാഗം പ്രധാനമാണ്. അത് ഒഴിവാക്കിയാൽ നിയമം ഉദ്ദേശിച്ചതിലും വളരെ കൂടുതൽ ട്രാഫിക്കിന് പൊരുത്തപ്പെടാവുന്ന വിശാല വിവർത്തനമായി മാറും, ക്രമത്തിൽ മുൻപുള്ള വിശാല identity നിയമത്തിന് ഇതിനെ പൂർണ്ണമായി തോൽപ്പിക്കാനാകും. നിങ്ങളുടെ നിയമമാണ് പൊരുത്തപ്പെടുന്നത് എന്ന് അനുമാനിക്കുന്നതിന് മുമ്പ് show nat detail ഉം വിഭാഗങ്ങളുടെ ക്രമവും പരിശോധിക്കുക.

ഇന്റർഫേസ് PAT എന്നാൽ പങ്കാളി ASA യുടെ ഇന്റർഫേസ് വിലാസം കാണുന്നു എന്നുമാണ്, അത് മുകളിലേക്ക് വീണ്ടും വിവർത്തനം ചെയ്യപ്പെടാം. കരാർ ഒരു വിലാസം പേരിടുന്നുവെങ്കിൽ, ഒരു ഹോപ്പിലല്ല, ആദ്യം മുതൽ അവസാനം വരെ സ്ഥിരീകരിക്കുക.

ശരിയായ പരീക്ഷണ ലക്ഷ്യത്തോടെ അത് തെളിയിക്കുക

പൊതുവായ what-is-my-ip പേജല്ല, പങ്കാളി ഹോസ്റ്റ് തന്നെ ഉപയോഗിക്കുക. ആ പേജ് ഏതാണ്ട് ഉറപ്പായും split പട്ടികയ്ക്ക് പുറത്താണ്, അതിനാൽ അത് നിങ്ങളുടെ പ്രാദേശിക ഇന്റർനെറ്റ് വിലാസം റിപ്പോർട്ട് ചെയ്യുന്നു, ഈ വഴിയെക്കുറിച്ച് ഒന്നും പറയുന്നുമില്ല. പങ്കാളി സേവനത്തിലേക്ക് പുതിയ കണക്ഷൻ തുറന്ന് അവർ ഏത് ഉറവിടമാണ് നിരീക്ഷിച്ചതെന്ന് ചോദിക്കുക, അല്ലെങ്കിൽ packet-tracer input outside tcp 10.77.0.10 12345 203.0.113.20 443 detailed പ്രവർത്തിപ്പിച്ച് NAT, റൂട്ടിംഗ് ഘട്ടങ്ങൾ വരി വരിയായി വായിക്കുക. ക്ലയന്റിൽ നിന്നുള്ള traceroute ദുർബലമായ പരിശോധനയാണ്, കാരണം അത് ഇതിനകം സംഭവിച്ച വഴി കാണിക്കുന്നു, അത് തിരഞ്ഞെടുത്ത നയമല്ല.

തുടർന്ന് എന്ത് മാറരുതെന്ന് പരിശോധിക്കുക. ഒരു സാധാരണ വെബ്സൈറ്റ് ഇപ്പോഴും പ്രാദേശിക കണക്ഷനിൽ നിന്ന് പുറത്തുപോകണം, ടണൽ പട്ടികയിലുള്ള ഒരു സ്വകാര്യ വിഭവം ഇപ്പോഴും എത്തിച്ചേരാവുന്നതാകണം. പങ്കാളിയെ ശരിയാക്കി ഇവയിൽ ഒന്ന് തകർക്കുന്ന മാറ്റം മറ്റൊരു ബഗ്ഗാണ്.

ഈ ഡിസൈന്റെ പ്രവർത്തിക്കുന്ന പതിപ്പ് ചെറുതാണ്: split ACL-ൽ ഒരു ഹോസ്റ്റ്, ഹെയർപിൻ അനുമതി, ലക്ഷ്യ-പരിമിതമായ ഒരു PAT നിയമം. കഥയിലെ ബാക്കിയെല്ലാം കെട്ടുകഥയാണ്.