क्या 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

असली key और 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 स्वामित्व और फ़ॉरवर्डिंग की ज़रूरतें डिज़ाइन में जुड़ जाती हैं, और धकेला गया रूट सिर्फ़ पहला आधा है। निर्देश जोड़ने से पहले आवश्यकता को ग्राफ़ के रूप में दोबारा लिखें: कौन-सा नोड किस प्रीफ़िक्स का स्वामी है, और कौन-सा नोड उसकी ओर फ़ॉरवर्ड करता है।

सिर्फ़ उसी एक सेवा की अनुमति दें जिसकी आप अनुमति देना चाहते थे

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

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 न जोड़ें, और मौजूदा अनुवाद नियम को यह जाने बिना न हटाएँ कि उस पर क्या निर्भर है। फिर उस एक प्रवाह को शुरू से अंत तक सत्यापित करें, और एक वर्जित स्रोत या पोर्ट भी जाँचें: दोनों तरफ़ काम करने वाला हैंडशेक न क्रॉस रूट साबित करता है न पृथक्करण।