AWS NAT ഗേറ്റ്വേയിലൂടെ GRE ഉം ESP ഉം പരാജയപ്പെടുന്നതെന്തുകൊണ്ട്

ടണൽ പരാജയപ്പെടുന്നു, സുരക്ഷാ ഗ്രൂപ്പ് ഇതിനകം എല്ലാ ട്രാഫിക്കും അനുവദിക്കുന്നു, ഒപ്പം AWS VPN ബ്ലോക്ക് ചെയ്യുന്നു എന്ന നിഗമനത്തിലെത്തുന്നു. അത് ഒന്നും ബ്ലോക്ക് ചെയ്യുന്നില്ല. നിയന്ത്രിത NAT ഗേറ്റ്വേ രേഖപ്പെടുത്തിയ ബാഹ്യ പ്രോട്ടോക്കോളുകളുടെ ഒരു കൂട്ടം കൈമാറുന്നു, സ്വദേശീയ GRE അല്ലെങ്കിൽ സ്വദേശീയ ESP അതിലില്ല, അതിനാൽ നിങ്ങൾ ചേർക്കുന്ന ഒരു നിയമവും ഗേറ്റ്വേയെ അവ കൈമാറാൻ പ്രേരിപ്പിക്കില്ല. അനുമതി നിയമവും കൈമാറ്റ ശേഷിയും രണ്ട് വ്യത്യസ്ത കാര്യങ്ങളാണ്, അവയിൽ ഒന്ന് മാത്രമാണ് നിങ്ങൾക്ക് മാറ്റാനാകുന്നത്.

നിയമങ്ങളുടെ കൂട്ടം പ്രോട്ടോക്കോളുകളുടെ കൂട്ടമല്ല

സുരക്ഷാ ഗ്രൂപ്പ് ഏത് ട്രാഫിക്കിന് ഇൻസ്റ്റൻസ് വിടാൻ അനുമതിയുണ്ടെന്ന് തീരുമാനിക്കുന്നു. NAT ഗേറ്റ്വേ എന്ത് വിവർത്തനം ചെയ്ത് കൈമാറാൻ കഴിയുമെന്ന് തീരുമാനിക്കുന്നു. രണ്ടാമത്തെ പരിധി ബാധകമാകുമ്പോൾ, അനുവദനീയമായ നിയമം ആളുകൾ ഫയർവാൾ പ്രശ്നമായി തെറ്റായി വായിക്കുന്ന ലക്ഷണം കൃത്യമായി സൃഷ്ടിക്കുന്നു: പാക്കറ്റുകൾ ഇൻസ്റ്റൻസ് വിടുന്നു, നിയന്ത്രണ കൈമാറ്റം പൂർത്തിയാകാം, ഒപ്പം ഇണയിലേക്ക് ഒന്നും എത്തുന്നില്ല.

AWS NAT ഗേറ്റ്വേ പ്രോട്ടോക്കോൾ സ്പെസിഫിക്കേഷൻ നിയന്ത്രിത സേവനത്തിനായി TCP, UDP, ICMP എന്നിവ പട്ടികപ്പെടുത്തുന്നു. അതാണ് പൂർണ്ണ പിന്തുണയുള്ള കൂട്ടം. മറ്റൊരു IP പ്രോട്ടോക്കോളിനുള്ള അനുമതി നിയമത്തിന് അത് വിപുലീകരിക്കാൻ കഴിയില്ല, കാരണം ഗേറ്റ്വേയുടെ കൈമാറ്റ പാതയിൽ എത്തുന്നതിന് വളരെ മുമ്പേ നിയമം വിലയിരുത്തപ്പെടുന്നു.

ഈ വ്യത്യാസം പ്രധാനമാണ്, കാരണം രണ്ട് പരാജയങ്ങളും ക്ലയന്റിന്റെ വശത്തുനിന്ന് ഒരേപോലെ കാണപ്പെടുന്നു, പരിഹാരങ്ങൾ തികച്ചും വ്യത്യസ്തമാണ്.

PPTP പോർട്ട് പരിശോധന എന്തുകൊണ്ട് കള്ളം പറയുന്നുവെന്ന് കാണിക്കുന്നു

ഒന്നും തെളിയിക്കാത്ത പോർട്ട് പരിശോധനയുടെ ഏറ്റവും വ്യക്തമായ പഴയ ഉദാഹരണമാണ് PPTP. അത് 1723 പോർട്ടിൽ TCP നിയന്ത്രണ ബന്ധം തുറന്ന്, തുടർന്ന് ടണൽ ഡാറ്റ GRE-യിലൂടെ കൈമാറുന്നു, അത് IP പ്രോട്ടോക്കോൾ 47 ആണ്. പ്രോട്ടോക്കോൾ 47 TCP പോർട്ട് 47 അല്ല, ഈ രണ്ട് സംഖ്യകൾക്കും അക്കങ്ങൾ പങ്കിടുന്നതല്ലാതെ പരസ്പരം ബന്ധമില്ല.

