നിങ്ങളുടെ /64 വിഭജിക്കുന്നത് IPv6 VPN ക്ലയന്റുകളിലേക്ക് റൂട്ട് ചെയ്യുന്നില്ല

ക്ലയന്റ് ആഗോള IPv6 വിലാസം കാണിക്കുന്നു, ഹാൻഡ്ഷേക്ക് പൂർത്തിയായി, ഇന്റർനെറ്റിൽ നിന്ന് ഒന്നും തിരികെ വരുന്നില്ല. പൂൾ ക്രമീകരണം ശരിയാണെന്ന് തോന്നുന്നു, കാരണം അത് ശരിയാണ്; വിലാസം സാധുവാണ്, ടണൽ അത് വഹിക്കുന്നു. പരാജയപ്പെടുന്നത് ഡെലിവറിയാണ്, ഡെലിവറി VPN സർവറിന് മുകളിൽ എടുക്കുന്ന ഒരു തീരുമാനത്തെ ആശ്രയിച്ചിരിക്കുന്നു, അതിൽ ക്ലയന്റ് വശത്തെ ഏത് കോൺഫിഗറേഷനും സ്വാധീനിക്കാൻ കഴിയില്ല.

കെട്ടുകഥ: നിങ്ങളുടെ /64 ന്റെ ഒരു ഭാഗം ഇതിനകം എത്താവുന്നതാണ്

കഥ ആകർഷകമാണ്: സർവറിന് പൊതു /64 ഉണ്ട്, അത് പകുതിയായി മുറിക്കുക, മറ്റേ പകുതി VPN പൂളിന് നൽകുക, ആ ക്ലയന്റുകൾ ഇപ്പോൾ ഇന്റർനെറ്റിലുണ്ട്. പ്രിഫിക്സ് വിഭജിക്കുന്നത് കൂട്ടിയിടികളില്ലാതെ വിലാസങ്ങൾ അനുവദിക്കുന്നു. എന്നാൽ ആ വിലാസങ്ങളിലൊന്നിലേക്കുള്ള പാക്കറ്റ് എവിടെ പോകണം എന്ന് അപ്സ്ട്രീം നെറ്റ്വർക്ക് തീരുമാനിക്കുന്ന രീതി അത് മാറ്റുന്നില്ല.

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

ഇതാണ് മുഴുവൻ പരാജയം: മുന്നോട്ടുള്ള ദിശ ജോലി ചെയ്യുന്നു, കാരണം അത് നിങ്ങളുടെ സർവർ അയയ്ക്കുന്നു, മടക്ക ദിശ ഒരു ഹോപ്പ് അകലെ മരിക്കുന്നു, കാരണം ക്ലയന്റ് നിലനിൽക്കുന്നുണ്ടെന്ന് അപ്സ്ട്രീം ഒരിക്കലും അറിഞ്ഞില്ല.

ലിങ്കിലെ ഡെലിവറി യഥാർത്ഥത്തിൽ എന്ത് ആവശ്യപ്പെടുന്നു

അപ്സ്ട്രീം മുഴുവൻ /64 ഭൗതിക ലിങ്കിലാണെന്ന് കണക്കാക്കുമ്പോൾ, ഓരോ ലക്ഷ്യ വിലാസവും അയൽപക്ക കണ്ടെത്തൽ ഉപയോഗിച്ച് പരിഹരിക്കുന്നു. ആ ലിങ്കിൽ ഒരു അഭ്യർത്ഥന അയയ്ക്കുന്നു, വിലാസത്തിന്റെ ഉടമ മറുപടി നൽകുമെന്ന് പ്രതീക്ഷിക്കുന്നു. ടണലിന് പിന്നിലുള്ള VPN ക്ലയന്റ് ആ ലിങ്കിലല്ല, മറുപടി നൽകാൻ കഴിയില്ല, അതിനാൽ അഭ്യർത്ഥന മറുപടിയില്ലാതെ തുടരുന്നു, പാക്കറ്റ് ഉപേക്ഷിക്കപ്പെടുന്നു.

/65 മുറിച്ചെടുക്കുന്നത് ആ പ്രതീക്ഷ മാറ്റുന്നില്ല. അപ്സ്ട്രീം ഇപ്പോഴും ശ്രേണിയെ ലിങ്കിലുള്ളതായി കണക്കാക്കുന്നു, കാരണം അതിന്റെ അഭിപ്രായം മാറ്റാൻ ക്ലയന്റിന് വേണ്ടി മറുപടി നൽകുന്ന ഒരു റൂട്ട് അല്ലെങ്കിൽ പ്രോക്സി മാത്രമേ ഉള്ളൂ. നിങ്ങൾ VPN കോൺഫിഗറേഷൻ എഡിറ്റ് ചെയ്തതിനാൽ രണ്ടും പ്രത്യക്ഷപ്പെടുന്നില്ല. ഈ വിടവാണ് പൂൾ സ്വന്തം ക്ലയന്റുകൾക്കിടയിൽ തികച്ചും പ്രവർത്തിക്കുകയും എന്നിട്ടും മറ്റെവിടെ നിന്നും എത്താനാകാതിരിക്കുകയും ചെയ്യുന്നതിന്റെ കാരണം.

