route-gateway, redirect-gateway नहीं है: वास्तव में क्या बदलता है
यह विकल्प केवल उन रूटों के लिए अगला हॉप देता है जो OpenVPN इंस्टॉल करता है। इसे हटाने से धकेला गया पूरा टनल बंद नहीं होता, और सुधार रीडायरेक्ट में है।
आपका टनल ऊपर आता है, निजी सबनेट जवाब देता है, और कोई प्रोफ़ाइल से गेटवे पंक्ति हटा देने के बावजूद सामान्य ब्राउज़िंग अब भी VPN में गायब हो जाती है। यही संयोजन गलत निर्देश के संपादित होने की उंगली की छाप है। जो हटाया गया वह क्लाइंट को उन रूटों के लिए अगला हॉप देता था जो वह इंस्टॉल करता है; जो ट्रैफ़िक पकड़ना जारी रखे हुए था वह कहीं और से आया और सर्वर ने उसे धकेला। कवरेज और अगला हॉप अलग काम हैं, और इनमें से केवल एक तय करता है कि सार्वजनिक गंतव्य टनल का उपयोग करते हैं या नहीं।
आपने जो पंक्ति हटाई वह अगला हॉप थी, नीति स्विच नहीं
क्लाइंट जो भी रूट इंस्टॉल करता है उसे इंगित करने के लिए गेटवे पता चाहिए, और जब कोई रूट स्वयं कोई पता नहीं बताता तो गेटवे निर्देश उसी पते का स्रोत होता है। उसे हटा दें तो उन रूटों के पास टिकने की जगह नहीं रहती, इसलिए वे या तो इंस्टॉल नहीं होते या ऐसे रास्ते पर उतरते हैं जो कहीं नहीं जाता। निजी सबनेट ठीक वही है जो ऐसा रूट ढोता था।
इस बीच जो व्यवहार बच गया उसका लेखक कोई और है: धकेले गए ब्लॉक में रीडायरेक्ट विकल्प, जो अपने फ़्लैग के अनुसार सामान्य आउटगोइंग ट्रैफ़िक को टनल में ले जाता है। गेटवे हटाने से वह न बंद होता है न कमज़ोर। नतीजा दोनों स्थितियों में सबसे बुरा है, सार्वजनिक ट्रैफ़िक अब भी पकड़ा जाता है और जिस निजी गंतव्य ने टनल को उचित ठहराया था वह अब अगम्य है। इसीलिए उसी भावना से किया गया दूसरा संपादन भी कुछ नहीं बदलता।
चार लीवर, चार अलग काम
इस चर्चा में चार निर्देशों को एक-दूसरे के बदले उद्धृत किया जाता है, और उनमें से केवल एक कवरेज नियंत्रित करता है, यानी कौन से गंतव्य टनल से गुज़रते हैं। दूसरा वह अगला हॉप तय करता है जो रूट उपयोग करते हैं, तीसरा एक ही प्रीफ़िक्स इंस्टॉल करता है, और चौथा सर्वर द्वारा धकेला गया सब कुछ फेंक देता है, जिसमें तैनाती को ज़रूरी निजी रूट भी शामिल हैं। तालिका उन्हें नाम के बजाय इस आधार पर क्रम में रखती है कि व्यवस्थापक क्या बदलना चाहता है, क्योंकि भ्रम नामों से ही पैदा होता है। इन्हें चार अलग निर्णय मानिए और वह चुनिए जिसे आप वास्तव में पलटना चाहते हैं।
व्यवहार में चारों अक्सर एक ही धकेले गए ब्लॉक में, पंक्ति दर पंक्ति आते हैं, जिससे वे एक ही सेटिंग के हिस्से लगते हैं। वे नहीं हैं, और OpenVPN संदर्भ ठीक इसी कारण उन्हें अलग तंत्र के रूप में दर्ज करता है। यह पता लगाना कि आप कौन सा निर्णय पलट रहे हैं, काम है; संपादन एक पंक्ति है।
| What you are trying to change | Directive that decides it | What it leaves alone |
|---|---|---|
| Which destinations use the tunnel | redirect-gateway | Per-prefix routes and resolver choice |
| The next hop a pushed route points at | route-gateway | Coverage of public destinations |
| One reachable prefix | route | Every other destination, default path included |
| All pushed routing and DNS at once | route-nopull | Nothing, which is the problem |
धकेली गई पंक्ति को फ़िल्टर करें, अगला हॉप रखें
यदि आप जिस कवरेज पर आपत्ति करते हैं वह धकेले गए विकल्प के रूप में आता है, तो संकीर्ण प्रतिक्रिया उस विकल्प को नाम से अनदेखा करना और धकेले गए ब्लॉक के बाकी हिस्से को अछूता छोड़ना है। फ़िल्टर के रूप में लिखा गया यह नीचे की पंक्ति जैसा दिखता है, और इसका स्थान प्रभावित क्लाइंट की प्रोफ़ाइल में है, सर्वर कॉन्फ़िगरेशन में नहीं।
pull-filter ignore "redirect-gateway"संकीर्णता ही मुद्दा है। चूँकि फ़िल्टर टेक्स्ट प्रीफ़िक्स की तुलना करता है, छोटा पैटर्न अगले-हॉप निर्देश से भी मेल खाता है, जो ठीक वही जानकारी छीन लेता है जिस पर निजी रूट निर्भर हैं और मूल गलती को नए रूप में दोहराता है। फ़िल्टर केवल धकेले गए विकल्पों पर ही काम करता है, इसलिए वह स्थानीय रूप से लिखी या नेटवर्क प्रबंधक द्वारा थोपी गई समतुल्य पंक्ति को कभी नहीं छूता। इसके बाद फिर से कनेक्ट करें, क्योंकि जीवंत सत्र सर्वर द्वारा धकेले गए को दोबारा नहीं आँकता।
तालिका नहीं, खोज पढ़ें
प्रोफ़ाइल फिर से लोड करने के बाद कर्नेल से पूछें कि दो गंतव्य वास्तव में कहाँ जाएँगे: एक निजी प्रीफ़िक्स के भीतर और एक सार्वजनिक इंटरनेट पर। मुख्य तालिका का पूरा डंप पढ़ना कठिन और गलत पढ़ना आसान है, क्योंकि कोई रूट मौजूद हो सकता है और फिर भी अधिक विशिष्ट मिलान से हार सकता है। नीति-आधारित रूटिंग में नियम, तालिका और स्रोत पता भी जाँच का हिस्सा हैं।
ip route get 10.40.7.25
ip route get 203.0.113.77
ip rule showdef1 प्रकार को जानना ज़रूरी है, क्योंकि यह पुरानी डिफ़ॉल्ट प्रविष्टि को दृश्यमान छोड़ता है जबकि आधा-डिफ़ॉल्ट की एक जोड़ी खोज जीत लेती है। इसलिए आउटपुट में 0.0.0.0/0 पंक्ति अपने आप कुछ साबित नहीं करती। खोज उस प्रश्न का उत्तर देती है जिसका उत्तर सूची केवल देती दिखती है।
DNS, IPv6 और निजी रूट को अब भी काम करना है
एक IPv4 रीडायरेक्ट अस्वीकार करना रिज़ॉल्वर के बारे में कुछ नहीं कहता, इसलिए धकेला गया DNS विकल्प रूटों के सही दिखने के दौरान भी प्रश्न टनल में भेजना जारी रख सकता है। IPv6 डिफ़ॉल्ट उस पता परिवार के लिए वही कर सकता है जिसे IPv4 जाँच ने कभी छुआ ही नहीं। दोनों को अनुमान के बजाय स्पष्ट निर्णय चाहिए। फिर पुष्टि करें कि निजी सेवा अब भी जवाब देती है, क्योंकि निजी रूट खो चुका स्प्लिट टनल स्प्लिट टनल नहीं है, वह टूटा हुआ है।
एक व्यापक उपकरण चेतावनी का हक़दार है: route-nopull हर धकेले गए रूट और हर धकेले गए DNS विकल्प को फेंक देता है, जो निश्चित रूप से पूरा टनल रोकता है और उतना ही निश्चित रूप से उन निजी रूटों को तोड़ता है जिन पर तैनाती निर्भर है, इसलिए यह एक विकल्प पर निशाना साधने वाले नाम-फ़िल्टर से बहुत बड़ा हथौड़ा है। किसी भी बदलाव के बाद निजी गंतव्य, सार्वजनिक गंतव्य और रिज़ॉल्वर जाँचें, और पूरी हुई हैंडशेक को हैंडशेक के अलावा किसी और चीज़ का सबूत न मानें।