സൈറ്റ്-ടു-സൈറ്റ് VPN-ലുടനീളം IPv6 പ്രിഫിക്സ് ഡെലിഗേഷൻ: ചെക്ക്ലിസ്റ്റ്

ടണൽ ഉയർത്തുന്നത് എളുപ്പമുള്ള പകുതിയാണ്. സൈറ്റ്-ടു-സൈറ്റ് ലിങ്ക് ദിവസങ്ങളോളം സ്ഥാപിതമായി നിൽക്കെ, ദൂരെയുള്ള LAN-ലെ ഓരോ ഹോസ്റ്റും നിശബ്ദത മാത്രം തിരികെ ലഭിക്കുന്നത് ഞാൻ കണ്ടിട്ടുണ്ട്, കാരണം ആ ഗേറ്റ്വേയ്ക്ക് പിന്നിലെ ഡെലിഗേറ്റ് ചെയ്ത പ്രിഫിക്സ് ഒരു ഇന്റർഫേസിൽ കോൺഫിഗർ ചെയ്തിരുന്നുവെങ്കിലും ഒരിക്കലും ടണലിലേക്ക് റൂട്ട് ചെയ്തിരുന്നില്ല. ടണൽ വിലാസങ്ങൾ ആ സമയമത്രയും പിംഗുകൾക്ക് മറുപടി നൽകി, അതുകൊണ്ടുതന്നെ ആരും പ്രിഫിക്സ് നോക്കിയില്ല. ഡെലിഗേറ്റ് ചെയ്ത IPv6 പ്രിഫിക്സ് ഒരു സൈറ്റ് VPN കടക്കേണ്ടിവരുമ്പോൾ ഞാൻ പരിശോധിക്കുന്ന ക്രമം ഇതാണ്: പ്രിഫിക്സ് മാപ്പ്, ട്രാഫിക് സെലക്ടറുകൾ, ഫോർവേഡിംഗും ഫയർവാളും, തുടർന്ന് തിരിച്ചുവരവ് പാത.

ടണൽ തൊടുന്നതിന് മുമ്പ് പ്രിഫിക്സ് മാപ്പ് എഴുതുക

പ്രിഫിക്സ് ഡെലിഗേഷൻ ആവശ്യപ്പെട്ട റൂട്ടറിന് ഒരു ബ്ലോക്ക് നൽകുന്നു. അത് പിയറിൽ ഒരു റൂട്ട് ഇൻസ്റ്റാൾ ചെയ്യുന്നില്ല, ആ ബ്ലോക്ക് on-link ആയി വികസിപ്പിക്കുന്നില്ല, ആവശ്യപ്പെടുന്ന റൂട്ടറിന് പിന്നിൽ എന്താണെന്ന് ദൂരെയുള്ള ഗേറ്റ്വേയോട് പറയുന്നുമില്ല. ഈ മൂന്നും നിങ്ങൾ തന്നെ കോൺഫിഗർ ചെയ്യണം, ഏതെങ്കിലും കോൺഫിഗ് ഫയൽ മാറുന്നതിന് മുമ്പ് അവ വിലാസ പ്ലാനിൽ ഉണ്ടായിരിക്കണം.

ഓരോ സൈറ്റിനും ഡെലിഗേറ്റ് ചെയ്ത പ്രിഫിക്സ്, LAN-ൽ യഥാർത്ഥത്തിൽ ഉപയോഗിക്കുന്ന /64, ടണൽ വിലാസങ്ങൾ, ഓരോ റൂട്ടിന്റെയും ഉടമ എന്നിവ രേഖപ്പെടുത്തുക. പ്രൊവൈഡർ സൈറ്റ് A-യ്ക്ക് 2001:db8:a1::/56 ഡെലിഗേറ്റ് ചെയ്യുന്നു, അത് തന്റെ LAN-ൽ 2001:db8:a1:10::/64 നൽകുന്നു; സൈറ്റ് B 2001:db8:b2::/64 നിലനിർത്തുന്നു. സൈറ്റ് A ആ ഒരു /64 മാത്രം നൽകുന്നുവെങ്കിൽ, രണ്ടറ്റവും മുഴുവൻ /56 അല്ല, 2001:db8:a1:10::/64 നാമനിർദ്ദേശം ചെയ്യണം.

