एउटै 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 कार्ड छुने अर्को व्यक्तिलाई चारै चाहिनेछ।