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 टनल में फिर से उत्पन्न होता है, और बीच की हर नीति उस पर लागू होती है।

पहले सर्वर की प्रोटोकॉल और प्रमाणीकरण आवश्यकताएँ स्पष्ट करें। फिर वह क्लाइंट और नामांकन पथ उपयोग करें जिसे ऑपरेटर समर्थन देता है, और तब तक निजी कुंजियों को वेब कन्वर्टर से दूर रखें।