डुअल-स्ट्याक 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 ठेगाना पायो कि पाएन र सुरक्षित प्रिफिक्सतर्फको ट्राफिक वास्तवमै कहाँ जान्छ देखाउँछन्। तोकिएको ठेगानालाई तपाईंले कन्फिगर गरेको पुलसँग तुलना गर्नुहोस्, तपाईंले अपेक्षा गरेको ठेगानासँग होइन। यदि उत्तरदाताले आफ्नो नीतिअनुसार फरक मान छान्यो भने, मार्ग र फायरवाल नियमहरू अझै उसको छनोटसँग मिल्नुपर्छ।

त्यसपछि प्रत्येक परिवारका लागि एक सुरक्षित होस्ट, र दुवैमा रिजोल्भ हुने नाम परीक्षण गर्नुहोस्। एक परिवारको परीक्षणले तपाईंले अभ्यास नगरेको आधा योजनाबारे केही भन्दैन, र हराएको मार्ग सामान्यतया त्यही आधामा हुन्छ।