IPv6 ശാഖാ പ്രിഫിക്സ്: സെർവറിൽ iroute-ipv6 അതോ route-ipv6?

ഏകദേശം ഒരേ പേരുള്ള രണ്ട് നിർദ്ദേശങ്ങൾ ഓരോ പ്രവർത്തിക്കുന്ന ഉദാഹരണത്തിലും കാണാം, ഒന്നിനെ മറ്റൊന്നില്ലാതെ പകർത്തുന്നത് ശരിയായി തോന്നുന്ന പക്ഷേ ശാഖാ പ്രിഫിക്സ് നിശ്ശബ്ദമായി ഉപേക്ഷിക്കുന്ന ടണൽ സൃഷ്ടിക്കുന്നു. അവ ഒരേ അതിർത്തിയുടെ രണ്ട് വ്യത്യസ്ത വശങ്ങളിൽ വ്യത്യസ്ത ജോലി ചെയ്യുന്നു: ഒന്ന് സെർവറിന്റെ കർണലിന് പ്രിഫിക്സ് എവിടെ ജീവിക്കുന്നു എന്ന് പഠിപ്പിക്കുന്നു, മറ്റൊന്ന് OpenVPN ന് ഏത് പ്രാമാണീകരിച്ച ക്ലയന്റ് അത് വഹിക്കുന്നു എന്ന് പഠിപ്പിക്കുന്നു. രണ്ടും ശരിയാണെങ്കിൽ പ്രിഫിക്സ് ഒഴുകുന്നു; ഒന്ന് ശരിയാണെങ്കിൽ പാക്കറ്റുകൾക്ക് വഴിയുണ്ട് പക്ഷേ ഉടമയില്ല.

രണ്ട് നിർദ്ദേശങ്ങൾ, രണ്ട് വ്യത്യസ്ത ജോലികൾ

route-ipv6 ഒരു സാധാരണ റൂട്ട് ഇൻസ്റ്റാളേഷനാണ്: സെർവർ ഒരു കർണൽ റൂട്ട് ചേർക്കുന്നു, അത് പ്രിഫിക്സിനെ തന്റെ ടണൽ ഇന്റർഫേസിലേക്ക് കാണിക്കുന്നു. iroute-ipv6 ഒരു നിർദ്ദിഷ്ട ക്ലയന്റിന്റെ സന്ദർഭത്തിൽ പെടുന്നു, ആന്തരിക ഉടമസ്ഥത പ്രഖ്യാപിക്കുന്നു, അതിനാൽ ഡീമണിന് ആ പ്രിഫിക്സിന്റെ ട്രാഫിക് ഒരു നിർദ്ദിഷ്ട ക്ലയന്റിന് അയക്കണമെന്ന് അറിയാം, കർണൽ റൂട്ട് യാദൃച്ഛികമായി പേരിടുന്ന പിയറിനല്ല.

ഒന്ന് കർണലിന്റെ ഫോർവേഡിംഗ് പട്ടികയെക്കുറിച്ച്, മറ്റൊന്ന് ഡീമണിന്റെ ആന്തരിക റൂട്ടിംഗ് മോഡലിനെക്കുറിച്ച്. അവ വേർതിരിച്ച് നിർത്തുന്നത് പൂർണ്ണമായി തോന്നുന്ന കോൺഫിഗറേഷനും എന്തുകൊണ്ട് പ്രിഫിക്സ് ഉപേക്ഷിക്കാമെന്ന് വിശദീകരിക്കുന്നു. അതേ നെറ്റ്വർക്ക് ഓരോ പ്രവർത്തിക്കുന്ന ഉദാഹരണത്തിലും രണ്ടുതവണ എന്തുകൊണ്ട് കാണുന്നു എന്നതും വിശദീകരിക്കുന്നു. രണ്ട് വരികളിൽ ഒന്നും അനാവശ്യമല്ല.

