ഡ്യുവൽ-സ്റ്റാക്ക് VPN പൂളുകൾ: strongSwan-ൽ രണ്ട് കുടുംബങ്ങളെയും അഭിസംബോധന ചെയ്യൽ

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

ഭൂരിഭാഗം ആശയക്കുഴപ്പവും ഡ്യുവൽ സ്റ്റാക്ക് എന്ന വാക്ക് ഒരിടത്ത് മാത്രം ഡ്യുവൽ സ്റ്റാക്ക് ആയ രൂപകൽപ്പനയിൽ പ്രയോഗിക്കുന്നതിൽ നിന്നാണ്. ഒരു സേവനം ഉള്ളിൽ ഡ്യുവൽ സ്റ്റാക്കും പുറം വിലാസത്തിൽ സിംഗിൾ സ്റ്റാക്കും ആയിരിക്കുകയും എന്നിട്ടും ക്ലയന്റുകൾക്ക് തികച്ചും നന്നായി പ്രവർത്തിക്കുകയും ചെയ്യാം. അതിന് ചെയ്യാനാകാത്തത് യാദൃശ്ചികമായി പ്രവർത്തിക്കുക എന്നതാണ്.

അകത്ത് രണ്ട് കുടുംബങ്ങൾ, പുറത്ത് ഒരു പാത

പുറം കണക്ഷൻ UDP-യിലുള്ള IKE ആണ്, ക്ലയന്റ് എവിടെയായാലും അവിടെ നിന്ന് എത്താവുന്ന ഒരു വിലാസ കുടുംബം അതിന് വേണം. ആന്തരിക IPv6 വിലാസത്തിന് IPv6 ഉള്ള ISP ആവശ്യമില്ല, കാരണം ആന്തരിക പാക്കറ്റ് പുറം പാക്കറ്റിനുള്ളിലെ പേലോഡാണ്. പല പ്രവർത്തിക്കുന്ന വിന്യാസങ്ങളും IPv6 പ്രിഫിക്സുകൾ IPv4 മാത്രമുള്ള അപ്‌ലിങ്കിലൂടെ കൊണ്ടുപോകുന്നു.

പുറം പാത യഥാർത്ഥത്തിൽ പരിമിതപ്പെടുത്തുന്നത് എത്തിച്ചേരാനുള്ള കഴിവും NAT കടന്നുപോകലുമാണ്. ഗേറ്റ്‌വേ IPv4 വിലാസം മാത്രം പ്രഖ്യാപിക്കുകയാണെങ്കിൽ, IPv6 മാത്രമുള്ള നെറ്റ്‌വർക്കിലെ ക്ലയന്റിന് നിങ്ങൾ എത്ര പൂളുകൾ കോൺഫിഗർ ചെയ്താലും ഒട്ടും ബന്ധിപ്പിക്കാനാവില്ല. പുറം കുടുംബം നിങ്ങളുടെ ക്ലയന്റ് ജനസംഖ്യയുടെ അടിസ്ഥാനത്തിൽ തീരുമാനിക്കുക, ആന്തരിക വിലാസ പ്ലാനിന്റെ അടിസ്ഥാനത്തിൽ അല്ല.

ഓരോ കുടുംബത്തിലും ക്ലയന്റിന് ഒരു വിലാസം നൽകുക

രണ്ട് കുടുംബങ്ങൾക്കും അഭ്യർത്ഥിക്കുന്നത് ക്ലയന്റ് ഭാഗത്ത് ഒരു വരിയുടെ പ്രസ്താവനയാണ്, ഗേറ്റ്‌വേയിൽ വിഭജിക്കാൻ എന്തെങ്കിലും ഉണ്ടെങ്കിൽ. പേരിട്ട പൂളുകൾ ഉറവിടങ്ങളെ സേവന നെറ്റ്‌വർക്കുകളിൽ നിന്ന് വേറിട്ട് നിർത്തുന്നു, ഈ സ്വഭാവമാണ് ആറ് മാസത്തിന് ശേഷവും ഫയർവാൾ നിയമങ്ങൾ വായിക്കാവുന്നതാക്കുന്നത്.

