സ്റ്റേറ്റ്ലെസ് VPN എഡ്ജ് ഫയർവാളിൽ DNS മറുപടി എന്തുകൊണ്ട് പരാജയപ്പെടുന്നു

ടണൽ പ്രവർത്തിക്കുന്നു, ക്ലയന്റുകൾ VPN ഹോസ്റ്റിൽ എത്തുന്നു, പക്ഷേ ഹോസ്റ്റിന് ഒന്നും റിസോൾവ് ചെയ്യാനാകുന്നില്ല. അതിന്റെ സ്വന്തം ഔട്ട്ബൗണ്ട് ക്വറികൾ ഇന്റർഫേസ് വൃത്തിയായി വിടുന്നു, അതിനാൽ പരാജയം മടങ്ങിവരുന്ന വഴിയിലാണ്: ഹോസ്റ്റ് ഇപ്പോൾ അയച്ചത് ഓർക്കാതെ ഇൻകമിംഗ് ട്രാഫിക് ഫിൽട്ടർ ചെയ്യുന്ന ഒരു മുകളിലെ എഡ്ജിൽ. ടണൽ പോർട്ട് അനുവദിക്കുന്നത് ആ കൈമാറ്റത്തെ ഒട്ടും വിവരിക്കുന്നില്ല. DNS ക്വറിക്കുള്ള മറുപടി വേറിട്ട ഒഴുക്കാണ്, എഡ്ജ് സ്റ്റേറ്റ്ലെസ് ആണെങ്കിൽ, മടങ്ങിവരാൻ അതിന് അനുമതി നൽകിയത് ഒന്നുമില്ല.

രണ്ട് കൈമാറ്റങ്ങളും ഒരേ കൈമാറ്റമല്ല

ട്യൂപ്പിളുകൾ എഴുതിവെക്കൂ, തെറ്റ് വ്യക്തമാകും. അഭ്യർത്ഥനയുടെ ലക്ഷ്യ പോർട്ട് മറുപടിയുടെ സ്രോതസ്സ് പോർട്ട് ആകുന്നു, ഇത് പോർട്ട് 53 നുള്ള ഇൻബൗണ്ട് നിയമം ചേർക്കുമ്പോൾ മിക്ക ആളുകളും സങ്കൽപ്പിക്കുന്നതിന് നേരെ വിപരീതമാണ്:

query:  203.0.113.10:53018 -> 198.51.100.53:53
reply:  198.51.100.53:53 -> 203.0.113.10:53018

ലക്ഷ്യ പോർട്ട് 53 ആവശ്യപ്പെടുന്ന ഇൻകമിംഗ് നിയമം ഹോസ്റ്റിൽ പ്രവർത്തിക്കുന്ന DNS ശ്രോതാവിന് അയക്കുന്ന ട്രാഫിക്കിനെ വിവരിക്കുന്നു, അത് തികച്ചും വേറെ സേവനമാണ്. ആ വിലാസങ്ങൾ ഡോക്യുമെന്റേഷൻ ഉദാഹരണങ്ങളാണ്, സ്രോതസ്സ് പോർട്ട് ഓരോ ക്വറിക്കും ക്ലയന്റ് തിരഞ്ഞെടുക്കുന്നു, അതിനാൽ ഇത് നിയമത്തിലേക്ക് പകർത്തി പ്രവർത്തനം തുടരുമെന്ന് പ്രതീക്ഷിക്കാവുന്ന മൂല്യമല്ല.

സ്റ്റേറ്റ്ലെസ് എഡ്ജും സ്റ്റേറ്റ്ഫുൾ ഹോസ്റ്റ് ഫയർവാളും