ഏതാണ്ടെല്ലാം രണ്ട് തെറ്റുകൾ കാണാം. ഒന്ന് ദൂരെയുള്ള പ്രിഫിക്സിനെ on-link ആയി കണക്കാക്കി ബ്രിഡ്ജ് ചെയ്യുകയോ ടണൽ ഇന്റർഫേസിൽ ഇടുകയോ ചെയ്യുന്നതാണ്, അപ്പോൾ എത്തിച്ചേരാൻ കഴിയാത്ത ഹോസ്റ്റുകൾക്കായുള്ള അയൽക്കാര അഭ്യർത്ഥനയ്ക്ക് ഗേറ്റ്വേ മറുപടി നൽകുന്നു. മറ്റൊന്ന് ഒരു /64 മാത്രം കോൺഫിഗർ ചെയ്തിരിക്കെ മുഴുവൻ /56 പ്രഖ്യാപിക്കുന്നതാണ്: റൂട്ട് പട്ടിക ബ്ലോക്ക് എത്താവുന്നതാണെന്ന് അവകാശപ്പെടുന്നു, വിലാസങ്ങളിൽ ഭൂരിഭാഗവും കറുത്ത കുഴിയിൽ വീഴുന്നു.

രണ്ടറ്റത്തെയും ട്രാഫിക് സെലക്ടറുകൾ റൂട്ടുകളുമായി യോജിപ്പിക്കുക

IKEv2-ഉം WireGuard-ഉം പൊരുത്തപ്പെടാത്ത ട്രാഫിക് നിരസിക്കുന്നു, ടണൽ ഇപ്പോഴും ആരോഗ്യകരമായി കാണപ്പെടുന്നത്ര ശാന്തമായി.

strongSwan-ൽ സെലക്ടറുകൾ വ്യക്തമാണ്. സൈറ്റ് A-യിൽ:

conn a-to-b
    left=2001:db8:ff::1
    leftsubnet=2001:db8:a1:10::/64
    right=2001:db8:ff::2
    rightsubnet=2001:db8:b2::/64
    auto=start

സൈറ്റ് B-യുടെ conn രണ്ട് സബ്നെറ്റുകളെ പ്രതിഫലിപ്പിക്കുന്നു. അവ യോജിക്കാത്തപ്പോൾ, പ്രതികരിക്കുന്നയാൾ CHILD_SA-യെ TS_UNACCEPTABLE ഉപയോഗിച്ച് നിരസിക്കുന്നു, അതിനാൽ IKE_SA ഉയർന്നാലും child SA ഒരിക്കലും ഉയരില്ല. ഇരുവശത്തും കോൺഫിഗർ ചെയ്ത സബ്നെറ്റ് പ്രാദേശിക കെർണൽ ടണലിലേക്ക് റൂട്ട് ചെയ്യുന്നതിന് തുല്യമായിരിക്കണം.

WireGuard അതേ വിവരങ്ങൾ AllowedIPs-ൽ വഹിക്കുന്നു, ഒരു പ്രത്യേകതയോടെ: AllowedIPs സ്വീകരിക്കുമ്പോൾ ഉറവിട ഫിൽട്ടറും അയയ്ക്കുമ്പോൾ റൂട്ടുമാണ്. സൈറ്റ് B-യുടെ സൈറ്റ് A-യ്ക്കുള്ള peer എൻട്രി 2001:db8:a1:10::/64 വിട്ടുപോയാൽ, സൈറ്റ് A-യിൽ നിന്നുള്ള പാക്കറ്റുകൾ സാധുവായ handshake-ൽ എത്തി അനുവദനീയമല്ലാത്തതായി ഉപേക്ഷിക്കപ്പെടുന്നു. അങ്ങനെ handshake മാത്രം വീണ്ടും വീണ്ടും പുതുക്കുന്ന, മറുപടി ഒരിക്കലും പുറത്തുപോകാത്ത പരിചിതമായ മാതൃക ഉണ്ടാകുന്നു. രണ്ടറ്റവും wg show wg0 allowed-ips ഉപയോഗിച്ച് താരതമ്യം ചെയ്യുക. ഡെലിഗേഷൻ മാറുമ്പോഴെല്ലാം ആ പട്ടിക വീണ്ടും പരിശോധിക്കുക; കാലഹരണപ്പെട്ട /64 സെഷൻ നിലനിർത്തി പുതിയ പ്രിഫിക്സിനെ എത്താനാവാത്തതാക്കുന്നു.

ആദ്യം ഫോർവേഡിംഗും ഫയർവാളും MTU-വും ഒഴിവാക്കുക

