രണ്ട് സൈറ്റുകൾക്കിടയിലുള്ള നിലവിലെ VPN വഴി IPv6 റൂട്ടിംഗ്

IPv4 മാത്രമുള്ള WAN പോലും ഉള്ളിലെ IPv6 വഹിക്കാൻ കഴിയും. സെലക്ടറുകൾ, കർണൽ റൂട്ടുകൾ, ഫോർവേഡിംഗ്, മറുപടികൾ നിശ്ശബ്ദമായി കളയുന്ന തിരിച്ചുവരവ് പ്രിഫിക്സ് എന്നിവ പിന്തുടരുക.

രണ്ട് സൈറ്റുകൾക്കിടയിലുള്ള ടണലിൽ IPv6 പ്രിഫിക്സ് ചേർക്കുമ്പോൾ, ചിത്രം സൂചിപ്പിക്കുന്നതുപോലെ പാക്കറ്റ് യാത്ര ചെയ്യുന്നില്ല। പ്രാദേശിക ഗേറ്റ്വേ മുഴുവൻ IPv6 പാക്കറ്റും എടുത്ത്, അത് എൻക്രിപ്റ്റ് ചെയ്ത്, മുന്നിൽ ഒരു ബാഹ്യ IP ഹെഡർ വയ്ക്കുന്നു; അതിന്റെ വിലാസ കുടുംബം ഉള്ളിലെ ഉള്ളടക്കം കൊണ്ടല്ല, അതിരുകളിലെ വിലാസങ്ങൾ കൊണ്ടാണ് നിർണ്ണയിക്കുന്നത്। ദൂരെയുള്ള ഗേറ്റ്വേ ആ ബാഹ്യ ഹെഡർ നീക്കി മൂല പാക്കറ്റ് തന്റെ LAN-ലേക്ക് അയയ്ക്കുന്നു; അവിടെ അത് വീണ്ടും സാധാരണ IPv6 പാക്കറ്റാണ്। ബാഹ്യ ടണലും ഉള്ളിലെ ട്രാഫിക്കും ഒരു കീ, ഒരു അതിർ ജോഡി, മറ്റൊന്നും പങ്കിടാത്ത രണ്ട് വേറിട്ട സംഭാഷണങ്ങളാണ്।

രണ്ട് ഹെഡറുകൾ, രണ്ട് വിലാസ കുടുംബങ്ങൾ

IPsec ടണൽ മോഡിൽ ഉള്ളിലെ IPv6 പാക്കറ്റ് ESP ഹെഡറിന് പിന്നിലെ പേലോഡ് ആകുന്നു। ആ ESP പാക്കറ്റ് വഹിക്കുന്ന ബാഹ്യ ഹെഡർ IPv4 അല്ലെങ്കിൽ IPv6 ആകാം; അത് local_addrs, remote_addrs എന്നിവ പിന്തുടരുന്നു। WireGuard ഇതേ കാര്യം കുറഞ്ഞ ആചാരത്തോടെ ചെയ്യുന്നു: ഉള്ളിലെ പാക്കറ്റ് സഖാവിന്റെ അതിരിലേക്ക് പോകുന്ന UDP ഡാറ്റാഗ്രാമിന്റെ പേലോഡാണ്। രണ്ടും ഉള്ളിലെ ഹെഡർ തൊടാതെ വിടുന്നു; അതുകൊണ്ട് ദൂരെയുള്ള വശത്തിന് ഡീകാപ്സുലേഷന് ശേഷം അത് റൂട്ട് ചെയ്യാം।

