एका 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 कार्डला पुढे हात लावणाऱ्या व्यक्तीला चारही लागतील।