WireGuard क्लायंट OpenVPN क्लायंटपर्यंत पोहोचू शकत नाही का?

दोन्ही टनेल जोडल्या जातात, प्रत्येक क्लायंट गेटवेपर्यंत पोहोचतो, आणि एकाने दुसऱ्याचा पत्ता वापरून पाहिल्याक्षणी पॅकेट अदृश्य होतात। दोन्हीपैकी कोणत्याही हँडशेकमध्ये काहीही चूक नाही, आणि किल्ल्या पुन्हा जारी केल्याने ते बदलत नाही। गेटवे आपल्या दोन इंटरफेसच्या दरम्यान सामान्य अनएन्क्रिप्टेड IP पॅकेट वाहून नेतो, म्हणून प्रोटोकॉलना एकमेकांना समजून घेण्याची कधीही गरज नसते; त्यांना तीन गोष्टी हव्यात ज्या कोणताही हँडशेक देत नाही। उगम क्लायंटवर गंतव्य कव्हरेज, गेटवेवर स्रोत मालकी आणि पलीकडच्या बाजूला परतीचा मार्ग। लक्षण तिन्हींसाठी सारखेच असते, म्हणून त्यांचे निदान एकत्र होते।

लक्षणात एका वेळी एकच भाग गहाळ असतो

ही रचना wg1 वर 10.71.0.0/24 चा WireGuard पूल आणि tun1 वर 10.72.0.0/24 चा OpenVPN पूल वापरते, दोन्ही एकाच गेटवेवर संपतात। चाचणीतील विनंती 10.71.0.5 वरून 10.72.0.30 वरील HTTPS कडे जाते। खालील प्रत्येक पायरी त्याच एका प्रवाहाबद्दल आहे। प्रत्येक तपासणीची अयशस्वी होण्याची खूण वेगळी असते तरी वापरकर्त्याला त्या सारख्याच जाणवतात, आणि सहसा एका वेळी तिन्हींपैकी एकच गहाळ असतो।

दोन्ही पूल खरोखर याच गेटवेवर आहेत आणि ज्या namespace मध्ये टनेल राहतात तिथे फॉर्वर्डिंग सुरू आहे याची खात्री करून सुरुवात करा। दोन्ही प्रोटोकॉल वेगवेगळ्या namespace मध्ये संपवणारा गेटवे त्यांच्यात काहीही फॉर्वर्ड करत नाही, आणि कोणतेही peer कॉन्फिगरेशन वाचण्यापूर्वी हे बाद करणे योग्य आहे।

स्पोकचे गंतव्य कव्हरेज वाढवा

WireGuard क्लायंटवर, विद्यमान peer नोंदीने OpenVPN गंतव्यासाठी गेटवे निवडला पाहिजे, म्हणजे गंतव्य प्रीफिक्स त्या peerच्या परवानगी असलेल्या यादीत आले पाहिजे। ते जोडल्याने दुसरे टनेल तयार होत नाही; क्लायंट तो पत्ता शोधताना कोणता peer निवडतो हे बदलते, आणि wg-quick सह मार्ग सहसा यादीचे आपोआप अनुसरण करतो।

AllowedIPs = 10.71.0.0/24, 10.72.0.0/24

खरे किल्ली आणि endpoint ओळी अशा आहेत तशाच ठेवा, आणि लक्षात ठेवा की Table = off वापरणारा व्यवस्थापक या यादीतून कोणताही मार्ग घेत नाही। अशा स्थितीत तोच प्रीफिक्स सिस्टमच्या मार्ग तक्त्यात ज्याची मालकी आहे त्याने बसवावा लागतो, आणि तिथे गहाळ मार्ग गहाळ परवानगी असलेल्या प्रीफिक्ससारखाच दिसतो।

गेटवेवर स्रोत मालकी ठेवा

या क्लायंटची गेटवेवरील peer नोंद त्या क्लायंटच्या स्रोत पत्त्याचीच मालकी ठेवली पाहिजे। परवानगी असलेले पत्ते दोन्ही दिशांनी तपासले जातात: ते बाहेर जाणाऱ्या रहदारीसाठी peer निवडतात आणि आत येणाऱ्या पॅकेटचा स्रोत ते पाठवणाऱ्या peerचाच आहे याची पडताळणी करतात। स्पोकला त्या पूलमध्ये पोहोचायचे आहे म्हणून OpenVPN पूल स्पोकच्या नोंदीत टाकणे हीच ती चूक आहे जी रहदारी चुकीच्या सहभागाकडे वळवते।