അടുത്ത ലോഗ് വരി വായിക്കുന്നതിന് മുമ്പ് ഗേറ്റ്വേകൾ ഒട്ടേറെ ഫോർവേഡ് ചെയ്യുന്നുണ്ടോ എന്ന് ഉറപ്പാക്കുക. sysctl net.ipv6.conf.all.forwarding രണ്ടിലും 1 തിരികെ നൽകണം, ടണലിന്റെയും LAN-ന്റെയും ഇന്റർഫേസുകളിൽ പ്രയോഗിച്ചിരിക്കണം. ഒരു കെണിയും ഒപ്പമുണ്ട്: ഫോർവേഡിംഗ് ഓണാക്കിയാൽ accept_ra=1 ഉള്ള ഇന്റർഫേസ് പ്രൊവൈഡറിൽ നിന്നുള്ള റൂട്ടർ പരസ്യങ്ങൾ സ്വീകരിക്കുന്നത് നിർത്തുന്നു, അതിനാൽ ടണലിനുള്ളിൽ അപാകതയില്ലാതെ റൂട്ട് ചെയ്യുമ്പോഴും യന്ത്രത്തിന് അപ്സ്ട്രീം ഡിഫോൾട്ട് റൂട്ട് നഷ്ടപ്പെടാം. പ്രൊവൈഡറിന്റെ RA ഇപ്പോഴും ആവശ്യമുള്ളിടത്ത് accept_ra=2 സജ്ജമാക്കുക.

തുടർന്ന് ഫയർവാൾ നിയമങ്ങൾ പ്രിഫിക്സ് ഇരുദിശകളിലും അനുവദിക്കണം, ICMPv6 അതിജീവിക്കണം: അയൽക്കാര കണ്ടെത്തൽ, packet-too-big, destination-unreachable എന്നിവ ഐച്ഛികമല്ല. അവ വിട്ടുകളഞ്ഞാൽ പാത MTU കണ്ടെത്തൽ തകരും, അതിനാൽ തുറന്ന ശേഷം ആദ്യ വലിയ പ്രതികരണത്തിൽ കുടുങ്ങുന്ന കണക്ഷനുകൾ ലഭിക്കും. കുറഞ്ഞ നിയമജോടി ഇങ്ങനെയാണ്:

nft add rule inet filter forward ip6 saddr 2001:db8:a1:10::/64 ip6 daddr 2001:db8:b2::/64 accept
nft add rule inet filter forward ip6 saddr 2001:db8:b2::/64 ip6 daddr 2001:db8:a1:10::/64 accept
nft add rule inet filter forward icmpv6 type { packet-too-big, nd-neighbor-solicit, nd-neighbor-advert } accept

MTU അതിന് പിന്നിലാണ്. ടണൽ ഉപയോഗയോഗ്യമായ MTU 1500-ൽ താഴെ ചുരുക്കുന്നു, IPv6 ഓരോ ലിങ്കും കുറഞ്ഞത് 1280 വഹിക്കണമെന്ന് ആവശ്യപ്പെടുന്നു. ചെറിയ പിംഗുകൾ കടക്കുന്നു, SSH സെഷൻ വലിയ പൊട്ടിത്തെറിയിൽ സ്തംഭിക്കുന്നു, /proc/net/snmp6 ഒരിക്കലും തിരികെ വരാത്ത packet-too-big സന്ദേശങ്ങൾ കാണിക്കുന്നു. ടണൽ MTU വ്യക്തമായി സജ്ജമാക്കുക, അല്ലെങ്കിൽ mangle പട്ടികയിൽ TCP MSS ക്ലാംപ് ചെയ്യുക, ചെറിയ MTU അറിയിക്കുന്ന ICMPv6 തിരികെ വരാൻ അനുവദിക്കുക.

ടണൽ വിലാസമല്ല, തിരിച്ചുവരവ് പാത പരിശോധിക്കുക

ഏറ്റവും സമയം എടുക്കുന്ന പരാജയം ഏകദിശ റൂട്ടിംഗാണ്. ഓരോ ഗേറ്റ്വേയും ദൂരെയുള്ള പ്രിഫിക്സ് ടണലിലേക്ക് റൂട്ട് ചെയ്യുന്നു, പക്ഷേ ഹോസ്റ്റുകൾ സ്വന്തം ഡിഫോൾട്ട് ഗേറ്റ്വേ വഴി മറുപടി നൽകുന്നു, കാരണം അവയുടെ /64 അവിടെയാണ്. പാക്കറ്റ് ലക്ഷ്യസ്ഥാനത്ത് എത്തിക്കുന്നത് പാതയുടെ പകുതി മാത്രം.

