Pi-hole en VPN op één Pi: wordt het besturingssysteem nog ondersteund?

Op een gecombineerde Pi-hole- en VPN-doos lopen twee dingen door elkaar: de distributiefamilie die u hebt geïnstalleerd en de release plus architectuur die de componenten werkelijk ondersteunen. Een bord dat een image start, bewijst dat de kernel draait; het bewijst niet dat Pi-holes FTL-binary en uw VPN-installer dezelfde gebruikersruimte targeten. De echte test is een vierzijdige overlap van bordondersteuning, releasebranch, pakketarchitectuur en een upgradepad dat u zelf kunt besturen. Verlies één van die vier poten en het apparaat werkt deze week, om u daarna bij de volgende beveiligingsupdate te laten vallen.

De releasebranch bepaalt de ondersteuning, niet de familienaam

Vraag tegen welke release het project nog test, en schrijf het antwoord op als een versiestring in plaats van als Debian. De prerequisites-pagina van Pi-hole noemt ondersteunde besturingssystemen en voorgebouwde FTL-architecturen als twee afzonderlijke eisen, beperkt de ondersteuning tot releases die de distributie zelf nog onderhoudt en waarschuwt dat varianten of ongebruikelijke configuraties zelfs binnen de ondersteunde lijst kunnen mislukken. Die formulering is belangrijk: een ondersteunde familie dekt niet elk lid ervan.

Een oud image dat nog op uw Pi start, is geen bewijs van ondersteuning. Het bord is in orde, de pakketindex is verouderd, en de mismatch komt later boven, wanneer een installer een afhankelijkheid ophaalt die de release niet meer kan vervullen.

De VPN-kant heeft meer onderdelen, elk met zijn eigen venster: de tunneldaemon, de installatiehelper die zijn configuratie schrijft, de clientapp van de provider en het integratiepakket van de distributie zijn vier afzonderlijke projecten. Een installer die uw distributie herkent en een installer die een dienst oplevert die de release draaiende kan houden, zijn twee verschillende beweringen. Zoek de eigen platformlijst van de daemon op en daarna of de helper die u wilt draaien sinds die release is aangeraakt. Waar een project alleen ondersteuning tot een genoemde release opgeeft, behandelt u de volgende als ongetest tot u die zelf hebt gestart.

Laat het binaire doel passen bij de gebruikersruimte die u hebt

Architectuur is de stillere fout. Een 64-bits kernel met een 32-bits gebruikersland is een echte, ondersteunde combinatie op meerdere borden, en het draait een 32-bits FTL-binary zonder klagen, tot het moment dat u iets installeert dat alleen voor arm64 wordt gepubliceerd. Druk beide helften af voordat u een image kiest, en houd de uitvoer bij uw notities.

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

Als die twee architectuurregels niet overeenkomen, zit u op een gemengde opstelling: werkbaar voor Pi-hole alleen, broos zodra een tweede dienst native bibliotheken wil. Een schoon 64-bits image opnieuw flashen is meestal sneller dan de toolchain herbouwen die de mismatch heeft veroorzaakt.

Bordmarketing beslist dit ook niet. Geheugengrootte en CPU-model zeggen niets over de libc waartegen uw pakketten linken, dus beslis op basis van de afgedrukte waarden, nooit op basis van de productpagina.

Eén doos, twee diensten, één eigenaar van het netwerk

Bepaal wie adressering, resolver en tunnel bezit voordat het eerste pakket erop gaat, want anders claimen twee diensten dezelfde taak en wint geen van beide schoon. Geef de Pi een statisch adres buiten de DHCP-pool die uw router uitgeeft, en houd de tunnel op zijn eigen subnet: 192.168.50.10 voor de Pi en 10.42.0.0/24 voor de tunnel is een werkbare splitsing, en de getallen zelf zijn willekeurig zolang ze niet botsen met wat uw router al bedient. Noteer dan welke component op poort 53 antwoordt, welke DHCP uitdeelt als u dat gebruikt, en welke de standaardroute bezit terwijl de tunnel omhoog staat. Op een headless image hoort die laatste taak bij NetworkManager of systemd-networkd, en een providerclient installeren die ook de resolverconfiguratie herschrijft is hoe mensen eindigen met een levende tunnel en dode DNS.

De doos delen is prima. Een rol delen niet. Pi-hole wil de enige luisteraar op poort 53 zijn, en de VPN-daemon wil zijn eigen DNS-instelling naar clients duwen, dus kies wie van de twee de clients moeten vertrouwen en configureer de ander om uit de weg te blijven.

Houd het beheerpad buiten de tunnel waar u kunt. Als de resolver en de tunnel samen falen, wilt u SSH nog steeds bereikbaar hebben op het LAN-adres, en dat betekent dat de beheerdienst van geen van beide mag afhangen.

Maak de volgende upgrade onderdeel van de keuze

Een release die u niet kunt upgraden is een ondersteuningsplafond dat u al hebt geaccepteerd. Test de upgrademachinerie op een reservekaart voordat het apparaat de DNS van uw huishouden draagt, en lees wat de projecten zeggen over tussen branches springen in plaats van aan te nemen dat een pakketupgrade genoeg is.

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

Vastgehouden pakketten zijn de gebruikelijke reden dat een upgrade geslaagd lijkt en niets verandert. Maak de holds bewust één voor één los, en noteer welke dienst de pin nodig had.

Exporteer voor de sprong de Pi-hole-configuratie, de statische leases en eventuele tunnelprofielen, en bevestig dat u ze op een vers image kunt terugzetten. Test na de sprong gewone client-DNS, de privé-resource achter de tunnel, een herverbinding en elke doorstuurregel op de gateway. Een doos die start en op ping antwoordt, is bijna niets gepasseerd.

Wanneer geen enkele release bij beide diensten past

Soms is de overlap leeg: de VPN-helper is naar een nieuwere release gegaan dan het Pi-hole-pakket dat u kunt installeren, of het leveranciersimage van het bord loopt achter op beide. Scheid in dat geval de rollen in plaats van releasemetadata te bewerken om een installer tevreden te stellen. Twee kleine apparaten, of één apparaat plus een container voor de tweede dienst, kosten minder dan een apparaat waarvan het ondersteuningsverhaal op een leugen rust.

De versie vervalsen is de enige snelkoppeling die u botweg moet weigeren. Pakketbeheerders geloven wat het releasebestand zegt, dus een vervalste identificatie geeft u een installatie die geen van beide projecten zal helpen debuggen.

Als twee huidige releases alles vervullen, kies dan degene waarvan u de upgradenotities zonder gokken kunt volgen, en stop met zoeken. Leg daarna de versie, de architectuur, de diensteigenaren en de herstelstap op één plek vast, want de volgende persoon die de SD-kaart aanraakt heeft alle vier nodig.