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। रुट अनुपस्थित छ भने पहिले स्थापना ठीक गर्नुहोस्। त्यो उपस्थित छ तर ट्राफिक असफल हुन्छ भने फर्वार्डिङ र फायरवाल नीतितिर जानुहोस्।

क्लाइन्टको संस्करण, त्यो कुन खातामा चल्छ र सेवा-आधारित छ कि छैन टिप्नुहोस्। ती तीन तथ्यले अर्को व्यक्तिलाई कुन कारण बाहिर राखिए भनी बताउँछन्।