OpenVPN रूट सीमा वास्तव में किस घटक के पास है?
रूट सीमा OpenVPN इंजन, NetworkManager प्लगइन या सर्वर की हो सकती है। प्रोफ़ाइल संपादित करने या संख्या बढ़ाने से पहले मालिक का नाम तय करें।
दो सौ रूट वाली एक प्रोफ़ाइल एक मशीन पर काम करती है और दूसरी पर चालीस स्थापित करती है। इंजन, उसे शुरू करने वाला एकीकरण और उसे खिलाने वाला सर्वर, सबकी अपनी बात है, और हर कोई सूची को अलग जगह रोक सकता है। विफलता को एक ही सीमा मानकर पढ़ने से आप गलत फ़ाइल तक पहुँचते हैं। तंत्र के तीन चरण हैं, और जो चरण रुका, वह दिखने वाला सबूत छोड़ जाता है, बशर्ते आप जानें कि क्या खोजना है।
तीन चरण, तीन अलग सीमाएँ
पहले इंजन विकल्प को पढ़ता है और तय करता है कि यह संस्करण उसे समझता है या नहीं। फिर एकीकरण वह स्थापित करता है जो इंजन बताता है, और उसका अपना कोड सूची को सीमित या नया आकार दे सकता है। अंत में सर्वर तय करता है कि किसी पहचान को कितने रूट भेजेगा, इससे पहले कि कोई भी क्लाइंट चरण कुछ देखे। तीन चरण, तीन छतें, और उनमें से केवल एक ही प्रोफ़ाइल की संख्या है।
एक छत बढ़ाने से बाकी के लिए कुछ नहीं होता। अस्वीकृत भेजा गया रूट सर्वर पर नीति का निर्णय हो सकता है, क्लाइंट द्वारा सुलझाया गया ओवरलैप हो सकता है, या इंस्टॉलर की सीमा हो सकती है जिसने अतिरिक्त हटा दिया। इनमें से हर एक का अलग समाधान है।
कुछ भी मापने से पहले तीनों को अलग करें। पार्सर त्रुटि एक टोकन का नाम बताती है, इंस्टॉलर की सीमा छोटी रूट तालिका छोड़ती है, और नीति का निर्णय कुछ भी नहीं छोड़ता। सबूत बताता है कि पहले कौन सा चरण जाँचना है।
| Stage | Who decides | What you can see |
|---|---|---|
| Parse | Client engine | An error naming the option |
| Install | Activation owner | A route count below the pushed count |
| Offer | Server policy | A route absent from the pushed list |
पार्सर पहले बोलता है
अज्ञात विकल्प ज़ोर से और जल्दी विफल होता है, और त्रुटि पाठ टोकन का नाम बताता है। वह पहचानने में सबसे आसान चरण है: सटीक संदेश की तुलना स्थापित इंजन संस्करण से करें, क्योंकि एक संस्करण में जोड़ा गया विकल्प उससे पहले वाले में अज्ञात होता है। नए परिनियोजन से नकल की गई प्रोफ़ाइल इस असंगति का सामान्य स्रोत है। पार्सर कभी भी किसी ऐसे निर्देश को चुपचाप नज़रअंदाज़ नहीं करता जिसे वह नहीं पहचानता।
स्वीकृत विकल्प परिणाम के बारे में कुछ नहीं कहता। पार्सिंग सफल होती है, और फिर भी सूची इंस्टॉलर द्वारा काटी जा सकती है या सर्वर द्वारा कभी प्रस्तावित नहीं की जा सकती। साफ़ पार्सिंग को आगे बढ़ने की अनुमति मानें, सबूत नहीं।
संस्करण स्ट्रिंग उस बाइनरी से दर्ज करें जो वास्तव में चली, पैकेज प्रबंधक की इस धारणा से नहीं कि क्या स्थापित है। ये दोनों अपेक्षा से अधिक बार मेल नहीं खाते।
इंस्टॉलर की अपनी छत है
जो घटक सक्रियण का मालिक है वह इंजन बाइनरी के बजाय NetworkManager प्लगइन हो सकता है, और कोई सुरंग बनने से पहले ही अपनी सीमा थोप सकता है। उसका संपादक ऐसा फ़ील्ड दिखा सकता है जिसे चलता हुआ इंजन कभी नहीं पढ़ता, या ऐसा फ़ील्ड पढ़ सकता है जिसे संपादक नहीं दिखाता। दोनों स्थितियाँ बाहर से क्लाइंट की खराबी जैसी दिखती हैं। कोई भी प्रोफ़ाइल संपादित करने से ठीक नहीं होती।
जो पहुँचा उसे गिनें, जो सेट किया गया उसे नहीं। ip route show dev tun0 आदेश स्थापित रूट की सूची दिखाता है, और उस संख्या की भेजी गई सूची से तुलना करने पर हटाया गया रूट उस रूट से अलग हो जाता है जो कभी भेजा ही नहीं गया। भेजे जाने से मेल खाती संख्या संदेह को सर्वर की ओर लौटा देती है।
बड़ी संख्या थोपने के लिए इंजन बाइनरी के चारों ओर शेल आवरण अपग्रेड को धुँधला करता है और वापसी को अनुमान बना देता है। यह आगे कॉन्फ़िगरेशन पढ़ने वाले हर व्यक्ति से असली सीमा भी छिपा देता है।
सर्वर तय करता है कि आपको क्या पेश किया गया
प्रति क्लाइंट नीति प्रसारण से पहले सूची को छोटा कर सकती है। क्लाइंट-विशिष्ट फ़ाइल एक पहचान के लिए रूट जोड़ सकती है, या समूह नीति उन्हें छोड़ सकती है, और क्लाइंट फ़िल्टर किए गए रूट को कभी परिभाषित न किए गए रूट से अलग नहीं कर सकता। यही अस्पष्टता सर्वर रिकॉर्ड को महत्वपूर्ण बनाती है। उस पहचान के लिए प्रभावी भेजने की सूची माँगें, टेम्पलेट नहीं।
सर्वर रिकॉर्ड की प्राप्त सूची से तुलना करें। उनके बीच का अंतर नीति परत है, और यह आमतौर पर प्रोफ़ाइल के संकेत से छोटा होता है।
जब डिज़ाइन अनुमति दे, तो सटे हुए नेटवर्कों को संक्षेपित करें और अप्रचलित प्रविष्टियाँ हटाएँ। कम पर बड़े रूट ऊँची छत से अधिक मामले सुलझाते हैं।
संख्या सही जगह बदलें
उसी घटक की प्रलेखित सेटिंग का उपयोग करें जो वास्तव में सीमा का मालिक है। अगर प्लगइन में फ़ील्ड नहीं है, तो जाँचें कि प्लगइन सुविधा से पुराना है या कोई अन्य पृष्ठभूमि रूट की मालिक है। फिर आपके चुने मान के पास इंजन, प्लगइन और सर्वर के संस्करण दर्ज करें। अगला अपग्रेड प्रश्न को फिर खोलता है, और नोट ही उसे उत्तर देने योग्य बनाता है।
तीनों में से किसी के भी किसी अपग्रेड के बाद फिर परखें। सही जगह बढ़ाई गई सीमा फिर भी खिसकती है जब उसे लागू करने वाला घटक बदलता है। संस्करण रिकॉर्ड ही एकमात्र चीज़ है जो उस खिसकन को पूर्वानुमेय बनाती है।