രണ്ട് കമാൻഡുകൾ മിക്കതും പരിഹരിക്കുന്നു. സൈറ്റ് A-യിൽ ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5 ആ ഉറവിടത്തിൽ നിന്നുള്ള മറുപടി ഏത് ഇന്റർഫേസ് ഉപയോഗിക്കുമെന്ന് കാണിക്കുന്നു; സൈറ്റ് B-യിൽ കണ്ണാടി പരിശോധന നടത്തുക. തുടർന്ന് ഗേറ്റ്വേയിൽ നിന്നല്ല, ഹോസ്റ്റിൽ നിന്ന് ട്രാഫിക് സൃഷ്ടിച്ച് രണ്ടറ്റത്തെയും കൗണ്ടറുകൾ താരതമ്യം ചെയ്യുക.

ദൂരെയുള്ള പ്രിഫിക്സിനുള്ള അയൽക്കാര അഭ്യർത്ഥന ടണലിൽ പ്രത്യക്ഷപ്പെട്ടാൽ, ആ പ്രിഫിക്സ് ഉണ്ടാകരുതാത്ത ഇടത്ത് on-link ആണ്; റൂട്ടുകൾ ക്രമീകരിക്കുന്നതിന് മുമ്പ് അത് പരിഹരിക്കുക. Proxy NDP ബ്രിഡ്ജിംഗ് യഥാർത്ഥത്തിൽ ആവശ്യമുള്ള സന്ദർഭങ്ങൾ ഉൾക്കൊള്ളുന്നു, റൂട്ടിന് പകരമല്ല.

പ്രിഫിക്സ് ഉങ്ങളിൽ മാറുമെന്ന് പ്ലാൻ ചെയ്യുക

പ്രിഫിക്സ് ഡെലിഗേഷൻ ഡെലിഗേറ്റ് ചെയ്യുന്നതും ആവശ്യപ്പെടുന്നതുമായ റൂട്ടറുകൾ തമ്മിലുള്ള പാട്ടമാണ്, പുതുക്കൽ മറ്റൊരു ബ്ലോക്ക് തിരികെ നൽകാം: പ്രൊവൈഡർ കുടിയേറ്റത്തിന് ശേഷം മറ്റൊരു /56, അല്ലെങ്കിൽ ടണൽ നിലനിന്നതിനേക്കാൾ ചെറിയ പാട്ടം. പഴയ പ്രിഫിക്സ് നാമനിർദ്ദേശം ചെയ്യുന്ന എല്ലാ സ്ഥലവും ഒരുമിച്ച് കാലഹരണപ്പെടുന്നു: റൂട്ടുകൾ, സെലക്ടറുകൾ, AllowedIPs, ഫയർവാൾ നിയമങ്ങൾ, DNS റെക്കോർഡുകൾ, അക്ഷരാർത്ഥ വിലാസങ്ങൾ ഹാർഡ്കോഡ് ചെയ്യുന്ന ഏത് നിരീക്ഷണവും. സന്ദേശ പ്രവാഹം RFC 8415-ൽ ഉണ്ട്.

പ്രിഫിക്സ് നീങ്ങുമെന്ന് പ്രതീക്ഷിക്കുന്നിടത്ത് അതിനെ ആശ്രയിക്കാത്ത ആന്തരിക വിലാസ പ്ലാൻ സൂക്ഷിച്ച് അതിർത്തിയിൽ വിവർത്തനം ചെയ്യുക. NPTv6 സ്ഥിതിരഹിതമായ ഓപ്ഷനാണ്, ആന്തരിക നയം വായിക്കാവുന്നതായി നിലനിർത്തുന്നു, പക്ഷേ ഇത് പ്രിഫിക്സ് വിവർത്തനമാണ്, മാന്ത്രിക പാളിയല്ല: /64 അതിർത്തികൾ യോജിക്കണം, ചെക്ക്സമ്മുകൾ ക്രമീകരിക്കപ്പെടുന്നു, അക്ഷരാർത്ഥ വിലാസങ്ങൾ ഉൾപ്പെടുത്തുന്ന ആപ്ലിക്കേഷനുകൾ ഇപ്പോഴും തകരുന്നു. പ്രൊവൈഡർ വിലാസങ്ങൾ അറ്റം മുതൽ അറ്റം വരെ സൂക്ഷിക്കുന്നുവെങ്കിൽ, പാട്ട സ്വഭാവവും മാറ്റ നടപടിക്രമവും വിലാസ പ്ലാനിൽ രേഖപ്പെടുത്തുക.

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