Pi-hole dhe VPN në një Pi: a mbështetet ende sistemi operativ?

Në një kuti të kombinuar Pi-hole dhe VPN përzihen dy gjëra: familja e shpërndarjes që keni instaluar dhe versioni plus arkitektura që komponentët mbështesin në të vërtetë. Tabela që nis një imazh provon se kerneli punon; nuk provon se binari FTL i Pi-hole dhe instaluesi juaj i VPN-së synojnë të njëjtën hapësirë përdoruesi. Prova e vërtetë është një mbivendosje katërpalëshe: mbështetja e tabelës, dega e versionit, arkitektura e paketave dhe një rrugë përditësimi që mund ta drejtoni vetë. Humbni cilëndo nga këto katër këmbë dhe pajisja punon këtë javë, për t'ju lënë në baltë në përditësimin e sigurisë që vjen.

Dega e versionit përcakton mbështetjen, jo emri i familjes

Pyetni kundër cilit version teston ende projekti, pastaj shkruajeni përgjigjen si varg versioni, jo si Debian. Faqja e parakushteve e Pi-hole rendit sistemet operative të mbështetura dhe arkitekturat FTL të parandërtuara si dy kërkesa të ndara, e kufizon mbështetjen në versionet që shpërndarja vetë ende mirëmban, dhe paralajmëron se variantet ose konfigurimet e pazakonta mund të dështojnë edhe brenda listës së mbështetur. Ky formulim ka rëndësi: një familje e mbështetur nuk mbulon çdo anëtar të saj.

Një imazh i vjetër që ende niset në Pi-n tuaj nuk është provë mbështetjeje. Tabela është në rregull, indeksi i paketave është i vjetëruar, dhe mospërputhja shfaqet më vonë, kur instaluesi tërheq një varësi që versioni nuk mund ta plotësojë më.

Ana e VPN-së ka më shumë pjesë, secila me dritaren e vet: demoni i tunelit, ndihmësi i instalimit që shkruan konfigurimin e tij, aplikacioni klient i ofruesit dhe paketa e integrimit e shpërndarjes janë katër projekte të ndara. Një instalues që njeh shpërndarjen tuaj dhe një instalues që prodhon një shërbim që versioni mund ta mbajë në punë janë dy pohime të ndryshme. Shikoni listën e platformave të vetë demonit, pastaj shikoni nëse ndihmësi që synoni të ekzekutoni është prekur që kur doli ai version. Kur një projekt deklaron mbështetje vetëm deri në një version të emërtuar, trajtojeni atë pasardhës si të patestuar derisa ta nisni vetë.

Përputhni objektivin binar me hapësirën e përdoruesit që keni

Arkitektura është dështimi më i qetë. Një kernel 64-bitësh me një tokë përdoruesi 32-bitëshe është një kombinim real dhe i mbështetur në disa tabela, dhe ekzekuton një binare FTL 32-bitëshe pa ankesa, deri në momentin kur instaloni diçka që publikohet vetëm për arm64. Printoni të dyja gjysmat përpara se të zgjidhni një imazh, dhe mbajini rezultatet pranë shënimeve tuaja.

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

Nëse ato dy rreshta arkitekture nuk përputhen, jeni në një konfigurim të përzier: i zbatueshëm për Pi-hole vetëm, i brishtë sapo një shërbim i dytë do biblioteka amtare. Rikthimi në një imazh të pastër 64-bitësh është zakonisht më i shpejtë sesa rindërtimi i zinxhirit të mjeteve që krijoi mospërputhjen.

Marketingu i tabelës nuk e zgjidh këtë gjithashtu. Madhësia e memories dhe modeli i CPU-së nuk thonë asgjë për libc-në me të cilën lidhen paketat tuaja, prandaj vendosni sipas vlerave të printuara, kurrë sipas faqes së produktit.

Një kuti, dy shërbime, një pronar i rrjetit

