OpenVPN द्वारा भेजे गए रूट इंस्टॉल नहीं होते: समय, अधिकार या नीति

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

बाहर से ये एक जैसे दिखते हैं और अलग सुधार माँगते हैं। क्लाइंट लॉग उस बिंदु पर पढ़ें जहाँ रूट का निर्णय लिया जाता है।

सिद्ध करें कि रूट अनुपस्थित है, केवल टूटा नहीं

शुरुआत यह सिद्ध करने से करें कि रूट टूटा नहीं बल्कि अनुपस्थित है। Linux पर, ip route show dev tun0 सूचीबद्ध करता है कि क्लाइंट ने टनल डिवाइस पर क्या इंस्टॉल किया। Windows पर, route print या Get-NetRoute वही बात तालिका के रूप में दिखाता है।

जो रूट मौजूद है पर ट्रैफ़िक फ़ॉरवर्ड नहीं करता, वह अलग समस्या है। इससे जाँच फ़ॉरवर्डिंग और फ़ायरवॉल नियमों की ओर जाती है, रूट इंस्टॉल की ओर नहीं।

समय: जोड़ने की प्रक्रिया डिवाइस के अस्तित्व में आने से पहले चली

नियंत्रण चैनल ऊपर आने के बाद और इंटरफ़ेस कॉन्फ़िगर करने के बाद क्लाइंट सर्वर के PUSH_REPLY का विश्लेषण करता है। तभी वह राउटिंग तालिका को छूता है, प्लेटफ़ॉर्म जो भी तंत्र दे उसका उपयोग करके। Linux netlink से होकर जाता है; Windows एक API का उपयोग करता है जिसके लिए उन्नत टोकन चाहिए। कॉन्फ़िगरेशन पढ़ते ही रूट जोड़ने वाली स्क्रिप्ट या क्लाइंट TUN/TAP डिवाइस के बनने से पहले चल सकता है, और कर्नेल जोड़ने से इनकार कर देता है।

यही दौड़ बताती है कि हाथ से लिखा रूट क्यों काम करता है जबकि स्वचालित नहीं: जब तक आप उसे लिखते हैं, इंटरफ़ेस ऊपर हो चुका होता है।

इसी स्थिति के लिए route-delay मौजूद है, और route-up ऐसी स्क्रिप्ट का नाम देता है जो इंटरफ़ेस और रूट कॉन्फ़िगर होने के बाद चलती है। टनल पते पर निर्भर रूट को शुरुआती चरण में नहीं, उसी हुक में रखें।

अधिकार: तालिका कौन बदल सकता है

Windows राउटिंग तालिका बदलने के लिए उन्नत टोकन चाहिए। सामान्य उपयोगकर्ता द्वारा शुरू किया गया GUI सेवा के ज़रिए एडाप्टर का पता सेट कर सकता है और फिर भी रूट नहीं जोड़ सकता। तब लॉग गुम पुश के बजाय पहुँच अस्वीकृत जैसी त्रुटि दिखाता है।

GUI को प्रशासक के रूप में शुरू करना, या सेवा-आधारित क्लाइंट का उपयोग करना, वह परिणाम बदल देता है। आवश्यक टोकन के बिना क्लाइंट शुरू करने वाला निर्धारित कार्य ऐसा नहीं करता।

कुछ भी बदलने से पहले जाँचें कि क्लाइंट वास्तव में किस खाते पर चलता है। संस्करण और सेवा मोड तय करते हैं कि कौन से कारण संभव हैं, इसलिए दोनों को रूट आउटपुट के पास दर्ज करें।

नीति: भेजे गए रूट जानबूझकर छोड़े जा सकते हैं

route-nopull क्लाइंट को सर्वर द्वारा भेजे गए रूट अनदेखा करने देता है, जिसमें भेजा गया डिफ़ॉल्ट रूट भी शामिल है, जबकि टनल पता अब भी स्वीकार किया जाता है। भेजे गए DNS और DHCP विकल्प उसी निर्देश से छोड़ दिए जाते हैं। ऐसा क्लाइंट दोषपूर्ण नहीं है; वह अपने कॉन्फ़िगरेशन में स्पष्ट रूट पंक्तियों की अपेक्षा करता है।

route-noexec एक अलग नियंत्रण है: यह क्लाइंट को रूट परिवर्तन बिल्कुल निष्पादित करने से रोकता है। जिस टोपोलॉजी को क्लाइंट मैप नहीं कर सकता, वह समान परिणाम दे सकती है, और रूट जोड़े जाने के बजाय अस्वीकृत के रूप में दर्ज होता है। तीनों में से कौन लागू है, इसका अनुमान लगाने के बजाय निर्णय बताने वाली लॉग पंक्ति पढ़ें। फिर प्रभावी प्रोफ़ाइल जाँचें, क्योंकि कोई आयातक या प्रबंधन उपकरण ऐसे विकल्प जोड़ सकता है जिन्हें उपयोगकर्ता ने कभी संपादित नहीं किया।

टेक्स्ट एडिटर में साफ़ दिखने वाली प्रोफ़ाइल रनटाइम में जोड़ा गया निर्देश लिए रह सकती है।

पुश सूची की तालिका से तुलना करें

जुड़ने के बाद सर्वर की पुश सूची क्लाइंट की तालिका के पास रखें। Linux पर वह ip route show dev tun0 है; Windows पर route print या Get-NetRoute। यदि रूट अनुपस्थित है, तो पहले इंस्टॉल ठीक करें। यदि वह मौजूद है और ट्रैफ़िक विफल होता है, तो फ़ॉरवर्डिंग और फ़ायरवॉल नीति पर जाएँ।

क्लाइंट का संस्करण, वह किस खाते पर चलता है और सेवा-आधारित है या नहीं, दर्ज करें। ये तीन तथ्य अगले व्यक्ति को बताते हैं कि कौन से कारण बाहर रखे गए।