AllowedIPs = 10.71.0.5/32

ती नोंद मार्गसुविधा नव्हे तर मालकीचे घोषणापत्र म्हणून वाचा। क्लायंटला जिथपर्यंत पोहोचायचे आहे ते सर्व क्लायंटच्या गंतव्य यादीत येते, या peerला काय पाठवायला परवानगी आहे या गेटवेच्या कल्पनेत नाही।

OpenVPN बाजूला परतीचा मार्ग द्या

गंतव्याला आता WireGuard स्रोताकडे परतीचा मार्ग हवा आहे, आणि पूल क्लायंटसाठी तो सहसा OpenVPN सर्व्हरकडून ढकललेला मार्ग म्हणून येतो। ज्यांना तो असायला हवा त्यांनाच तो ढकला, आणि निर्देश लागू झाला असे गृहीत धरण्याऐवजी क्लायंटवर तो स्वीकारला गेला याची खात्री करा।

push "route 10.71.0.0 255.255.255.0"

मार्ग वितरण हे अधिकृतता नाही। जेव्हा गंतव्य पूलमध्ये नसून दुसऱ्या OpenVPN क्लायंटच्या मागे असते, तेव्हा त्या क्लायंटची स्वतःची LAN मालकी आणि फॉर्वर्डिंगच्या गरजा रचनेत जोडल्या जातात, आणि ढकललेला मार्ग फक्त पहिला अर्धा आहे। निर्देश जोडण्यापूर्वी गरज graph म्हणून पुन्हा लिहा: कोणत्या नोडकडे कोणते प्रीफिक्स आहे आणि कोणता नोड त्या दिशेने फॉर्वर्ड करतो।

तुम्हाला परवानगी द्यायची होती तीच एक सेवा परवानगी द्या

फॉर्वर्डिंग सुरू आणि दोन्ही पूल मार्गयोग्य असताना उरलेला प्रश्न धोरणाचा आहे। नियम सर्वसाधारणपणे इंटरफेस जोडीसाठी नव्हे तर त्या विशिष्ट प्रवाहासाठी लिहा, लागू करण्यापूर्वी पूर्वावलोकन करा, आणि उत्तरे नवीन कनेक्शन म्हणून अडवली जाऊ नयेत म्हणून स्थिती टिकवणारा परतीचा मार्ग ठेवा। कोरड्या चाचणीला काही खर्च नाही आणि काय जोडले जाईल ते नेमके दाखवते।

sudo ufw --dry-run route allow in on wg1 out on tun1 proto tcp from 10.71.0.5 to 10.72.0.30 port 443

हे फॉर्वर्ड केलेल्या रहदारीचे नियम आहेत, गेटवेच्या दोन VPN सेवांसाठीच्या ऐकण्याच्या नियमांपेक्षा वेगळे। बाहेरील UDP पोर्ट उघडल्याने आतील विनंती अधिकृत होत नाही, आणि आतील विनंती अधिकृत करण्यासाठी गेटवेपर्यंत अमर्यादित SSH किंवा फॉर्वर्डिंगवर डीफॉल्ट परवानगी लागत नाही। गंतव्याचा स्वतःचा फायरवॉल आणि ऐकण्याचा पत्ता यांचीही जुळणी हवी, कारण loopback ला बांधलेली सेवा सर्वात काळजीपूर्वक मार्ग दिलेले पॅकेटही नाकारते। जे धोरण संभाषणाची फक्त एक दिशा झाकते ते सहसा यशस्वी विनंती आणि शांत उत्तराने अपयशी ठरते, आणि हा तिन्हींपैकी सर्वात गोंधळाचा निकाल आहे।

परस्पर मार्ग म्हणजे सहसा स्रोत भाषांतराची गरज नाही, ज्यामुळे गंतव्यावर WireGuard पत्ता टिकतो आणि लॉग वाचनीय होतात। दोन प्रोटोकॉल सहभागी आहेत म्हणून सर्वसमावेशक masquerading जोडू नका, आणि विद्यमान भाषांतर नियम त्यावर काय अवलंबून आहे हे जाणून घेतल्याशिवाय काढू नका। नंतर तो एकच प्रवाह सुरुवातीपासून शेवटपर्यंत तपासा, आणि एक निषिद्ध स्रोत किंवा पोर्टही तपासा: दोन्ही बाजूला चालणारा हँडशेक क्रॉस मार्गही सिद्ध करत नाही आणि विलगीकरणही नाही।