IPv4 യാത്രാമധ്യത്തിൽ ശകലീകരിക്കുന്നു; IPv6 പകരം പാക്കറ്റ് വളരെ വലുത് സന്ദേശം അയയ്ക്കുന്നു
IPv4 റൗട്ടറുകൾക്ക് മാത്രമേ വലിപ്പമേറിയ പാക്കറ്റ് ശകലീകരിക്കാനാകൂ. ടണലോ ഫിൽട്ടർ ചെയ്ത ICMP നിയമമോ തകർക്കാവുന്ന, പാക്കറ്റ് വളരെ വലുത് സന്ദേശത്തോട് അയയ്ക്കുന്നയാൾ പ്രതികരിക്കുമെന്ന് IPv6 പ്രതീക്ഷിക്കുന്നു.
IPv6 പരാജയങ്ങൾ അവയ്ക്ക് കാരണമായ പാക്കറ്റ് വലിപ്പത്തെക്കാൾ പ്രോട്ടോക്കോളിനാണ് പലപ്പോഴും കുറ്റം ചുമത്തുന്നത്. രണ്ട് കുടുംബങ്ങളും വലിപ്പമേറിയ പാക്കറ്റിനെ യഥാർത്ഥത്തിൽ വ്യത്യസ്തമായി കൈകാര്യം ചെയ്യുന്നു, ആ വ്യത്യാസത്തെ പ്രധാനമാക്കുന്നത് ടണലാണ്. IPv4 റൗട്ടറുകൾക്ക് നിയമങ്ങൾ അനുവദിക്കുമ്പോൾ പാക്കറ്റ് ശകലീകരിക്കാം, എന്നാൽ IPv6 റൗട്ടറുകൾ യാത്രയിൽ ഒരിക്കലും ശകലീകരിക്കരുത്. IPv6 പകരം അയയ്ക്കുന്നയാളോട് പറയുന്നു, അയയ്ക്കുന്നയാൾ പ്രതികരിക്കുമെന്ന് പ്രതീക്ഷിക്കുന്നു. തുടർന്ന് കാര്യങ്ങൾ തെറ്റുന്നത് ആ സന്ദേശം എത്തുന്നുണ്ടോ എന്നതിനെ ആശ്രയിച്ചാണ്.
ഓരോ കുടുംബവും ചെയ്യുന്നത്
നാല് വരികളിൽ അവതരിപ്പിക്കുന്ന സംവിധാനമാണ് പട്ടിക, ഒരു വരി ആശയക്കുഴപ്പത്തിന്റെ ഭൂരിഭാഗവും വിശദീകരിക്കുന്നു.
| Behaviour | IPv4 | IPv6 |
|---|---|---|
| Router fragments an oversized packet | Allowed while DF is clear | Never |
| Signal returned to the sender | ICMP Fragmentation Needed | ICMPv6 Packet Too Big |
| Size that must always work | 68 bytes | 1280 bytes |
| Fragmentation possible | Routers or source | Source only |
IPv6-ന് യാത്രയിൽ ശകലീകരണവുമില്ല, മായ്ക്കാനുള്ള DF ഫ്ലാഗും ഇല്ല, അതിനാൽ പാക്കറ്റ് വളരെ വലുതാകുമ്പോൾ ആശ്രയിക്കാൻ ഒന്നുമില്ല. അയയ്ക്കുന്നയാളോട് പറയണം, അയയ്ക്കുന്നയാൾ അത് വിശ്വസിക്കണം.
ടണൽ വഴി നിശബ്ദമായി ചുരുക്കുന്നു
VPN പാക്കറ്റ് ഹോസ്റ്റ് വിടുന്നതിന് മുമ്പ് പുറം ഹെഡറുകൾ ചേർക്കുന്നു, എൻക്രിപ്റ്റ് ചെയ്ത സാഹചര്യത്തിൽ സമഗ്രതാ ഡാറ്റയും. ഉള്ളിലെ പാക്കറ്റ് അത് കാണുന്ന ഇന്റർഫേസ് MTU-യിൽ ഒതുങ്ങാമെങ്കിലും പുറത്തെ പാക്കറ്റ് അടുത്ത ലിങ്കിന്റെ പരിധി കവിയുന്നതിനാൽ ഇത് ആദ്യം ടണലിൽ പ്രത്യക്ഷപ്പെടുന്നു. ടണൽ ഇന്റർഫേസിന്റെ MTU ബോധപൂർവം കുറയ്ക്കൂ, അല്ലെങ്കിൽ വഴിയിൽ TCP MSS മുറുക്കൂ, കൂടാതെ തിരഞ്ഞെടുത്ത സംഖ്യയും കാരണവും എഴുതിവയ്ക്കൂ.
ESP-യുടെ അധികഭാരം മോഡും അൽഗോരിതങ്ങളും അനുസരിച്ച് മാറുന്നു, അതിനാൽ ശരിയായ ടണൽ MTU ഒരു കണക്കുകൂട്ടലാണ്, പാരമ്പര്യമല്ല. നിങ്ങൾ എന്ത് തിരഞ്ഞെടുത്താലും, പൂർണ്ണമായ 1280 ബൈറ്റ് ഉള്ളിലെ IPv6 പാക്കറ്റിന് ഇടം നൽകണം, കാരണം ഓരോ IPv6 ലിങ്കും അത്രയെങ്കിലും വഹിക്കണം. 1280 ബൈറ്റ് IPv6 വഹിക്കാനാകാത്ത ടണൽ ട്യൂണിംഗ് പ്രശ്നമല്ല; അത് ആ കുടുംബത്തിനുള്ള പൊട്ടിയ വഴിയാണ്. IPv4 മാത്രമുള്ള വിന്യാസത്തിൽ നിന്ന് MTU മൂല്യം പകർത്തുമ്പോൾ അപ്രത്യക്ഷമാകുന്നത് ഈ പരിമിതിയാണ്.
ലക്ഷണം തടഞ്ഞുനിൽക്കൽ ആയി തോന്നുന്നത് എന്തുകൊണ്ട്
പരാജയം വ്യക്തമായ പിശകല്ല, അതുകൊണ്ടാണ് തെറ്റായ രോഗനിർണയം ഉണ്ടാകുന്നത്. TCP ഹാൻഡ്ഷേക്ക് പൂർത്തിയാകുന്നു, ചെറിയ പ്രതികരണങ്ങൾ എത്തുന്നു, വലിയ പ്രതികരണമോ വലിയ അപ്ലോഡോ തുടങ്ങുമ്പോൾ കണക്ഷൻ നിലയ്ക്കുന്നു, കാരണം അവയാണ് വലിച്ചെറിയാൻ മതിയായ വലിപ്പമുള്ള ആദ്യ പാക്കറ്റുകൾ. SSH ബന്ധിപ്പിച്ചശേഷം ആദ്യ വലിയ ഔട്ട്പുട്ടിൽ നിലയ്ക്കുന്നു, പേജിന്റെ ഹെഡർ ലോഡ് ചെയ്യുമ്പോൾ ബോഡി ഒരിക്കലും തീരുന്നുമില്ല.
ICMPv6-യുടെ പാക്കറ്റ് വളരെ വലുത് സന്ദേശങ്ങൾ ഫിൽട്ടർ ചെയ്താൽ, അയയ്ക്കുന്നയാൾ അത് ഒരിക്കലും അറിയില്ല, അതേ വലിപ്പം വീണ്ടും വീണ്ടും ശ്രമിക്കും. അത് കറുത്ത കുഴിയാണ്, മന്ദഗതിയിലുള്ള വഴിയല്ല, അതിന്റെ അടയാളം ആകസ്മിക നഷ്ടമല്ല, ആവർത്തിക്കാവുന്ന വലിപ്പപരിധിയാണ്. ബന്ധപ്പെട്ട നിയന്ത്രണ ട്രാഫിക് അനുവദിച്ചിട്ടിരിക്കുന്നത് പ്രവർത്തിക്കുന്ന IPv6 വിന്യാസത്തിന്റെ ഭാഗമാണ്, ദയയല്ല.
നിങ്ങളുടെ സ്വന്തം വഴി ആശ്രയിക്കുന്ന സന്ദേശങ്ങൾ ഓഫ് ചെയ്തിട്ട് ഫലത്തെ IPv6 കുറ്റമെന്ന് വിശേഷിപ്പിക്കരുത്. അതേ വാദം IPv4-ന്റെ Fragmentation Needed സന്ദേശങ്ങൾക്കും ബാധകമാണ്, അവ ഫയർവാൾ എഴുത്തുകാർക്കിടയിൽ ഒരുപോലെ അജനപ്രിയവും ഒരുപോലെ ആവശ്യവുമാണ്.
അതിർത്തി അളക്കൂ, പിന്നെ പാളി നന്നാക്കൂ
ഊഹിക്കാതെ പരിശോധിക്കൂ: IPv4-യിൽ don't-fragment ഫ്ലാഗും IPv6-യിൽ സ്ഥിരമായ പേലോഡ് വലിപ്പങ്ങളും ഉപയോഗിക്കൂ, പ്രതികരണങ്ങൾ എവിടെ നിൽക്കുന്നുവെന്ന് രേഖപ്പെടുത്തൂ. ping -M do -s 1472 ഉം ping -6 -s 1400 ഉം പ്രശ്നത്തിന്റെ രൂപം നിർണ്ണയിക്കാൻ മതി, കൂടാതെ tracepath വഴിയിൽ കണ്ടെത്തിയ പാത MTU റിപ്പോർട്ട് ചെയ്യുന്നു.
പിന്നെ ആ സംഖ്യയുടെ ഉടമയായ പാളി നന്നാക്കൂ: ടണൽ ഇന്റർഫേസിന്റെ MTU, TCP-യ്ക്കുള്ള MSS മുറുക്കൽ, അല്ലെങ്കിൽ വഴി തന്നെ. IPv6 നിയമത്തിന് RFC 8200 അവലംബമാണ്, അത് തടയുന്ന സംഭവത്തെക്കാൾ ചെറിയ വായനയാണ്.
ആപ്ലിക്കേഷൻ യഥാർത്ഥത്തിൽ ഉപയോഗിക്കുന്ന കുടുംബം പരിശോധിക്കൂ, കാരണം ഇരട്ട-സ്റ്റാക്ക് നാമം ഒരു കുടുംബത്തിൽ പ്രതികരിച്ചേക്കാം മറ്റൊന്നിൽ ഇല്ലായിരിക്കാം, നെറ്റ്വർക്ക് മാറ്റത്തിന് ശേഷം ആപ്ലിക്കേഷൻ മാറിയേക്കാം. പരിശോധിച്ച വിലാസം രേഖപ്പെടുത്തൂ, കാരണം A റെക്കോർഡിനെതിരായ ഫലം AAAA റെക്കോർഡിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല.
വലിപ്പപരിധിയെ തെളിവായി കാണൂ
ആവർത്തിക്കാവുന്ന വലിപ്പപരിധി ഓരോ തവണയും അതേ ബൈറ്റ് എണ്ണത്തിൽ, അതേ ഉറവിടത്തിൽ നിന്ന് കൃത്യമായി പുനരുൽപ്പാദിക്കുന്ന കുറച്ച് നെറ്റ്വർക്ക് തകരാറുകളിൽ ഒന്നാണ്. അത് അതിനെ ദുരൂഹതയല്ല, സമ്മാനമാക്കുന്നു, കൂടാതെ തിരുത്തൽ പ്രതീക്ഷിക്കുന്നതിന് പകരം പരിശോധിക്കാമെന്നും അർത്ഥമാക്കുന്നു.
കണ്ടെത്തിയ MTU, നിങ്ങൾ കോൺഫിഗർ ചെയ്ത ടണൽ MTU, വ്യത്യാസം തെളിയിച്ച പരിശോധന എന്നിവ ടിക്കറ്റിൽ എഴുതൂ. അടുത്തയാൾ മറ്റൊരു ലിങ്കിൽ അതേ ഗണിതം കാണും.