നിങ്ങളുടെ IPv6 ടണലിലെ പങ്കാളിക്ക് ping പരാജയപ്പെടുന്നോ? :: വിലാസം പരിശോധിക്കുക

നിങ്ങളുടെ IPv6 ടണലിന്റെ ഒരറ്റം മറ്റേ അറ്റത്തേക്ക് ping അയയ്ക്കുന്നു, എന്നാൽ എപ്പോഴും ഒരു ദിശ മാത്രമാണ് മറുപടി നൽകുന്നത്. ഇന്റർഫേസ് പ്രവർത്തനക്ഷമമാണ്, റൗട്ട് ശരിയായി കാണുന്നു, ലോഗിൽ ഇത് വിശദീകരിക്കുന്ന ഒന്നുമില്ല. നിങ്ങൾ നൽകിയ വിലാസം സബ്നെറ്റ്-റൗട്ടർ anycast വിലാസമാണ്, അത് ഒരിക്കലും ഹോസ്റ്റ് വിലാസമല്ല, രണ്ടറ്റം ഉള്ള ലിങ്കിൽ അതിന് കൃത്യമായി ഒരു ഡെലിവറി ലക്ഷ്യമുണ്ട്: അയച്ചയാൾ. ഏത് ടൈംഔട്ട് മൂല്യവും ഇത് ശരിയാക്കില്ല, കാരണം വിലാസം നിങ്ങൾ കരുതുന്ന കാര്യം ചെയ്യുന്നില്ല.

വിലാസത്തിലേക്ക് ചൂണ്ടുന്ന ലക്ഷണം

ലിങ്കിലെ എല്ലാ ഹോസ്റ്റുകളും മറുപടി നൽകുന്നു, ഇന്റർഫേസ് ഐഡന്റിഫയർ എല്ലാം പൂജ്യമായ ഹോസ്റ്റ് ഒഴികെ. ആ രൂപത്തിലേക്ക് വിലാസമിട്ട പാക്കറ്റ് നിർവചനപ്രകാരം സബ്നെറ്റിലെ റൗട്ടറിലേക്ക് എത്തിക്കുന്നു, അതിനാൽ പോയിന്റ്-ടു-പോയിന്റ് ടണലിൽ അത് അയച്ച യന്ത്രത്തിലേക്ക് തന്നെ തിരികെ വരുന്നു. അകലെയുള്ള അറ്റത്തുനിന്ന് ഇത് എത്തിച്ചേരാനാകാത്ത പങ്കാളിയായി വായിക്കപ്പെടുന്നു; അടുത്ത അറ്റത്തുനിന്ന് നിശ്ശബ്ദതയായി. അതേ പ്രിഫിക്സിലെ മറ്റൊരു ഐഡന്റിഫയർ മാറ്റിവയ്ക്കുക, മറ്റ് മാറ്റമില്ലാതെ ലക്ഷണം അപ്രത്യക്ഷമാകും, റൗട്ടുകളിൽ സ്പർശിക്കുന്നതിന് മുമ്പ് നേടേണ്ട സ്ഥിരീകരണം അതാണ്.

എല്ലാം പൂജ്യമായ ഐഡന്റിഫയർ anycast ആയി സംവരണം ചെയ്തിരിക്കുന്നു

RFC 4291 എല്ലാം പൂജ്യമായ ഇന്റർഫേസ് ഐഡന്റിഫയറിനെ സബ്നെറ്റ്-റൗട്ടർ anycast വിലാസമായി നിലനിർത്തുന്നു, അതിനാൽ /64 പോലുള്ള 2001:db8:4a::/64 ൽ ഉപയോഗയോഗ്യമായ ഹോസ്റ്റ് ഇല്ല 2001:db8:4a:: വിലാസത്തിൽ. ഈ സംവരണം അതിന്റെ സ്ഥാനം അർഹിക്കുന്നു: റൗട്ടർ പരസ്യങ്ങളും അയൽവാസി കണ്ടെത്തലും ആ രൂപത്തെ വിലാസമിടുന്നു, റൗട്ടർ താൻ സേവിക്കുന്ന പ്രിഫിക്സിനുവേണ്ടി മറുപടി നൽകുന്നു. ആ മൂല്യം ടണൽ അറ്റത്തിന് നൽകുന്നത് ഒരു ഇലയ്ക്ക് റൗട്ടർ പങ്ക് നൽകുന്നു, അതുകൊണ്ടാണ് ഒന്നും തിരികെ വരാത്തത്. പ്രിഫിക്സിലെ മറ്റേതെങ്കിലും ഐഡന്റിഫയർ ഹോസ്റ്റായി പ്രവർത്തിക്കുന്നു, അതിനാൽ പരിഹാരം സാധാരണയായി ഒരു അക്കമാണ്.

