VPN ക്ലയന്റ് ട്രാഫിക്കും ഫയർവാൾ അവസ്ഥയും: പുറം, അകം ഒഴുക്കുകൾ

VPN ഹാൻഡ്ഷേക്ക് പൂർത്തിയാകുന്നു, ക്ലയന്റിന് വിലാസം ലഭിക്കുന്നു, എന്നിട്ടും ഗേറ്റ്‌വേയ്ക്ക് പിന്നിലെ ഒരു സേവനം കണക്ഷൻ നിരസിക്കുന്നു. ഫയർവാൾ പലപ്പോഴും അതിനോട് പറഞ്ഞത് കൃത്യമായി ചെയ്യുന്നു. അത് പുറം ടണൽ ഒഴുക്കിന് അനുവാദം നൽകി, അത് ഡീകാപ്സുലേറ്റ് ചെയ്ത ആപ്ലിക്കേഷൻ കണക്ഷനിൽ നിന്ന് വ്യത്യസ്തമായ പാക്കറ്റാണ്. ഇതിൽ നിന്ന് രണ്ട് തീരുമാനങ്ങൾ ഉണ്ടാകുന്നു: ഏത് ഒഴുക്കിനാണ് അനുവാദം നൽകുന്നത്, അതിർത്തി അവസ്ഥ ട്രാക്ക് ചെയ്യുന്നുണ്ടോ എന്നതും.

ഇവ രണ്ടും വേർതിരിക്കുന്നതുവരെ, ഓരോ നിയമ മാറ്റവും ഒരു ഊഹമാണ്.

ഫയർവാൾ രണ്ട് വ്യത്യസ്ത പാക്കറ്റുകൾ കാണുന്നു

ഡീകാപ്സുലേഷന് മുമ്പ്, ഫയർവാൾ VPN എൻഡ്‌പോയിന്റിലേക്ക് വിലാസമിട്ട ട്രാഫിക് കാണുന്നു: ശ്രോതാവിലേക്കുള്ള പുറം UDP ഒഴുക്ക്. ഡീകാപ്സുലേഷന് ശേഷം, ഫോർവേഡ് ചെയ്ത പാക്കറ്റ് ക്ലയന്റിന്റെ അകത്തെ വിലാസവും സേവനത്തിന്റെ ലക്ഷ്യവും വഹിക്കുന്നു.

പുറം ഒഴുക്കിനുള്ള അനുവാദം ഫോർവേഡ് ചെയ്ത TCP കണക്ഷന് അധികാരം നൽകുന്നില്ല. അവ വ്യത്യസ്ത ചെയിനുകളിൽ, വ്യത്യസ്ത ഇന്റർഫേസുകളുടെ മുന്നിൽ, വിവർത്തനത്തിന് ശേഷം വ്യത്യസ്ത വിലാസങ്ങളോടെ വിലയിരുത്താം.

ഇരുവശത്തുമുള്ള തുല്യമായ സ്ഥാനങ്ങളിൽ നിന്നുള്ള ക്യാപ്ചറുകൾ താരതമ്യം ചെയ്യുക. ടണലിന്റെ അരികിലെ ക്യാപ്ചറും സെർവറിലെ ക്യാപ്ചറും ഒരേ സെഷന് വ്യത്യസ്ത ട്യൂപിളുകൾ കാണിക്കുന്നു.

ആദ്യ തീരുമാനം: ടണലോ സേവനമോ അനുവദിക്കുക

ക്ലയന്റിന് VPN എൻഡ്‌പോയിന്റ് മാത്രം ആവശ്യമെങ്കിൽ, പുറം അനുവാദം മതിയാകാം. ഗേറ്റ്‌വേയ്ക്ക് അപ്പുറത്ത് സേവനം ആവശ്യമെങ്കിൽ, ആ ലക്ഷ്യത്തിനും പോർട്ടിനും ഫോർവേഡിംഗ് അനുവാദം വേണം. സേവനത്തിനും അനുവാദം നൽകുന്ന ടണൽ നിയമം നിങ്ങൾ പേരിടേണ്ട രൂപകൽപ്പന തിരഞ്ഞെടുപ്പാണ്, അപകടമല്ല.

ക്ലയന്റ് ശ്രേണിയും സേവനത്തിന്റെ പരിധിയും ഇടുങ്ങിയതായി സൂക്ഷിക്കുക. ടണൽ സബ്നെറ്റിൽ നിന്ന് മുഴുവൻ LAN-ലേക്കുള്ള അനുവാദം ഓരോ ഹോസ്റ്റിലും വിശ്വസിക്കാനുള്ള തീരുമാനമാണ്, ഒരു ആപ്ലിക്കേഷനുള്ള കുറുക്കുവഴിയല്ല.