സൈറ്റുകൾക്കിടയിലുള്ള വഴി IPsec NAT ട്രാവേഴ്സൽ ഉപയോഗിക്കുമ്പോൾ UDP 4500 മാത്രം കാണുന്നു, അല്ലെങ്കിൽ സ്ഥിരസ്ഥിതി WireGuard ശ്രോതാവിന് UDP 51820। വഴിയിലെ ഏത് റൂട്ടറും IPv4 മാത്രമാകാം; IPv6 ട്രാഫിക്ക് എന്നിട്ടും കടക്കുന്നു, കാരണം അത് ആ വഴിയിൽ ഒരിക്കലും IPv6 പാക്കറ്റായി പ്രത്യക്ഷപ്പെടുന്നില്ല। അത് വ്യക്തമായ ആദ്യ വിഭജനം നൽകുന്നു: tcpdump -ni eth0 udp port 51820 എൻക്രിപ്റ്റ് ചെയ്ത വഴി കാണിക്കുന്നു, tcpdump -ni wg0 ip6 ഉള്ളിലെ ട്രാഫിക്ക് കാണിക്കുന്നു। ബാഹ്യ ക്യാപ്ചർ തിരക്കേറിയതും ഉള്ളിലെത് നിശ്ശബ്ദവുമാണെങ്കിൽ കർണൽ IPv6 ടണലിൽ ഇടുന്നില്ല എന്നർത്ഥം; അത് റൂട്ടിംഗ് അല്ലെങ്കിൽ നയമാണ്, ലിങ്ക് അവസ്ഥയല്ല।

ഗേറ്റ്വേ ഫോർവേഡ് ചെയ്യുമ്പോൾ ഉള്ളിലെ Hop Limit കൂടി കുറയ്ക്കുന്നു; അതിനാൽ അതിരുകൾ IPv6 വഴിയിൽ റൂട്ടറുകളായി കണക്കാക്കപ്പെടുന്നു। ബാഹ്യ ഹോപ്പ് എണ്ണവും ഉള്ളിലെ Hop Limit-ഉം വെവ്വേറെ നീങ്ങുന്നു; ദൂരെയുള്ള ഗേറ്റ്വേയിൽ മരിക്കുന്ന പാക്കറ്റ് ഫോർവേഡിംഗിൽ മരിച്ചു, എൻക്രിപ്ഷനിൽ അല്ല।

സെലക്ടറുകളും AllowedIPs-ഉം അനുമതി പട്ടികയാണ്

IKEv2, child SA ഏത് ഉള്ളിലെ പ്രിഫിക്സുകൾ വഹിക്കാമെന്ന് ചർച്ച ചെയ്യുന്നു। strongSwan 5.9 മുതൽ അവ swanctl.conf-ൽ എഴുതുന്നത് ഇങ്ങനെ കാണാം:

children {
  net6 {
    local_ts  = 2001:db8:aa::/48
    remote_ts = 2001:db8:bb::/48
    mode = tunnel
    esp_proposals = aes256gcm16-prfsha384-ecp384
    start_action = trap
  }
}

local_ts, remote_ts ഒഴിവാക്കിയാൽ strongSwan അവ താൻ തിരഞ്ഞെടുത്ത ഇന്റർഫേസിന്റെ സബ്നെറ്റുകളിൽ നിന്ന് കണ്ടെത്തുന്നു। ഇരട്ട സ്റ്റാക്ക് ഹോസ്റ്റിൽ ആ ഷോർട്ട്കട്ട് പലപ്പോഴും IPv4 ജോഡി മാത്രം നൽകുന്നു: SA ഉയരുന്നു, IPv6 ESP കോഡ് എത്തുന്നതിന് മുമ്പ് നിരസിക്കപ്പെടുന്നു। രണ്ട് പ്രിഫിക്സുകളും എഴുതുന്നത് SA-യെ അവ വഹിക്കാൻ പ്രാപ്തമാക്കുന്നു; start_action = trap ആദ്യം യോജിക്കുന്ന പാക്കറ്റിൽ അത് ഉയർത്തുന്നു।