പ്രോക്സി അയൽപക്ക കണ്ടെത്തലാണ് രണ്ട് ലോകങ്ങളെ ബന്ധിപ്പിക്കാൻ കഴിയുന്ന സംവിധാനം. ഗേറ്റ്വേ തനിക്കുള്ള നിർദ്ദിഷ്ട ക്ലയന്റ് വിലാസങ്ങൾക്കുള്ള അഭ്യർത്ഥനകൾക്ക് മറുപടി നൽകുകയും ട്രാഫിക് ടണലിലേക്ക് അയയ്ക്കുകയും ചെയ്യുന്നു. ഇത് പ്രവർത്തിക്കുന്നു, കൂടാതെ പൂളിനെ പിന്തുടരുന്ന ജീവിതചക്രത്തോടെ കൃത്യമായി ആ വിലാസങ്ങളിൽ മാത്രം ഇത് പരിമിതപ്പെടുത്തണം, കാരണം നിങ്ങൾ ഇനി സേവനം നൽകാത്ത ഒരു വിലാസത്തിന് വേണ്ടി മറുപടി നൽകുന്നത് മറ്റൊരാളുടെ ട്രാഫിക്കിനെ കറുത്ത കുഴിയാക്കുന്നു. ചില അപ്സ്ട്രീമുകൾ പ്രതീക്ഷിക്കാത്ത പ്രോക്സി മറുപടികൾ സ്വീകരിക്കില്ല, അതിനാൽ ഈ രൂപകൽപ്പനയ്ക്ക് ദാതാവിന്റെ സമ്മതവും ആവശ്യമാണ്.

റൂട്ട് ചെയ്ത ഡെലിവറി എന്ത് ആവശ്യപ്പെടുന്നു

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

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

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

ശരിയാക്കേണ്ട രണ്ട് സ്വതന്ത്ര റൂട്ടുകൾ

പൂൾ പ്രിഫിക്സും ക്ലയന്റിന്റെ സ്വന്തം സ്ഥിരസ്ഥിതി റൂട്ടും വെവ്വേറെ ക്രമീകരണങ്ങളാണ്, അവ കൂട്ടിക്കലർത്തുന്നത് ടണൽ തകർന്നതുപോലെ തോന്നുന്ന ഭാഗിക കണക്റ്റിവിറ്റി സൃഷ്ടിക്കുന്നു. പൂൾ സർവറിനോട് ഏത് വിലാസങ്ങൾ നൽകണമെന്ന് പറയുന്നു. ക്ലയന്റിന്റെ റൂട്ടുകൾ ക്ലയന്റ് ഏത് ലക്ഷ്യസ്ഥാനങ്ങളിലേക്ക് ട്രാഫിക് ടണലിലേക്ക് അയയ്ക്കുന്നു എന്ന് തീരുമാനിക്കുന്നു.

server-ipv6 2001:db8:42:100::/64
push "redirect-gateway ipv6 !ipv4"

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

നിങ്ങൾ പ്രയോഗിക്കുന്ന ഏത് നയത്തിന് കീഴിലും IPv6 ആശ്രയിക്കുന്ന നിയന്ത്രണ ട്രാഫിക് പ്രവർത്തനക്ഷമമായി നിലനിർത്തുക. Packet Too Big സന്ദേശങ്ങൾ TCP, UDP എന്നിവ മാത്രം അനുവദിക്കുന്ന ഫയർവാളിന്റെ ക്ലാസിക് ഇരയാണ്, അവ ഉപേക്ഷിക്കുന്നത് സ്ഥാപിക്കപ്പെട്ടതിന് ശേഷം വലിയ കൈമാറ്റങ്ങളിൽ തടയുന്ന കണക്ഷനുകൾ സൃഷ്ടിക്കുന്നു.

റൗട്ടർ പ്രഖ്യാപനങ്ങൾ മൂന്നാമത്തെ ചലിക്കുന്ന ഭാഗമാണ്. ഗേറ്റ്വേ മേൽ ലിങ്കിൽ പ്രഖ്യാപിക്കാൻ തുടങ്ങിയാൽ, ലിങ്കിലെ പ്രിഫിക്സുകളെക്കുറിച്ച് ക്ലയന്റുകളും അയൽക്കാരും വിശ്വസിക്കുന്നത് അത് മാറ്റിയേക്കാം, അത് നിങ്ങൾ ഇപ്പോൾ രേഖപ്പെടുത്തിയ രൂപകൽപ്പന നിശ്ശബ്ദമായി റദ്ദാക്കിയേക്കാം.

പുനർനിർമ്മാണം അത് പുനർനിർമ്മിക്കാൻ രൂപകൽപ്പന രേഖപ്പെടുത്തുക

മൂന്ന് വസ്തുക്കൾ വെവ്വേറെ എഴുതുക: ക്ലയന്റ് അനുവദനം, ക്ലയന്റിന്റെ ലക്ഷ്യ റൂട്ട്, അനുവദനത്തിനായി അപ്സ്ട്രീമിന്റെ ഡെലിവറി രീതി. മൂന്നും ഉള്ള വായനക്കാരന് വിന്യാസം പുനർനിർമ്മിക്കാം; പൂൾ ക്രമീകരണം മാത്രമുള്ള വായനക്കാരൻ യഥാർത്ഥ ബഗ് പുനർനിർമ്മിക്കും.

തുടർന്ന് പുറത്തുനിന്ന് തിരികെ വരേണ്ട ഒരു പാക്കറ്റ് ഉപയോഗിച്ച് മടക്ക ദിശ വ്യക്തമായി പരിശോധിക്കുക. openvpn(8) മാനുവൽ server-ipv6, redirect ഓപ്ഷനുകൾ ഉൾക്കൊള്ളുന്നു, നിങ്ങളുടെ ദാതാവിന്റെ റൂട്ടിംഗ് സ്ഥിരീകരണം മാനുവലിന് ഉൾക്കൊള്ളാനാകാത്ത പകുതി ഉൾക്കൊള്ളുന്നു.