strongSwan सँग दोहोरो-स्ट्याक IKEv2 निजी पहुँचको योजना

दोहोरो-स्ट्याक सुरुङ एक निर्णय होइन तीन हो, र तिनलाई फरक तरिकाले जवाफ दिन सकिन्छ। बाह्य सुरुङ कुन परिवारमाथि चल्छ, ग्राहकले भित्र कुन परिवार पाउँछ, र संरक्षित सेवाहरूले वास्तवमा कुन परिवारमा जवाफ दिन्छन्। तिनलाई एकै विकल्प मान्ने डिजाइनले या त कहिल्यै आवश्यक नभएको IPv6 बोक्छ, या कुनैले पनि फर्काएर रुट गर्न नसक्ने ठेगाना बाँड्छ। तीनलाई अलग गर्नुहोस् र बाँकी कन्फिगरेसन लगभग यान्त्रिक हुन्छ।

तीन प्रकारका ठेगाना, अलग-अलग तय गरिएका

बाह्य ठेगाना भनेको दुई गेटवे कसरी एकअर्कासम्म पुग्छन् भन्ने हो, र भित्री ट्राफिकले दुवै परिवार बोक्दा पनि त्यो IPv4 हुन सक्छ। भित्री भर्चुअल ठेगाना सुरुङभित्र ग्राहकको पहिचान हो, र प्रत्येक परिवारलाई आफ्नै पूल चाहिन्छ। संरक्षित उपसर्ग भनेको ग्राहकले पुग्न सक्ने कुरा हो, र ती सुरुङका होइनन्, सेवाहरूका हुन्। तेस्रोलाई दोस्रोसँग मिसाउँदा अधिकांश योजना त्रुटि हुन्छन्, किनकि दुवै निजी दायराजस्ता देखिन्छन्।

IPv4 मात्र बाह्य यातायात र दोहोरो-स्ट्याक भित्री ट्राफिक सामान्य र राम्रोसँग समर्थित व्यवस्था हो।

प्रत्येकलाई स्पष्ट रूपमा तय गर्नुहोस् र निर्णयहरू लेख्नुहोस्। बाह्य मार्ग IPv4 मात्र भए त्यो भन्नुहोस् र IPv6 अन्त्य बिन्दुको पहुँचबारे चिन्ता गर्न छोड्नुहोस्। भित्र कुनै परिवार तोकिए पनि त्यसमा केही पनि जवाफ नदिने भए, त्यसलाई योजनाबाट हटाउनुहोस् वा ती सेवाहरूलाई साँच्चै दोहोरो-स्ट्याक बनाउनुहोस्।

प्रत्येक परिवारमा भर्चुअल ठेगाना तोक्नुहोस्

swanctl कन्फिगरेसनमा ग्राहकले भर्चुअल ठेगाना माग्छ, र प्रत्येक परिवारको वाइल्डकार्डले उत्तरदातालाई प्रत्येकबाट एक तोक्न भन्छ। उत्तरदाताले ती पूलबाट लिन्छ, र पूलहरू गेटवेपछाडिका नेटवर्कबाट अलग वस्तु हुन्। योजनामा पनि तिनलाई अलग राख्नुहोस्, किनकि सेवा उपसर्गसँग ओभरल्याप हुने पूलले ट्राफिक अनपेक्षित ठाउँमा अवतरण हुने क्षणसम्म सही देखिने रुटिङ बनाउँछ।

दुवै चाहिएको बेला दुवै परिवार माग्नुहोस्, र नचाहिएको बेला एक, किनकि नप्रयोग गरिएको ठेगाना लाभविना नीतिको सतह हो। विशिष्ट अनुरोध अनुरोध हो, आरक्षण होइन, र उत्तरदाताले आफ्नै नीतिअनुसार फरक मान फर्काउन सक्छ। त्यो विवरण जहाँ ठेगाना फायरवाल नियम वा अनुगमन जाँचमा कडारूपमा लेखिएको हुन्छ त्यहाँ महत्त्वपूर्ण हुन्छ। जडानमा पूलहरूलाई नामले सन्दर्भ गर्नुहोस् र सेवा नेटवर्क तिनका बाहिर राख्नुहोस्।

