OpenVPN വീണ്ടും ആരംഭിച്ചതിന് ശേഷം IPv6 എഗ്രെസ് മരിക്കുന്നു: പ്രിഫിക്സ് ഉടമസ്ഥത പരിശോധിക്കുക
ടണൽ വീണ്ടും സൃഷ്ടിച്ചതിന് ശേഷം IPv6 മരിക്കുന്നു. എന്തെങ്കിലും വീണ്ടും ആരംഭിക്കുന്നതിന് മുമ്പ് ഡെലിഗേറ്റ് ചെയ്ത പ്രിഫിക്സ്, ക്ലയന്റ് വിലാസങ്ങൾ, തിരികെയുള്ള റൂട്ട് എന്നിവ ആരുടേതാണെന്ന് തീരുമാനിക്കുക.
IPv6 ട്രാഫിക് കടത്തിവിടുന്നത് നിർത്തുന്നത് OpenVPN വീണ്ടും ആരംഭിക്കുന്ന നിമിഷത്താണ്, IPv4 അപ്പോഴും പ്രവർത്തിക്കുന്നു. ടണൽ ഇന്റർഫേസ് വീണ്ടും സൃഷ്ടിക്കപ്പെട്ടു, അതിന്റെ IPv6 അവസ്ഥ കൈകാര്യം ചെയ്തിരുന്ന മറ്റെന്തോ വിലാസം നഷ്ടപ്പെടുത്തി അല്ലെങ്കിൽ പ്രിഫിക്സ് എത്തിച്ചേരാവുന്നതാക്കുന്ന റൂട്ട് നഷ്ടപ്പെടുത്തി. മൂന്ന് വേറിട്ട അവസ്ഥാ ഭാഗങ്ങൾ ഇതിൽ ഉൾപ്പെടുന്നു, ഓരോന്നിനും വ്യത്യസ്ത ഉടമയാണ്: ദാതാവിന്റെ ഡെലിഗേറ്റ് ചെയ്ത പ്രിഫിക്സും അതിന്റെ ആയുസ്സും, VPN ക്ലയന്റുകൾക്ക് നൽകുന്ന വിലാസങ്ങൾ, ആ ക്ലയന്റ് പ്രിഫിക്സ് സെർവറിലേക്ക് തിരികെ അയക്കുന്ന അപ്സ്ട്രീം റൂട്ട്. ഏതെങ്കിലും ഡീമൺ തൊടുന്നതിന് മുമ്പ് ഓരോന്നിന്റെയും ഉടമയെ തിരിച്ചറിയുക, കാരണം തെറ്റായത് വീണ്ടും ആരംഭിച്ചാൽ പ്രശ്നം ഒരു ദിവസം മറഞ്ഞിരിക്കുകയും അടുത്ത കണക്ഷനിൽ തിരികെ വരികയും ചെയ്യും.
IPv6 അവസ്ഥയുടെ മൂന്ന് ഭാഗങ്ങൾ, മൂന്ന് ഉടമകൾ
| State | Typical owner | What breaks when it is wrong |
|---|---|---|
| Delegated prefix and lifetime | Upstream router or provider via DHCPv6-PD | Clients keep addresses that the upstream no longer routes |
| Client addresses inside the tunnel | OpenVPN server config or a delegation daemon | No global address, or an address outside the routed prefix |
| Return route for the client prefix | Upstream router, or the server's own routing table | Outbound works, replies never arrive |
ടണലിനുള്ളിലെ ആഗോള പരിധിയുള്ള വിലാസം മാത്രം മതിയാകില്ല. അപ്സ്ട്രീം റൗട്ടർമാർ ആ പ്രിഫിക്സ് VPN സെർവറിലേക്ക് തിരികെ അയക്കണം, സെർവറിന് അതിൽ നിന്ന് ഒരു വിലാസം യാദൃശ്ചികമായി ഉള്ളതുകൊണ്ട് അവർ അത് ചെയ്യില്ല.
അതുകൊണ്ടാണ് പൊതു /64 ഒരു ടണൽ പൂളിലേക്ക് പകർത്തുന്നതും അപകടകരമാകുന്നത്. സെർവറിലേക്ക് റൂട്ട് ചെയ്ത പ്രിഫിക്സ്, അപ്സ്ട്രീം on-link ആയി കണക്കാക്കുന്ന പ്രിഫിക്സിന് തുല്യമല്ല, അയൽവാസി കണ്ടെത്തൽ ആ വിടവ് നികത്തില്ല.
എന്തെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് സെർവറിന്റെ അവസ്ഥ വായിക്കുക
അവസ്ഥ രണ്ടുതവണ രേഖപ്പെടുത്തുക, ഒരിക്കൽ IPv6 പ്രവർത്തിക്കുമ്പോൾ, ഒരിക്കൽ വീണ്ടും ആരംഭിച്ചതിന് ശേഷം, എന്നിട്ട് താരതമ്യം ചെയ്യുക. വായനയ്ക്ക് മാത്രമുള്ള കാഴ്ചകൾ മതിയാകും, അറ്റകുറ്റപ്പണി സമയത്ത് അവയ്ക്ക് ചെലവില്ല:
ip -6 addr show
ip -6 route show table all
ip -6 rule show
sysctl net.ipv6.conf.all.forwardingമൂന്ന് നിർദിഷ്ട വ്യത്യാസങ്ങൾ നോക്കുക: അപ്രത്യക്ഷമായ ഒരു റൂട്ട്, കാലഹരണപ്പെട്ട അല്ലെങ്കിൽ അസാധുവായ ആയുസ്സിലേക്ക് മാറിയ ഒരു വിലാസം, വീണ്ടും ഡെലിഗേഷന് ശേഷം മാറിയതും എന്നാൽ VPN കോൺഫിഗറേഷൻ ഇപ്പോഴും പഴയത് പ്രഖ്യാപിക്കുന്നതുമായ ഒരു പ്രിഫിക്സ്.
വിലാസം അപ്രത്യക്ഷമായെങ്കിലും പ്രിഫിക്സ് മാറിയില്ലെങ്കിൽ, അത് അനുവദിക്കുന്ന ഡീമൺ ഇന്റർഫേസ് കൈകാര്യം ചെയ്യുന്നത് നിർത്തി. പ്രിഫിക്സ് മാറിയെങ്കിലും വിലാസങ്ങൾ മാറിയില്ലെങ്കിൽ, ക്ലയന്റ് കോൺഫിഗറേഷൻ കാലഹരണപ്പെട്ടതാണ്. രണ്ട് പരാജയങ്ങളും ബ്രൗസറിൽ നിന്ന് ഒരുപോലെ കാണപ്പെടുന്നു, പൊതുവായി ഒന്നുമില്ല.
dhcpcd ടണൽ കൈകാര്യം ചെയ്യണമോ എന്ന് തീരുമാനിക്കുക
dhcpcd-യ്ക്ക് ഇന്റർഫേസുകൾ കണ്ടെത്താനും DHCPv6 പ്രിഫിക്സിന്റെ ഭാഗങ്ങൾ താഴെയുള്ള ഇന്റർഫേസുകൾക്ക് ഡെലിഗേറ്റ് ചെയ്യാനും കഴിയും, അതിന്റെ കോൺഫിഗറേഷന് ഡെലിഗേഷൻ ലക്ഷ്യങ്ങൾ വ്യക്തമായി പേരിടാനും കഴിയും. വ്യക്തമായ ലക്ഷ്യമില്ലാതെ, അതിന്റെ രേഖപ്പെടുത്തിയ സ്വഭാവം മറ്റ് ഇന്റർഫേസുകളെ ഉൾപ്പെടുത്തിയേക്കാം, അങ്ങനെയാണ് ടണലിന് ആരും ആസൂത്രണം ചെയ്യാത്ത ഒരു വിലാസം ലഭിക്കുന്നത്.
രണ്ട് വ്യവസ്ഥകൾ ടണലിന്റെ സ്റ്റാറ്റിക് അഡ്രസിംഗ് OpenVPN-ന് വിടാൻ നിങ്ങളെ പ്രേരിപ്പിക്കണം: സെർവർ അതിന്റെ കോൺഫിഗറേഷനിൽ സ്ഥിര വിലാസങ്ങൾ തള്ളുന്നു, വീണ്ടും കണക്ട് ചെയ്യുമ്പോൾ ടണലിന്റെ പേര് മാറുന്നു. രണ്ടും ശരിയെങ്കിൽ, ടണലിനെ ഡെലിഗേഷൻ ഡീമണിൽ നിന്ന് ബോധപൂർവം ഒഴിവാക്കുക, കാരണം പറയുന്ന ഒരു കമന്റോടെ.
പകരം ടണലിലേക്കുള്ള ഡെലിഗേഷൻ ബോധപൂർവമാണെങ്കിൽ, പ്രിഫിക്സ് മാറ്റ കൈകാര്യം നടപ്പിലാക്കുക. ഡെലിഗേറ്റ് ചെയ്ത പ്രിഫിക്സോ അതിന്റെ ആയുസ്സോ മാറുമ്പോൾ പ്രതികരിക്കുക, സെർവർ പ്രഖ്യാപിക്കുന്ന ക്ലയന്റ് പ്രിഫിക്സ് പുതുക്കുക, റൂട്ട് വീണ്ടും ചേർക്കുക എന്നതാണ് അതിന്റെ അർത്ഥം. ആ രൂപകൽപ്പനയിൽ ഇന്റർഫേസ് ഒഴിവാക്കുന്നത് പുതിയ പ്രിഫിക്സ് അറിയുന്ന ഏക ഘടകത്തെ നീക്കം ചെയ്യുന്നു.
dhcpcd വീണ്ടും ആരംഭിക്കുന്നത് അവസ്ഥ വീണ്ടും സൃഷ്ടിക്കുന്നതിനാൽ കാര്യങ്ങൾ ശരിയാക്കുന്നതായി തോന്നിയേക്കാം, പക്ഷേ അത് നിങ്ങൾ ചിന്തിക്കാത്ത ഇന്റർഫേസുകളുടെ കോൺഫിഗറേഷനും പുതുക്കുകയോ പിൻവലിക്കുകയോ ചെയ്യുന്നു. ആ വീണ്ടെടുപ്പ് അതിനെ ഓരോ VPN പുനരാരംഭത്തിനും ശേഷം നിർബന്ധമാക്കുന്നില്ല. തെളിവായി ഉപയോഗിച്ച കൗണ്ടറുകളും അത് പുനഃസജ്ജമാക്കുന്നു. നിങ്ങൾ യഥാർത്ഥത്തിൽ മാറ്റിയ ഇന്റർഫേസിന്റെ ലക്ഷ്യബദ്ധമായ റീലോഡിന് മുൻഗണന നൽകുക.
IPv6 IPv4 NAT-ൽ നിന്ന് വേറിട്ട് സാധുത പരിശോധിക്കുക
ഫോർവേഡിംഗ് സജീവമാണെന്നും അപ്സ്ട്രീം റൂട്ട് യഥാർത്ഥ ക്ലയന്റ് പ്രിഫിക്സിലേക്ക് ചൂണ്ടുന്നുവെന്നും ഉറപ്പാക്കുക, എന്നിട്ട് പുതിയ അനുവദിച്ച IPv6 കണക്ഷൻ ഉണ്ടാക്കുക. ക്ലയന്റിന്റെ സ്വന്തം IPv6 റൂട്ട് പട്ടികയും പരിശോധിക്കുക, പൊതു വിലാസം കാണിക്കുന്ന ക്ലയന്റ് അതിന്റെ അഭ്യർത്ഥന ടണൽ ഉപയോഗിച്ചു എന്ന് തെളിയിക്കുന്നില്ല.
IPv4 മാസ്കറേഡിംഗ് മറ്റൊരു പ്രശ്നം പരിഹരിക്കുന്നു: സ്വകാര്യ ഉറവിടങ്ങൾക്കുള്ള തിരിച്ചുള്ള പാത. പിൻവലിച്ച IPv6 പ്രിഫിക്സിന് അത് ഒന്നും ചെയ്യുന്നില്ല, അത് ചേർത്താൽ IPv6 തിരികെ വരില്ല.
ഉടമസ്ഥതാ രേഖയോടെ അവസാനിപ്പിക്കുക: ഏത് ഘടകം പ്രിഫിക്സ് ഡെലിഗേറ്റ് ചെയ്യുന്നു, ഏത് ക്ലയന്റ് വിലാസങ്ങൾ അനുവദിക്കുന്നു, ഏത് തിരിച്ചുള്ള റൂട്ട് കൈവശം വയ്ക്കുന്നു, വീണ്ടും കണക്ട് ചെയ്യുമ്പോൾ ഓരോന്നിനും എന്ത് സംഭവിക്കുന്നു. റൺബുക്കിലെ നാല് വരികൾ അടുത്ത വ്യക്തിയെ മൂന്ന് ഡീമണുകൾ വീണ്ടും ആരംഭിക്കുന്നതിൽ നിന്ന് രക്ഷിക്കുന്നു, പ്രധാനമായത് കണ്ടെത്താൻ.