WireGuard-ന് രണ്ട് ജോലി ചെയ്യുന്ന ഒരു പട്ടികയുണ്ട്। സഖാവ് ബ്ലോക്കിൽ AllowedIPs = 2001:db8:bb::/48, fd00:bb::/48 അയയ്ക്കുമ്പോൾ സ്ഥാപിക്കുന്ന വഴിയും സ്വീകരിക്കുമ്പോൾ പ്രയോഗിക്കുന്ന ഫിൽട്ടറും ആണ്: ഉള്ളിലെ ഉറവിടം ആ സഖാവിന്റെ പട്ടികയ്ക്ക് പുറത്ത് വീഴുന്ന ഡീക്രിപ്റ്റ് ചെയ്ത പാക്കറ്റ് നിശ്ശബ്ദമായി കളയുന്നു। wg-quick ഓരോ എൻട്രിക്കും വഴി ചേർക്കുന്നു; അതിനാൽ താഴെയുള്ള സഖാവ് ബ്ലോക്കിന് വേറെ ip -6 route കമാൻഡ് ആവശ്യമില്ല।

[Interface]
Address = 2001:db8:aa:ff::1/64, fd00:aa:ff::1/64
ListenPort = 51820

[Peer]
PublicKey = <site-b-public-key>
Endpoint = 203.0.113.20:51820
AllowedIPs = 2001:db8:bb::/48, fd00:bb::/48

രണ്ട് പട്ടികകളും കണ്ണാടിപോലെ ഇരിക്കണം: സൈറ്റ് B, സൈറ്റ് A-യുടെ പ്രിഫിക്സ് ദൂരെയുള്ള സെലക്ടറായി സ്വീകരിച്ച് തിരികെ റൂട്ട് ചെയ്യുന്നു; രണ്ട് ദിശകളും യോജിച്ചാൽ മാത്രം ടണൽ പ്രവർത്തിക്കുന്നു। അസമമായ പട്ടിക ഏറ്റവും സമയമെടുക്കുന്ന ലക്ഷണം നൽകുന്നു — ആരോഗ്യകരമായ ഹാൻഡ്ഷേക്ക്, ഒരു വശത്ത് നീങ്ങുന്ന കൗണ്ടറുകൾ, കൂടാതെ A-യിൽ നിന്ന് B-യിലേക്ക് വിജയകരമായ ping, പക്ഷേ B-യിൽ നിന്ന് ഒന്നും A-യിലെത്തുന്നില്ല।

ഫോർവേഡിംഗ്, റൂട്ടുകൾ, തിരിച്ചുവരവ് പ്രിഫിക്സ്

നിങ്ങൾ പറയുന്നതുവരെ Linux IPv6 ഫോർവേഡ് ചെയ്യുന്നില്ല; ക്രമീകരണം ഇന്റർഫേസിനല്ല, namespace-നാണ്:

sysctl -w net.ipv6.conf.all.forwarding=1
ip -6 route add 2001:db8:bb::/48 dev wg0
ip -6 route get 2001:db8:bb::10 from 2001:db8:aa::10

രണ്ടാം വരിയാണ് റൂട്ട് അധിഷ്ഠിത രൂപകൽപ്പനകളിൽ ആളുകൾ മറക്കുന്നത്। നയ അധിഷ്ഠിത IPsec പ്രിഫിക്സുകളുമായി യോജിക്കുന്ന XFRM നയം സ്ഥാപിക്കുന്നു; എന്നാൽ vti6 അല്ലെങ്കിൽ WireGuard ഉള്ള റൂട്ട് അധിഷ്ഠിത ക്രമീകരണത്തിന് ആ ഉപകരണത്തിലേക്ക് ചൂണ്ടുന്ന യഥാർത്ഥ IPv6 വഴി വേണം। sysctl /etc/sysctl.d/-ന് കീഴിൽ നിലനിർത്തുക; അല്ലെങ്കിൽ പുനർബൂട്ട് ഫോർവേഡിംഗ് നിശ്ശബ്ദമായി ഓഫ് ചെയ്യും।