vips = 0.0.0.0, ::

छोटो उदाहरण मान अपनाउनुको सट्टा IPv6 पूलका लागि आफ्नै अद्वितीय-स्थानीय उपसर्ग बनाउनुहोस्। उदाहरणले सेटिङको आकार देखाउँछ, वंशानुगत डिफल्ट होइन।

गन्तव्यहरू पूलबाट अलग वर्णन गर्नुहोस्

ट्राफिक चयनकर्ताले प्रत्येक पक्षले के साटासाट गर्न खोज्छ भन्ने वर्णन गर्छन्, त्यसैले गेटवेका स्थानीय चयनकर्ताले संरक्षित सेवा उपसर्गको नाम दिनुपर्छ, ग्राहक पूलको होइन। ग्राहकका दूरस्थ चयनकर्ताले त्यो मनसाय झल्काउँछन्। दुवै सूचीले फरक वस्तु वर्णन गर्दा सुरुङ माथि आउन सक्छ तर पनि उपयोगी केही बोक्दैन।

तीही उपसर्गलाई गेटवेको नेटवर्कभित्र फिर्ती मार्ग र अनुमति दिइएको अग्रेषण चाहिन्छ, तपाईंले सक्षम गर्नुहुने प्रत्येक परिवारका लागि।

यहीँ निजी IPv6 योजना पर्याप्त हुन छोड्छ। अद्वितीय-स्थानीय ठेगानाले निजी पहुँच किन्छ र सार्वजनिक IPv6 इग्रेस बनाउँदैन, त्यसैले नम्बर नभएको परिवारले सरासर IPv4 मास्करेडिङ नियम पछ्याउने भनी मान्ने डिजाइनले आफ्ना प्रयोगकर्तालाई निराश पार्छ। सार्वजनिक IPv6 पहुँच आवश्यकताको भाग भए, त्यसलाई रुट गरिएको योजना र त्यससँग सहमत हुने माथिल्लो प्रवाह चाहिन्छ। अन्यथा IPv6 पक्ष निजी मात्र हो भनी स्पष्ट भन्नुहोस्, जो लुकाउनुपर्ने सीमा होइन, इमानदार सीमा हो।

DNS र फिर्ती मार्गलाई जानाजान बनाउनुहोस्

नाम समाधान यातायात पछ्याउँदैन। रिजोल्भरले IPv4 मात्र सुरुङमार्फत A र AAAA रेकर्ड फर्काउन सक्छ, र त्यसपछि ग्राहकले तपाईंले कहिल्यै योजना नगरेको परिवार प्रयास गर्नेछ। कुन सेवा नामले उपयोगी दोहोरो-स्ट्याक जवाफ बोक्नुपर्छ भनी तय गर्नुहोस् र ती दुवै मार्ग जानाजान बनाउनुहोस्। काम गर्ने मार्ग नभएको परिवारमा समाधान हुने नामले सफा त्रुटिको सट्टा रोकावट बनाउँछ, र रोकावटको निदान गर्न धेरै गाह्रो हुन्छ।

बाह्य अन्त्य बिन्दुको पहुँच अलगै लेख्नुहोस्, कुनै NAT पार गर्ने कुरा संलग्न छ कि छैन र कुन परिवार प्रयोग गर्छ भन्नेसमेत।

त्यसपछि योजना छ लाइनमा लेख्नुहोस्: बाह्य अन्त्य बिन्दु, IPv4 पूल, IPv6 पूल, IPv4 सेवा उपसर्ग, IPv6 सेवा उपसर्ग, र प्रत्येकका जवाफ हुने राउटर। त्यो आकारको योजनाले राति तीन बजे अपरेटरले साँच्चै सोध्ने प्रश्नको जवाफ दिन्छ। यसभन्दा छोटो केहीले दोहोरो स्ट्याकलाई IPv4 मात्र नीतिमा बाँधिएको दोस्रो ठेगानाका रूपमा छोड्छ, र प्रायः त्यो आधा काम गर्दै अन्त्य हुन्छ।