ടണൽ അറ്റത്തുനിന്ന് ഏറ്റെടുക്കാൻ അവകാശമില്ലാത്ത ഒരു പങ്കായി സംവരണത്തെ കാണുക, റൗട്ട് ഉപയോഗിച്ച് ഒഴിവാക്കാവുന്ന വിചിത്രതയായി അല്ല.

ഹോസ്റ്റ് വിലാസങ്ങൾ നൽകി പ്രിഫിക്സ് റൗട്ട് ചെയ്യുക

രണ്ട് അറ്റങ്ങൾക്കും ::1 ഉം ::2 ഉം തിരഞ്ഞെടുക്കുക, ഒന്ന് ഇതുപയോഗിച്ച് ചേർക്കുക: ip -6 addr add 2001:db8:4a::2/64 dev tun0, തുടർന്ന് ദൂരെയുള്ള പ്രിഫിക്സിന് വിലാസം നൽകാൻ ശ്രമിക്കുന്നതിനുപകരം അത് റൗട്ട് ചെയ്യുക. 2001:db8:4a::/64 എന്നതിനുള്ള റൗട്ട് ടണലിലൂടെ ദൂരെയുള്ള വശം എത്താവുന്നതാക്കുന്നു; വിലാസം മാത്രം ലോക്കൽ ഇന്റർഫേസ് കോൺഫിഗർ ചെയ്യുന്നു.

പൂർണ്ണ ടണലിന് മൂന്നാം ഘട്ടമുണ്ട്, ഉപകരണത്തിലൂടെ ആഗോള unicast-നുള്ള ഡിഫോൾട്ട് റൗട്ട്, ഇത് എല്ലാം ടണലിലേക്ക് അയയ്ക്കുന്നതിന്റെ IPv6 തുല്യതയാണ്. ഇത് ഒഴിവാക്കിയാൽ, IPv4 ടണലിനുള്ളിൽ സഞ്ചരിക്കുമ്പോൾ IPv6 ഭൗതിക ലിങ്ക് ഉപയോഗിച്ചുകൊണ്ടിരിക്കും, അതിനാൽ നിങ്ങൾ മൂടിയതായി കരുതിയ ട്രാഫിക് തന്നെ ഹോസ്റ്റ് ചോർത്തുന്നു. ഇതുപയോഗിച്ച് സ്ഥിരീകരിക്കുക: ip -6 route get 2001:4860:4860::8888 കൂടാതെ ഉത്തരം അനുമാനിക്കുന്നതിനുപകരം ഏത് ഉപകരണത്തെ പേരെടുത്ത് പറയുന്നു എന്ന് വായിക്കുക.

റൗട്ടിംഗിന് മുമ്പ് multicast നിരസിക്കപ്പെടുന്നു

Android VpnService.Builder എന്നതിനുള്ള വിലാസങ്ങളും റൗട്ടുകളും LinkAddress വഴി സാധുത പരിശോധിക്കുന്നു, ആ കൺസ്ട്രക്ടർ multicast നേരിട്ട് നിരസിക്കുന്നു. റൗട്ടായി multicast പ്രിഫിക്സ് നൽകിയാൽ ഫലം റൗട്ടല്ല, മോശം LinkAddress പരാമീറ്ററുകളുടെ പരാജയമാണ്, അത് നെറ്റ്വർക്കിന്റെ ഉത്തരമല്ല, സാധുതയുടെ ഉത്തരമാണ്. ഈ നിരസിക്കൽ മാധ്യമവുമായി യോജിക്കുന്നു: പോയിന്റ്-ടു-പോയിന്റ് tun ഉപകരണത്തിന് ലിങ്ക്-പാളി multicast ഇല്ല, അതിനാൽ അതിൽ ഗ്രൂപ്പ് റൗട്ടിന് ഇൻസ്റ്റാൾ ചെയ്യാൻ ഡെലിവറി മാതൃകയില്ല. ഗ്രൂപ്പ് വിലാസങ്ങൾ കൈകൊണ്ട് കോൺഫിഗർ ചെയ്യുന്നതിനുപകരം സ്റ്റാക്ക് തന്നെ സൃഷ്ടിച്ച് ഉപയോഗിക്കുന്നു.

