OpenVPN क्लाइंट को दूसरे होस्ट पर Pi-hole रिज़ॉल्वर की ओर भेजें

OpenVPN प्रोफ़ाइल में Pi-hole का पता डालना उस तक कोई रास्ता नहीं बनाता, उससे पूछने की अनुमति नहीं देता और यह गारंटी नहीं देता कि क्लाइंट उसका उपयोग करेगा। जब Pi-hole किसी अलग LAN मशीन पर हो, चार चीज़ें एक साथ मिलनी चाहिए: क्लाइंट से रास्ता, गेटवे से फ़ॉरवर्डिंग, पूल तक वापसी पथ और स्वयं Pi-hole पर स्वीकृति नीति। हर विफलता लॉग में अलग दिखती है। इन्हें इसी क्रम में निपटाना आख़िरी को पहले ठीक करने से तेज़ है। आम शॉर्टकट, हर स्रोत के लिए रिकर्शन खोलना, एक छोटी समस्या को स्थायी समस्या से बदल देता है।

धकेली गई DNS विकल्प क्या करती है और क्या नहीं

सर्वर नीचे दिए निर्देश के साथ एक रिज़ॉल्वर का विज्ञापन करता है, यह मानते हुए कि 192.168.50.53 Pi-hole होस्ट है। क्लाइंट विकल्प प्राप्त करता है और, अपने प्लेटफ़ॉर्म और रिज़ॉल्वर एकीकरण के अनुसार , उसे टनल इंटरफ़ेस पर लागू करता है या स्थानीय स्टब के पक्ष में नज़रअंदाज़ कर देता है। रूट पंक्ति DNS पंक्ति जितनी ही मायने रखती है, क्योंकि जिस रिज़ॉल्वर तक क्लाइंट नहीं पहुँच सकता वह कोई रिज़ॉल्वर ही नहीं है। इसमें से कुछ भी सर्वर की ओर से दिखाई नहीं देता।

server 10.90.0.0 255.255.255.0
push "dhcp-option DNS 192.168.50.53"
push "route 192.168.50.0 255.255.255.0"

विकल्प प्राप्त करना उसका उपयोग करने के बराबर नहीं है। रिज़ॉल्वर प्रबंधक वाला Linux क्लाइंट धकेले गए सर्वर को स्वीकार कर सकता है और उसे केवल कुछ डोमेन भेज सकता है; जो क्लाइंट स्वयं DNS संभालता है वह सेटिंग को पूरी तरह बदल सकता है। धकेले गए रूट कुछ प्लेटफ़ॉर्म पर प्रतिबंधित भी होते हैं, जिससे रिज़ॉल्वर अगम्य रह जाता है भले ही विकल्प स्वीकार हो गया हो। क्लाइंट पर देखें कौन सा सर्वर जवाब देता है, सर्वर पर नहीं कि क्या भेजा गया।

विकल्प सर्वर पक्ष के बारे में भी कुछ नहीं कहती। DNS ट्रैफ़िक को अब भी क्लाइंट से गेटवे तक और गेटवे से Pi-hole तक जाना होता है, इससे पहले कि कोई विकल्प मायने रखे। गुम रास्ता और अस्वीकृत क्वेरी क्लाइंट की ओर से एक जैसे दिखते हैं, इसलिए पहले गेटवे पर फ़ॉरवर्डिंग की पुष्टि करें।

Pi-hole से पूल तक वापसी पथ

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

LAN राउटर को पूल के लिए स्थिर रूट दें जिसमें OpenVPN गेटवे अगला हॉप हो, या Pi-hole की ओर फ़ॉरवर्ड करने से पहले गेटवे पर स्रोत का अनुवाद करें। पहला हर क्लाइंट के पते Pi-hole के क्वेरी लॉग में दिखाई देते रखता है। दूसरा वापसी रूट की शर्त हटाता है मगर हर क्वेरी को गेटवे से आया हुआ दिखाता है। कोई भी ग़लत नहीं है; वे अलग सवालों के जवाब देते हैं।

अगर प्रति-क्लाइंट रिपोर्टिंग या नीति मायने रखती है, तो स्थिर रूट बेहतर सौदा है। अगर LAN किसी और के पास है और कोई रूट उपलब्ध नहीं है, तो अनुवाद व्यावहारिक विकल्प है, क्लाइंट की पहचान के नुकसान के साथ। लिखें कि आपने कौन सा चुना, क्योंकि हर बाद का लॉग सवाल उसी पर निर्भर है।

रूट किए गए क्लाइंट के लिए Pi-hole का सुनने का मोड

