OpenVPN क्लाइन्टको पछाडिको सबनेट किन पहुँचयोग्य छैन?

सर्भरको टनेल ठेगानामा ping सफल हुन्छ, क्लाइन्टको आफ्नै रुट तालिका ठीक देखिन्छ, तैपनि त्यो क्लाइन्टको पछाडिको LAN पहुँचयोग्य छैन। क्लाइन्टको राउटिङ तालिका सही देखिन्छ, सर्भरमा टनेलतर्फ देखाउने मार्ग छ, र प्याकेटहरू अझै हराउँछन्। यो layer-3 टनेलको क्लासिक लक्षण हो, जसलाई थाहा छैन कि यसका एक क्लाइन्ट आफैं गेटवे पनि हुन्।

tun इन्टरफेसमा प्रत्येक क्लाइन्टका लागि अर्को हप हुँदैन। कर्नेलले धेरै पियर भएको एउटै इन्टरफेस देख्छ, त्यसैले टाढाको LAN का लागि कुन क्लाइन्टले प्याकेट पाउने भन्ने निर्णय OpenVPN प्रक्रियाभित्र लिनुपर्छ। त्यो निर्णय iroute ले कन्फिगर गरिन्छ, र त्यो बिना प्याकेटलाई जाने ठाउँ छैन।

सर्भर इन्टरफेस अनुसार होइन, क्लाइन्ट अनुसार रुट गर्छ

सर्भरले क्लाइन्टको टनेल ठेगानामा प्याकेट पठाउनुपर्दा उत्तर स्पष्ट हुन्छ: ठेगाना त्यो क्लाइन्टको सत्रको हो। जब गन्तव्य त्यो क्लाइन्टको पछाडिको पूरै सबनेट हुन्छ, ठेगाना सर्भरलाई थाहा भएको कसैको हुँदैन, र टनेलतर्फको कर्नेल मार्गले मात्र "यो इन्टरफेसबाट" भन्छ, कुन पियर भनेर बताउँदैन।

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

म्यापिङ नभए प्याकेट सर्भरसम्म पुग्छ, टनेल मार्गसँग मिल्छ र कुनै क्लाइन्टले गन्तव्यको दाबी नगर्ने भएकाले फालिन्छ। केही पनि स्पष्ट त्रुटि लग गर्दैन, त्यसैले विफलता राउटिङ लूपजस्तो नभई शान्त कालो प्वालजस्तो देखिन्छ।

क्लाइन्टको नाम लिने iroute प्रविष्टि लेख्ने

iroute सर्भरको मुख्य कन्फिगरेसनमा होइन, क्लाइन्ट-विशेष कन्फिगरेसन फाइलमा बस्छ। client-config-dir विकल्पसँग सर्भरलाई एउटा डिरेक्टरीतर्फ निर्देश गर्नुहोस्, त्यसपछि नाम क्लाइन्टको प्रमाणपत्रको सामान्य नाम हुने फाइल बनाउनुहोस् र प्रिफिक्स त्यसमा राख्नुहोस्।

जसको LAN 10.20.0.0/24 छ र प्रमाणपत्रको सामान्य नाम branch-router छ त्यस्तो शाखाका लागि त्यो बाटोको फाइलमा iroute 10.20.0.0 255.255.255.0 जस्तो लाइन हुन्छ। मुख्य कन्फिगरेसनलाई डिरेक्टरी विकल्प मात्र चाहिन्छ; प्रिफिक्स क्लाइन्टसँग बस्छ।

सामान्य नाम नै नाजुक भाग हो। फरक subject सँग जारी गरिएको प्रमाणपत्र, वा प्रयोगकर्ताहरूलाई प्रयोगकर्ता नामले प्रमाणित गर्ने तर फाइल प्रमाणपत्रको नाममा रहेको तैनाथीले कहिल्यै नपढिने फाइल बनाउँछ। सर्भरले सत्रका लागि वास्तवमा कुन नाम बताउँछ जाँच्नुहोस्, र नमिल्ने क्लाइन्टलाई यसका मार्गबिना चुपचाप जोडिनुको सट्टा असफल हुन दिने विकल्प विचार गर्नुहोस्। प्रमाणपत्रसँग मिल्ने गरी फाइलको नाम बदल्नु धेरै लामो साँझ रोक्ने पाँच मिनेटको सुधार हो।

