എല്ലാ ICMP-യും തടയുന്നത് പ്രവർത്തിക്കുന്ന VPN പാത്ത് എന്തുകൊണ്ട് തകർക്കുന്നു

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

ഈ പാത്തിൽ ICMP യഥാർത്ഥത്തിൽ എന്താണ് വഹിക്കുന്നത്

IPv4 പാത്ത് MTU കണ്ടെത്തൽ don't-fragment ബിറ്റ് ഉള്ള പാക്കറ്റ് കൈമാറാൻ കഴിഞ്ഞില്ലെന്ന് റൂട്ടർ റിപ്പോർട്ട് ചെയ്യുന്നതിനെ ആശ്രയിക്കുന്നു. ആ റിപ്പോർട്ട് ICMP Fragmentation Needed സന്ദേശമാണ്, അതില്ലാതെ അയച്ചയാൾക്ക് സെഗ്മെന്റിന്റെ വലിപ്പം കുറയ്ക്കാൻ കാരണമില്ല. IPv6 കൂടുതൽ കർശനമാണ്: റൂട്ടറുകൾ ട്രാൻസിറ്റിൽ വിഭജിക്കുന്നില്ല, അതിനാൽ ICMPv6 Packet Too Big സന്ദേശം മാത്രമാണ് അയച്ചയാളെ ചുരുക്കുന്ന സിഗ്നൽ.

രണ്ട് സന്ദേശങ്ങളും നിയന്ത്രണ-തലത്തിലെ ഫീഡ്ബാക്കാണ്, ഒന്നും ഡയഗ്നോസ്റ്റിക് പ്രതിധ്വനിയല്ല. ping തടയുന്ന നയവും എല്ലാ ICMP-യും തടയുന്ന നയവും നിയമപ്പട്ടികയിൽ സമാനമായി കാണപ്പെടുന്നു, പക്ഷേ നെറ്റ്വർക്കിൽ വളരെ വ്യത്യസ്തമായി പ്രവർത്തിക്കുന്നു. രണ്ടാമത്തേത് ശരിയായി അളന്ന ടണലിനെ ശൃംഖലയിലെ ഏറ്റവും ചെറിയ കണ്ണിയേക്കാൾ വലുതായ എന്തിനും ഏകദിശാ പാത്താക്കി മാറ്റാം.

ചില ട്രാൻസ്പോർട്ടുകൾ RFC 4821 വിവരിക്കുന്നതുപോലെ പ്രോബ് പാക്കറ്റുകൾ ഉപയോഗിച്ച് സ്വന്തം കണ്ടെത്തൽ നടപ്പാക്കുന്നു, അവ ഈ ഫീഡ്ബാക്കിനെ കുറച്ചുമാത്രം ആശ്രയിക്കുന്നു. ഏത് ട്രാൻസ്പോർട്ടാണ് നടത്തുന്നതെന്ന് പരിശോധിക്കാനുള്ള വാദമാണിത്, ഓരോ ടണലും പ്രതിരോധശേഷിയുള്ളതാണെന്ന് അനുമാനിക്കാനല്ല.

പരാജയം വലിപ്പത്തെ ആശ്രയിച്ചിരിക്കുന്നു

പരാജയം പാക്കറ്റിന്റെ വലിപ്പവുമായി ബന്ധപ്പെട്ടിരിക്കുന്നുവോ എന്ന് ചോദിക്കുക. ലോഗിൻ പേജ്, DNS ക്വറി, ചെറിയ API കോൾ എന്നിവ വിജയിക്കുന്നു, അതേസമയം ഫയൽ അപ്ലോഡ്, വലിയ ഉത്തരം, ചിത്ര ഡൗൺലോഡ് എന്നിവ നിലയ്ക്കുന്നു. ഈ മാതൃക രണ്ട് അറ്റങ്ങൾക്കിടയിൽ എവിടെയോ വലിപ്പപരിധിയിലേക്ക് വിരൽ ചൂണ്ടുന്നു, പ്രാമാണീകരണത്തിലേക്കോ റൂട്ടിംഗിലേക്കോ അല്ല. വിജയകരമായ ചെറിയ ping ആ പരിധി എവിടെയെന്നതിനെക്കുറിച്ച് ഏതാണ്ട് ഒന്നും പറയുന്നില്ല.

