ड्युअल-स्टॅक 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 पत्ता मिळाला का आणि संरक्षित प्रीफिक्सकडील रहदारी प्रत्यक्षात कुठे जाईल. नियुक्त केलेला पत्ता तुम्ही कॉन्फिगर केलेल्या पूलशी तुलना करा, तुम्ही अपेक्षित असलेल्या पत्त्याशी नाही. उत्तरदात्याने त्याच्या धोरणानुसार वेगळे मूल्य निवडले असेल, तर मार्ग आणि फायरवॉल नियम अजूनही त्याच्या निवडीशी जुळले पाहिजेत.

नंतर प्रत्येक कुटुंबासाठी एक संरक्षित होस्ट आणि दोन्हीत मिळणारे नाव तपासा. एका कुटुंबाची चाचणी तुम्ही सराव न केलेल्या अर्ध्या योजनेबद्दल काहीही सांगत नाही, आणि गहाळ मार्ग सामान्यतः त्याच अर्ध्यात असतो.