ഫോർവേഡിംഗിന് അറിയാൻ യോഗ്യമായ ഒരു പാർശ്വഫലമുണ്ട്: കർണൽ അപ്പോൾ റൂട്ടർ പ്രഖ്യാപനങ്ങൾ അവഗണിക്കും, net.ipv6.conf.<wan>.accept_ra 2 അല്ലെങ്കിൽ; അതിനാൽ WAN വിലാസം SLAAC വഴി വരുന്ന ഗേറ്റ്വേ, ഫോർവേഡിംഗ് ഓൺ ചെയ്യുന്ന നിമിഷത്തിൽ തന്നെ സ്വന്തം സ്ഥിരസ്ഥിതി വഴി നഷ്ടപ്പെട്ടേക്കാം। അതേ ഫയലിൽ ആ ഇന്റർഫേസിൽ accept_ra = 2 ക്രമീകരിക്കുക, വഴി അതിജീവിക്കും। സൈറ്റ് B-യുടെ കോറും ടണൽ ഗേറ്റ്വേയിൽ നിന്ന് 2001:db8:aa::/48 പഠിക്കണം, സ്ഥിര വഴി അല്ലെങ്കിൽ ടണലിന് മുകളിലുള്ള റൂട്ടിംഗ് പ്രോട്ടോക്കോൾ വഴി, അല്ലെങ്കിൽ മറുപടി B-യുടെ സ്വന്തം നെറ്റ്വർക്കിൽ തന്നെ മരിക്കും।

വിള്ളലിന്റെ സ്ഥാനം കണ്ടെത്തുന്ന നാല് ഘട്ട പരിശോധന

ഈ ക്രമത്തിൽ പ്രവർത്തിച്ച് പരാജയപ്പെടുന്ന ആദ്യ ഘട്ടത്തിൽ നിൽക്കുക, കാരണം ഓരോ അടുത്ത ഘട്ടവും മുൻപുള്ളവയെ ആശ്രയിച്ചിരിക്കുന്നു।

  1. സെലക്ടറുകൾ: swanctl --list-sas child SA-യിൽ IPv6 പ്രിഫിക്സ് ജോഡി കാണിക്കണം, അല്ലെങ്കിൽ wg show wg0 allowed-ips ദൂരെയുള്ള പ്രിഫിക്സ് പുതിയ latest-handshakes-മായി।
  2. കർണൽ റൂട്ട്: ip -6 route get 2001:db8:bb::10 ടണൽ ഉപകരണത്തോട് ഉത്തരം നൽകണം, WAN ഇന്റർഫേസിനോടല്ല।
  3. ഉള്ളിലെ ക്യാപ്ചർ: tcpdump -ni wg0 ip6 യഥാർത്ഥ LAN ഹോസ്റ്റുകൾക്കിടയിൽ ping ചെയ്യുമ്പോൾ। പുറത്തുപോകുന്ന പാക്കറ്റുകൾ എന്നാൽ ഒന്നും തിരികെ വരാത്തത് B-യുടെ വഴിയെയോ ഫയർവാളിനെയോ സൂചിപ്പിക്കുന്നു; പാക്കറ്റുകൾ ഒട്ടുമില്ലാത്തത് ഘട്ടം 1 അല്ലെങ്കിൽ 2-ലേക്ക് തിരികെ സൂചിപ്പിക്കുന്നു।
  4. ലക്ഷ്യം: B ഹോസ്റ്റിൽ ss -6 -ltn സേവനം IPv6-ൽ കേൾക്കുന്നുവെന്ന് സ്ഥിരീകരിക്കുന്നു; പ്രാദേശിക ഫയർവാൾ കൗണ്ടറുകൾ പാക്കറ്റ് സ്വീകരിച്ചോ കളഞ്ഞോ എന്ന് കാണിക്കുന്നു।

MTU അതേ റൗണ്ടിൽ വരുന്നു। IPv6 റൂട്ടറുകൾ ഖണ്ഡിക്കുന്നില്ല; അതിനാൽ വളരെ വലിയ പാക്കറ്റ് കളയുന്നു, Packet Too Big അയച്ചയാൾക്ക് തിരികെ വരുന്നു। ഹാൻഡ്ഷേക്കുകളും ചെറിയ ping-കളും പ്രവർത്തിച്ച്, ഫയൽ കൈമാറ്റം നിന്നാൽ, അത് കടക്കുന്നതുവരെ പേലോഡ് കുറയ്ക്കുക: ping -6 -s 1400 -c 3 2001:db8:bb::10। WireGuard ഇന്റർഫേസുകളുടെ സ്ഥിരസ്ഥിതി MTU 1420 ബൈറ്റാണ്; IPv4-ന് മുകളിലുള്ള IPsec കൂടുതൽ കുറയ്ക്കുന്നു, അതിനാൽ ഉള്ളിലെ MTU ക്രമീകരിക്കുന്നത് ICMPv6 കളയുന്ന ഫയർവാളിലൂടെ വഴി MTU കണ്ടെത്താൻ പ്രതീക്ഷിക്കുന്നതിനേക്കാൾ നല്ലതാണ്।

