Pi-hole og VPN på én Pi: understøttes styresystemet stadig?

To ting blandes sammen på en kombineret Pi-hole- og VPN-boks: den distributionsfamilie, du installerede, og den udgivelse plus arkitektur, som komponenterne faktisk understøtter. Et board, der booter et image, beviser, at kernen kører; det beviser ikke, at Pi-holes FTL-binære og din VPN-installatør sigter mod samme brugerrum. Den egentlige prøve er et firedobbelt overlap af boardunderstøttelse, udgivelsesgren, pakkearkitektur og en opgraderingsvej, du selv kan styre. Mister du bare ét af de ben, virker apparatet i denne uge og strander dig ved næste sikkerhedsopdatering.

Udgivelsesgrenen fastlægger understøttelsen, ikke familienavnet

Spørg, hvilken udgivelse projektet stadig tester imod, og skriv svaret ned som en versionsstreng i stedet for Debian. Pi-holes side om forudsætninger lister understøttede styresystemer og forudbyggede FTL-arkitekturer som to separate krav, begrænser understøttelsen til udgivelser, som distributionen selv stadig vedligeholder, og advarer om, at varianter eller usædvanlige konfigurationer kan fejle selv inden for den understøttede liste. Den formulering betyder noget: en understøttet familie dækker ikke hvert af dens medlemmer.

Et gammelt image, der stadig booter på din Pi, er ikke bevis på understøttelse. Boardet er fint, pakkeindekset er forældet, og uoverensstemmelsen viser sig senere, når en installatør trækker en afhængighed, som udgivelsen ikke længere kan opfylde.

VPN-siden har flere dele, hver med sit eget vindue: tunnel-daemonen, installationshjælperen der skriver dens konfiguration, udbyderens klientapp og distributionens integrationspakke er fire separate projekter. En installatør, der genkender din distribution, og en installatør, der producerer en tjeneste, som udgivelsen kan holde kørende, er forskellige påstande. Slå daemonens egen platformliste op, og slå derefter op, om den hjælper, du vil køre, er blevet rørt, siden den udgivelse kom. Hvor et projekt kun erklærer understøttelse op til en navngivet udgivelse, skal du behandle den næste som uafprøvet, indtil du selv har bootet den.

Match det binære mål til det brugerrum, du har

Arkitektur er den mere stille fejl. En 64-bit kerne med et 32-bit brugerland er en reel, understøttet kombination på flere boards, og den kører en 32-bit FTL-binær uden klager, lige indtil det øjeblik du installerer noget, der kun udgives til arm64. Udskriv begge halvdele, før du vælger et image, og læg outputtet ved dine noter.

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

Hvis de to arkitekturlinjer ikke stemmer overens, er du på et blandet setup: brugbart for Pi-hole alene, skrøbeligt når en anden tjeneste vil have native biblioteker. At flashe et rent 64-bit image igen er normalt hurtigere end at genopbygge den værktøjskæde, der skabte uoverensstemmelsen.

Boardmarkedsføring afgør det heller ikke. Hukommelsesstørrelse og CPU-model siger intet om, hvilken libc dine pakker linkes mod, så beslut ud fra de udskrevne værdier, aldrig ud fra produktsiden.

Én boks, to tjenester, én ejer af netværket

Beslut, hvem der ejer adressering, resolver og tunnel, før den første pakke kommer på, for ellers ender to tjenester med at gøre krav på samme pligt, og ingen vinder rent. Giv Pi'en en statisk adresse uden for den DHCP-pulje, din router uddeler, og hold tunnelen på sit eget subnet: 192.168.50.10 til Pi'en og 10.42.0.0/24 til tunnelen er en brugbar opdeling, og tallene selv er vilkårlige, så længe de ikke kolliderer med det, din router allerede betjener. Skriv derefter ned, hvilken komponent der svarer på port 53, hvilken der uddeler DHCP, hvis du bruger det, og hvilken der ejer standardruten, mens tunnelen er oppe. På et headless image tilhører det sidste job NetworkManager eller systemd-networkd, og at installere en udbyderklient, der også omskriver resolverkonfigurationen er, hvordan folk ender med en levende tunnel og død DNS.

At dele boksen er fint. At dele en rolle er det ikke. Pi-hole vil være den eneste lytter på port 53, og VPN-daemonen vil skubbe sin egen DNS-indstilling ud til klienterne, så vælg, hvem af de to klienterne skal stole på, og konfigurer den anden til at holde sig væk.

Hold administrationsvejen uden om tunnelen, hvor du kan. Hvis resolversen og tunnelen fejler sammen, vil du stadig have SSH tilgængeligt på LAN-adressen, og det betyder, at styringstjenesten ikke må afhænge af nogen af dem.

Gør den næste opgradering til en del af valget

En udgivelse, du ikke kan opgradere, er et understøttelsesloft, du allerede har accepteret. Test opgraderingsmekanikken på et ekstra kort, før apparatet bærer din husstands DNS, og læs, hvad projekterne siger om at springe mellem grene, i stedet for at antage, at en pakkeopgradering er nok.

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

Tilbageholdte pakker er den sædvanlige grund til, at en opgradering ser vellykket ud og ikke ændrer noget. Fjern tilbageholdelserne med vilje, én ad gangen, og noter, hvilken tjeneste der havde brug for pinningen.

Før springet skal du eksportere Pi-hole-konfigurationen, de statiske leases og eventuelle tunnelprofiler og bekræfte, at du kan gendanne dem på et friskt image. Efter springet skal du teste almindelig klient-DNS, den private ressource bag tunnelen, en genopkobling og enhver videresendelsesregel på gatewayen. En boks, der booter og svarer på ping, har bestået næsten intet.

Når ingen enkelt udgivelse passer til begge tjenester

Nogle gange er overlapningen tom: VPN-hjælperen er flyttet til en nyere udgivelse end den Pi-hole-pakke, du kan installere, eller boardets leverandørimage sakker bagud efter begge. I så fald skal du adskille rollerne i stedet for at redigere udgivelsesmetadata for at gøre en installatør tilfreds. To små enheder, eller én enhed plus en container til den anden tjeneste, koster mindre end et apparat, hvis understøttelseshistorie hviler på en løgn.

At forfalske versionen er den ene genvej, du bør afvise blankt. Pakkehåndteringer stoler på, hvad udgivelsesfilen siger, så en forfalsket identifikator giver dig en installation, som ingen af de to projekter vil hjælpe dig med at fejlfinde.

Hvis to aktuelle udgivelser opfylder alt, så vælg den, hvis opgraderingsnoter du kan følge uden at gætte, og hold op med at shoppe. Skriv derefter versionen, arkitekturen, tjenesteejerne og gendannelsestrinet ned ét sted, for den næste person, der rører SD-kortet, får brug for alle fire.