Pi-hole og VPN på én Pi: støttes operativsystemet fortsatt?

I en kombinert Pi-hole- og VPN-boks blandes to ting: distribusjonsfamilien du installerte, og utgivelsen pluss arkitekturen komponentene faktisk støtter. Et kort som starter et image, beviser at kjernen kjører; det beviser ikke at Pi-holes FTL-binære og VPN-installatøren din sikter mot samme brukerrom. Den virkelige prøven er en firedelt overlapping av kortstøtte, utgivelsesgren, pakkearkitektur og en oppgraderingsvei du selv kan styre. Mister du ett av disse fire beina, virker apparatet denne uken og forlater deg ved neste sikkerhetsoppdatering.

Utgivelsesgrenen bestemmer støtten, ikke familienavnet

Spør hvilken utgivelse prosjektet fortsatt tester mot, og skriv svaret som en versjonsstreng i stedet for Debian. Pi-holes side om forutsetninger lister støttede operativsystemer og forhåndsbygde FTL-arkitekturer som to separate krav, begrenser støtten til utgivelser som distribusjonen selv fortsatt vedlikeholder, og advarer om at varianter eller uvanlige konfigurasjoner kan feile selv innenfor den støttede listen. Den formuleringen betyr noe: en støttet familie dekker ikke hvert av medlemmene sine.

Et gammelt image som fortsatt starter på Pi-en din, er ikke bevis på støtte. Kortet er i orden, pakkeindeksen er utdatert, og avviket dukker opp senere, når en installatør trekker inn en avhengighet utgivelsen ikke lenger kan oppfylle.

VPN-siden har flere deler, hver med sitt eget vindu: tunneldaemonen, installasjonshjelperen som skriver konfigurasjonen, leverandørens klientapp og distribusjonens integrasjonspakke er fire separate prosjekter. En installatør som gjenkjenner distribusjonen din, og en installatør som lager en tjeneste utgivelsen kan holde kjørende, er to forskjellige påstander. Slå opp daemonens egen plattformliste, og slå deretter opp om hjelperen du vil kjøre er blitt rørt siden den utgivelsen kom. Der et prosjekt bare oppgir støtte til og med en navngitt utgivelse, skal du behandle den neste som uutprøvd til du selv har startet den.

Tilpass det binære målet til brukerrommet du har

Arkitektur er den stillere feilen. En 64-biters kjerne med et 32-biters brukerland er en reell, støttet kombinasjon på flere kort, og den kjører en 32-biters FTL-binær uten klager, helt til du installerer noe som bare publiseres for arm64. Skriv ut begge halvdelene før du velger et image, og hold utdataene ved notatene dine.

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

Hvis de to arkitekturlinjene ikke stemmer, er du på et blandet oppsett: brukbart for Pi-hole alene, skjørt så snart en annen tjeneste vil ha opprinnelige biblioteker. Å flashe et rent 64-biters image på nytt er vanligvis raskere enn å bygge verktøykjeden som skapte avviket på nytt.

Kortmarkedsføring avgjør heller ikke dette. Minnestørrelse og CPU-modell sier ingenting om hvilken libc pakkene dine lenker mot, så bestem ut fra de trykte verdiene, aldri ut fra produktsiden.

Én boks, to tjenester, én eier av nettverket

Bestem hvem som eier adressering, resolver og tunnel før den første pakken settes inn, ellers vil to tjenester kreve den samme plikten, og ingen vinner rent. Gi Pi-en en statisk adresse utenfor DHCP-bassenget ruteren din deler ut, og hold tunnelen på sitt eget subnett: 192.168.50.10 for Pi-en og 10.42.0.0/24 for tunnelen er en brukbar deling, og tallene selv er vilkårlige så lenge de ikke kolliderer med det ruteren din allerede betjener. Skriv deretter ned hvilken komponent som svarer på port 53, hvilken som deler ut DHCP hvis du bruker det, og hvilken som eier standardruten mens tunnelen er oppe. På et hodeløst image tilhører den siste jobben NetworkManager eller systemd-networkd, og å installere en leverandørklient som også skriver om resolverkonfigurasjonen er hvordan folk ender med en levende tunnel og død DNS.

Å dele boksen er greit. Å dele en rolle er det ikke. Pi-hole vil være den eneste lytteren på port 53, og VPN-daemonen vil skyve sin egen DNS-innstilling ut til klientene, så velg hvem av de to klientene skal stole på, og konfigurer den andre til å holde seg unna.

Hold administrasjonsveien utenfor tunnelen der du kan. Hvis resolveren og tunnelen feiler sammen, vil du fortsatt kunne nå SSH på LAN-adressen, og det betyr at administrasjonstjenesten ikke kan avhenge av noen av dem.

Gjør den neste oppgraderingen til en del av valget

En utgivelse du ikke kan oppgradere, er et støttetak du allerede har akseptert. Test oppgraderingsmekanikken på et reservekort før apparatet bærer DNS-en til husstanden din, og les hva prosjektene sier om å hoppe mellom grener i stedet for å anta at en pakkeoppgradering er nok.

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

Tilbakeholdte pakker er den vanlige grunnen til at en oppgradering ser vellykket ut og ikke endrer noe. Fjern tilbakeholdene med vilje, én om gangen, og noter hvilken tjeneste som trengte festingen.

Før hoppet eksporterer du Pi-hole-konfigurasjonen, de statiske leasene og alle tunnelprofiler, og bekrefter at du kan gjenopprette dem på et ferskt image. Etter hoppet tester du vanlig klient-DNS, den private ressursen bak tunnelen, en gjenoppkobling og enhver videresendingsregel på gatewayen. En boks som starter og svarer på ping, har bestått nesten ingenting.

Når ingen enkelt utgivelse passer til begge tjenestene

Noen ganger er overlappingen tom: VPN-hjelperen har flyttet til en nyere utgivelse enn Pi-hole-pakken du kan installere, eller leverandørimaget til kortet ligger bak begge. I så fall skiller du rollene i stedet for å redigere utgivelsesmetadata for å tilfredsstille en installatør. To små enheter, eller én enhet pluss en container for den andre tjenesten, koster mindre enn et apparat hvis støttehistorie hviler på en løgn.

Å forfalske versjonen er den eneste snarveien du bør avvise blankt. Pakkebehandlere tror på det utgivelsesfilen sier, så en forfalsket identifikator gir deg en installasjon som ingen av de to prosjektene vil hjelpe deg å feilsøke.

Hvis to gjeldende utgivelser oppfyller alt, velg den hvis oppgraderingsnotater du kan følge uten å gjette, og slutt å lete. Skriv deretter ned versjonen, arkitekturen, tjenesteeierne og gjenopprettingstrinnet på ett sted, for den neste personen som tar på SD-kortet trenger alle fire.