Pi-hole et VPN sur un seul Pi : le système est-il encore pris en charge ?

Sur une machine qui réunit Pi-hole et VPN, deux choses se confondent : la famille de distribution installée et la version, plus l’architecture que les composants prennent réellement en charge. Une carte qui démarre une image prouve que le noyau tourne ; elle ne prouve pas que le binaire FTL de Pi-hole et votre installateur VPN visent le même espace utilisateur. Le vrai test est un recoupement à quatre volets : prise en charge de la carte, branche de version, architecture des paquets et un chemin de mise à niveau que vous pouvez piloter vous-même. Perdez un seul de ces quatre appuis et l’appareil fonctionne cette semaine, puis vous laisse en plan à la prochaine mise à jour de sécurité.

La branche de version fixe la prise en charge, pas le nom de la famille

Demandez contre quelle version le projet teste encore, puis notez la réponse sous forme de chaîne de version plutôt que de Debian. La page des prérequis de Pi-hole liste les systèmes d’exploitation pris en charge et les architectures FTL précompilées comme deux exigences distinctes, limite la prise en charge aux versions que la distribution elle-même maintient encore et avertit que des variantes ou des configurations inhabituelles peuvent échouer même dans la liste prise en charge. Cette formulation compte : une famille prise en charge ne couvre pas chacun de ses membres.

Une vieille image qui démarre encore sur votre Pi n’est pas une preuve de prise en charge. La carte va bien, l’index des paquets est périmé, et l’écart se révèle plus tard, quand un installateur tire une dépendance que la version ne peut plus satisfaire.

Le côté VPN comporte plus de pièces, chacune avec sa propre fenêtre : le démon de tunnel, l’assistant d’installation qui écrit sa configuration, l’application cliente du fournisseur et le paquet d’intégration de la distribution sont quatre projets distincts. Un installateur qui reconnaît votre distribution et un installateur qui produit un service que la version peut maintenir en marche sont deux affirmations différentes. Consultez la liste de plateformes propre au démon, puis vérifiez si l’assistant que vous comptez lancer a été touché depuis la sortie de cette version. Quand un projet ne déclare sa prise en charge que jusqu’à une version nommée, traitez la suivante comme non testée tant que vous ne l’avez pas démarrée vous-même.

Faites correspondre la cible binaire à l’espace utilisateur dont vous disposez

L’architecture est la panne la plus discrète. Un noyau 64 bits avec un espace utilisateur 32 bits est une combinaison réelle et prise en charge sur plusieurs cartes, et elle exécute un binaire FTL 32 bits sans se plaindre, jusqu’au moment où vous installez quelque chose publié uniquement pour arm64. Imprimez les deux moitiés avant de choisir une image, et gardez la sortie à côté de vos notes.

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

Si ces deux lignes d’architecture ne concordent pas, vous êtes sur un montage mixte : praticable pour Pi-hole seul, fragile dès qu’un second service veut des bibliothèques natives. Reflasher une image 64 bits propre est généralement plus rapide que de reconstruire la chaîne d’outils qui a produit l’écart.

Le marketing de la carte ne tranche pas non plus. La taille de mémoire et le modèle de CPU ne disent rien sur la libc contre laquelle vos paquets se lient, alors décidez d’après les valeurs imprimées, jamais d’après la fiche produit.

Une machine, deux services, un seul propriétaire du réseau

Décidez qui possède l’adressage, le résolveur et le tunnel avant que le premier paquet n’arrive, sinon deux services revendiqueront le même devoir et aucun ne l’emportera proprement. Donnez au Pi une adresse statique hors de la plage DHCP que votre routeur distribue, et gardez le tunnel sur son propre sous-réseau : 192.168.50.10 pour le Pi et 10.42.0.0/24 pour le tunnel est un découpage viable, et les nombres eux-mêmes sont arbitraires tant qu’ils n’entrent pas en collision avec ce que votre routeur sert déjà. Notez ensuite quel composant répond sur le port 53, lequel distribue le DHCP si vous l’utilisez, et lequel possède la route par défaut tant que le tunnel est actif. Sur une image sans interface graphique, cette dernière tâche revient à NetworkManager ou systemd-networkd, et installer un client fournisseur qui réécrit aussi la configuration du résolveur est la façon dont les gens finissent avec un tunnel vivant et un DNS mort.

Partager la machine est acceptable. Partager un rôle ne l’est pas. Pi-hole veut être le seul écouteur sur le port 53, et le démon VPN veut pousser son propre réglage DNS aux clients, alors choisissez auquel des deux les clients doivent faire confiance et configurez l’autre pour rester à l’écart.

Gardez le chemin d’administration hors du tunnel quand vous pouvez. Si le résolveur et le tunnel tombent ensemble, vous voulez encore SSH joignable sur l’adresse LAN, et cela signifie que le service de gestion ne doit dépendre ni de l’un ni de l’autre.

Faites de la prochaine mise à niveau une partie du choix

Une version que vous ne pouvez pas mettre à niveau est un plafond de prise en charge que vous avez déjà accepté. Testez la mécanique de mise à niveau sur une carte de rechange avant que l’appareil ne porte le DNS de votre foyer, et lisez ce que les projets disent du saut entre branches au lieu de supposer qu’une mise à niveau de paquet suffit.

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

Les paquets retenus sont la raison habituelle pour laquelle une mise à niveau semble réussir et ne change rien. Levez les retenues délibérément, une par une, et notez quel service avait besoin de l’épinglage.

Avant le saut, exportez la configuration de Pi-hole, les baux statiques et tout profil de tunnel, et confirmez que vous pouvez les restaurer sur une image neuve. Après le saut, testez le DNS ordinaire des clients, la ressource privée derrière le tunnel, une reconnexion et toute règle de redirection sur la passerelle. Une machine qui démarre et répond au ping n’a presque rien validé.

Quand aucune version unique ne convient aux deux services

Parfois le recoupement est vide : l’assistant VPN est passé à une version plus récente que le paquet Pi-hole que vous pouvez installer, ou l’image du fabricant de la carte retarde sur les deux. Dans ce cas, séparez les rôles au lieu de modifier les métadonnées de version pour satisfaire un installateur. Deux petits appareils, ou un appareil plus un conteneur pour le second service, coûtent moins qu’un appareil dont l’histoire de prise en charge repose sur un mensonge.

Falsifier la version est le seul raccourci qu’il faut refuser net. Les gestionnaires de paquets croient ce que dit le fichier de version, donc un identifiant falsifié vous donne une installation qu’aucun des deux projets n’aidera à déboguer.

Si deux versions actuelles satisfont tout, choisissez celle dont vous pouvez suivre les notes de mise à niveau sans deviner, et arrêtez de chercher. Consignez ensuite la version, l’architecture, les propriétaires des services et l’étape de restauration au même endroit, car la prochaine personne à toucher la carte SD aura besoin des quatre.