एउटा क्लाइन्टसँग धेरै प्रिफिक्स हुन सक्छन्। प्रत्येक नेटवर्कका लागि एउटा iroute लाइन थप्नुहोस् र म्यापिङ लेखापरीक्षणयोग्य रहन सूची त्यो क्लाइन्टका बाँकी सेटिङसँगै राख्नुहोस्।

दुवै दिशामा फर्कने मार्ग बनाउने

टाढाको LAN सम्म प्याकेट पुर्‍याउनु आधा काम हो। क्लाइन्टले त्यो LAN को ट्राफिक पनि टनेलमा पठाउनुपर्छ, जो सामान्यतया क्लाइन्टलाई मार्ग धकेलेर गरिन्छ: push "route 10.8.0.0 255.255.255.0" जस्तो लाइनले प्रत्येक क्लाइन्टलाई सर्भरतर्फको नेटवर्कमा कसरी पुग्ने बताउँछ। शाखाका लागि, समतुल्य मार्गले सर्भरतर्फ पुग्नुपर्ने सबैतर्फ टनेल देखाउँछ।

फर्कने दिशालाई टाढाकोतर्फ मालिक चाहिन्छ। त्योतर्फ कसैलाई फर्कने बाटो थाहा हुनुपर्छ: VPN पूल सर्भरतर्फ देखाउने LAN राउटरमा स्थिर मार्ग, वा ट्राफिक LAN मा पस्नुअघि सर्भरमा ठेगाना अनुवाद। स्थिर मार्गले मूल ठेगानाहरू लग र पहुँच नियमहरूमा देखिने राख्छ तर LAN मालिकको सहयोग चाहिन्छ; अनुवाद आत्मनिर्भर छ तर वास्तवमा को जोडियो भन्ने लुकाउँछ।

सर्भर होस्टमा फर्वार्डिङ सक्षम हुनुपर्छ। त्यो बिना कर्नेलले टनेलबाट प्याकेट स्वीकार्छ र त्यसलाई LAN इन्टरफेसमा पठाउन अस्वीकार गर्छ, जो क्लाइन्टको दृष्टिकोणबाट हराएको iroute जस्तै देखिन्छ।

सही प्रोबले पहुँच जाँच्ने

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

त्यसपछि प्याकेट हेर्नुहोस्। टनेल इन्टरफेसमा क्याप्चरले सर्भर क्लाइन्टतर्फ पठाइरहेको छ कि छैन देखाउँछ, र LAN इन्टरफेसमा क्याप्चरले यो फर्वार्ड गरिरहेको छ कि छैन देखाउँछ। पहिलोले प्याकेट देखाउँछ र दोस्रोले केही देखाउँदैन भने समस्या फर्वार्डिङ वा फिल्टरमा छ; दुवैले केही नदेखाएमा खोज पहिले नै असफल भएको छ।

टनेलले जोडिएका दुई सर्भरले दुवैतर्फ उही नियम दोहोर्‍याउँछन्: प्रत्येकलाई अर्कोको पूलका लागि iroute चाहिन्छ, र प्रत्येकलाई मार्ग सममित बनाउने मार्ग र फर्वार्डिङ चाहिन्छ। यहाँ राउटिङ र नीति अलग-अलग विषय हुन्। राउटिङले प्याकेट कहाँ जान सक्छ निर्धारण गर्छ, जबकि FORWARD नियमले अनुमति छ कि छैन निर्धारण गर्छ, त्यसैले दुई iroute लाइन भएको क्लाइन्टले फिल्टर अन्यथा नभने दुवै प्रिफिक्समा पुग्न सक्छ।