IPsec गेटवेका लागि WireGuard प्रोफाइल: यसको सट्टा के माग्ने

शान्त गेटवेसँग ह्यान्डशेकको समय सकिनु सामान्यतया कहिल्यै नभेट्ने दुई प्रोटोकलको अर्थ हुन्छ। WireGuard पियर Noise बोल्छ जबकि IPsec गेटवे IKE प्रतीक्षा गर्छ। सही ठेगाना र पोर्टले यो बदल्दैन।

प्रोफाइलमा इन्डपोइन्ट पुनः प्रयोग गर्नाले दुईलाई जोड्दैन। अर्को कदम गेटवे चलाउने व्यक्तिलाई अनुरोध गर्नु हो।

पहिलो अनुरोध: प्रोटोकल संस्करण

IPsec ले एक परिवारको नाम दिन्छ, एकल कार्यप्रवाहको होइन। IKEv2 र IKEv1 आफ्ना आदानप्रदान, प्रमाणीकरण विकल्प र नेटवर्क परिवर्तन हुँदाको व्यवहारमा भिन्न छन्। केवल IKEv1 अन्त्य गर्ने गेटवेले IKEv2 प्रस्ताव गर्ने गेटवेभन्दा पूर्ण रूपमा फरक व्यवहार गर्नेछ। क्लाइन्ट कन्फिगरेसन पनि त्यसैसँग बदलिन्छ।

सेवाले कुन संस्करण अन्त्य गर्छ र यो मानक-आधारित कार्यान्वयन चलाउँछ कि आफ्नै क्लाइन्ट भएको विक्रेता संस्करण भन्ने सोध्नुहोस्। अपरेटिङ सिस्टमका मेनुले प्रायः त्यो उत्तर एउटै लेबलपछि लुकाउँछन्। लेबल नै प्रोटोकल होइन।

दोस्रो अनुरोध: क्लाइन्टको प्रमाणीकरण विधि

प्रमाणीकरण त्यहीँ छ जहाँ अधिकांश वास्तविक काम हुन्छ। सेवाले कुनै विशेष विस्तारित कुञ्जी प्रयोग भएको मेसिन प्रमाणपत्र, प्रयोगकर्ता प्रमाणपत्र, IKEv2 माथिको EAP विधि वा पहिचानसँग बाँधिएको पूर्व-साझा कुञ्जी अपेक्षा गर्न सक्छ। कुन लागू हुन्छ भन्नेले क्लाइन्टलाई के चाहिन्छ भन्ने निर्धारण गर्छ।

WireGuard निजी कुञ्जी तीमध्ये केही पनि होइन। यो एक विशिष्ट ह्यान्डशेकमा प्रयोग हुने Curve25519 कुञ्जी हो। कुनै रूपान्तरणले यसलाई प्रमाणपत्र वा EAP प्रमाण बनाउँदैन। विपरीत दाबी गर्ने उपकरणले फाइलको नाम बदल्दै छ वा असम्बन्धित केही उत्पादन गर्दै छ।

RFC 7296 मा रहेको IKEv2 विनिर्देशले त्यो संस्करणको कार्यान्वयनले के समर्थन गर्नुपर्ने वर्णन गर्छ। यो अपरेटरको अस्पष्ट उत्तरका लागि सन्दर्भ हो, क्लाइन्ट कन्फिगरेसनको मार्गदर्शिका होइन।

तेस्रो अनुरोध: विश्वसनीय पहिचान र गन्तव्यहरू

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

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

इन्डपोइन्टको जाँच क्लाइन्ट त्रुटिभन्दा फरक प्रश्नको उत्तर दिन्छ। संगठन बिना पुग्न सकिने पोर्टले प्रमाणीकरणतर्फ संकेत गर्छ, जबकि नपुग्ने पोर्टले मार्गतर्फ।

# what does the endpoint offer on its IPsec ports?
sudo nmap -sU -p 500,4500 198.51.100.44

# strongSwan: what did the IKE exchange negotiate?
sudo swanctl --list-sas
sudo swanctl --list-conns

क्लाइन्टमा केही बदल्नु अघि यो जाँच चलाउनुहोस्। पोर्टहरूले उत्तर दिए पनि संगठन असफल भइरहेमा समस्या प्रमाण वा नीतिमा छ। तिनीहरूले बिल्कुलै उत्तर नदिएमा कुनै प्रोफाइल सम्पादनले सहयोग गर्दैन।

जब दुवै प्रोटोकल सँगै रहनुपर्छ

दुवै नेटवर्कको प्रशासन दुवै प्रोटोकल राख्ने वैध कारण हो। सामान्य डिजाइनले WireGuard र IPsec लाई छुट्टै इन्टरफेस वा छुट्टै गेटवेमा अन्त्य गर्छ। स्वीकृत ट्राफिक त्यसपछि तिनीहरूबीच रुट गरिन्छ।

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

यो जो होइन त्यो पारदर्शी रूपान्तरण हो। WireGuard मार्फत आउने ट्राफिक IPsec टनेलमा पुनः सिर्जना हुन्छ, र बीचको प्रत्येक नीति त्यसमा लागू हुन्छ।

पहिले सर्भरको प्रोटोकल र प्रमाणीकरण आवश्यकता स्पष्ट पार्नुहोस्। त्यसपछि अपरेटरले समर्थन गर्ने क्लाइन्ट र दर्ता मार्ग प्रयोग गर्नुहोस्, र त्यस क्रममा निजी कुञ्जीहरूलाई वेब कन्भर्टरबाट टाढा राख्नुहोस्।