IPv4 VPN സർവറിലൂടെയുള്ള IPv6-ന് ഇപ്പോഴും യഥാർത്ഥ IPv6 എക്സിറ്റ് വേണം

ടണൽ ഉയരുന്നു, ക്ലയന്റ് പൂളിൽ നിന്ന് IPv6 വിലാസം സ്വീകരിക്കുന്നു, എന്നിട്ടും ഓരോ IPv6 ലക്ഷ്യവും സമയപരിധി കഴിയുന്നു. ടണലിൽ ഒന്നും കേടായിട്ടില്ല: IPv6, IPv4 ഗതാഗതത്തിനുള്ളിൽ നന്നായി സഞ്ചരിക്കുന്നു, അത് ഒരിക്കലും ബുദ്ധിമുട്ടുള്ള ഭാഗമായിരുന്നില്ല. നിങ്ങൾ നൽകിയ വിലാസം സർവറിന് പാലിക്കാനാവാത്ത ഒരു വാഗ്ദാനമാണ്, കാരണം എക്സിറ്റിന് അത് അയയ്ക്കാൻ ഒരു IPv6 upstream ഇല്ല. അറ്റകുറ്റപ്പണി എക്സിറ്റിലാണ്, ക്ലയന്റ് പ്രൊഫൈലിലല്ല.

രോഗലക്ഷണം: വിലാസമുണ്ട്, വഴിയില്ല

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

ക്ലയന്റ് തൊടുന്നതിന് മുൻപ് സർവറിന്റെ സ്വന്തം റൂട്ടിംഗ് പട്ടിക വായിക്കുക, കാരണം വഴിയുടെ കാണാതായ പകുതി അവിടെയാണ്. ഒരു IPv4 ഡിഫോൾട്ട് റൂട്ട് ഉള്ള സർവർ നിങ്ങൾക്ക് ഉത്തരം നൽകിക്കഴിഞ്ഞു.

ഡീകാപ്സുലേഷന് ശേഷം പാക്കറ്റ് പിന്തുടരുക

ടണലിനുള്ളിൽ പാക്കറ്റ് സാധാരണ IPv6 ആണ്, അതിന്റെ ഉറവിടം ക്ലയന്റിന്റെ വിലാസമാണ്. സർവർ ഗതാഗത കാപ്സുലേഷൻ ഊരിമാറ്റി, തുടർന്ന് അടുത്ത IPv6 ഹോപ്പിലേക്ക് കൈമാറേണ്ട ഒരു സ്വദേശീയ IPv6 പാക്കറ്റ് കൈവശം വയ്ക്കുന്നു. IPv4 ഡിഫോൾട്ട് റൂട്ടിന് അത് വഹിക്കാനാവില്ല, അത് IPv4-ലേക്ക് വിവർത്തനം ചെയ്യുന്നത് ആരും വിന്യസിക്കാത്ത മറ്റൊരു പ്രവർത്തനമാണ്. അതാണ് മുഴുവൻ പരാജയം, VPN ലിസണർ IPv4 വഴി ഉത്തരം നൽകിയോ എന്നതുമായി അതിന് യാതൊരു ബന്ധവുമില്ല.

IPv4-ന് മുകളിൽ IPv6 കാപ്സുലേറ്റ് ചെയ്യുന്ന രീതി RFC 4213-ൽ വിവരിച്ചിരിക്കുന്നു, അവിടെയുള്ള പ്രധാന വിശദാംശം എന്തെന്നാൽ അഗ്രങ്ങൾക്ക് ടണലിന്റെ മറുവശത്ത് ഇപ്പോഴും യഥാർത്ഥ IPv6 കണക്റ്റിവിറ്റി ആവശ്യമാണ്. ഒരു ഹെഡർ പൊതിഞ്ഞാൽ upstream മായാജാലത്തിൽ ഉണ്ടാകുന്നില്ല.

രണ്ട് ടണൽ പാളികൾ, രണ്ട് സ്വതന്ത്ര പരിശോധനകൾ

ഓരോ പാളിയും വെവ്വേറെ പരിശോധിക്കുക, കാരണം പ്രവർത്തിക്കുന്ന പുറം ടണൽ കേടായ ഉൾ ടണലിനെ മറയ്ക്കുന്നു. പുറം വഴി ക്ലയന്റിൽ നിന്ന് സർവറിലേക്ക് IPv4 പിംഗ് ഉപയോഗിച്ച് പരിശോധിച്ച് നിങ്ങൾ ഉപയോഗിക്കുന്ന പോർട്ട് ഉറപ്പാക്കുക. തുടർന്ന് സർവറിൽ ഉൾ വഴി പരിശോധിക്കുക, അവിടെ ip -6 route യഥാർത്ഥ upstream-ൽ നിന്ന് പഠിച്ച ഡിഫോൾട്ട് അല്ലെങ്കിൽ നിർദ്ദിഷ്ട റൂട്ട് കാണിക്കണം, ഒപ്പം ip -6 addr upstream സ്വീകരിക്കുന്ന ഉറവിട പ്രിഫിക്സ് കാണിക്കണം. അതിൽ കുറവ് ഇന്റർഫേസിലെ അലങ്കാരം മാത്രമാണ്.

