രണ്ട് സൈറ്റുകളുള്ള WireGuard ഹബ്ബിനുള്ള IPv6 പദ്ധതി: പ്രിഫിക്സ്, പിയർ, റൂട്ടുകൾ
രണ്ട് LAN-നുള്ള സ്വകാര്യ IPv6 ഹബ്ബിൽ പ്രവർത്തിക്കുക: പ്രിഫിക്സ് തിരഞ്ഞെടുക്കുക, ടണൽ വിലാസങ്ങൾ മാറ്റിവയ്ക്കുക, തുടർന്ന് ഏത് പിയർ ഏത് സബ്നെറ്റ് സ്വന്തമാക്കുന്നു എന്ന് AllowedIPs പ്രകടിപ്പിക്കട്ടെ.
രണ്ട് LAN, ഒരു WireGuard ഹബ്ബ്, കൂടാതെ മൂന്ന് വേറിട്ട ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകേണ്ട ഒരു IPv6 വിലാസ പദ്ധതി: ഏത് പ്രിഫിക്സ്, ഏത് വിലാസം ഏത് റൗട്ടറിനുള്ളതാണ്, ഏത് പിയർ ഏത് സബ്നെറ്റ് സ്വന്തമാക്കുന്നു. ഇവയിൽ ഒന്ന് തെറ്റായാൽ കൈകൊടുക്കുന്നതും ഒന്നും റൂട്ട് ചെയ്യാത്തതുമായ ടണൽ ഉണ്ടാകും. താഴെയുള്ള പദ്ധതി അതേ ക്രമത്തിൽ സ്വകാര്യ രണ്ട് സൈറ്റ് രൂപകൽപ്പനയിലൂടെ കടന്നുപോകുന്നു. ഇത് ബോധപൂർവം IPv6 ഇന്റർനെറ്റ് ആക്സസ് നൽകുന്നില്ല.
പ്രിഫിക്സ് എന്തിനുള്ളതാണെന്ന് തീരുമാനിക്കുക
സൈറ്റുകൾക്കിടയിലെ സ്വകാര്യ എത്തിച്ചേരൽ ലക്ഷ്യമാകുമ്പോൾ fd00::/8-ൽ നിന്നുള്ള അതുല്യ-പ്രാദേശിക പ്രിഫിക്സ് സ്വാഭാവിക തിരഞ്ഞെടുപ്പാണ്. ഓരോ സ്ഥലത്തിനും ഏത് ISP സേവനം നൽകുന്നു എന്നത് പരിഗണിക്കാതെ അത് സ്ഥിരമായി നിൽക്കുന്നു, ആഗോള റൂട്ടിംഗ് പട്ടികയിൽ പ്രഖ്യാപിക്കപ്പെടുന്നുമില്ല, അതിനാൽ നിങ്ങളുടെ ആന്തരിക നമ്പറിംഗ് ഇന്റർനെറ്റിലേക്ക് ചോരാൻ കഴിയില്ല.
അതേ സ്വഭാവമാണ് പരിമിതി. ULA പൊതുവായ ഒരു മടങ്ങിവരവ് പാത നൽകുന്നില്ല, കാരണം അത് നിങ്ങളുടെ ഗേറ്റ്വേയിലേക്ക് റൂട്ട് ചെയ്യണമെന്ന് ഏതെങ്കിലും മുകളിലെ ദാതാവിന് അറിയില്ല. ആവശ്യകതയിൽ IPv6 ഇന്റർനെറ്റ് എഗ്രസ് ഉൾപ്പെടുന്നുവെങ്കിൽ, നിങ്ങൾക്ക് വേണം അത് നിങ്ങളിലേക്ക് റൂട്ട് ചെയ്യുന്ന ദാതാവിൽ നിന്നുള്ള അനുവദനം, ഇത് സ്വന്തം പ്രിഫിക്സ് വലുപ്പമുള്ള വേറിട്ട രൂപകൽപ്പന തീരുമാനമാണ്.
എല്ലാ വിന്യാസത്തിനും /48 വേണമെന്ന് കരുതരുത്. RFC 6177 അന്തിമ സൈറ്റിന്റെ ഒരൊറ്റ നിർബന്ധിത വലുപ്പത്തിൽ നിന്ന് അകന്നു, ശരിയായ വലുപ്പം നിങ്ങൾ പ്രവർത്തിപ്പിക്കുന്ന നെറ്റ്വർക്കുകളുടെ എണ്ണത്തെ ആശ്രയിച്ചിരിക്കുന്നു. മറ്റൊരു സംഘടനയും ഉപയോഗിച്ചേക്കാവുന്ന പ്രിഫിക്സ് കണ്ടുപിടിക്കുന്നതിനുപകരം RFC 4193 നടപടിക്രമത്തിൽ ULA സൃഷ്ടിക്കുക. ഏതെങ്കിലും ഉപകരണം കോൺഫിഗർ ചെയ്യുന്നതിന് മുൻപ് ഫലം വിലാസ പദ്ധതിയിൽ എഴുതുക, കാരണം ആരും രേഖപ്പെടുത്താത്ത പ്രിഫിക്സ് ആരോ വീണ്ടും ഉപയോഗിക്കുന്ന പ്രിഫിക്സാണ്.
പ്രിഫിക്സ് റോളുകളായി വിഭജിക്കുക
താഴെയുള്ള ഉദാഹരണം fd7c:2e91:4a00::/48 ഉപയോഗിക്കുന്നു, പട്ടിക സൈറ്റ് പ്രകാരമല്ല, ഓരോ ബ്ലോക്ക് എവിടെ എഴുതുന്നു എന്നതിന് പ്രകാരം ക്രമീകരിച്ചിരിക്കുന്നു. മൂല്യങ്ങളെ മാതൃകയായി എടുത്ത് എന്തെങ്കിലും വിന്യസിക്കുന്നതിന് മുൻപ് നിങ്ങളുടേത് സൃഷ്ടിക്കുക.
| Where it is written | What appears there | Block used | What it establishes |
|---|---|---|---|
| Hub wg0.conf, interface address | A single host address on the tunnel | fd7c:2e91:4a00:ff00::1/128 | The hub's own tunnel identity |
| Hub wg0.conf, Site A peer | Two ranges in one AllowedIPs line | ::2/128 and :10::/64 | That A owns its tunnel address and its LAN |
| Hub wg0.conf, Site B peer | Two ranges in one AllowedIPs line | ::3/128 and :20::/64 | That B owns its tunnel address and its LAN |
| Site A wg0.conf, interface address | A single host address on the tunnel | fd7c:2e91:4a00:ff00::2/128 | A's identity as the hub sees it |
| Site B wg0.conf, interface address | A single host address on the tunnel | fd7c:2e91:4a00:ff00::3/128 | B's identity as the hub sees it |
LAN ബ്ലോക്കുകൾ /64 ആണ്, കാരണം സാധാരണ SLAAC 64-ബിറ്റ് ഇന്റർഫേസ് ഐഡന്റിഫയർ പ്രതീക്ഷിക്കുന്നു. ഒരു LAN-നെ ചെറിയ ബ്ലോക്കായി വിഭജിക്കുന്നത് മിക്ക ഹോസ്റ്റുകളിലും ആ ഊഹം തകർക്കുന്നു, സ്വകാര്യ പദ്ധതിയിൽ വിലാസ ലാഭത്തിന് പ്രവർത്തന ചെലവ് മൂല്യമില്ല. രണ്ട് LAN ബ്ലോക്കുകളും /48-ന്റെ മധ്യത്തിൽ നിന്ന് വരുന്നു, താഴ്ന്ന ശ്രേണി പിന്നീടുള്ള സൈറ്റുകൾക്കായി ഒഴിച്ചിടുന്നു.
ടണൽ വിലാസങ്ങൾ ഒരു ഭരണ കലവറയാണ്, ലിങ്കിലെ നെറ്റ്വർക്കല്ല. ഓരോ ഇന്റർഫേസിനും അതിൽ നിന്ന് ഒരു /128 ലഭിക്കുന്നു, അതിനാൽ ഏതെങ്കിലും ഹോസ്റ്റ് ടണലിൽ പങ്കിട്ട സബ്നെറ്റ് അനുമാനിക്കുന്നില്ല, ആവശ്യമില്ലാത്തിടത്ത് അയൽവാസി കണ്ടെത്തൽ നടക്കുന്നുമില്ല. റോളുകൾ വേറിട്ട് നിർത്തി സംഘടനയുടെ വിലാസ പദ്ധതിയിൽ രേഖപ്പെടുത്തുക, പിന്നീടുള്ള സൈറ്റ് ബ്ലോക്ക് വീണ്ടും ഉപയോഗിക്കാതിരിക്കാൻ.
ഓരോ റൗട്ടറിനും ഒരു ടണൽ വിലാസം നൽകുക
ഓരോ റൗട്ടറിനും ഒരു /128 അനുവദിക്കുക, പ്രവർത്തിക്കുന്ന ഹബ്ബിന്റെ നിലവിലുള്ള കീകളും എൻഡ്പോയിന്റുകളും നിലനിർത്തുക. താഴെയുള്ള മൂന്ന് മൂല്യങ്ങൾ ഹോസ്റ്റ് ഭാഗത്ത് മാത്രം വ്യത്യാസപ്പെടുന്നു.
Hub: Address = fd7c:2e91:4a00:ff00::1/128
Site A: Address = fd7c:2e91:4a00:ff00::2/128
Site B: Address = fd7c:2e91:4a00:ff00::3/128ഈ /128 ആ ഇന്റർഫേസിന് അനുവദിച്ച ഏക വിലാസം വിവരിക്കുന്നു. പിയർ എത്ര ലക്ഷ്യങ്ങളിലേക്ക് റൂട്ട് ചെയ്യാമെന്ന് അത് പറയുന്നില്ല, കാരണം എത്തിച്ചേരൽ ഇന്റർഫേസ് പ്രിഫിക്സിലല്ല, AllowedIPs-ൽ പ്രകടിപ്പിക്കുന്നു.
ഓരോ സൈറ്റ് റൗട്ടറിനും അതിന്റെ LAN ബ്ലോക്കിൽ ഒരു വിലാസവും അത് വിതരണം ചെയ്യാനുള്ള മാർഗവും വേണം, സാധാരണയായി SLAAC-നുള്ള റൗട്ടർ പ്രഖ്യാപനങ്ങൾ. WireGuard ആ പ്രഖ്യാപനങ്ങൾ നിങ്ങൾക്കുവേണ്ടി അയക്കുന്നില്ല, രണ്ട് LAN-കളെ ബ്രിഡ്ജ് ചെയ്യുന്നുമില്ല. സൈറ്റ് റൗട്ടർ രണ്ട് ദിശകളിലും ഒരു റൗട്ടറാണ്.
സബ്നെറ്റ് ഉടമസ്ഥത AllowedIPs-ൽ ഇടുക
സൈറ്റ് A-യ്ക്കുള്ള ഹബ്ബിന്റെ പിയർ എൻട്രി A-യുടെ ടണൽ വിലാസവും A-യുടെ LAN-ഉം സ്വന്തമാക്കുന്നു, ആ ജോടിയാണ് മുഴുവൻ ഉടമസ്ഥതാ പ്രസ്താവന. ആ പിയർ വിഭാഗത്തിൽ മറ്റൊന്നും സൈറ്റ് വിവരിക്കേണ്ടതില്ല.
AllowedIPs = fd7c:2e91:4a00:ff00::2/128, fd7c:2e91:4a00:10::/64സൈറ്റ് B-യുടെ പിയർ എൻട്രി ചേരുന്ന ജോടി സ്വന്തമാക്കുന്നു, ഇവിടെ സമമിതി സംക്ഷിപ്തതയേക്കാൾ പ്രധാനമാണ്. രണ്ട് വരികളും ഒരുമിച്ച് വായിക്കുക, ഉടമസ്ഥതയുടെ വിഭജനം ഒറ്റനോട്ടത്തിൽ കാണാം.
AllowedIPs = fd7c:2e91:4a00:ff00::3/128, fd7c:2e91:4a00:20::/64ഇവ രണ്ട് വേറിട്ട പിയർ വിഭാഗങ്ങളാണ്, ഒരു പിയറിനായി മത്സരിക്കുന്ന രണ്ട് പട്ടികകളല്ല. WireGuard AllowedIPs രണ്ട് ദിശകളിലും ഉപയോഗിക്കുന്നു: പുറത്തേക്കുള്ള ലക്ഷ്യത്തിന് പിയർ തിരഞ്ഞെടുക്കുന്നു, അത് ഡീക്രിപ്റ്റ് ചെയ്ത പിയറിന് അനുവദിച്ച ശ്രേണിയുമായി ഉറവിടം ചേരാത്ത ഇൻബൗണ്ട് പാക്കറ്റ് നിരസിക്കുന്നു. രണ്ട് പിയറുകൾക്കും മുഴുവൻ /48 നൽകിയാൽ ആ രണ്ടാം പരിശോധന പ്രവർത്തനരഹിതമാകും, ഏത് സൈറ്റ് ഏത് ബ്ലോക്ക് സ്വന്തമാക്കുന്നു എന്നത് മങ്ങും. ആ വ്യത്യാസമാണ് തെറ്റായ ഉറവിട വിലാസത്തെ നിശ്ശബ്ദമായി സ്വീകരിക്കാതെ കാണാൻ സഹായിക്കുന്നത്.
ഓരോ സൈറ്റിനും അതിന്റെ ഹബ്ബ് പിയറിലൂടെ എത്താവുന്ന ലക്ഷ്യങ്ങൾ മാത്രം മതി: സൈറ്റ് A ഹബ്ബിന്റെ വിലാസം, സൈറ്റ് B-യുടെ ടണൽ വിലാസം, B-യുടെ LAN എന്നിവ പട്ടികപ്പെടുത്തുന്നു, സൈറ്റ് B വിപരീത ഗണം പട്ടികപ്പെടുത്തുന്നു. പട്ടികകൾ ബോധപൂർവം അസമമിതമാണ്, കാരണം ഓരോ റൗട്ടറും ടോപ്പോളജിയുടെ വേറിട്ട വശം കാണുന്നു. രണ്ടും മറ്റേ സൈറ്റിന്റെ കോൺഫിഗറേഷനിൽ നിന്നല്ല, വിലാസ പദ്ധതിയിൽ നിന്ന് എഴുതുക, അങ്ങനെയാണ് പഴയ ശ്രേണി പുനർനമ്പറിംഗിനെ അതിജീവിക്കുന്നത്.
wg-quick-ൽ ഈ ശ്രേണികൾ റൂട്ടുകളും സൃഷ്ടിക്കുന്നു. systemd-networkd അല്ലെങ്കിൽ കൈകൊണ്ട് സജ്ജീകരണത്തിൽ തത്തുല്യ റൂട്ടുകൾ നിങ്ങൾ തന്നെ ചേർക്കുക; അല്ലെങ്കിൽ കെർണൽ ഒരിക്കലും അയക്കാത്ത പാക്കറ്റുകൾ ടണൽ വഹിക്കും.
ഫോർവേഡിംഗ് പൂർത്തിയാക്കി രണ്ട് ദിശകളും പരിശോധിക്കുക
ഹബ്ബിലും രണ്ട് സൈറ്റ് റൗട്ടറുകളിലും IPv6 ഫോർവേഡിംഗ് പ്രവർത്തനക്ഷമമാക്കുക, ഫോർവേഡ് നയത്തിൽ ആവശ്യമായ അന്തർ-സൈറ്റ് സേവനങ്ങൾ അനുവദിക്കുക. ICMPv6 Packet Too Big സന്ദേശങ്ങൾ ഉപയോഗയോഗ്യമായി നിർത്തുക, കാരണം അവ വലിച്ചെറിഞ്ഞാൽ പാത MTU കണ്ടെത്തൽ തകരുകയും ആപ്ലിക്കേഷൻ തകരാറുകൾ പോലെ തോന്നുന്ന വലിയ കൈമാറ്റ തടസ്സങ്ങൾ ഉണ്ടാകുകയും ചെയ്യും. ഫയർവാൾ അനുമതിയില്ലാതെ ഫോർവേഡ് ചെയ്യുന്ന ഹബ്ബ് റൂട്ടിംഗിനും ടണലിനും ഇടയിൽ പാക്കറ്റ് ഉപേക്ഷിക്കുന്നു. ഈ പരാജയ മോഡ് അറിയേണ്ടതാണ്, കാരണം ടണൽ പ്രവർത്തിച്ചുകൊണ്ടിരിക്കും, ചില ഫ്ലോകൾ മാത്രം മരിക്കും.
sysctl net.ipv6.conf.all.forwarding
ip -6 route
ping -6 -c 3 fd7c:2e91:4a00:20::1സൈറ്റ് A-യിലെ ഹോസ്റ്റിൽ നിന്ന് സൈറ്റ് B-യിലെ ഹോസ്റ്റിലേക്കും പിന്നീട് വിപരീത ദിശയിലേക്കും പരിശോധിക്കുക. ഹബ്ബിന്റെ ടണൽ വിലാസത്തിലേക്കുള്ള ping ആദ്യ ഹോപ്പ് മാത്രം പരിശോധിക്കുന്നു, LAN റൂട്ടുകൾ തെറ്റായാലും വിജയിക്കും. ഹോസ്റ്റ്-തൊട്ട്-ഹോസ്റ്റ് ഫ്ലോയാണ് പദ്ധതി തെളിയിക്കുന്നത്.
പുറം WireGuard കണക്ഷൻ IPv4-ന് മേലെ പ്രവർത്തിക്കുമ്പോൾ അകത്തെ ട്രാഫിക് IPv6 ആകാം, ഈ സ്വാതന്ത്ര്യം കുടിയേറ്റ സമയത്ത് ഉപകാരപ്രദമാണ്. പിന്നീട് ആഗോള IPv6 എഗ്രസ് ചേർത്താൽ, ദാതാവിന്റെ അനുവദനം, ഉറവിട വിലാസ തിരഞ്ഞെടുപ്പ്, മടങ്ങിവരവ് റൂട്ടിംഗ് എന്നിവ പുതിയ രൂപകൽപ്പന ഘട്ടമായി പുനഃപരിശോധിക്കുക; മുകളിലെ സ്വകാര്യ പദ്ധതി സൈറ്റ്-തൊട്ട്-സൈറ്റ് ട്രാഫിക്കിന് സാധുവായി തുടരുന്നു.