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 लाई पनि अनुमति दिन्छ, त्यो अर्को समस्या हो जो हुन बाटो हेरिरहेको छ।