Vendosni kush zotëron adresimin, zgjidhësin dhe tunelin përpara se të ngarkohet paketa e parë, përndryshe dy shërbime do të kërkojnë të njëjtën detyrë dhe asnjëri nuk do të fitojë pastër. Jepini Pi-së një adresë statike jashtë grupit DHCP që shpërndan ruteri juaj, dhe mbajeni tunelin në nënrrjetin e tij: 192.168.50.10 për Pi-në dhe 10.42.0.0/24 për tunelin është një ndarje e zbatueshme, dhe vetë numrat janë arbitrarë për sa kohë nuk përplasen me atë që ruteri juaj tashmë shërben. Pastaj shkruani cili komponent përgjigjet në portën 53, cili shpërndan DHCP nëse e përdorni, dhe cili zotëron rrugën e parazgjedhur sa kohë tuneli është lart. Në një imazh pa ekran, ajo detyrë e fundit i takon NetworkManager ose systemd-networkd, dhe instalimi i një klienti ofruesi që rishkruan edhe konfigurimin e zgjidhësit është rruga me të cilën njerëzit përfundojnë me një tunel të gjallë dhe DNS të vdekur.

Ndarja e kutisë është në rregull. Ndarja e një roli nuk është. Pi-hole dëshiron të jetë dëgjuesi i vetëm në portën 53, dhe demoni i VPN-së dëshiron të shtyjë cilësimin e vet të DNS-së tek klientët, prandaj zgjidhni se cilit prej të dyve duhet t'u besojnë klientët dhe konfiguroni tjetrin të qëndrojë larg rrugës.

Mbani rrugën e administrimit jashtë tunelit kur mundeni. Nëse zgjidhësi dhe tuneli dështojnë së bashku, ju ende dëshironi që SSH të jetë i arritshëm në adresën LAN, dhe kjo do të thotë që shërbimi i menaxhimit nuk duhet të varet nga asnjëri prej tyre.

Bëni përditësimin e radhës pjesë të zgjedhjes

Një version që nuk mund ta përditësoni është një tavan mbështetjeje që e keni pranuar tashmë. Testoni mekanikën e përditësimit në një kartë rezervë përpara se pajisja të mbajë DNS-në e shtëpisë tuaj, dhe lexoni çfarë thonë projektet për kalimin mes degëve në vend që të supozoni se një përditësim pakete mjafton.

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

Paketat e mbajtura janë arsyeja e zakonshme pse një përditësim duket i suksesshëm dhe nuk ndryshon asgjë. Lironi mbajtjet me qëllim, një nga një, dhe shënoni cili shërbim kishte nevojë për fiksimin.

Përpara kërcimit eksportoni konfigurimin e Pi-hole, qiratë statike dhe çdo profil tuneli, dhe konfirmoni se mund t'i riktheni në një imazh të ri. Pas kërcimit testoni DNS-në e zakonshme të klientëve, burimin privat pas tunelit, rilidhjen dhe çdo rregull përcjelljeje në portë. Një kuti që niset dhe i përgjigjet ping-ut nuk ka kaluar pothuajse asgjë.

Kur asnjë version i vetëm nuk u përshtatet të dy shërbimeve

Ndonjëherë mbivendosja është bosh: ndihmësi i VPN-së ka kaluar në një version më të ri se paketa Pi-hole që mund të instaloni, ose imazhi i prodhuesit të tabelës mbetet pas të dyjave. Në atë rast ndani rolet në vend që të modifikoni metadata e versionit për të kënaqur një instalues. Dy pajisje të vogla, ose një pajisje plus një kontejner për shërbimin e dytë, kushtojnë më pak se një pajisje historia e mbështetjes së së cilës mbështetet në një gënjeshtër.

Falsifikimi i versionit është e vetmja shkurtore që duhet refuzuar sheshazi. Menaxherët e paketave besojnë atë që thotë skedari i versionit, kështu që një identifikues i falsifikuar ju jep një instalim që asnjëri prej dy projekteve nuk do t'ju ndihmojë ta korrigjoni.

Nëse dy versione aktuale plotësojnë gjithçka, zgjidhni atë shënimet e përditësimit të së cilës mund t'i ndiqni pa hamendësuar, dhe ndaloni së kërkuari. Pastaj regjistroni versionin, arkitekturën, pronarët e shërbimeve dhe hapin e rikthimit në një vend, sepse personi i radhës që prek kartën SD do t'i ketë të nevojshme të katërta.