പരമ്പരാഗത userspace ക്രമീകരണത്തിൽ രണ്ടും ആവശ്യമാണ്, അവ പരസ്പരം പൂർത്തീകരിക്കുന്നു. ഒറ്റ കർണൽ റൂട്ട് ഡീമണിനെ പിയർ തിരഞ്ഞെടുക്കാനാകാതെ വിടുന്നു. ഒറ്റ iroute കർണലിനെ ടണലിലേക്ക് വഴിയില്ലാതെ വിടുന്നു. ഇവിടെ നിന്നാണ് പ്രതി-ക്ലയന്റ് ഫയലുകളെക്കുറിച്ചുള്ള കൂടുതൽ ആശയക്കുഴപ്പം വരുന്നത്: ഫയൽ റൂട്ട് പട്ടികയുടെ എൻട്രിയല്ല, റൂട്ട് എൻട്രി ഉടമസ്ഥതയുടെ പ്രഖ്യാപനവുമല്ല.

ip -6 route show | grep fd00:7a
ip -6 route get fd00:7a::1

ഏത് എവിടെ പെടുന്നു

റൂട്ട് സെർവറിന്റെ നിർവഹിക്കപ്പെടുന്ന കോൺഫിഗറേഷനിലേക്ക് പോകുന്നു, അവിടെ അത് ആ സെർവർ പ്രക്രിയയ്ക്ക് ബാധകമാണ്. iroute ക്ലയന്റ്-നിർദ്ദിഷ്ട ഫയലിലേക്ക് പോകുന്നു, അത് ശാഖാ ഉപകരണത്തിന്റെ പ്രാമാണീകരിച്ച ഐഡന്റിറ്റിയുടെ പേരിലാണ്.

യഥാർത്ഥ ഐഡന്റിറ്റിയുമായി പൊരുത്തപ്പെടാത്ത ഫയൽ നാമം ഒരിക്കലും വായിക്കപ്പെടുന്നില്ല, ലക്ഷണം കൃത്യമായി കാണാത്ത iroute പോലെയാണ്. സെർവർ പ്രാമാണീകരിച്ച ഐഡന്റിറ്റി പരിശോധിക്കുക, തുടർന്ന് ഫയൽ നാമം അക്ഷരം-അക്ഷരം പരിശോധിക്കുക.

# /etc/openvpn/server/server.conf
route-ipv6 fd00:7a::/64
client-config-dir /etc/openvpn/server/ccd

# /etc/openvpn/server/ccd/branch-b
iroute-ipv6 fd00:7a::/64

പൂളും ശാഖാ പ്രിഫിക്സും വേർതിരിച്ച് നിർത്തുക, കാരണം അവയുടെ ഓവർലാപ്പ് ഒരു നിർദ്ദേശവും പരിഹരിക്കാനാകാത്ത ഒരു പ്രഹേളിക സൃഷ്ടിക്കുന്നു.

മറ്റൊരു ക്ലയന്റിന് എന്ത് വേണം

ആ ശാഖയിലെത്തേണ്ട രണ്ടാമത്തെ ക്ലയന്റിന് ഉടമസ്ഥതയല്ല, പ്രഖ്യാപനം വേണം. പ്രിഫിക്സ് നിങ്ങൾ ഉദ്ദേശിക്കുന്ന ക്ലയന്റുകൾക്ക് അയക്കുക, നിങ്ങളുടെ കോൺഫിഗറേഷനുമായി പൊരുത്തപ്പെടുന്ന ക്ലയന്റ് അല്ലെങ്കിൽ ഗ്രൂപ്പ് സന്ദർഭത്തിൽ.

അത് ശാഖയ്ക്കുതന്നെ അയക്കരുത്, കാരണം ആ ഉപകരണത്തിന് പ്രിഫിക്സ് ഇതിനകം ബന്ധിപ്പിച്ച നെറ്റ്വർക്കായി ഉണ്ട്.

അത് എല്ലാവർക്കും അയക്കുന്നത് പരിണിതഫലങ്ങളുള്ള തിരഞ്ഞെടുപ്പാണ്: അപ്പോൾ ഓരോ ക്ലയന്റും ശാഖ ടണലിലൂടെ എത്താമെന്ന് വിശ്വസിക്കുന്നു, നിങ്ങൾ ഒരിക്കലും ഈ പ്രവേശനം നൽകാൻ ഉദ്ദേശിക്കാത്ത ക്ലയന്റുകളുൾപ്പെടെ. പ്രഖ്യാപനം പ്രായോഗികമായി പ്രവേശനത്തിന്റെ തീരുമാനമാണ്, നിർദ്ദേശം പ്ലംബിംഗ് ജോലി പോലെ തോന്നുന്നുവെങ്കിലും. സെർവർ ഓപ്ഷനുകളുടെ റഫറൻസ് iroute-ipv6 എന്നതിനെ ക്ലയന്റ്-നിർദ്ദിഷ്ട ഉടമസ്ഥതയായി രേഖപ്പെടുത്തുന്നു, സൂക്ഷിക്കാൻ യോഗ്യമായ വ്യത്യാസം അതാണ്.