1723-ലേക്കുള്ള കണക്റ്റിവിറ്റി പരിശോധിച്ച് പൂർത്തിയായ ഹാൻഡ്ഷേക്ക് കാണുന്ന ഓപ്പറേറ്റർ പാത പ്രവർത്തിക്കുന്നുവെന്ന് അനുമാനിക്കുന്നു. തുടർന്ന് ഡാറ്റ ചാനൽ ഒരു പാക്കറ്റുപോലും കടക്കുന്നില്ല, കാരണം ഗേറ്റ്വേയ്ക്ക് നൽകാൻ GRE പിന്തുണയില്ല. ഇത് പഴയ പ്രോട്ടോക്കോളിന്റെ ആവശ്യകതകളുടെ വ്യാഖ്യാനമാണ്, വർഷങ്ങളായി കാലഹരണപ്പെട്ട PPTP വിന്യസിക്കാനുള്ള ഉപദേശമല്ല.

നിയന്ത്രണ ചാനൽ TCP അല്ലെങ്കിൽ UDP ആയിരിക്കുകയും ഡാറ്റ പാത അങ്ങനെയല്ലാതിരിക്കുകയും ചെയ്യുന്ന ഏത് പ്രോട്ടോക്കോളിനും ഇതേ യുക്തി ബാധകമാണ്.

IPsec UDP ആയി മാത്രം അതിജീവിക്കുന്നു

IPsec എന്നത് ഉത്തരം വ്യക്തമായ ഇല്ല എന്നതല്ല, സോപാധികമായിരിക്കുന്ന സന്ദർഭമാണ്. NAT ഗേറ്റ്വേയിലൂടെയുള്ള IPsec-ന് NAT ട്രാവേഴ്സൽ പിന്തുണയുള്ള ക്രമീകരണമായി AWS രേഖപ്പെടുത്തുന്നു. NAT-T ചർച്ച ചെയ്താൽ ESP UDP-യ്ക്കുള്ളിൽ എൻകാപ്സുലേറ്റ് ചെയ്യപ്പെടുന്നു, ഗേറ്റ്വേ പ്രോട്ടോക്കോൾ 50-ന് പകരം സാധാരണ UDP കാണുന്നു.

UDP 4500 അനുവദിക്കുന്നത് എൻഡ്പോയിന്റുകളെ NAT ട്രാവേഴ്സൽ ഉപയോഗിക്കാൻ പ്രേരിപ്പിക്കുന്നില്ല. പാക്കറ്റുകൾ ഇതിനകം ആ രൂപത്തിലാണെങ്കിൽ മാത്രം അത് അനുവദിക്കുന്നു. ക്ലയന്റിന്റെ സ്വന്തം ചർച്ചാ ഔട്ട്പുട്ടിൽനിന്ന് ഏത് എൻകാപ്സുലേഷൻ തിരഞ്ഞെടുത്തുവെന്ന് സ്ഥിരീകരിക്കുക, സ്വീകരിക്കുന്ന വശത്ത് ഇണ അത് സ്വീകരിച്ചുവെന്ന് സ്ഥിരീകരിക്കുക. സ്വദേശീയ ESP-നായി കോൺഫിഗർ ചെയ്ത രണ്ട് എൻഡ്പോയിന്റുകൾ നിയമക്കൂട്ടം എന്തുപറഞ്ഞാലും സ്വദേശീയ ESP അയയ്ക്കുന്നത് തുടരും.

TCP അല്ലെങ്കിൽ UDP അടിസ്ഥാനമാക്കിയ VPN രേഖപ്പെടുത്തിയ കൈമാറ്റ കൂട്ടത്തിൽ ഇണങ്ങുന്നു, എന്നിട്ടും റൂട്ടിംഗ്, ഫിൽട്ടറിംഗ് അല്ലെങ്കിൽ പ്രാമാണീകരണ കാരണങ്ങളാൽ പരാജയപ്പെടാം. കൂട്ടത്തിൽ ഇണങ്ങുന്നത് ആവശ്യമാണ്, പര്യാപ്തമല്ല.

നയം വിപുലീകരിക്കുന്നതിന് മുമ്പ് പാത പരിശോധിക്കുക

വർക്ക്ലോഡ് സബ്നെറ്റിന്റെ യഥാർത്ഥ റൂട്ടും അതിന്റെ അടുത്ത ഹോപ്പിന്റെ ഐഡന്റിറ്റിയും ആദ്യം പരിശോധിക്കുക. നേരിട്ടുള്ള പൊതു പാത, ഒരു NAT ഇൻസ്റ്റൻസ്, നിയന്ത്രിത NAT ഗേറ്റ്വേ, ട്രാൻസിറ്റ് ഗേറ്റ്വേയിലൂടെയുള്ള സ്വകാര്യ പാത എന്നിവ നാല് വ്യത്യസ്ത ഡിസൈനുകളാണ്, അവയിൽ ഒന്ന് മാത്രമാണ് ഇവിടെ വിവരിച്ച നിയന്ത്രിത സേവനം.