pools {
  pool4 { addrs = 10.90.0.0/24 }
  pool6 { addrs = fd42:90::/64 }
}
connections {
  private-access {
    version = 2
    pools = pool4, pool6
    local  { auth = pubkey  certs = gateway.pem  id = vpn.example.com }
    remote { auth = pubkey  cacerts = ca.pem  vips = 0.0.0.0, :: }
    children {
      private { local_ts = 10.60.0.0/16, fd42:60::/48  remote_ts = dynamic }
    }
  }
}

ഈ vips മൂല്യം ഓരോ കുടുംബത്തിൽ നിന്നും ഒരു വിലാസം ആവശ്യപ്പെടുന്നു, ആ വിലാസങ്ങൾ എവിടെ നിന്ന് വരുന്നു എന്ന് പൂളുകളുടെ പട്ടിക തീരുമാനിക്കുന്നു.strongSwan-ന്റെ വിർച്വൽ-IP രേഖകൾ നിരവധി അഭ്യർത്ഥനകളും പൂൾ അനുവദനവും ഉൾക്കൊള്ളുന്നു, നിർദ്ദിഷ്ട വിലാസം ആവശ്യപ്പെടുന്ന ക്ലയന്റ് പ്രതികരിക്കുന്നയാൾക്ക് അസാധുവാക്കാവുന്ന ഒരു മുൻഗണന മാത്രം പ്രകടിപ്പിക്കുന്നു എന്ന കാര്യവും അതിൽ ഉൾപ്പെടുന്നു. ക്ലയന്റ് എപ്പോഴും അതേ മൂല്യം സ്വീകരിക്കുന്നു എന്ന് അനുമാനിക്കുന്ന ആക്‌സസ് നിയമം നിർമ്മിക്കരുത്.

ഉദാഹരണം പകർത്തുന്നതിന് പകരം നിങ്ങളുടെ സ്വന്തം അനന്യ സ്ഥലീയ പ്രിഫിക്സ് സൃഷ്ടിക്കുക. രണ്ട് സ്ഥാപനങ്ങളും fd42::/16 നടപ്പാക്കിയാൽ, ആദ്യമായി പരസ്പരം ബന്ധിപ്പിക്കുമ്പോൾ കൂട്ടിയിടി കണ്ടെത്തും, അത് രോഗനിർണയം ചെയ്യുന്നത് സുഖകരമല്ല.

സെലക്ടറുകൾ ലക്ഷ്യങ്ങളെ വിവരിക്കുന്നു, ഉറവിടങ്ങളെയല്ല

ചൈൽഡ് SA-യുടെ സ്ഥലീയ ട്രാഫിക് സെലക്ടറുകൾ ഗേറ്റ്‌വേയുടെ പിന്നിൽ ഏത് സംരക്ഷിത നെറ്റ്‌വർക്കുകളാണെന്ന് പറയുന്നു, ദൂര സെലക്ടറുകൾ ക്ലയന്റിന് ഉറവിടമായി എന്ത് ഉപയോഗിക്കാമെന്ന് വിവരിക്കുന്നു. വിർച്വൽ പൂൾ വിലാസം ആ നയത്തിന്റെ ഉറവിട ഭാഗത്തിനാണ്; അതിനെ ലക്ഷ്യ പട്ടികയിൽ ഇടുന്നത് കോൺഫിഗറേഷന്റെ സാധാരണ തെറ്റായ വായനയാണ്.

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

പൂളുകളും സേവന പ്രിഫിക്സുകളും നിങ്ങളുടെ വിലാസ പ്ലാനിന്റെ വേറിട്ട ബ്ലോക്കുകളിൽ സൂക്ഷിക്കുക. അവ ഓവർലാപ്പ് ചെയ്യുമ്പോൾ, സംരക്ഷിത ഹോസ്റ്റിലേക്ക് എത്തേണ്ട പാത ഒരു പൂൾ വിലാസവുമായി ഒത്തുപോയി ടണലിനുള്ളിൽ അപ്രത്യക്ഷമായേക്കാം.

DNS-ഉം മറുപടി പാതയും അത് പൂർത്തിയായതായി തോന്നുന്നുണ്ടോ എന്ന് തീരുമാനിക്കുന്നു

