Pi-hole och VPN på en enda Pi: stöds operativsystemet fortfarande?

I en kombinerad Pi-hole- och VPN-box blandas två saker: distributionsfamiljen du installerade och utgåvan plus arkitekturen som komponenterna faktiskt stöder. Ett kort som startar en image bevisar att kärnan körs; det bevisar inte att Pi-holes FTL-binär och din VPN-installatör siktar på samma användarrymd. Det verkliga provet är en fyrfaldig överlappning av kortstöd, utgivningsgren, paketarkitektur och en uppgraderingsväg du själv kan styra. Tappar du något av dessa fyra ben fungerar apparaten den här veckan och lämnar dig sedan i sticket vid nästa säkerhetsuppdatering.

Utgivningsgrenen avgör stödet, inte familjenamnet

Fråga vilken utgåva projektet fortfarande testar mot och skriv sedan ned svaret som en versionssträng i stället för Debian. Pi-holes sida om förutsättningar listar stödda operativsystem och förbyggda FTL-arkitekturer som två separata krav, begränsar stödet till utgåvor som distributionen själv fortfarande underhåller och varnar för att varianter eller ovanliga konfigurationer kan misslyckas även inom den stödda listan. Den formuleringen spelar roll: en stödd familj täcker inte varje medlem i den.

En gammal image som fortfarande startar på din Pi är inte bevis på stöd. Kortet är okej, paketindexet är inaktuellt, och avvikelsen dyker upp senare, när en installatör drar in ett beroende som utgåvan inte längre kan uppfylla.

VPN-sidan har fler delar, var och en med sitt eget fönster: tunneldemonen, installationshjälparen som skriver dess konfiguration, leverantörens klientapp och distributionens integrationspaket är fyra separata projekt. En installatör som känner igen din distribution och en installatör som producerar en tjänst som utgåvan kan hålla igång är två olika påståenden. Slå upp demonens egen plattformslista och sedan om hjälparen du tänker köra har rörts sedan den utgåvan kom. Där ett projekt bara anger stöd till och med en namngiven utgåva ska du behandla nästa som otestad tills du själv har startat den.

Anpassa det binära målet till användarrymden du har

Arkitektur är det tystare felet. En 64-bitars kärna med ett 32-bitars användarland är en verklig, stödd kombination på flera kort, och den kör en 32-bitars FTL-binär utan klagomål, ända till det ögonblick du installerar något som bara publiceras för arm64. Skriv ut båda halvorna innan du väljer en image, och håll utdata vid dina anteckningar.

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

Om de två arkitekturraderna inte stämmer är du på en blandad uppsättning: fungerande för Pi-hole ensamt, skört så snart en andra tjänst vill ha inhemska bibliotek. Att flasha om till en ren 64-bitars image går oftast snabbare än att bygga om verktygskedjan som skapade avvikelsen.

Kortmarknadsföring avgör inte heller detta. Minnesstorlek och CPU-modell säger ingenting om vilken libc dina paket länkar mot, så besluta utifrån de utskrivna värdena, aldrig utifrån produktsidan.

En box, två tjänster, en ägare av nätverket

Bestäm vem som äger adressering, resolver och tunnel innan det första paketet läggs in, annars gör två tjänster anspråk på samma plikt och ingen vinner rent. Ge Pi:n en statisk adress utanför DHCP-poolen som din router delar ut, och håll tunneln i sitt eget subnät: 192.168.50.10 för Pi:n och 10.42.0.0/24 för tunneln är en fungerande uppdelning, och själva siffrorna är godtyckliga så länge de inte krockar med det din router redan betjänar. Skriv sedan ned vilken komponent som svarar på port 53, vilken som delar ut DHCP om du använder det, och vilken som äger standardrutten medan tunneln är uppe. På en image utan skärm tillhör det sista jobbet NetworkManager eller systemd-networkd, och att installera en leverantörsklient som också skriver om resolverkonfigurationen är hur folk hamnar med en levande tunnel och död DNS.

Att dela boxen är okej. Att dela en roll är det inte. Pi-hole vill vara den enda lyssnaren på port 53, och VPN-demonen vill skjuta ut sin egen DNS-inställning till klienterna, så välj vem av de två klienterna ska lita på och konfigurera den andra att hålla sig undan.

Håll administrationsvägen utanför tunneln där du kan. Om resolvern och tunneln fallerar tillsammans vill du fortfarande nå SSH på LAN-adressen, och det betyder att hanteringstjänsten inte får bero på någon av dem.

Gör nästa uppgradering till en del av valet

En utgåva du inte kan uppgradera är ett stödstak du redan har accepterat. Testa uppgraderingsmekaniken på ett reservkort innan apparaten bär din hushålls DNS, och läs vad projekten säger om att hoppa mellan grenar i stället för att anta att en paketuppgradering räcker.

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

Tillbakahållna paket är den vanliga orsaken till att en uppgradering ser lyckad ut och inte ändrar något. Släpp hållningarna medvetet, en åt gången, och notera vilken tjänst som behövde fästningen.

Före hoppet exporterar du Pi-holes konfiguration, de statiska leasingarna och alla tunnelprofiler, och bekräftar att du kan återställa dem på en färsk image. Efter hoppet testar du vanlig klient-DNS, den privata resursen bakom tunneln, en återanslutning och varje vidarebefordringsregel på gatewayen. En box som startar och svarar på ping har klarat nästan ingenting.

När ingen enskild utgåva passar båda tjänsterna

Ibland är överlappningen tom: VPN-hjälparen har flyttat till en nyare utgåva än Pi-hole-paketet du kan installera, eller kortets leverantörsimage ligger efter båda. Skilj då på rollerna i stället för att redigera utgivningsmetadata för att tillfredsställa en installatör. Två små enheter, eller en enhet plus en container för den andra tjänsten, kostar mindre än en apparat vars stödhistoria vilar på en lögn.

Att förfalska versionen är den enda genväg du bör avvisa blankt. Pakethanterare tror på vad utgivningsfilen säger, så en förfalskad identifierare ger dig en installation som ingen av de två projekten hjälper dig felsöka.

Om två aktuella utgåvor uppfyller allt, välj den vars uppgraderingsanteckningar du kan följa utan att gissa, och sluta leta. Skriv sedan ned versionen, arkitekturen, tjänsteägarna och återställningssteget på ett ställe, för nästa person som rör SD-kortet behöver alla fyra.