VPN വഴിയുള്ള ping: പ്രതിധ്വനി ഉത്തരത്തിന്റെ നിയമങ്ങൾ മടങ്ങിവരവ് പാത കണ്ടെത്താത്തത് എന്തുകൊണ്ട്

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

പാക്കറ്റ് പോർട്ടല്ല, തരം മാറുന്നു

പ്രതിധ്വനി അഭ്യർത്ഥന ICMP തരം 8, കോഡ് 0 ആണ്, അത് ഒരു ഐഡന്റിഫയറും ക്രമ നമ്പറും വഹിക്കുന്നു. ഉത്തരം തരം 0, കോഡ് 0 ആണ്, അതേ ഐഡന്റിഫയറും ക്രമവും ഉള്ളത്, IP അറ്റങ്ങൾ മാറ്റിയത്. ഈ ഫീൽഡുകൾ RFC 792 നിർവചിക്കുന്നു, ഒപ്പം ഐഡന്റിഫയർ ആണ് അയച്ചയാൾക്ക് ഉത്തരങ്ങൾ സ്വന്തം അഭ്യർത്ഥനകളുമായി ചേർക്കാൻ അവസരം നൽകുന്നത്.

ഇല്ലാത്തതും അത്രതന്നെ പ്രധാനമാണ്: TCP അല്ലെങ്കിൽ UDP ഹെഡറും ഇല്ല, അതിനാൽ അനുവദിക്കാൻ ഒരു പോർട്ടുമില്ല. പ്രതിധ്വനി ഉത്തരത്തിന് ഒരു പോർട്ട് പേരിടുന്ന നിയമം ഒരിക്കലും നിലനിൽക്കാത്ത ഒരു പാക്കറ്റിനെ വിവരിക്കുന്നു. VPN ping ടിക്കറ്റുകളിൽ ഏറ്റവും സാധാരണമായ പിഴവ് ഇതാണ്. നിയമം നിർദ്ദിഷ്ടമായി തോന്നുന്നു, ഒന്നിനും ബാധകമല്ല, പരാജയത്തെ ഉണ്ടായിരുന്ന അതേ സ്ഥലത്ത് ഉപേക്ഷിക്കുന്നു.

മൂന്ന് സന്ദർഭങ്ങൾ പാക്കറ്റ് തീരുമാനിക്കുന്നു

ping വിദൂര LAN-ലെ ഹോസ്റ്റിനെ ലക്ഷ്യമിട്ടാൽ അഭ്യർത്ഥന ഗേറ്റ്‌വേ ഫോർവേഡ് ചെയ്യണം. അത് ഗേറ്റ്‌വേയ്ക്ക് തന്നെയുള്ള വിലാസത്തെ ലക്ഷ്യമിട്ടാൽ, അത് പ്രാദേശിക ഇൻപുട്ട് പാതയിൽ അവസാനിക്കുന്നു. ഗേറ്റ്‌വേ തന്നെ ping തുടങ്ങിയാൽ, പാക്കറ്റ് അതിന്റേതായ ഔട്ട്പുട്ട് പാതയിൽ തുടങ്ങുകയും ഫോർവേഡിംഗ് തീരുമാനം ഒട്ടും കടക്കുകയും ചെയ്യുന്നില്ല.

ഈ മൂന്ന് സന്ദർഭങ്ങൾക്ക് വ്യത്യസ്ത നിയമ ശൃംഖലകളും വ്യത്യസ്ത കൗണ്ടറുകളുമുണ്ട്, അവയെ ഒന്നായി കണക്കാക്കുന്നതാണ് «ഫയർവാൾ ICMP അനുവദിക്കുന്നു» എന്നിട്ടും ping പരാജയപ്പെടാൻ കാരണം. പുറം ടണൽ നാലാമത്തെ സന്ദർഭമാണ്: VPN ശ്രോതാവിന് അനുമതി നൽകുന്നത് ഡീകാപ്സുലേറ്റ് ചെയ്ത ആന്തരിക അഭ്യർത്ഥനയ്ക്ക് സ്വയമേവ അനുമതി നൽകുന്നില്ല, ഒപ്പം ആന്തരിക അനുമതി പുറം ടണൽ പ്രവർത്തിക്കുന്നുണ്ടോ എന്നതിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല.

സ്റ്റേറ്റ്ഫുൾ, സ്റ്റേറ്റ്ലെസ് ഫിൽട്ടറുകൾ ഉത്തരം വ്യത്യസ്തമായി കൈകാര്യം ചെയ്യുന്നു

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

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

നിങ്ങൾ അനുവദിക്കുന്നതിന്റെ പരിധി നിർണ്ണയിക്കുക. എവിടെനിന്നും എല്ലാ പ്രതിധ്വനി ഉത്തരങ്ങൾക്കും അനുമതി നൽകുന്നത് സ്റ്റേറ്റ്ഫുൾ ബന്ധം പൂർത്തിയാക്കുന്നതിന് തുല്യമല്ല, ഒപ്പം തരം നമ്പർ അയച്ചയാളെ പ്രാമാണീകരിക്കുന്നുമില്ല.

