ડ્યુઅલ-સ્ટેક 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 સરનામું મળ્યું છે કે નહીં અને સુરક્ષિત પ્રીફિક્સ તરફનો ટ્રાફિક ખરેખર ક્યાં જશે. ફાળવેલા સરનામાને તમે ગોઠવેલા પૂલ સાથે સરખાવો, તમે આશા રાખેલા સરનામા સાથે નહીં. જો જવાબ આપનારે તેની નીતિ હેઠળ અલગ મૂલ્ય પસંદ કર્યું હોય, તો માર્ગો અને ફાયરવોલ નિયમોએ હજી પણ તેની પસંદગી સાથે મેળ ખાવો જોઈએ.

પછી દરેક કુટુંબ માટે એક સુરક્ષિત હોસ્ટ ચકાસો, અને એવું નામ ચકાસો જે બંનેમાં રિઝોલ્વ થાય. એક-કુટુંબની કસોટી તમે અભ્યાસ ન કરેલા અડધા ભાગ વિશે કંઈ કહેતી નથી, અને સામાન્ય રીતે ખૂટતો માર્ગ એ જ અડધા ભાગમાં હોય છે.