ടണലിനുള്ളിൽ പരിഗണിക്കേണ്ട രണ്ട് പാളികളുണ്ട്: പേലോഡ് പാക്കറ്റും പുറം എൻകാപ്സുലേറ്റഡ് പാക്കറ്റും. ടണൽ അനുമാനിക്കുന്നതിനേക്കാൾ പുറം പാത്ത് ചെറുതായിരിക്കുമ്പോഴും ആന്തരിക അയച്ചയാൾ ശരിയായി പ്രവർത്തിക്കാം, അതുകൊണ്ടാണ് ടണലിന്റെ സ്വന്തം MTU ക്രമീകരണവും അതിനടിയിലെ ഭൗതിക കണ്ണിയും പ്രധാനമാകുന്നത്.

നിയമങ്ങൾ തിരുത്തുന്നതിന് മുമ്പ് അളക്കുക

don't-fragment ബിറ്റും നിങ്ങൾ തിരഞ്ഞെടുക്കുന്ന പേലോഡ് വലിപ്പവും ഉപയോഗിച്ച് പരിശോധിക്കുക, പരാജയപ്പെട്ട ക്ലയന്റിൽ നിന്ന് സംരക്ഷിത വിലാസത്തിലേക്ക്:

ping -M do -s 1472 10.20.5.7
ping -M do -s 1300 10.20.5.7

1472 ബൈറ്റ് പേലോഡും 28 ബൈറ്റ് ഹെഡറുകളും ചേർന്ന് 1500 ബൈറ്റ് പാക്കറ്റ് ഉണ്ടാകുന്നു. വലിയ പരിശോധന വിഭജന പിശകോടെ പരാജയപ്പെടുകയും ചെറുത് കടന്നുപോകുകയും ചെയ്താൽ, നിങ്ങൾ പരിധി കണ്ടെത്തി; ടണലിന്റെ അധിക ഭാരം കണക്കാക്കി ക്രമീകരിച്ച്, പ്രവർത്തിക്കുന്ന വലിപ്പം സ്ഥിരമാകുന്നതുവരെ ആവർത്തിക്കുക.

എന്നിട്ട് വിടവ് റിപ്പോർട്ട് തന്നെയാണെന്ന് ഉറപ്പാക്കുക. പരിശോധന പിശകോ ഉത്തരമോ ഇല്ലാതെ നിശബ്ദമായി പരാജയപ്പെട്ടാൽ, സന്ദേശം എത്തിക്കുന്നതിനുപകരം ഉപേക്ഷിക്കപ്പെടുകയാണ്, സംശയിക്കേണ്ടത് നിയമമാണ്.

നിയമം ഇടുക്കുക, എന്നിട്ട് ജോലി വീണ്ടും പരിശോധിക്കുക

തിരുത്തൽ നിർദ്ദിഷ്ട നിയന്ത്രണ സന്ദേശങ്ങളെ അനുവദിക്കണം, മുഴുവൻ പ്രോട്ടോക്കോളിനെയല്ല. iptables ഹോസ്റ്റിൽ രൂപം തരം-നിർദ്ദിഷ്ട അനുവാദമാണ്; നിങ്ങളുടെ പ്ലാറ്റ്ഫോമിൽ ഫയർവാൾ കൈകാര്യം ചെയ്യുന്നതിന് അനുസരിച്ച് വാക്യഘടന ക്രമീകരിക്കുക:

iptables -I INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT
ip6tables -I INPUT -p icmpv6 --icmpv6-type packet-too-big -j ACCEPT

അതാണ് പ്രാദേശിക നയമെങ്കിൽ പ്രതിധ്വനി ഉത്തരങ്ങൾ തടഞ്ഞുതന്നെ വയ്ക്കുക, കാരണം പാത്തിന് അവ ആവശ്യമില്ല. പിന്നീട് യഥാർത്ഥത്തിൽ പരാജയപ്പെട്ട കൈമാറ്റം പുതിയ കണക്ഷനിൽ നിന്ന് വീണ്ടും പരിശോധിച്ച്, നിയമത്തിന്റെ കൗണ്ടറുകൾ സന്ദേശങ്ങൾ എത്തുന്നതായി കാണിക്കുന്നുവെന്ന് ഉറപ്പാക്കുക.

സന്ദേശങ്ങൾ അനുവദിച്ചതിന് ശേഷവും വലിയ കൈമാറ്റം നിലയ്ക്കുന്നെങ്കിൽ, ബാക്കിയുള്ള പരിധി മറ്റെവിടെയോ ആണ്: വളരെ ഉയർന്ന ടണൽ MTU, പാക്കറ്റുകൾ വീണ്ടും എഴുതുന്ന പ്രോക്സി, അല്ലെങ്കിൽ റിപ്പോർട്ട് ചെയ്യുന്നതിനുപകരം ഉപേക്ഷിക്കുന്ന ഇടനില പെട്ടി. ICMP നിയമം ആവശ്യമായിരുന്നു, മതിയായിരുന്നില്ല.