ഒരു അനന്യ-പ്രാദേശിക വിലാസമോ, ആഗോളമായി തോന്നുന്ന എന്നാൽ ഒന്നും തിരികെ റൂട്ട് ചെയ്യാത്ത ഒരു പ്രിഫിക്സോ സന്തോഷത്തോടെ ഇന്റർഫേസിൽ പ്രത്യക്ഷപ്പെടുകയും എങ്ങോട്ടും പോകാതിരിക്കുകയും ചെയ്യും. പൊതു എത്തിച്ചേരൽ അനുവദിക്കുന്നത് upstream ആണ്, വിലാസത്തിന്റെ ആകൃതിയല്ല.

അതേ കാര്യം ക്ലയന്റിനും ബാധകമാണ്: ip -6 route get 2001:4860:4860::8888 ടണൽ ഉപകരണം പേര് പറയണം; ഭൗതിക ഉപകരണമാണ് പേര് പറയുന്നതെങ്കിൽ ക്ലയന്റ് IPv6-ന് VPN ഒട്ടും ഉപയോഗിക്കുന്നില്ല.

ഉറവിട പ്രിഫിക്സ്, വലിപ്പം, ICMPv6

ഫോർവേഡിംഗിനായി ഏത് ഉറവിട പ്രിഫിക്സുകൾ സ്വീകരിക്കുമെന്ന് upstream-നോട് ചോദിക്കുക, അവയിലൊന്ന് ക്ലയന്റ് പൂളിന് ഉപയോഗിക്കുക. സർവറിന്റെ സ്വന്തം ഇന്റർഫേസിന് നിങ്ങൾക്ക് /64 നൽകുന്ന ദാതാവ് രണ്ടാമതൊരു /64 അല്ലെങ്കിൽ വലിയ ബ്ലോക്ക് നിങ്ങളിലേക്ക് റൂട്ട് ചെയ്യണമെന്നില്ല, വ്യത്യാസം ഒരു ഉച്ചയ്ക്ക് ശേഷമുള്ള ഡീബഗ്ഗിംഗ് ആണ്, അത് ഒരു സപ്പോർട്ട് ടിക്കറ്റ് ഒരു ചോദ്യത്തിൽ തീർക്കുന്നു. എഴുതി ചോദിക്കുക, ഉത്തരം കോൺഫിഗറേഷനൊപ്പം സൂക്ഷിക്കുക.

നിങ്ങളുടെ സ്റ്റാക്ക് യഥാർത്ഥത്തിൽ ഉപയോഗിക്കുന്ന അധിക കാപ്സുലേഷന് ബജറ്റ് ഇടുക, Packet Too Big ഉൾപ്പെടെ ICMPv6 പ്രവർത്തനക്ഷമമായി നിലനിർത്തുക. രണ്ടാമതൊരു ഹെഡർ ഉപയോഗയോഗ്യമായ പേലോഡ് ചെറുതാക്കുന്നു, അതിനാൽ ചെറിയ പിംഗുകൾക്ക് ഉത്തരം നൽകുന്ന വഴിക്കും ഫയൽ കൈമാറ്റത്തിൽ പരാജയപ്പെടാം, എല്ലാ ICMPv6-ഉം വലിച്ചെറിയുന്ന ഫയർവാൾ പരിഹരിക്കാവുന്ന വലിപ്പ പ്രശ്നത്തെ കറുത്ത കുഴിയാക്കുന്നു. സേവനം പ്രഖ്യാപിക്കുന്നതിന് മുൻപ് ഒരു വലിയ കൈമാറ്റം പരിശോധിക്കുക.

ഏതാണ് തികച്ചും വ്യത്യസ്തമായ പ്രശ്നം

IPv4 മാത്രം ഉള്ള ഒരു ആപ്ലിക്കേഷനിലേക്ക് IPv6 മാത്രം ഉള്ള ക്ലയന്റിൽ നിന്ന് എത്തുന്നത് വിവർത്തനമാണ്, ടണലിംഗല്ല, അതിന് ബോധപൂർവം വിന്യസിച്ച NAT64 പോലെ എന്തെങ്കിലും വേണം. നിങ്ങൾ ഒരു അധിക ടണൽ ഹെഡർ ചേർത്തതുകൊണ്ട് മാത്രം ലക്ഷ്യസ്ഥാനം അത് മനസ്സിലാക്കില്ല. ചരിത്രപരമായ പരിവർത്തന സേവനങ്ങൾക്കും അതേ ശ്രദ്ധ വേണം: RFC 7526 6to4 anycast റിലേ മാതൃക റദ്ദാക്കി, അതിനാൽ അതിനെ ചുറ്റിപ്പറ്റി എഴുതിയ ഗൈഡ് ഇനി പരിപാലിക്കപ്പെടുന്ന പൊതു റിലേ ഇല്ലാത്ത ഒന്നിനെ വിവരിക്കുന്നു.

സർവറിന് ഉപയോഗയോഗ്യമായ IPv6 upstream ഇല്ലെങ്കിൽ ഓപ്ഷനുകൾ പിന്തുണയുള്ള upstream, മറ്റൊരു എക്സിറ്റ്, അല്ലെങ്കിൽ IPv6 ടണലിന് പുറത്ത് തുടരുമെന്ന രേഖപ്പെടുത്തിയ തീരുമാനം എന്നിവയാണ്. സ്വീകാര്യമല്ലാത്തത് IPv6 സേവനം ഉണ്ടെന്ന് ക്ലയന്റുകളോട് പറയുമ്പോൾ അവരുടെ സാധാരണ IPv6 കണക്ഷൻ നിശബ്ദമായി VPN ഒഴിവാക്കുന്നതാണ്.