OpenVPN रूट मेट्रिक: चुना गया रूट फिर भी क्यों हारता है

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

पहले प्रोफ़ाइल, फिर इंस्टॉल की गई तालिका, फिर चयन के नियम देखें। यह क्रम उस तरीके से मेल खाता है जिससे क्लाइंट रूट बनाता है और आपको ऐसा मान ट्यून करने से रोकता है जो कभी तुलना में नहीं आता।

रूट लाइन को फ़ील्ड के क्रम में पढ़ें

OpenVPN 2.6 समुदाय का क्लाइंट IPv4 route लाइन पर चार फ़ील्ड स्वीकार करता है: नेटवर्क, नेटमास्क, गेटवे और एक वैकल्पिक मेट्रिक। गेटवे की जगह वह स्थान है जहाँ विशेष vpn_gateway कीवर्ड जाता है। इसका अर्थ इस कनेक्शन के लिए VPN पक्ष का अगला हॉप है, कोई राउटिंग तालिका संख्या नहीं और आपका भौतिक राउटर भी नहीं। इसे छोड़ दें तो लाइन का बाकी हिस्सा यह गलत धारणा बनाकर पढ़ा जाता है कि यह क्या करता है। नेटवर्क विकल्पों का संदर्भ सभी चार फ़ील्ड का दस्तावेज़ीकरण करता है।

निजी गंतव्य के लिए लाइन ऐसे पढ़ी जा सकती है:

route-metric 50
route 172.20.0.0 255.255.0.0 vpn_gateway 30

स्पष्ट 30 उस रूट पर लागू होता है, और 50 प्रोफ़ाइल के हर उस अन्य रूट के लिए डिफ़ॉल्ट रहता है जो संख्या छोड़ देता है। लाइन को बाएँ से दाएँ पढ़ना ही यह जानने के लिए पर्याप्त है कि कौन-सा मान कहाँ लागू होता है।

route-metric डिफ़ॉल्ट है, रैंक नहीं

route-metric उन रूट के लिए फ़ॉलबैक तय करता है जो अपनी संख्या नहीं रखते। यह किसी रूट को किसी और चीज़ से ऊपर नहीं उठाता, और स्पष्ट मेट्रिक के साथ इंस्टॉल किए गए रूट का क्रम नहीं बदलता।

यह अंतर तब मायने रखता है जब प्रोफ़ाइल दोनों रूप मिलाता है। ऊपर के पास एक अकेली route-metric लाइन आधिकारिक दिखती है और उस पर दोष देना आसान है, जबकि जो रूट वास्तव में ट्रैफ़िक ढोता है वह तीन लाइन नीचे अपनी मेट्रिक रख सकता है।

यदि आप चाहते हैं कि एक रूट किसी पथ को प्राथमिकता दे, तो संख्या उसी रूट पर रखें। यदि आप जनरेट की गई प्रोफ़ाइल में एकसमान डिफ़ॉल्ट चाहते हैं, तो route-metric का उपयोग करें और अलग-अलग लाइनों को छोड़ दें। बिना कारण दोनों को मिलाना ही वह तरीका है जिससे प्रोफ़ाइल ऐसे रूट के साथ खत्म होती है जिसे कोई समझा नहीं सकता।

क्लाइंट ने क्या इंस्टॉल किया यह जाँचें

पुनः कनेक्शन पूरा होने के बाद प्रोफ़ाइल से नहीं, कर्नेल से पूछें।

ip route show क्लाइंट द्वारा जोड़े गए रूट की सूची देता है, और ip route get 172.20.5.10 अधिक उपयोगी प्रश्न का उत्तर देता है: यह गंतव्य वास्तव में कौन-सा रूट उपयोग करेगा, और किस स्रोत पते के साथ। यदि गंतव्य तालिका में नहीं है, तो क्लाइंट ने उसे इंस्टॉल नहीं किया।

कोई स्थानीय निर्देश, सर्वर पुश या कोई अन्य नेटवर्क प्रबंधक उसी प्रीफ़िक्स को जोड़ या हटा सकते हैं, और अंत में लिखने वाला जीतता है। काम करते समय एंडपॉइंट रूट को नज़र में रखें, क्योंकि कनेक्शन को दूरस्थ सर्वर तक ऐसा पथ चाहिए जो उस टनल से न गुज़रे जिसे वह बना रहा है।

छोटी मेट्रिक फिर भी क्यों हारती है

मेट्रिक एक ही गंतव्य के रूट की तुलना करती हैं। वे किसी चौड़े प्रीफ़िक्स को अधिक विशिष्ट नहीं बनातीं। जब redirect-gateway def1 चल रहा होता है, क्लाइंट 0.0.0.0/1 और 128.0.0.0/1 इंस्टॉल करता है, और ये दोनों प्रीफ़िक्स 0.0.0.0/0 की तुलना में पूरे IPv4 स्थान को अधिक विशिष्ट रूप से ढकते हैं। डिफ़ॉल्ट रूट पर 1 की मेट्रिक उनसे आगे नहीं निकलती।

यही तर्क किसी भी अतिव्यापी जोड़ी पर लागू होता है। /24 किसी भीतर के पते के लिए /16 को हरा देता है, चाहे जुड़ी संख्याएँ कोई भी हों, क्योंकि खोज पहले सबसे विशिष्ट मिलान चुनती है और उसके बाद ही समान लोगों के बीच मेट्रिक की तुलना करती है।

यही वह हिस्सा है जो मेट्रिक बग जैसा दिखता है और है नहीं। कोई भी संख्या बदलने से पहले दोनों उम्मीदवारों पर प्रीफ़िक्स की लंबाई जाँचें।

नीति नियम तालिका से पहले चलते हैं

Linux पर ip rule तय करता है कि कौन-सी राउटिंग तालिका देखी जाएगी। नियम प्राथमिकता क्रम में मूल्यांकित होते हैं, इसलिए पहले वाली तालिका मुख्य तालिका के पढ़े जाने से पहले ही रूट लौटा सकती है। main के भीतर की मेट्रिक उस तालिका के मिलान से आगे नहीं निकल सकती जिसे पहले देखा गया।

ip rule show का उपयोग करें और फिर उस विशिष्ट तालिका से पूछें, उदाहरण के लिए ip route show table 100, यह देखने के लिए कि वह नियम क्या लौटाएगा। यदि किसी VPN क्लाइंट या कंटेनर रनटाइम ने कोई नियम जोड़ा है, तो उत्तर आप जो तालिका पढ़ रहे थे उसमें नहीं, वहाँ हो सकता है। स्रोत पता भी मायने रखता है, क्योंकि कोई नियम स्रोत से मेल खाकर उसी गंतव्य को टनल ट्रैफ़िक और LAN ट्रैफ़िक के लिए अलग तरह से हल कर सकता है।

गंतव्य सत्यापित करें, रैंकिंग नहीं

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

IPv6 और DNS को इस जाँच से बाहर रखें। ये अलग निर्देशों से कॉन्फ़िगर होते हैं और अलग तंत्रों से हल होते हैं, और एक काम करता IPv4 रूट इनमें से किसी के बारे में कुछ नहीं कहता। एक बार में एक परत बदलें और क्वेरी दोबारा चलाएँ।