സ്റ്റേറ്റ്ലെസ് എഡ്ജ് ഫിൽട്ടർ പിന്നിൽ കണക്ഷൻ പട്ടികയില്ലാതെ ഓരോ ഇൻകമിംഗ് പാക്കറ്റും അതിന്റെ നിയമപ്പട്ടികയുമായി താരതമ്യം ചെയ്യുന്നു. വിജയകരമായി പുറത്തുപോയ ഔട്ട്ബൗണ്ട് ക്വറി അതിന്റെ ഇൻകമിംഗ് മറുപടിക്ക് ഒരു അനുമതിയും സൃഷ്ടിക്കുന്നില്ല, കാരണം ഒരു ക്വറി ഉണ്ടായിരുന്നു എന്ന രേഖ ഉപകരണത്തിനില്ല. സ്റ്റേറ്റ്ഫുൾ ഹോസ്റ്റ് ഫയർവാൾ ഇതിന് വിപരീതമാണ്: അതിന്റെ കണക്ഷൻ ട്രാക്കിംഗ് അനുവദിച്ച കൈമാറ്റത്തിന്റെ മടങ്ങിവരുന്ന ട്രാഫിക് തിരിച്ചറിഞ്ഞ് മറുപടിക്ക് നിയമമില്ലാതെ അത് കടത്തിവിടുന്നു. രണ്ട് അതിരുകളും സാധാരണ പാതയിലുണ്ട്, രണ്ടും ഉദ്ദേശിച്ച പാക്കറ്റ് അനുവദിക്കണം.

താരതമ്യം പ്രധാനമാണ് കാരണം രണ്ട് ഉപകരണങ്ങളും വ്യത്യസ്തമായി പരാജയപ്പെടുന്നു. മറുപടി നിരസിക്കുന്ന സ്റ്റേറ്റ്ഫുൾ ഫയർവാൾ ഡ്രോപ്പ് രേഖപ്പെടുത്തുന്നു; സ്റ്റേറ്റ്ലെസ് എഡ്ജ് അത് നിശ്ശബ്ദമായി നിരസിക്കുന്നു, അതിനാൽ ഹോസ്റ്റ് സമയപരിധിയിൽ എത്തുന്നു.

അനുമതി പോർട്ട് നമ്പറിനു ചുറ്റുമല്ല, പ്രോട്ടോക്കോളിനു ചുറ്റും നിർമ്മിക്കുക

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

തുടർന്ന് പാതയിലെ ഏത് ഉൽപ്പന്നമാണ് ട്രാഫിക് യഥാർത്ഥത്തിൽ ഫിൽട്ടർ ചെയ്യുന്നതെന്ന് സ്ഥിരീകരിക്കുക. രേഖപ്പെടുത്തിയ IPv4 എഡ്ജ് പരിധി IPv6 നയം സ്ഥാപിക്കുന്നില്ല, ദാതാവിന്റെ ആന്തരിക ട്രാഫിക് ഒരിക്കലും അതേ ഫിൽട്ടറിലൂടെ കടന്നുപോകണമെന്നില്ല.

ഏതെങ്കിലും സ്രോതസ്സ് പോർട്ട് 53 അനുവദിക്കുന്നത് എന്തുകൊണ്ട് പരിഹാരമല്ല

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

റിസോൾവർ നിങ്ങൾ നിയന്ത്രിക്കുന്ന സേവനമാണെങ്കിൽ അതിന്റെ വിലാസങ്ങളിൽ പരിമിതപ്പെടുത്തിയാൽ മതി. പൊതു റിസോൾവർ ആണെങ്കിൽ നിങ്ങൾ അംഗീകരിച്ച വിലാസങ്ങളിൽ പരിമിതപ്പെടുത്തി അവ നിയമത്തിന്റെ കമന്റിൽ രേഖപ്പെടുത്തുക.

ശരിയായ അതിരിൽ, ശരിയായ ദിശയിൽ പരിശോധിക്കുക

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

ഇത് ശരിയാക്കുന്നത് ഹോസ്റ്റിന് യഥാർത്ഥത്തിൽ ആവശ്യമായ DNS കൈമാറ്റം പൂർത്തിയാക്കുന്നു. ഇത് ഹോസ്റ്റിനെ പൊതു റിസോൾവറാക്കുന്നില്ല, ഫോർവേഡ് ചെയ്ത VPN ഒഴുക്കുകൾ അനുവദിക്കുന്നില്ല, DNS ആണ് ഏതെങ്കിലും അസംബന്ധ ടണൽ പ്രശ്നത്തിന്റെ കാരണമെന്ന് തെളിയിക്കുന്നുമില്ല.