IPv6 all-nodes, solicited-node വിലാസങ്ങളും അതേ നിയമത്തിന് കീഴിലാണ്. ഇന്റർഫേസ് അവയെ വഹിക്കുന്നത് സ്റ്റാക്ക് അവിടെ വെച്ചതുകൊണ്ടാണ്, ഏതെങ്കിലും നയം അവ ഉദ്ദേശിച്ചതുകൊണ്ടല്ല.

ടണലിന് പകരം എന്ത് വഹിക്കാം

ടണലിലൂടെയുള്ള multicast കണ്ടെത്തൽ നീക്കാൻ ഗ്രൂപ്പ് അംഗത്വം മനസ്സിലാക്കുന്ന ഒരു പാളി വേണം: Ethernet സെഗ്മെന്റ് അവതരിപ്പിക്കുന്ന TAP ബ്രിഡ്ജ്, ആപ്ലിക്കേഷൻ തലത്തിലുള്ള റിലേ, അല്ലെങ്കിൽ ഏത് പങ്കാളികളിലേക്ക് പകർത്തണം എന്ന് വ്യക്തമായി പറയപ്പെട്ട റൗട്ടിംഗ് പ്രോട്ടോക്കോൾ. VpnService മാതൃകയിൽ ഇവയൊന്നും ഇല്ല, അവിടെ ആപ്ലിക്കേഷൻ പാക്കറ്റുകൾ വായിക്കുകയും എഴുതുകയും ചെയ്യുന്നു, ടണലിനുവേണ്ടി ഗ്രൂപ്പിൽ ചേരുന്ന ഒരു കോളും ഇല്ല. ഗ്രൂപ്പുകൾ മനസ്സിലാക്കുന്ന ഘടകം ചേർക്കുകയോ ഡിസൈനിൽനിന്ന് ആവശ്യകത ഒഴിവാക്കുകയോ ചെയ്യുക.

നേരെമറിച്ച് unicast-ന് മുകളിലെ വിലാസങ്ങൾക്കും റൗട്ടുകൾക്കും പുറമേ ഒന്നും അധികം ആവശ്യമില്ല, അതുകൊണ്ടാണ് ടണലുകൾ അത് വഹിക്കുമെന്ന് പ്രതീക്ഷിക്കപ്പെടുന്നത്, പിന്നീട് കണ്ടെത്തൽ പ്രോട്ടോക്കോൾ പരാജയപ്പെടുമ്പോൾ അവയെ കുറ്റപ്പെടുത്തുന്നത്.

എന്തെങ്കിലും നൽകുന്നതിന് മുമ്പ് മൂന്ന് പരിശോധനകൾ

വിലാസം anycast രൂപമല്ലെന്ന്, അത് multicast അല്ലെന്ന്, പ്രിഫിക്സ് ഉപകരണത്തിന് മാത്രം നൽകിയതല്ല, റൗട്ട് ചെയ്തതാണെന്ന് ഉറപ്പാക്കുക. തുടർന്ന് നിങ്ങളുടെ പരീക്ഷണം യഥാർത്ഥ ഹോസ്റ്റായ ലക്ഷ്യസ്ഥാനത്തേക്ക് അയയ്ക്കുക, anycast വിലാസത്തിലേക്ക് ലക്ഷ്യമിട്ട ping അയച്ചയാളെ അളക്കുകയും പാതയെക്കുറിച്ച് ഒന്നും പറയുകയും ചെയ്യുന്നില്ല. ആ മൂന്ന് പരിശോധനകൾ മാറ്റരേഖയിൽ സൂക്ഷിക്കുക, അടുത്ത വിന്യാസം അവ വീണ്ടും കണ്ടെത്താതിരിക്കാൻ.

പ്ലാറ്റ്ഫോം ഒരിക്കലും ഇൻസ്റ്റാൾ ചെയ്യാത്ത റൗട്ട് കൂടുതൽ നേരം കാത്തിരുന്ന് ഡീബഗ് ചെയ്യാനാവില്ല, ഒരിക്കലും ഹോസ്റ്റായിരുന്നിട്ടില്ലാത്ത വിലാസം മികച്ച ping ഉപയോഗിച്ച് ശരിയാക്കാനും ആവില്ല.