ശാഖാ ഉപകരണത്തിലെ തിരിച്ചുവരവ് വഴി

ശാഖ പാക്കറ്റുകൾ ഫോർവേഡ് ചെയ്യുകയും അതിന്റെ LAN എങ്ങനെ പ്രതികരിക്കണം എന്ന് അറിയുകയും ചെയ്താൽ മാത്രമേ ഉടമസ്ഥത സഹായിക്കൂ. ശാഖാ ഉപകരണത്തിൽ IPv6 ഫോർവേഡിംഗ് പ്രവർത്തനക്ഷമമാക്കി, അതിന്റെ LAN-ലെ ഹോസ്റ്റുകൾ VPN പൂളിന്റെ ട്രാഫിക് പൂൾ അറിയാത്ത ഡിഫോൾട്ട് റൂട്ടിലേക്കല്ല, ശാഖയിലേക്ക് തിരികെ അയക്കുന്നുവെന്ന് ഉറപ്പാക്കുക.

ആ തിരിച്ചുവരവ് വഴി IPv6-ൽ ആളുകൾ IPv4-ൽ അഭിമുഖീകരിക്കുന്ന കാണാത്ത റൂട്ട് പ്രശ്നത്തിന്റെ സമാനമാണ്.

അത് LAN-ലെ ഹോസ്റ്റിൽ നിന്ന് VPN പൂൾ വിലാസത്തിന്റെ ക്വറിയോടെ പരിശോധിക്കുക, ശാഖയിൽ നിന്നല്ല. റൗട്ടറിൽ ചെയ്ത ക്വറി നിങ്ങളുടെ ഉപയോക്താക്കളുടെ ചോദ്യത്തിൽ നിന്ന് വ്യത്യസ്ത ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു, രണ്ടും അധിക കമാന്റിന് യോഗ്യമാകുന്നത്ര തവണ വ്യത്യാസപ്പെടുന്നു.

ജോടി ഇപ്പോഴും മതിയാകുന്നില്ലെങ്കിൽ

ചില വിന്യാസങ്ങൾ ഈ വഴി ഒട്ടും ഉപയോഗിക്കുന്നില്ല. കർണലിന്റെ ഡാറ്റാ വഴിയും ഉൽപ്പന്നം നിർവഹിക്കുന്ന സെർവറുകളും അവയുടെ സ്വന്തം പിന്തുണയുള്ള റൂട്ട് കൈകാര്യം ചെയ്യൽ ഉള്ളവയാണ്, userspace ഉദാഹരണം നേരിട്ട് കൈമാറിയെന്ന് വരില്ല.

മറ്റൊന്നിനായി എഴുതിയ ഗൈഡിൽ നിന്ന് നിർദ്ദേശങ്ങൾ പകർത്തുന്നതിന് മുമ്പ് നിങ്ങളുടെ ബിൽഡ് ഏത് ഡാറ്റാ വഴി ഉപയോഗിക്കുന്നുവെന്ന് ഉറപ്പാക്കുക.

അവസാനമായി, വിലാസങ്ങളുടെ പരിധി ഓർക്കുക: അദ്വിതീയ പ്രാദേശിക പ്രിഫിക്സ് പോലെയുള്ള fd00:7a::/64 രൂപകൽപ്പനയാൽ സ്വകാര്യമാണ്, പൊതു IPv6 എത്തിച്ചേരലിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല. അതിനെ ആന്തരിക പ്രവേശനമായി കാണുക, ഇന്റർനെറ്റിലേക്കുള്ള പുറത്തുപോക്ക് സ്വന്തം നയമുള്ള പ്രത്യേക വിഷയമായി നിർത്തുക.