നിങ്ങളുടെ സ്വന്തം ഉറവിടം ഉപയോഗിച്ച് VPN വഴി IPv6 പരിശോധിക്കുന്നതെങ്ങനെ
ഒരു പാത പ്രവർത്തിക്കുന്നു എന്ന് തെളിയിക്കാൻ പൊതു IPv6 പരിശോധിനി ആവശ്യമില്ല। നിങ്ങൾ നിയന്ത്രിക്കുന്ന ഒരു ഉറവിടം ഉപയോഗിക്കുക, രണ്ട് അറ്റങ്ങളും രേഖപ്പെടുത്തുക, പരിശോധന എന്തൊക്കെ ഉൾക്കൊള്ളുന്നില്ല എന്ന് എഴുതുക।
ഒരു പൊതു IP പരിശോധനാ പേജ് ഒരു ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു, സാധാരണയായി നിങ്ങൾ ചോദിച്ച ചോദ്യത്തിനല്ല। പേജ് കണ്ട എക്സിറ്റ് വിലാസം അത് പറയുന്നു; ടണലിലൂടെയുള്ള IPv6 പാത പ്രവർത്തിക്കുന്നുണ്ടോ, ഹോസ്റ്റ് IPv6 ന് മുൻഗണന നൽകിയോ പിന്നോട്ട് പോയോ, ഒഴിവാക്കിയ ആപ്ലിക്കേഷൻ മറ്റൊരു പാത എടുത്തോ എന്നൊന്നും അത് പറയുന്നില്ല। നിങ്ങൾ നിയന്ത്രിക്കുന്ന അംഗീകൃത ഉറവിടം ഇടുങ്ങിയ ചോദ്യത്തിന് ശരിയായി ഉത്തരം നൽകുന്നു, കാരണം നിങ്ങൾ രണ്ട് അറ്റങ്ങളും കാണുന്നു। താഴെയുള്ള വഴികാട്ടി പ്രതിരോധിക്കാവുന്ന ഒരു നിഗമനത്തിൽ എത്തുന്നതിനെക്കുറിച്ചാണ്, പച്ച ഫലം നേടുന്നതിനെക്കുറിച്ചല്ല।
ഘട്ടം 1: ഏത് IPv6 പാതയാണ് നിങ്ങൾ പരിശോധിക്കുന്നതെന്ന് പറയുക
ഒരു വാക്യത്തിൽ അത് പറയുക। ടണൽ സെർവറിന്റെ സ്വന്തം IPv6 വിലാസത്തിലേക്കുള്ള അഭ്യർത്ഥന ടണൽ പരിശോധിക്കുന്നു; എക്സിറ്റിന് അപ്പുറമുള്ള ഹോസ്റ്റിലേക്കുള്ള അഭ്യർത്ഥന എക്സിറ്റിന്റെ IPv6 എഗ്രസ് പരിശോധിക്കുന്നു; സ്വകാര്യ IPv6 വിലാസത്തിലേക്കുള്ള അഭ്യർത്ഥന ആന്തരിക പാത പരിശോധിക്കുന്നു।
ഇവ മൂന്ന് വ്യത്യസ്ത അവകാശവാദങ്ങളാണ്, ഒരു വിജയകരമായ അഭ്യർത്ഥന മൂന്നിനെയും പിന്തുണയ്ക്കാൻ കഴിയില്ല। നിങ്ങളുടെ മുന്നിലുള്ള തീരുമാനത്തിന് പ്രധാനമായത് തിരഞ്ഞെടുത്ത് എന്തെങ്കിലും പ്രവർത്തിപ്പിക്കുന്നതിന് മുൻപ് അത് എഴുതിവയ്ക്കുക। ടണലിന് ചുറ്റും IPv6 ചോരുന്നുണ്ടോ എന്നതാണ് ആശങ്കയെങ്കിൽ, ചോദ്യം ഹോസ്റ്റിന്റെ പാത തിരഞ്ഞെടുപ്പിനെക്കുറിച്ചാണ്, എക്സിറ്റിന്റെ എത്തിച്ചേരാനുള്ള കഴിവിനെക്കുറിച്ചല്ല। അകലെയുള്ള വശത്തിന് ആന്തരിക സേവനത്തിൽ എത്താനാകുമോ എന്നതാണ് ആശങ്കയെങ്കിൽ, എക്സിറ്റ് അപ്രസക്തമാണ്।
ഘട്ടം 2: ഹോസ്റ്റ് ആ പാത തിരഞ്ഞെടുക്കുന്നുവെന്ന് ഉറപ്പാക്കുക
ip -6 route get 2001:db8:1::10 പാത, ഉറവിട വിലാസം, കേർണൽ ഉപയോഗിക്കുന്ന ഇന്റർഫേസ് എന്നിവ അച്ചടിക്കുന്നു, ബാക്കിയുള്ള പരിശോധന ഈ വസ്തുതയെ ആശ്രയിച്ചിരിക്കുന്നു।
ഒരു ഇന്റർഫേസ് ഉണ്ടായിരിക്കുന്നത് അത് തിരഞ്ഞെടുക്കപ്പെടുന്നതിന് തുല്യമല്ല। ഇരട്ട സ്റ്റാക്ക് ഹോസ്റ്റുകൾക്ക് മുൻഗണനാ പട്ടികയുണ്ട്, Linux ൽ /etc/gai.conf രണ്ടിലേക്കും പരിഹരിക്കുന്ന ഒരു പേരിന് ഏത് കുടുംബം വിജയിക്കുമെന്ന് മാറ്റാം।
ഘട്ടം 3: നിയമാനുസൃത ലക്ഷ്യവും പേരും ഉപയോഗിക്കുക
നിങ്ങൾ HTTPS പരിശോധിക്കുകയാണെങ്കിൽ, സർട്ടിഫിക്കറ്റ് പുറപ്പെടുവിച്ച ഹോസ്റ്റ് നാമം തന്നെ ഉപയോഗിക്കുകയും പരിശോധന ഓണായി വയ്ക്കുകയും ചെയ്യുക; പരിശോധന വിജയിക്കാൻ അക്ഷരാർത്ഥ വിലാസത്തിലേക്ക് മാറുന്നത് നിങ്ങൾ ഉദ്ദേശിച്ച ഹോസ്റ്റിൽ എത്തിയെന്ന് തെളിയിക്കുന്ന അതേ പരിശോധനയെ നിർജ്ജീവമാക്കുന്നു। നിങ്ങൾ നിയന്ത്രിക്കുന്ന ഡയഗ്നോസ്റ്റിക് സേവനം, അറിയപ്പെടുന്ന ഒരു പേരിൽ സാധുവായ സർട്ടിഫിക്കറ്റുമായി ഉത്തരം നൽകുന്നത്, ഏറ്റവും ശുദ്ധമായ ലക്ഷ്യമാണ്। അത് താരതമ്യപ്പെടുത്താൻ സെർവർ വശത്തെ ഒരു ലോഗ് വരിയും നൽകുന്നു, മൂന്നാം കക്ഷി പരിശോധിനി അത് ഒരിക്കലും നൽകില്ല।
ഉപയോഗിച്ച വിലാസം കാണിക്കുന്ന രൂപത്തിൽ അഭ്യർത്ഥന പ്രവർത്തിപ്പിക്കുക: curl -6 -sS -o /dev/null -w '%{remote_ip} %{http_code}\n' https://test6.example.net/। -6 കുടുംബത്തെ നിർബന്ധിക്കുന്നു, ഇങ്ങനെയാണ് നിങ്ങൾ IPv6 പ്രവർത്തിക്കുന്നില്ല എന്നതിനെ IPv6 മുൻഗണന ലഭിച്ചില്ല എന്നതിൽ നിന്ന് വേർതിരിക്കുന്നത്।
ICMPv6 അനുവദിച്ചിട്ടുള്ള ശുദ്ധമായ എത്തിച്ചേരൽ പരിശോധനയ്ക്ക് ping -6 -c 3 2001:db8:1::10 മതി। അത് പാത തെളിയിക്കുന്നു, അതിന് മുകളിൽ ഒന്നുമല്ല।
ഘട്ടം 4: രണ്ട് അറ്റങ്ങളും താരതമ്യപ്പെടുത്തുക
രണ്ട് അറ്റങ്ങളിലേക്കും പ്രവേശനമുണ്ടെങ്കിൽ, ക്ലയന്റിൽ tcpdump -ni any ip6 and host 2001:db8:1::10 ഉം ഉറവിടത്തിൽ അതിന് തുല്യമായതും സമയ മുദ്രകളോടെ പ്രവർത്തിപ്പിച്ച് അതേ പ്രവാഹം രണ്ടിലും കാണുന്നുവെന്ന് ഉറപ്പാക്കുക। അതാണ് സാധ്യതയുള്ള ഒരു ഫലത്തെ തെളിവാക്കി മാറ്റുന്നത്: ക്ലയന്റിന്റെ കാഴ്ച മാത്രം ഉറവിടത്തിന്റെ ഉത്തരത്തെ ഇടയിലുള്ള എന്തോ ഒന്നിന്റെ ഉത്തരത്തിൽ നിന്ന് വേർതിരിക്കാൻ കഴിയില്ല। പകർത്തൽ ഒരു ലക്ഷ്യത്തിലേക്ക് ഇടുങ്ങിയതാക്കി വയ്ക്കുക, ഔട്ട്പുട്ട് വായനയ്ക്ക് യോഗ്യമായി നിലനിൽക്കട്ടെ, ആരുടെയും ബന്ധമില്ലാത്ത സെഷൻ ഫയലിൽ എത്താതിരിക്കട്ടെ।
നയം പുനരാരംഭത്തെ അതിജീവിക്കുമോ എന്നതാണ് ആശങ്കയെങ്കിൽ, വീണ്ടും ബന്ധിപ്പിച്ചതിന് ശേഷം പരിശോധന ആവർത്തിക്കുക। ബന്ധിപ്പിക്കുമ്പോൾ ഒരിക്കൽ പ്രയോഗിച്ച പാതയുടെയും ഫയർവാളിന്റെയും അവസ്ഥ വീണ്ടും പ്രയോഗിക്കുന്ന അവസ്ഥയിൽ നിന്ന് വ്യത്യസ്തമായേക്കാം, വ്യത്യാസം രണ്ടാം ബന്ധത്തിൽ മാത്രം പ്രത്യക്ഷപ്പെടുന്നു।
ആവശ്യമെങ്കിൽ പരാജയ സാഹചര്യം വെവ്വേറെ പരിശോധിക്കുക। വീഴുമ്പോൾ IPv6 തടയുന്ന ടണലും അത് ചോരാൻ അനുവദിക്കുന്ന ടണലും വ്യത്യസ്ത രൂപകൽപ്പനകളാണ്, അവയിൽ ഒന്നിനെ മാത്രമേ വിജയകരമായ അഭ്യർത്ഥന കൊണ്ട് സ്ഥിരീകരിക്കാൻ കഴിയൂ।
ഘട്ടം 5: പരിശോധന എന്ത് തെളിയിച്ചില്ലെന്ന് എഴുതുക
അഞ്ചാം ഘട്ടം പരിശോധന എന്ത് തെളിയിച്ചില്ലെന്ന് എഴുതുന്നതാണ്, ഈ ഭാഗമാണ് പലപ്പോഴും വിട്ടുപോകുന്നത്। സ്വകാര്യ അന്ത്യ ബിന്ദുവിലേക്കുള്ള വിജയകരമായ പരിശോധന പൊതു IPv6 എഗ്രസ് തെളിയിക്കുന്നില്ല, DNS സ്വഭാവം തെളിയിക്കുന്നില്ല, ടണലിൽ നിന്ന് നിങ്ങൾ ഒഴിവാക്കിയ ആപ്ലിക്കേഷനുകളെ ഉൾക്കൊള്ളുന്നുമില്ല। അവയോരോന്നിനും സ്വന്തം ലക്ഷ്യവും സ്വന്തം നിരീക്ഷണവും വേണം। ഒരു ഹോസ്റ്റിലേക്ക് ഒരു അഭ്യർത്ഥനയ്ക്ക് ശേഷം IPv6 പ്രവർത്തിക്കുന്നു എന്ന കുറിപ്പ് കണ്ടെത്തലല്ല; അത് സമയ മുദ്രയുള്ള ഒരു ഊഹമാണ്।
സൂക്ഷിക്കാൻ യോഗ്യമായ രേഖ ചെറുതാണ്: ലക്ഷ്യം, പേര്, ഹോസ്റ്റ് തിരഞ്ഞെടുത്ത ഉറവിട വിലാസം, നിരീക്ഷിച്ച വിദൂര വിലാസം, സമയം। RFC 7359 പ്രസക്തമായ ഒരു IPv6 പാത യഥാർത്ഥത്തിൽ ഉപയോഗയോഗ്യമാണോ എന്ന് പരിശോധിക്കുന്നതിനെക്കുറിച്ച് ചർച്ച ചെയ്യുന്നു, ഈ വഴികാട്ടി ലളിതമായ ഉപകരണങ്ങളോടെ അതിനോട് അടുക്കുന്നു। നിഗമനം ശരിയാകാൻ ഒരു പൊതു പരിശോധിനി ആവശ്യമെങ്കിൽ, പരിശോധന മതിയായവിധം നിർദ്ദിഷ്ടമായിരുന്നില്ല।