സൈറ്റ്-ടു-സൈറ്റ് VPN: ഏത് ദിശയ്ക്കാണ് യഥാർത്ഥത്തിൽ ഒരു നിയമം വേണ്ടത്?

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

സ്റ്റേറ്റ്ഫുൾ മടങ്ങിവരവ് എണ്ണം മാറ്റുന്നു

സ്റ്റേറ്റ്ഫുൾ ഫയർവാൾ അഭ്യർത്ഥന രേഖപ്പെടുത്തി രണ്ടാമത്തെ നിയമമില്ലാതെ മറുപടി കടത്തിവിടുന്നു, അതിനാൽ ഒരു നിയമം മാത്രം വേണ്ട രൂപകൽപ്പന സാധാരണമാണ്. സ്റ്റേറ്റ്ലെസ് ആക്സസ് ലിസ്റ്റിന് അത്തരം ഓർമ്മയില്ല, മറുപടിക്ക് വ്യക്തമായി അനുമതി നൽകണം. രണ്ടും അതത് പ്ലാറ്റ്ഫോമിൽ ശരിയാണ്, അതുകൊണ്ടാണ് ഉപദേശങ്ങൾ പരസ്പരം വിരുദ്ധമാകുന്നത്.

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

ഫയർവാൾ ഡീക്രിപ്റ്റ് ചെയ്ത പാക്കറ്റുകൾ എവിടെ കാണുന്നു

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

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

അസമമിത റൂട്ടിംഗ് അനുമാനം തകർക്കുന്നു

സ്റ്റേറ്റ്ഫുൾ ഫയർവാൾ സംഭാഷണത്തിന്റെ രണ്ട് പകുതികളും കാണുന്നു എന്ന് അനുമാനിക്കുന്നു. മറുപടി മറ്റൊരു ഗേറ്റ്വേയിലൂടെ തിരികെ വന്നാൽ, ആ ഉപകരണത്തിന് അഭ്യർത്ഥനയ്ക്ക് സ്റ്റേറ്റ് ഇല്ല, സ്വന്തം നയം അനുസരിച്ച് അത് ഉപേക്ഷിക്കുന്നു. ലക്ഷണം അയയ്ക്കുന്ന വശത്തെ ഒരു നിയമത്തിനും പരിഹരിക്കാനാകാത്ത ഏകദിശാ പരാജയമാണ്. മറുപടിയുടെ പാത പിന്തുടരുക എന്തെങ്കിലും തിരുത്തുന്നതിന് മുമ്പ്.

ഇരു വശങ്ങളിലും വിശാലമായ അനുമതി നിയമം ചേർക്കുന്നതിന് മുമ്പ് മറുപടിയുടെ റൂട്ട് പരിശോധിക്കുക. ഓരോ ഇന്റർഫേസിലും എല്ലാം സഹിക്കുന്നത് റൂട്ടിംഗ് പിശക് മറയ്ക്കുകയും അതേസമയം പ്രവേശനം വിശാലമാക്കുകയും ചെയ്യുന്നു, അതാണ് ലഭ്യമായ ഏറ്റവും മോശം സംയോജനം.

യഥാർത്ഥ സ്രോതസ്സ് വിലാസങ്ങളുമായി രണ്ട് ദിശകളും പരിശോധിക്കുക

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

tcpdump -ni any 'host 10.30.8.15 and tcp port 443'
nft list ruleset | grep -A 8 'chain forward'
ip route get 10.30.8.15
conntrack -L | grep 10.30.8.15

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

വിവർത്തനത്തിന് ശേഷമുള്ള സ്രോതസ്സ് വിലാസം, ഡീക്രിപ്റ്റ് ചെയ്ത പാക്കറ്റ് ഉപയോഗിച്ച ഇന്റർഫേസ്, പൊരുത്തപ്പെട്ട നിയമം എന്നിവ രേഖപ്പെടുത്തുക. ആ മൂന്ന് വസ്തുതകൾ മുഴുവൻ അന്വേഷണവും ആവർത്തിക്കാതെ അടുത്ത ടിക്കറ്റിന് ഉത്തരം നൽകുന്നു.