OpenVPN का pull-filter आपके इरादे के रूट से ज़्यादा से मेल खाता है
pull-filter आपके टेक्स्ट को उपसर्ग की तरह भेजे गए विकल्पों से तुलना करता है, इसलिए route route-gateway और route-ipv6 को भी पकड़ लेता है। पहले क्रियाएँ देखें, फिर रूट।
आप अपना स्थानीय डिफ़ॉल्ट रूट बनाए रखने के लिए एक पंक्ति जोड़ते हैं, और उसके बाद टनल अब आंतरिक DNS सर्वर तक नहीं पहुँचती। वह पंक्ति pull-filter ignore "route" थी, जिसका अर्थ "इस रूट को अनदेखा करो" नहीं है। इसका अर्थ है "ऐसा हर भेजा गया विकल्प छोड़ दो जिसका टेक्स्ट उन पाँच अक्षरों से शुरू होता है", और सामान्य सर्वर पर इसमें रूट के साथ-साथ route-gateway, route-metric और route-ipv6 भी शामिल होते हैं। नीचे दी गई जाँच-सूची वही है जो मैं किसी और के इस्तेमाल वाली प्रोफ़ाइल को छूने से पहले चलाता हूँ।
फ़िल्टर केवल भेजे गए विकल्पों पर लागू होता है
pull-filter केवल उन विकल्प-पंक्तियों पर काम करता है जो सर्वर टनल स्थापित होने के बाद भेजता है, और किसी और चीज़ पर नहीं। आपकी स्थानीय फ़ाइल में लिखे विकल्प इससे प्रभावित नहीं होते, और एप्लिकेशन ट्रैफ़िक भी नहीं। अगर आप किसी प्रक्रिया को टनल इस्तेमाल करने से रोकने की आशा रखते थे, तो यह पूरी तरह गलत औज़ार है और फ़िल्टरों का कोई संयोजन यह नहीं करेगा।
यह दायरा उपयोगी है, क्योंकि इसका अर्थ है कि आप सर्वर के कॉन्फ़िगरेशन को अछूता छोड़ सकते हैं और फिर भी उसका एक हिस्सा स्थानीय रूप से अस्वीकार कर सकते हैं। यह एक सीमा भी है जिसे टिकट में लिखना चाहिए: फ़िल्टर बदलता है कि यह क्लाइंट क्या स्वीकार करता है, न कि सर्वर क्या पेश करता है। इसका उसी प्रोफ़ाइल के दूसरे उपयोगकर्ताओं पर कोई असर नहीं होता। यह किसी ऐसे क्लाइंट पर जाने पर भी नहीं टिकता जो इस विकल्प को लागू नहीं करता, जो इस पर कोई कार्यप्रवाह बनाने से पहले जानना चाहिए।
पैटर्न लिखने से पहले पुष्टि करें कि सर्वर वास्तव में क्या भेजता है। उच्च वर्बोसिटी पर क्लाइंट प्राप्त भेजी गई विकल्प-श्रृंखला छापता है, और यही उस सटीक टेक्स्ट का एकमात्र ईमानदार स्रोत है जिससे आप तुलना करते हैं:
sudo openvpn --config /etc/openvpn/corp.ovpn --verb 4
sudo grep -n 'pull-filter' /etc/openvpn/corp.ovpnभेजी गई पंक्ति को अल्पविराम से अलग विकल्पों की सूची की तरह पढ़ें, और ध्यान दें कि विकल्पों के नाम और उनके आर्ग्युमेंट स्पेस से अलग होते हैं। आपका फ़िल्टर टेक्स्ट उसी प्रवाह से तुलना किया जाता है, इसलिए अगले चरण में स्पेस इतने मायने रखते हैं।
मिलान एक उपसर्ग है, इसलिए स्पेस ही पूरा खेल हैं
तुलना स्ट्रिंग उपसर्ग है, पार्स किया गया विकल्प नाम नहीं। इसलिए "route" route-gateway 10.8.0.1, route-ipv6 2001:db8::/32 और route-metric 100 से मेल खाता है। अंत में एक स्पेस जोड़ने से यह उस परिवार तक सिकुड़ जाता है जिसका आपने संभवतः इरादा किया, और पूरा उपसर्ग इसे और सिकोड़कर किसी विशिष्ट गंतव्य तक ले आता है।
| Filter text | What it actually matches | Typical outcome |
|---|---|---|
"route" | Every option beginning with those letters | Routes, gateway, metric and IPv6 routes all dropped |
"route " | Route entries only, not the hyphenated siblings | The routes go, the rest survives |
"route 10.60." | A single destination range | The narrowest rule, and the easiest to audit |
"dhcp-option DNS" | Pushed DNS settings | Resolver stays local, internal names stop resolving |
आखिरी पंक्ति वही है जो स्प्लिट-टनल काम के दौरान लोगों को पकड़ती है। अपना खुद का रिज़ॉल्वर रखना वैध विकल्प है, और इसका अर्थ है कि अब हर आंतरिक नाम ऐसे रिज़ॉल्वर पर निर्भर है जो निजी ज़ोन नहीं देख सकता। यह जानबूझकर स्वीकार किया जाने वाला परिणाम है, उत्पादन में खोजा जाने वाला दुष्प्रभाव नहीं।
उपसर्ग मिलान का अर्थ यह भी है कि कोई नियम बाद में चुपचाप विस्तृत हो सकता है। जब सर्वर कोई नया विकल्प जोड़ता है जो आपके टेक्स्ट से शुरू होता है, तो आपका फ़िल्टर बिना किसी के प्रोफ़ाइल संपादित किए उस पर लागू होने लगता है। यही वह विफलता-विधा है जिसके विरुद्ध डिज़ाइन करना चाहिए, और उपाय है विकल्प का जितना हो सके उतना बड़ा हिस्सा मिलाना, जितना कम हो सके उतना नहीं।
तीन क्रियाएँ, तीन अलग परिणाम
accept, ignore और reject एक ही विचार की तीन वर्तनियाँ नहीं हैं। वे इस बात में भिन्न हैं कि क्लाइंट मिलान पर क्या करता है और किसी को इसका पता चलता है या नहीं।
ignore मेल खाते विकल्प को चुपचाप छोड़ देता है, जो आपने जानबूझकर बदली गई सेटिंग के लिए चाहिए। reject उसे छोड़ देता है और क्लाइंट को शिकायत करने देता है, जो तब चाहिए जब उसकी अनुपस्थिति बाद में खोजे जाने के बजाय लॉग में दिखनी चाहिए। accept सकारात्मक रूप है, तब इस्तेमाल होता है जब आप अलग-अलग विकल्प हटाने के बजाय अनुमति-सूची बनाते हैं।
आप कोई भी क्रिया इस्तेमाल करें, फ़िल्टर उसी क्रम में लागू होते हैं जिसमें वे दिखते हैं, इसलिए दो अतिव्यापी नियम क्रम-निर्भर परिणाम देते हैं जिसकी समीक्षा करना बहुत कठिन है। प्रति उद्देश्य एक नियम रखें और हर एक में सबसे विशिष्ट टेक्स्ट रखें। अगर अनुमति-सूची चाहिए, तो ignore नियमों के ढेर के बजाय, जो वही जोड़ते हैं, कुछ accept नियमों को प्राथमिकता दें। तब समीक्षक फ़ाइल को ऊपर से नीचे पढ़कर परिणाम का अनुमान लगा सकते हैं, और यही एकमात्र परीक्षण है जो स्केल करता है।
लागू हुए रूट और रिज़ॉल्वर जाँचें, प्रोफ़ाइल नहीं
फ़ाइल में सही दिखने वाला फ़िल्टर फिर भी आपको ऐसी टनल के साथ छोड़ सकता है जो कुछ भी उपयोगी रूट नहीं करती। चालू सिस्टम पर प्रभाव सत्यापित करें, जहाँ भेजे गए विकल्प पहले ही लागू या छोड़े जा चुके हैं:
ip route show default
ip route show | grep -c 'proto static'
resolvectl status | grep -A4 'Link.*tun0'
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://intranet.example.internal/पहली दो पंक्तियाँ आपको बताती हैं कि भेजा गया डिफ़ॉल्ट रूट आया या नहीं और कितनी स्थिर प्रविष्टियाँ बचीं। रिज़ॉल्वर क्वेरी दिखाती है कि टनल इंटरफ़ेस वास्तव में कौन-सा सर्वर इस्तेमाल कर रहा है, और आम तौर पर वहीं DNS का आश्चर्य सामने आता है। आखिरी पंक्ति उस एकमात्र सवाल का जवाब देती है जो उपयोगकर्ता के लिए मायने रखता है।
जब वहाँ हों तो दोनों दिशाएँ जाँचें। ऐसा नियम जो आपका स्थानीय इंटरनेट चालू रखता है पर आंतरिक नाम-समाधान चुपचाप तोड़ देता है, सतही जाँच पास कर लेता है और पहले असली काम में विफल होता है, इसलिए एक ही परीक्षण में एक आंतरिक संसाधन और एक सार्वजनिक साइट शामिल करें।
अपवाद और उसका मालिक दर्ज करें
फ़िल्टर ऑपरेटर के डिज़ाइन का अपवाद है, इसलिए इसे कारण और समीक्षा-बिंदु के साथ लिखें। "स्थानीय डिफ़ॉल्ट रखने के लिए भेजे गए रूट अनदेखा करता है" समीक्षा-योग्य है; प्रोफ़ाइल में नंगी पंक्ति नहीं, और अगला व्यक्ति उसे मिटा देगा या अनुमान से बढ़ा देगा।
संस्करण यहाँ भी मायने रखता है। मिलान का व्यवहार और सटीक स्वीकृत सिंटैक्स OpenVPN 2.4, 2.5 और 2.6 में परिष्कृत हुए हैं, इसलिए पैटर्न को उस बिल्ड के मैनुअल से पुष्टि करें जो आप भेजते हैं, न कि पुराने संस्करण के फ़ोरम पोस्ट से। OpenVPN 2.6 मैनुअल इस विकल्प और उसके मिलान नियम का दस्तावेज़ीकरण करता है।
अंत में, जो सर्वर चलाता है उसके साथ अपवाद पर सहमति बनाएँ। जानबूझकर बनाई सर्वर नीति का विरोध करने वाला क्लाइंट-पक्षीय फ़िल्टर अगली ऑडिट का इंतज़ार करती सपोर्ट घटना है, और प्रोफ़ाइल भेजे जाने से पहले इसे सुलझाना बहुत सस्ता है, बजाय इसके कि कोई रूट गायब होने पर ध्यान दे।