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 टनेलमध्ये पुन्हा तयार होते, आणि मधल्या प्रत्येक धोरणाचा त्यावर अमल होतो।

प्रथम सर्व्हरच्या प्रोटोकॉल आणि प्रमाणीकरण आवश्यकता स्पष्ट करा। नंतर ऑपरेटरला समर्थित क्लायंट आणि नोंदणी मार्ग वापरा, आणि त्या काळात खाजगी की वेब कन्व्हर्टरपासून दूर ठेवा।