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" जैसी पंक्ति हर क्लाइंट को बताती है कि सर्वर-पक्ष के नेटवर्क तक कैसे पहुँचना है। शाखा के लिए, समतुल्य रूट सर्वर-पक्ष पर जो कुछ भी पहुँचना चाहिए उसके लिए टनल की ओर इशारा करता है।

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

सर्वर होस्ट पर फ़ॉरवर्डिंग सक्षम होनी चाहिए। उसके बिना कर्नेल टनल से पैकेट स्वीकार करता है और उसे LAN इंटरफ़ेस तक पास करने से मना कर देता है, जो क्लाइंट की दृष्टि से गुम iroute जैसा ही दिखता है।

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

दूर के सिरे पर ping करके अनुमान लगाने के बजाय परतों में परीक्षण करें। सर्वर से जाँचें कि प्रीफ़िक्स के लिए आंतरिक मैपिंग मौजूद है और कर्नेल रूट टनल की ओर इशारा करता है। क्लाइंट से पुष्टि करें कि पुश किया गया रूट स्थापित है और LAN पते के लिए उसका डिफ़ॉल्ट पथ टनल है।

फिर पैकेट देखें। टनल इंटरफ़ेस पर कैप्चर दिखाता है कि सर्वर क्लाइंट की ओर प्रसारित कर रहा है या नहीं, और LAN इंटरफ़ेस पर कैप्चर दिखाता है कि वह फ़ॉरवर्ड कर रहा है या नहीं। यदि पहला पैकेट दिखाता है और दूसरा कुछ नहीं, तो समस्या फ़ॉरवर्डिंग या फ़िल्टर में है; यदि दोनों में से कोई कुछ नहीं दिखाता, तो खोज पहले ही विफल हो चुकी है।

टनल से जुड़े दो सर्वर दोनों ओर वही नियम दोहराते हैं: हर एक को दूसरे के पूल के लिए iroute चाहिए, और हर एक को वह रूट और फ़ॉरवर्डिंग चाहिए जो पथ को सममित बनाए। यहाँ रूटिंग और नीति अलग-अलग विषय हैं। रूटिंग तय करती है कि पैकेट कहाँ जा सकता है, जबकि FORWARD नियम तय करता है कि उसे अनुमति है या नहीं, इसलिए दो iroute पंक्तियों वाला क्लाइंट दोनों प्रीफ़िक्स तक पहुँच सकता है, जब तक कोई फ़िल्टर अन्यथा न कहे।