OpenVPN ടണലിലൂടെ IPv6: വീട്ടിലെ റൗട്ടറിനുള്ള ഘട്ടം ഘട്ടമായ സഞ്ചാരം

ലാപ്ടോപ്പിന് IPv6 വിലാസമുണ്ട്, ടണൽ IPv4-ന് മുകളിൽ പ്രവർത്തിക്കുന്നു, എന്നിട്ടും എല്ലാ IPv6 പരിശോധനയും പരാജയപ്പെടുന്നു. അല്ലെങ്കിൽ അതിലും മോശം: പരിശോധന വിജയിക്കുകയും ട്രാഫിക് ഒരിക്കലും ടണലിൽ പ്രവേശിക്കാതെ ISP പാതയിലൂടെ പുറത്തുപോകുകയും ചെയ്യുന്നു. രണ്ട് ഫലവും ഒരേ കാണാതായ തീരുമാനത്തിലേക്ക് തിരികെ വരുന്നു: റൗട്ടറിന് ക്ലയന്റുകളിലേക്ക് റൂട്ട് ചെയ്യാവുന്ന പ്രിഫിക്സ് ആരും നൽകിയില്ല. ക്ലയന്റിൽ നിന്ന് പുറത്തേക്ക് പാത പിന്തുടർന്നാൽ ഏത് ഭാഗമാണ് കാണാതായതെന്ന് കണ്ടെത്താം.

ക്ലയന്റ് ഇരിക്കുന്നിടത്തുനിന്ന് തുടങ്ങുക

സർവറിനെ തൊടുന്നതിന് മുൻപ് ക്ലയന്റിനെ നോക്കുക. ip -6 addr പൂളിൽ നിന്നുള്ള ടണൽ വിലാസം കാണിക്കണം, ip -6 route ടണൽ ഉപകരണത്തിലേക്ക് ചൂണ്ടുന്ന തള്ളിയ പ്രിഫിക്സ് കാണിക്കണം. വിലാസമുണ്ടെങ്കിലും പാതയില്ലെങ്കിൽ തള്ളൽ കാണാതായി അല്ലെങ്കിൽ ക്ലയന്റ് അത് അവഗണിച്ചു. രണ്ടും ഇല്ലെങ്കിൽ സർവർ ഒന്നും അനുവദിച്ചിട്ടില്ല.

പിന്നീട് ക്ലയന്റ് പുറംലോകത്തെക്കുറിച്ച് എന്ത് വിശ്വസിക്കുന്നു എന്ന് പരിശോധിക്കുക. ടണലിലൂടെയുള്ള ഡിഫോൾട്ട് പാത എല്ലാ IPv6 ട്രാഫിക്കും ആവശ്യപ്പെടുന്നു, അതേസമയം 2000::/3-നുള്ള പാത ആഗോള യൂണികാസ്റ്റ് മാത്രം ആവശ്യപ്പെടുന്നു. രണ്ടും ശരിയാകാം, അവ ചോര്ച്ചയെക്കുറിച്ച് വ്യത്യസ്ത ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകുന്നു.

IPv6 ഡിഫോൾട്ട് പാതയേ ഇല്ലാത്ത ക്ലയന്റ് ടണൽ തന്നെ പൂർണ്ണമായി ആരോഗ്യകരമായിരിക്കുമ്പോഴും എല്ലാ പൊതു പരിശോധനയിലും പരാജയപ്പെടുന്നു. അത് നയത്തിലെ വിടവാണ്, കേടായ ടണലല്ല.

സർവറിന് യഥാർത്ഥത്തിൽ റൂട്ട് ചെയ്യാവുന്ന പൂൾ പരിശോധിക്കുക

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

പൂളും തള്ളലും ഒരുമിച്ചാണ്. server-ipv6 2001:db8:80:10::/64 വിലാസങ്ങൾ അനുവദിക്കുന്നു, push "route-ipv6 2000::/3" ടണലിലേക്ക് എന്ത് അയക്കണമെന്ന് ക്ലയന്റുകളോട് പറയുന്നു. 2000::/3 തള്ളുന്നത് ആഗോള യൂണികാസ്റ്റ് ഉൾക്കൊള്ളുന്നു, link-local, multicast ശ്രേണികൾ ടണലിന് പുറത്ത് നിർത്തുന്നു.

