एक ही Pi पर Pi-hole और VPN: क्या ऑपरेटिंग सिस्टम अभी भी समर्थित है?

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

समर्थन रिलीज़ शाखा तय करती है, परिवार का नाम नहीं

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

आपके Pi पर अभी भी बूट होने वाली पुरानी इमेज समर्थन का प्रमाण नहीं है। बोर्ड ठीक है, पैकेज सूचकांक पुराना है, और असंगति बाद में सामने आती है, जब इंस्टॉलर ऐसी निर्भरता खींचता है जिसे रिलीज़ अब पूरा नहीं कर सकती।

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

बाइनरी लक्ष्य को अपने उपयोगकर्ता-स्थान से मिलाएँ

आर्किटेक्चर अधिक शांत विफलता है। 32-बिट उपयोगकर्ता-भूमि के साथ 64-बिट कर्नेल कई बोर्डों पर वास्तविक, समर्थित संयोजन है, और यह 32-बिट FTL बाइनरी को बिना शिकायत चलाता है, ठीक उस क्षण तक जब आप केवल arm64 के लिए प्रकाशित कुछ इंस्टॉल करते हैं। इमेज चुनने से पहले दोनों आधे छापें, और आउटपुट को अपने नोट्स के पास रखें।

uname -m
dpkg --print-architecture
grep -E '^(PRETTY_NAME|VERSION_ID)=' /etc/os-release
apt-cache policy pihole-ftl

अगर वे दो आर्किटेक्चर पंक्तियाँ मेल नहीं खातीं, तो आप मिश्रित सेटअप पर हैं: अकेले Pi-hole के लिए चलने योग्य, दूसरी सेवा देशी लाइब्रेरी माँगे तो नाज़ुक। साफ़ 64-बिट इमेज पर फिर से फ़्लैश करना आम तौर पर उस टूलचेन को फिर से बनाने से तेज़ है जिसने असंगति पैदा की।

बोर्ड की मार्केटिंग भी इसे तय नहीं करती। मेमोरी का आकार और CPU मॉडल इस बारे में कुछ नहीं कहते कि आपके पैकेज किस libc से लिंक होते हैं, इसलिए छपे मानों से तय करें, कभी उत्पाद पृष्ठ से नहीं।

एक बॉक्स, दो सेवाएँ, नेटवर्क का एक मालिक

पहला पैकेज चढ़ने से पहले तय करें कि पता-निर्धारण, रिज़ॉल्वर और टनल किसके हैं, वरना दो सेवाएँ एक ही कर्तव्य का दावा करेंगी और कोई साफ़ नहीं जीतेगी। Pi को अपने राउटर द्वारा दिए जाने वाले DHCP पूल के बाहर स्थिर पता दें, और टनल को उसके अपने सबनेट पर रखें: Pi के लिए 192.168.50.10 और टनल के लिए 10.42.0.0/24 एक चलने योग्य विभाजन है, और संख्याएँ स्वयं मनमानी हैं जब तक वे उससे टकराएँ नहीं जो आपका राउटर पहले से सेवा देता है। फिर लिखें कि कौन-सा कंपोनेंट पोर्ट 53 पर उत्तर देता है, कौन DHCP बाँटता है अगर आप उसका उपयोग करते हैं, और टनल चालू रहने पर किसके पास डिफ़ॉल्ट रूट है। हेडलेस इमेज पर वह अंतिम काम NetworkManager या systemd-networkd का है, और ऐसा प्रदाता क्लाइंट इंस्टॉल करना जो रिज़ॉल्वर कॉन्फ़िगरेशन भी फिर से लिखता है वह रास्ता है जिससे लोग जीवित टनल और मृत DNS के साथ फँसते हैं।

बॉक्स साझा करना ठीक है। भूमिका साझा करना नहीं। Pi-hole पोर्ट 53 पर एकमात्र श्रोता बनना चाहता है, और VPN डेमॉन अपनी DNS सेटिंग क्लाइंट्स तक धकेलना चाहता है, इसलिए चुनें कि क्लाइंट्स दोनों में से किस पर भरोसा करें और दूसरे को रास्ते से हटकर रहने के लिए कॉन्फ़िगर करें।

जहाँ हो सके प्रशासन मार्ग को टनल से बाहर रखें। अगर रिज़ॉल्वर और टनल साथ-साथ विफल हों, तो भी आप LAN पते पर SSH पहुँचने योग्य चाहेंगे, और इसका मतलब है कि प्रबंधन सेवा दोनों में से किसी पर निर्भर न हो।

अगले अपग्रेड को चुनाव का हिस्सा बनाएँ

जिस रिलीज़ को आप अपग्रेड नहीं कर सकते, वह समर्थन की वह सीमा है जिसे आप पहले ही स्वीकार कर चुके हैं। उपकरण आपके घर का DNS उठाने से पहले अतिरिक्त कार्ड पर अपग्रेड की प्रक्रिया जाँचें, और यह मानने के बजाय कि पैकेज अपग्रेड पर्याप्त है, शाखाओं के बीच कूदने के बारे में प्रोजेक्ट क्या कहते हैं पढ़ें।

sudo apt update
apt-mark showhold
sudo apt full-upgrade
pihole -up

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

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

जब कोई एक रिलीज़ दोनों सेवाओं से मेल न खाए

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

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

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