റിസോൾവറിന്റെ മറുപടികൾ അതിലേക്ക് എത്താൻ ഉപയോഗിക്കുന്ന ട്രാൻസ്‌പോർട്ടിൽ നിന്ന് സ്വതന്ത്രമാണ്. ഒരു പേരിന് A റെക്കോർഡ്, AAAA റെക്കോർഡ് അല്ലെങ്കിൽ രണ്ടും തിരികെ നൽകാം, ക്ലയന്റ് സ്വന്തം മുൻഗണനാ നിയമങ്ങൾ അനുസരിച്ച് തിരഞ്ഞെടുക്കുന്നു. ഒരു ആന്തരിക സേവനം AAAA റെക്കോർഡ് പ്രസിദ്ധീകരിക്കുകയും എന്നാൽ ആ പ്രിഫിക്സ് ഒന്നും റൂട്ട് ചെയ്യാതിരിക്കുകയും ചെയ്താൽ, ഡ്യുവൽ-സ്റ്റാക്ക് നെറ്റ്‌വർക്കുകളിലെ ക്ലയന്റുകൾ ആദ്യം IPv6 പാത പരീക്ഷിച്ച് അത് പരാജയപ്പെടുന്നതുവരെ അവിടെ ഇരിക്കും. അപ്പോൾ ടണൽ കോൺഫിഗറേഷനിൽ ഒന്നും തെറ്റായി തോന്നുന്നില്ല.

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

പൂർത്തിയായി വിളിക്കുന്നതിന് മുമ്പ് രണ്ട് കുടുംബങ്ങളും പരിശോധിക്കുക

ലോഡ് ചെയ്യുന്ന കോൺഫിഗറേഷൻ പ്രവർത്തിക്കുന്ന കോൺഫിഗറേഷനല്ല. ഡീമൺ റിപ്പോർട്ട് ചെയ്യുന്ന അവസ്ഥ വായിക്കുക, പൂൾ അനുവദനകൾ സ്ഥിരീകരിക്കുക, തുടർന്ന് ക്ലയന്റ് യഥാർത്ഥത്തിൽ ഇൻസ്റ്റാൾ ചെയ്ത പാതകൾ നോക്കുക.

swanctl --list-sas
swanctl --list-pools
ip -6 addr show scope global
ip -6 route get fd42:60::10

ആദ്യ രണ്ട് കമാൻഡുകൾ സ്ഥാപിത ചൈൽഡ് SA-കളും ഏത് പൂളുകളിൽ ഇപ്പോഴും വിലാസങ്ങൾ ലഭ്യമാണെന്നും കാണിക്കുന്നു, അതിനാൽ ആദ്യ ക്ലയന്റിന് പ്രവർത്തിച്ച് പത്താമന് പരാജയപ്പെടുന്ന പ്ലാൻ ദൃശ്യമാകും. അവസാന രണ്ട് ക്ലയന്റിന് പൂളിൽ നിന്ന് ആഗോള IPv6 വിലാസം ലഭിച്ചോ എന്നും സംരക്ഷിത പ്രിഫിക്സിലേക്കുള്ള ട്രാഫിക് യഥാർത്ഥത്തിൽ എവിടെ പോകുമെന്നും കാണിക്കുന്നു. അനുവദിച്ച വിലാസം നിങ്ങൾ കോൺഫിഗർ ചെയ്ത പൂളുമായി താരതമ്യം ചെയ്യുക, നിങ്ങൾ പ്രതീക്ഷിച്ച വിലാസവുമായി അല്ല. പ്രതികരിക്കുന്നയാൾ തന്റെ നയപ്രകാരം മറ്റൊരു മൂല്യം തിരഞ്ഞെടുത്തിട്ടുണ്ടെങ്കിൽ, പാതകളും ഫയർവാൾ നിയമങ്ങളും ഇപ്പോഴും അതുമായി പൊരുത്തപ്പെടണം.

തുടർന്ന് ഓരോ കുടുംബത്തിനും ഒരു സംരക്ഷിത ഹോസ്റ്റ് പരിശോധിക്കുക, രണ്ടിലേക്കും റിസോൾവ് ചെയ്യുന്ന ഒരു പേരും പരിശോധിക്കുക. ഒരു കുടുംബത്തിന്റെ പരിശോധന നിങ്ങൾ പരിശീലിക്കാത്ത പകുതി പ്ലാനിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല, കാണാത്ത പാത സാധാരണയായി ആ പകുതിയിലാണ്.