തിരഞ്ഞെടുത്ത പ്രിഫിക്സ് വിന്യാസരേഖയിൽ എഴുതുക. അടുത്ത തവണ ISP കൈമാറ്റം മാറ്റുന്നയാൾ ഏത് /64 ടണൽ ഇതിനകം ഉപയോഗിക്കുന്നു എന്ന് അറിയണം.

രണ്ടാം കുടുംബത്തിനായി ഫോർവേഡിംഗ് ഓണാക്കുക

IPv4 ഫോർവേഡിംഗ് IPv6 ഫോർവേഡിംഗ് അർത്ഥമാക്കുന്നില്ല. net.ipv6.conf.all.forwarding=1 സെറ്റ് ചെയ്ത് IPv4 FORWARD നയം ഇതിനകം അനുവദിക്കുന്നതെല്ലാം പ്രതിഫലിപ്പിക്കുക. FORWARD ശൃംഖല സ്വതവേ ഉപേക്ഷിക്കുന്ന റൗട്ടറിൽ നിയമക്കൂട്ടം ഇല്ലാത്തത് മരിച്ച ടണലിനെപ്പോലെ തന്നെ തോന്നും.

ഹാൻഡ്ഷേക്ക് വിജയിക്കുന്നു, ക്ലയന്റിന് വിലാസം കിട്ടുന്നു, തിരികെ ഒന്നും വരുന്നില്ല. ഇരു ദിശകൾക്കും WAN ഭാഗത്തിനും നിയമങ്ങൾ ചേർക്കുക, കാരണം LAN-ൽ എത്തി ഇന്റർനെറ്റിൽ എത്താത്ത ടണൽ മൂന്നാം പരിശോധനയിൽ പരാജയപ്പെടും. പരാജയപ്പെട്ട ശ്രമത്തിന് ശേഷം ശൃംഖലയുടെ കൗണ്ടറുകൾ നോക്കുക, കാരണം ഒരിക്കലും പൊരുത്തപ്പെടാത്ത നിയമം പൊരുത്തപ്പെട്ട് ഉപേക്ഷിച്ച നിയമത്തിൽ നിന്ന് വ്യത്യസ്ത പ്രശ്നമാണ്.

ip6tables -A FORWARD -i br0 -o tun0 -j ACCEPT
ip6tables -A FORWARD -i tun0 -o br0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
ip6tables -A FORWARD -i tun0 -o wan0 -j ACCEPT

ഒരു പാർശ്വഫലം ഒടുവിൽ ടണലിനെ കുറ്റപ്പെടുത്തുന്നവരെ പിടിക്കുന്നു. ഫോർവേഡിംഗ് ഓണാക്കുമ്പോൾ കെർണൽ Router Advertisement വഴിയുള്ള വിലാസ കോൺഫിഗറേഷൻ ഒഴിവാക്കുന്നു, വേറെ പറയാത്ത പക്ഷം, അങ്ങനെ പഠിച്ച ഡിഫോൾട്ട് പാത അതിനൊപ്പം അപ്രത്യക്ഷമാകുന്നു. ഒന്നുകിൽ WAN ഇന്റർഫേസിൽ വ്യക്തമായ ഡിഫോൾട്ട് പാത പിൻ ചെയ്യുക, അല്ലെങ്കിൽ അവിടെ ബോധപൂർവം accept_ra 2 ആക്കുക. ഏത് മാറ്റത്തിനും ശേഷം ക്ലയന്റുകളെ വീണ്ടും പരിശോധിക്കുന്നതിന് മുൻപ് റൗട്ടറിന് ഇപ്പോഴും ഉപയോഗയോഗ്യമായ IPv6 പുറംപാത ഉണ്ടെന്ന് ഉറപ്പാക്കുക.

മേൽഭാഗം റൂട്ട് ചെയ്യാത്തപ്പോൾ അയൽക്കാർ കണ്ടെത്തലിന് ഉത്തരം നൽകുക

