डुअल-स्टैक 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 पता मिला या नहीं और संरक्षित प्रीफ़िक्स की ओर ट्रैफ़िक वास्तव में कहाँ जाएगा। आवंटित पते की तुलना उस पूल से करें जो आपने कॉन्फ़िगर किया, उस पते से नहीं जिसकी आपने आशा की थी। अगर उत्तरदाता ने अपनी नीति के तहत अलग मान चुना, तो मार्ग और फ़ायरवॉल नियम अब भी उसके चुनाव से मेल खाने चाहिए।

फिर हर परिवार के लिए एक संरक्षित होस्ट जाँचें, और ऐसा नाम जाँचें जो दोनों में रिज़ॉल्व हो। एक-परिवार का परीक्षण आपको योजना के उस आधे हिस्से के बारे में कुछ नहीं बताता जिसका अभ्यास आपने नहीं किया, और आमतौर पर गुम मार्ग उसी आधे में होता है।