തുടർന്ന് ശ്രമിച്ച എൻഡ്പോയിന്റ്, വിലാസ കുടുംബം, ബാഹ്യ പ്രോട്ടോക്കോൾ, പ്രോട്ടോക്കോളിന് പോർട്ടുണ്ടെങ്കിൽ ആ പോർട്ട് എന്നിവ രേഖപ്പെടുത്തുക. വിജയകരമായ ബ്രൗസർ അഭ്യർത്ഥനയ്ക്ക് പകരം ക്ലയന്റിന്റെ ഡയഗ്നോസ്റ്റിക്സും നെറ്റ്വർക്ക് ഉടമയുടെ ഫ്ലോ നിരീക്ഷണങ്ങളും ഉപയോഗിക്കുക, കാരണം അത് TCP ഉം UDP ഉം പ്രവർത്തിക്കുന്നു എന്ന് മാത്രം തെളിയിക്കുന്നു. അതിനുശേഷം, ഫ്ലോയുടെ രണ്ട് ദിശകൾക്കും സുരക്ഷാ ഗ്രൂപ്പ്, സബ്നെറ്റ് ACL, ഗസ്റ്റ് ഫയർവാൾ, സേവന നയം എന്നിവ അവലോകനം ചെയ്യുക.

സേവനത്തിന് കൈമാറാൻ കഴിയാത്ത ഒരു കൈമാറ്റത്തിന് നഷ്ടപരിഹാരമായി എല്ലാ ട്രാഫിക്കും തുറക്കരുത്. നിയമ മാറ്റം അത് ശരിയാക്കില്ല, അത് സംഭവത്തെ അതിജീവിക്കും.

കൈമാറ്റം ഇണങ്ങാത്തപ്പോൾ

ബാഹ്യ പ്രോട്ടോക്കോൾ പിന്തുണയുള്ള കൂട്ടത്തിന് പുറത്താണെങ്കിൽ, പരിഹാരം വാസ്തുവിദ്യാപരമാണ്: പാതയ്ക്ക് കൈമാറാൻ കഴിയുന്ന ഒരു കൈമാറ്റം തിരഞ്ഞെടുക്കുക, അല്ലെങ്കിൽ നിങ്ങൾക്ക് ആവശ്യമുള്ളത് കൈമാറുന്ന ഒന്നിലേക്ക് എഗ്രസ് നീക്കുക. OpenVPN UDP-യിൽ, WireGuard UDP-യിൽ, TLS അടിസ്ഥാനമാക്കിയ ടണലുകൾ എന്നിവയെല്ലാം രേഖപ്പെടുത്തിയ കൂട്ടത്തിൽ ഇണങ്ങുന്നു. ഒരു നിർദ്ദിഷ്ട പ്രോട്ടോക്കോൾ കടക്കണമെന്നും അത് പ്രവർത്തിപ്പിക്കുന്ന ചെലവ് സ്വീകാര്യമാണെന്നും ഉള്ളപ്പോൾ ഉപഭോക്താവ് നിയന്ത്രിക്കുന്ന NAT ഇൻസ്റ്റൻസാണ് ഓപ്ഷൻ.

ഇൻബൗണ്ട് VPN സർവർ ഹോസ്റ്റ് ചെയ്യുന്നത് വേറിട്ട ഉത്തരമുള്ള വേറിട്ട പ്രശ്നമാണ്. NAT ഗേറ്റ്വേ ഔട്ട്ബൗണ്ട് വിവർത്തനം നൽകുന്നു, പൊതുവായ ഇൻബൗണ്ട് പോർട്ട് ഫോർവേഡിംഗ് നൽകുന്നില്ല, അതിനാൽ അതിന് പിന്നിലുള്ള സർവറിന് സ്വന്തം നിബന്ധനകളിൽ രൂപകൽപ്പന ചെയ്ത അംഗീകൃത പൊതു പ്രവേശനം ആവശ്യമാണ്.

ജോലിക്രമം: ബാഹ്യ പ്രോട്ടോക്കോൾ പേരിടുക, അടുത്ത ഹോപ്പ് സ്ഥിരീകരിക്കുക, രേഖപ്പെടുത്തിയ കൂട്ടവുമായി താരതമ്യം ചെയ്യുക, തുടർന്ന് വാസ്തുവിദ്യയോ കൈമാറ്റമോ മാറ്റുക. വ്യത്യസ്ത പോർട്ട് നമ്പറിന് GRE-യെ TCP ആക്കാൻ കഴിയില്ല, ഒരു അനുവദനീയ നിയമം കൂടി ചേർത്താലും പൂർത്തിയായ നിയന്ത്രണ കൈമാറ്റം പ്രവർത്തിക്കുന്ന ഡാറ്റ ചാനലാകില്ല.