മേൽഭാഗ ഉപകരണങ്ങൾ ചിലപ്പോൾ നിയോഗിച്ച /64 തങ്ങളുടെ സ്വന്തം ലിങ്കിന്റേതായി കണക്കാക്കി VPN ബോക്സിലേക്ക് ഏതെങ്കിലും ഉപപ്രിഫിക്സ് റൂട്ട് ചെയ്യാൻ വിസമ്മതിക്കുന്നു. അങ്ങനെ സംഭവിക്കുമ്പോൾ ഓരോ ക്ലയന്റ് വിലാസത്തിനും വെവ്വേറെ അയൽ അഭ്യർത്ഥനകൾക്ക് എന്തെങ്കിലും ഉത്തരം നൽകണം.

OpenVPN അനുവദിച്ച വിലാസം client-connect ഹൂക്കിലേക്ക് തുറക്കുന്നു, അതിനാൽ കൈകൊണ്ട് സൂക്ഷിക്കുന്ന പട്ടികയ്ക്ക് പകരം എൻട്രികൾക്ക് യഥാർത്ഥ പൂളിനെ പിന്തുടരാം. ഹൂക്ക് ip -6 neigh add proxy $ifconfig_pool_remote_ip6 dev eth0 ചേർക്കുന്നു, യോജിക്കുന്ന client-disconnect ഹൂക്ക് അത് നീക്കം ചെയ്യുന്നു. നീക്കം ചെയ്യാത്ത പക്ഷം പ്രോക്സി പട്ടിക പഴകും, പിന്നീട് വരുന്ന ക്ലയന്റിന് ഒരിക്കലും ലഭിക്കാത്ത വിലാസത്തിന്റെ എൻട്രി പാരമ്പര്യമായി ലഭിച്ചേക്കാം. ip -6 neigh show proxy ഉപയോഗിച്ച് അവസ്ഥ ഉറപ്പാക്കുക.

പ്രോക്സിയെ താൽക്കാലിക പരിഹാരമായി കാണുക. ടണലിന്റെ /64-നായി റൗട്ടറിലേക്ക് ചൂണ്ടുന്ന സ്ഥിത പാത ക്ലയന്റ് മാറ്റങ്ങളെ അതിജീവിക്കുന്നു, പ്രത്യേകാവകാശമുള്ള ഷെൽ ഹൂക്ക് ആവശ്യമേയില്ല.

പുറത്തേക്കുള്ള പാത പിന്തുടരുക, ഒരു ഹോപ്പ് വീതം

മൂന്ന് ഘട്ടത്തിൽ പുറത്തേക്ക് പരിശോധിക്കുക: ആദ്യം റൗട്ടറിന്റെ ടണൽ വിലാസം, പിന്നെ LAN ഹോസ്റ്റ്, മൂന്നാമതായി traceroute6 വഴി പൊതു ലക്ഷ്യം. പൂൾ ആദ്യത്തേത് തെളിയിക്കുന്നു, ഫോർവേഡിംഗും LAN ഫയർവാളും രണ്ടാമത്തേത്, മേൽഭാഗത്തിലൂടെയുള്ള മടക്കപ്പാത മൂന്നാമത്തേത്. ഓരോ പരാജയവും മുഴുവൻ രൂപകൽപ്പന വീണ്ടും തുറക്കുന്നതിന് പകരം അന്വേഷണം ഒരു ഉപകരണത്തിൽ ഒതുക്കുന്നു.

ടണലിന്റെ MTU ശ്രദ്ധിക്കുക, കാരണം പാതയിലെ IPv6 റൗട്ടറുകൾ നിങ്ങൾക്കുവേണ്ടി ഖണ്ഡിക്കില്ല. വളരെ വലിയ MTU വൃത്തിയായ പരാജയത്തിന് പകരം packet-too-big പിശകും നിന്ന TLS ആയി പ്രത്യക്ഷപ്പെടുന്നു. അത് വ്യക്തമായി സെറ്റ് ചെയ്ത് പരിധിക്ക് അടുത്ത പേലോഡ് ഉപയോഗിച്ച് പരിശോധിക്കുക.