രണ്ട് നിയമങ്ങളും വെവ്വേറെ എഴുതുക. ടണൽ നിയമവും സേവന നിയമവും വ്യത്യസ്ത രീതിയിൽ പരാജയപ്പെടുന്നു, വ്യത്യസ്ത തെളിവുകൾ കൊണ്ട് ഡീബഗ് ചെയ്യുന്നു. ഒന്ന് പരാജയപ്പെടുമ്പോൾ, ഏത് പാളി ആദ്യം പരിശോധിക്കണമെന്ന് നിങ്ങൾക്ക് അറിയാം.

രണ്ടാം തീരുമാനം: ഓരോ അതിർത്തിയിലും അവസ്ഥയോടെയോ അവസ്ഥയില്ലാതെയോ

സ്ഥാപിത ഒഴുക്ക് നിയമം അനുവദിച്ച കൈമാറ്റത്തിന് മറുപടികൾ കടത്തിവിടാം, പക്ഷേ അതിന്റെ സ്വഭാവം ഉൽപ്പന്നത്തെ ആശ്രയിച്ചിരിക്കുന്നു. ക്ലൗഡ് സുരക്ഷാ ഗ്രൂപ്പ് സാധാരണയായി അവസ്ഥ സൂക്ഷിക്കുന്നു; സബ്നെറ്റ് ACL പലപ്പോഴും അവസ്ഥ സൂക്ഷിക്കുന്നില്ല, ഇരു ദിശകളിലും വ്യക്തമായ കൈകാര്യം ആവശ്യമാണ്. വഴിയിലെ ഓരോ അതിർത്തിയും അവസ്ഥയെ ഒരേ രീതിയിൽ കാണുന്നു എന്ന് കരുതരുത്. നിയമങ്ങൾ രൂപകൽപ്പന ചെയ്യുന്നതിന് മുമ്പ് ഓരോ അതിർത്തിയും പട്ടികപ്പെടുത്തി അവസ്ഥയോടെയോ അല്ലാതെയോ അടയാളപ്പെടുത്തുക.

ഒരു നിയമം മാറിയാൽ, നിലവിലുള്ള ട്രാക്ക് ചെയ്ത ഒഴുക്കുകൾ പ്രവർത്തിക്കുന്നത് തുടരാം, പുതിയവ പരാജയപ്പെടാം, അല്ലെങ്കിൽ നേരെ മറിച്ചും. ആ വ്യത്യാസം ഉപകാരപ്രദമായ സൂചനയാണ്, സജീവമായ ഗേറ്റ്‌വേയിൽ എല്ലാ കണക്ഷൻ അവസ്ഥയും ഒഴിവാക്കാനുള്ള കാരണമല്ല.

പുതിയ നിയന്ത്രിത അഭ്യർത്ഥന ഉപയോഗിച്ച് പരീക്ഷിക്കുക, ബന്ധപ്പെട്ട കൗണ്ടറുകൾ പരിശോധിക്കുക. ശുദ്ധമായ പരീക്ഷണം തടസ്സപ്പെടുത്തുന്ന റീസെറ്റിനേക്കാൾ നല്ലതാണ്. മാറ്റ രേഖയിൽ കൗണ്ടറിന്റെ പേര് രേഖപ്പെടുത്തുക, അടുത്ത പരീക്ഷണം അതേ തെളിവ് ഉപയോഗിക്കട്ടെ.

അതേ നയപ്രകാരം തിരിച്ചുവരവ് പാത പരിശോധിക്കുക

ക്ലയന്റിൽ നിന്ന് സേവനത്തിലേക്ക് പുതിയ അഭ്യർത്ഥന അയയ്ക്കുക, തുടർന്ന് ഓരോ അതിർത്തിയിലും മുന്നോട്ടും തിരിച്ചുമുള്ള കൗണ്ടറുകൾ പരിശോധിക്കുക. മറുപടി നിങ്ങൾ പ്രതീക്ഷിക്കുന്ന പാത ഉപയോഗിക്കുന്നുവെന്ന് ഉറപ്പാക്കുക, പ്രത്യേകിച്ച് വിവർത്തനം ഉൾപ്പെട്ടിട്ടുണ്ടെങ്കിൽ.

ഉദ്ദേശിച്ച ക്ലയന്റ് ശ്രേണിയും സേവനത്തിന്റെ പരിധിയും ഇടുങ്ങിയതായി സൂക്ഷിക്കുക, അഭ്യർത്ഥനയ്ക്ക് അനുവാദം നൽകിയ അതേ നിയമ കൂട്ടത്തിന് കീഴിൽ തിരിച്ചുവരവ് പാത പരിശോധിക്കുക. പഴയ ഒഴുക്ക് ഇപ്പോഴും തുറന്നിരിക്കുന്നത് കൊണ്ട് മാത്രം പ്രവർത്തിക്കുന്ന നിയമം പ്രവർത്തിക്കുന്ന നിയമമല്ല.