DNS के अंतर्गत सेटिंग्स पृष्ठ पर इंटरफ़ेस सुनने के व्यवहार का ड्रॉपडाउन तय करता है कि Pi-hole किन स्रोतों को जवाब देता है। सबसे सख़्त विकल्प केवल सीधे जुड़े नेटवर्क के क्लाइंट स्वीकार करता है; जो विकल्प उपकरणों को अधिकतम एक हॉप दूर तक अनुमति देता है वह इसे निकटवर्ती राउटर के पीछे के सबनेट तक बढ़ाता है, और रूट किया गया VPN क्लाइंट बिल्कुल ऐसा ही दिखता है। पैकेट वाकई LAN इंटरफ़ेस पर पहुँचता है, मगर उसका स्रोत पता किसी दूसरे सबनेट का है। यह नीति की अस्वीकृति है न कि रूटिंग की विफलता, और लॉग पढ़ते समय यह अंतर मायने रखता है।

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

पहली क्वेरी के काम करने के लिए सभी मूलों के लिए रिकर्शन खोलना ग़लत मरम्मत है। यह निजी रिज़ॉल्वर को खुला बना देता है, और सुधार सीमित अनुमति है न कि वैश्विक।

जवाब को क्वेरी लॉग से मिलाएँ

क्लाइंट से पूछें, फिर सर्वर जाँचें और दोनों की तुलना करें। systemd-resolved क्लाइंट पर नीचे दिए कमांड बताते हैं कि किस रिज़ॉल्वर ने जवाब बनाया और प्रति लिंक कौन से सर्वर कॉन्फ़िगर हैं। ऐसा नाम इस्तेमाल करें जो केवल Pi-hole जानता हो, क्योंकि Pi-hole के पते पर सीधी क्वेरी पहुँच साबित करती है, कॉन्फ़िगरेशन नहीं।

resolvectl query intranet.example.lan
resolvectl dns

अपेक्षित जवाब 192.168.50.53 को सर्वर के रूप में नाम देता है और ऐसा पता लौटाता है जो केवल वही रिज़ॉल्वर जानता होगा। फिर Pi-hole का अपना दृश्य देखें: pihole -t क्वेरी लॉग को सीधे फ़ॉलो करता है, और हर पंक्ति स्रोत पता रखती है। अगर स्रोत क्लाइंट का टनल पता है तो पूल का रूट सही है। अगर यह गेटवे का LAN पता है तो स्रोत अनुवाद चल रहा है और क्लाइंट का अपना पता कभी नहीं दिखेगा।

अगर लॉग में कुछ भी नहीं दिखता, तो क्वेरी कभी Pi-hole तक नहीं पहुँची और अगली जाँच गेटवे पर फ़ॉरवर्डिंग है। अगर क्वेरी दिखती है और कोई जवाब वापस नहीं आता, तो समस्या वापसी पथ है, यानी पिछला खंड। विफलता को इस तरह बाँटना रूटिंग गलती को फ़ायरवॉल नियम समझे जाने से रोकता है।

गेटवे का फ़ॉरवर्डिंग नियम जाँचें

गेटवे को क्लाइंट के DNS पैकेट Pi-hole की ओर फ़ॉरवर्ड करने होते हैं, और जो नियम यह करता है उसे मानने के बजाय पढ़ना चाहिए। नीचे दिए कमांड पोर्ट 53 को छूने वाले नियम काउंटरों के साथ सूचीबद्ध करते हैं, nftables होस्ट और iptables होस्ट पर। मौजूद नियम जो शून्य मिलान दिखाए, यह संकेत है कि ट्रैफ़िक अनुवाद से पहले गिरा दिया जा रहा है।

sudo nft list ruleset | grep -A3 'dport 53'
sudo iptables -t nat -L POSTROUTING -n -v | grep 53

काउंटर पढ़ें, केवल नियम नहीं। जो नियम कभी नहीं मिलता उसका अर्थ है कि पैकेट किसी दूसरे इंटरफ़ेस से निकलता है, या क्लाइंट ने उसे कभी भेजा ही नहीं। जो नियम हर क्वेरी पर मिलता है उसका अर्थ है कि फ़ॉरवर्डिंग काम कर रही है और समस्या रास्ते में आगे है।

होस्ट जो भी उपकरण इस्तेमाल करे, जाँच संकरी रखें: पूल स्रोत के रूप में, पोर्ट 53 गंतव्य के रूप में और Pi-hole एकमात्र अनुमत लक्ष्य के रूप में। चौड़ा फ़ॉरवर्डिंग नियम जो पोर्ट 80 की भी अनुमति दे, एक और समस्या है जो होने का इंतज़ार कर रही है।