പരിഭാഷ ഐഡന്റിഫയറും മാറ്റുന്നു

ഉറവിട പരിഭാഷ ഉദ്ദേശ്യപൂർവമാണെങ്കിൽ, വിദൂര അറ്റത്തുള്ള ട്യൂപ്പിൾ ക്ലയന്റ് അയച്ചതുമായി ചേരുന്നില്ല. NAT ICMP അന്വേഷണത്തിന്റെ ഐഡന്റിഫയർ വിലാസങ്ങളോടൊപ്പം പരിഭാഷപ്പെടുത്താം, അതിനാൽ ഇരുവശത്തും അതേ നമ്പർ കാണണമെന്ന് ശഠിക്കുന്നത് വ്യാജ പൊരുത്തക്കേട് സൃഷ്ടിക്കുന്നു.

പകരം പരിഭാഷകൻ റിപ്പോർട്ട് ചെയ്യുന്ന മാപ്പിംഗുമായി ബന്ധിപ്പിക്കുക. ഐഡന്റിഫയർ വീണ്ടും എഴുതുന്ന പരിഭാഷകൻ നിങ്ങളുടെ ക്ലയന്റ് രേഖപ്പെടുത്തിയ നമ്പർ നിലനിർത്തില്ല, അതിനാൽ നമ്പറല്ല, മാപ്പിംഗിനെ ഐഡന്റിറ്റിയായി കണക്കാക്കുക. തുടർന്ന് തിരിച്ചറിയാവുന്ന ഒരു അഭ്യർത്ഥന പാതയിലൂടെ പിന്തുടരുക: പ്രതീക്ഷിച്ച ഉറവിടത്തോടെ അത് ലക്ഷ്യത്തിലെത്തുന്നുവെന്ന് ഉറപ്പാക്കുക, ലക്ഷ്യം ഒരു ഉത്തരം പുറപ്പെടുവിച്ചുവെന്ന് ഉറപ്പാക്കുക, ആ ഉത്തരത്തിന്റെ മടങ്ങിവരവ് പാത പിന്തുടരുക, ഒപ്പം ക്ലയന്റ് അത് സ്വീകരിച്ചുവെന്ന് ഉറപ്പാക്കുക, ഗേറ്റ്‌വേ കൗണ്ടർ ഉയരുന്നത് മാത്രം നോക്കുന്നതിന് പകരം.

ICMP പിശകുകൾ പ്രതിധ്വനി നയത്തിൽ ചേർക്കരുത്

പാതയുടെ MTU കണ്ടെത്തൽ ഉപയോഗിക്കുന്ന «ഫ്രാഗ്മെന്റേഷൻ ആവശ്യമാണ്» സന്ദേശം പ്രതിധ്വനി ഉത്തരമല്ല, അതിന്റെ പേലോഡ് അത് ഉണ്ടാക്കിയ പാക്കറ്റ് ഉദ്ധരിക്കുന്നു. പ്രതിധ്വനിക്ക് മാത്രമുള്ള അനുമതി ആ പിശകുകൾ നിശബ്ദമായി ഉപേക്ഷിക്കുമ്പോൾ വലിപ്പപ്രശ്നം തൂങ്ങിക്കിടക്കുന്ന ബന്ധമായി മാറുന്നു, അത് സഹായകരമാകുന്നതിന് വിപരീതമാണ്.

അതേ മുൻകരുതൽ വിലാസ കുടുംബങ്ങൾക്കും ബാധകമാണ്. ICMPv6 വ്യത്യസ്ത സന്ദേശ തരങ്ങൾ ഉപയോഗിക്കുന്നു, IPv4-ന് ഇല്ലാത്ത അത്യാവശ്യ പ്രവർത്തനങ്ങൾ വഹിക്കുന്നു, അതിനാൽ ഈ നമ്പറുകൾ IPv6 നിയമത്തിലേക്ക് പകർത്തുന്നത് വെറും തെറ്റാണ്.

പ്രതിധ്വനി കൈമാറ്റം പ്രവർത്തിക്കുമ്പോൾ യഥാർത്ഥ ആപ്ലിക്കേഷൻ വെവ്വേറെ പരീക്ഷിക്കുക. വിജയകരമായ ping ഒരു പ്രോട്ടോക്കോളിന്റെ ഒരു വലിപ്പത്തിൽ ഒരു ലക്ഷ്യത്തിലേക്കുള്ള പോക്കും വരവും തെളിയിക്കുന്നു, അത് HTTPS, SMB അല്ലെങ്കിൽ മറ്റേതെങ്കിലും ഫ്ലോ അനുവദനീയമാണെന്ന് അനുമാനിക്കാനുള്ള അനുമതിയല്ല.