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 स्वामित्व र फर्वार्डिङका आवश्यकताहरू डिजाइनमा थपिन्छन्, र धकेलिएको मार्ग पहिलो आधा मात्र हो। निर्देश थप्नुअघि आवश्यकतालाई ग्राफका रूपमा पुनः लेख्नुहोस्: कुन नोड कुन प्रिफिक्सको मालिक हो र कुन नोड त्यतिर फर्वार्ड गर्छ।

तपाईंले अनुमति दिन खोजेको त्यही एउटा सेवालाई मात्र अनुमति दिनुहोस्

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

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 नथप्नुहोस्, र विद्यमान अनुवाद नियमलाई त्यसमा के निर्भर छ भनी नजानी नहटाउनुहोस्। त्यसपछि त्यो एकल प्रवाहलाई सुरुदेखि अन्तसम्म प्रमाणित गर्नुहोस्, र एउटा निषेधित स्रोत वा पोर्ट पनि परीक्षण गर्नुहोस्: दुवैतर्फ काम गर्ने ह्यान्डसेकले न क्रस मार्ग प्रमाणित गर्छ न अलगाव।