ഫയർവാൾ പ്രശ്നങ്ങളായി തോന്നുന്ന പരാജയ മാതൃകകൾ

ഏറ്റവും സാധാരണമായത് ഫയർവാൾ അല്ല: സേവനം ::-ന് പകരം 0.0.0.0-ലേക്ക് ബന്ധിക്കുന്നു, AAAA റെക്കോർഡ് ഉണ്ട്, ക്ലയന്റ് IPv6 വഴി വേഗത്തിലുള്ള നിരസിക്കൽ ലഭിക്കുന്നു, അത് ഇരട്ട സ്റ്റാക്ക് ബ്രൗസർ IPv4-ലേക്ക് തിരികെ പോയി മറയ്ക്കുന്നു। ചില ആപ്ലിക്കേഷനുകൾ മാത്രം പരാജയപ്പെട്ടാൽ, നിയമക്കൂട്ടം തൊടുന്നതിന് മുമ്പ് കേൾക്കുന്ന കുടുംബം പരിശോധിക്കുക।

രണ്ടാമത്തേത് ICMPv6 ഫിൽട്ടറിംഗ്। Neighbor Discovery, Packet Too Big എന്നിവ സാധാരണ പ്രവർത്തനത്തിന്റെ ഭാഗമാണ്, രോഗനിർണ്ണയത്തിന്റെയല്ല; എല്ലാ ICMPv6-ഉം കളയുന്ന നയം, ബന്ധിപ്പിക്കുകയും സാക്ഷ്യപ്പെടുത്തുകയും ചെയ്ത് പിന്നീട് ചെറിയ പാക്കറ്റിനേക്കാൾ വലിയ എന്തിലും നിൽക്കുന്ന ടണൽ സൃഷ്ടിക്കുന്നു। വഴി ആശ്രയിക്കുന്ന തരങ്ങൾ അനുവദിക്കുക, കളയൽ കാണാൻ കൗണ്ടറുകൾ ഓണാക്കി വയ്ക്കുക।

മൂന്നാമത്തേത് ടണലിൽ ചേർക്കപ്പെടുന്നതും എന്നാൽ അതിന്റെ ഉടമസ്ഥതയിലുള്ള സൈറ്റിന്റെ വിലാസ പ്ലാനിൽ ഒരിക്കലും ചേർക്കാത്തതുമായ പ്രിഫിക്സാണ്; അതിനാൽ ഒരു റൂട്ടറും അത് പ്രഖ്യാപിക്കുന്നില്ല, ഒരു ഹോസ്റ്റിനും അതിൽ നിന്ന് ഉത്തരം നൽകാനാവില്ല। ഒരു പ്രിഫിക്സും ഒരു ഹോസ്റ്റ് ജോഡിയും കൊണ്ട് തുടങ്ങി, രണ്ട് ദിശകളും നാല് ഘട്ടങ്ങളിൽ തെളിയിച്ച്, പിന്നീട് ബാക്കിയുള്ളവ ചേർക്കുക; കേടായ പ്രിഫിക്സ് പുനർരൂപകൽപ്പനയ്ക്ക് പകരം കോൺഫിഗറേഷനിൽ ഒരു വരിയായി തുടരും। തുറന്ന് വയ്ക്കാൻ യോഗ്യമായ ഏക ഔദ്യോഗിക റഫറൻസ് RFC 8200 ആണ്, അത് ടണൽ വഹിക്കുന്ന ഹെഡർ നിർവചിക്കുന്നു।

അനുബന്ധ ലേഖനങ്ങൾ