Pi-hole i VPN en un sol Pi: encara té suport el sistema operatiu?

En una caixa combinada de Pi-hole i VPN es barregen dues coses: la família de distribució que heu instal·lat i la versió més l’arquitectura que els components realment suporten. Una placa que arrenca una imatge demostra que el nucli funciona; no demostra que el binari FTL de Pi-hole i el vostre instal·lador de VPN apuntin al mateix espai d’usuari. La prova real és una superposició quàdruple de suport de placa, branca de versió, arquitectura de paquets i un camí d’actualització que pugueu conduir vosaltres mateixos. Perdeu qualsevol d’aquestes quatre potes i l’aparell funciona aquesta setmana, però us deixa tirada a la propera actualització de seguretat.

La branca de versió fixa el suport, no el nom de la família

Pregunteu contra quina versió encara prova el projecte i escriviu la resposta com una cadena de versió, no com a Debian. La pàgina de requisits previs de Pi-hole llista els sistemes operatius suportats i les arquitectures FTL precompilades com dos requisits separats, limita el suport a les versions que la mateixa distribució encara manté i avisa que les variants o configuracions inusuals poden fallar fins i tot dins de la llista suportada. Aquesta formulació importa: una família suportada no cobreix tots els seus membres.

Una imatge antiga que encara arrenca al vostre Pi no és prova de suport. La placa va bé, l’índex de paquets és obsolet, i la discrepància surt més tard, quan un instal·lador estira una dependència que la versió ja no pot satisfer.

El costat VPN té més peces, cadascuna amb la seva finestra: el dimoni del túnel, l’ajudant d’instal·lació que escriu la seva configuració, l’aplicació client del proveïdor i el paquet d’integració de la distribució són quatre projectes separats. Un instal·lador que reconeix la vostra distribució i un instal·lador que produeix un servei que la versió pot mantenir en marxa són afirmacions diferents. Consulteu la llista de plataformes pròpia del dimoni i, després, si l’ajudant que voleu executar s’ha tocat des que es va publicar aquella versió. Quan un projecte declara suport només fins a una versió concreta, tracteu la següent com no provada fins que l’hàgiu arrencat vosaltres.

Feu coincidir l’objectiu binari amb l’espai d’usuari que teniu

L’arquitectura és la fallada més silenciosa. Un nucli de 64 bits amb un espai d’usuari de 32 bits és una combinació real i suportada en diverses plaques, i executa un binari FTL de 32 bits sense queixar-se, fins al moment que instal·leu una cosa publicada només per a arm64. Imprimiu les dues meitats abans de triar una imatge i guardeu la sortida al costat de les vostres notes.

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

Si aquestes dues línies d’arquitectura no coincideixen, esteu en un muntatge mixt: viable per a Pi-hole sol, fràgil quan un segon servei vol biblioteques natives. Reflassar una imatge neta de 64 bits sol ser més ràpid que reconstruir la cadena d’eines que va produir la discrepància.

El màrqueting de la placa tampoc no ho resol. La mida de la memòria i el model de CPU no diuen res sobre contra quina libc enllacen els vostres paquets, així que decidiu per als valors impresos, mai per la pàgina del producte.

Una caixa, dos serveis, un propietari de la xarxa

Decidiu qui posseeix l’adreçament, el resolutor i el túnel abans que el primer paquet hi entri, perquè si no dos serveis acabaran reclamant el mateix deure i cap no guanyarà net. Doneu al Pi una adreça estàtica fora del pool DHCP que reparteix el vostre router, i manteniu el túnel en la seva pròpia subxarxa: 192.168.50.10 per al Pi i 10.42.0.0/24 per al túnel és una divisió viable, i els números mateixos són arbitraris mentre no xoquin amb el que el vostre router ja serveix. Després anoteu quin component respon al port 53, quin reparteix DHCP si l’useu i quin posseeix la ruta per defecte mentre el túnel és aixecat. En una imatge sense entorn gràfic, aquesta última feina pertany a NetworkManager o systemd-networkd, i instal·lar un client de proveïdor que també reescriu la configuració del resolutor és com la gent acaba amb un túnel viu i un DNS mort.

Compartir la caixa està bé. Compartir un rol no. Pi-hole vol ser l’únic oient al port 53, i el dimoni VPN vol empènyer la seva pròpia configuració de DNS als clients, així que trieu en quin dels dos han de confiar els clients i configureu l’altre perquè no hi faci nosa.

Manteniu el camí d’administració fora del túnel sempre que pugueu. Si el resolutor i el túnel fallen alhora, encara voleu SSH accessible a l’adreça LAN, i això vol dir que el servei de gestió no pot dependre de cap dels dos.

Feu de la propera actualització part de l’elecció

Una versió que no podeu actualitzar és un sostre de suport que ja heu acceptat. Proveu la mecànica d’actualització en una targeta de recanvi abans que l’aparell porti el DNS de casa vostra, i llegiu què diuen els projectes sobre saltar entre branques en lloc de suposar que n’hi ha prou amb actualitzar un paquet.

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

Els paquets retinguts són la raó habitual que una actualització sembli reeixida i no canviï res. Allibereu les retencions deliberadament, d’una en una, i anoteu quin servei necessitava la fixació.

Abans del salt, exporteu la configuració de Pi-hole, les concessions estàtiques i qualsevol perfil de túnel, i confirmeu que podeu restaurar-los en una imatge nova. Després del salt, proveu el DNS normal dels clients, el recurs privat darrere del túnel, una reconnexió i qualsevol regla de reenviament a la passarel·la. Una caixa que arrenca i respon a ping gairebé no ha superat res.

Quan cap versió única encaixa amb tots dos serveis

De vegades la superposició és buida: l’ajudant de VPN ha passat a una versió més nova que el paquet de Pi-hole que podeu instal·lar, o la imatge del fabricant de la placa va per darrere de totes dues. En aquest cas separeu els rols en lloc d’editar metadades de versió per satisfer un instal·lador. Dos dispositius petits, o un dispositiu més un contenidor per al segon servei, costen menys que un aparell la història de suport del qual depèn d’una mentida.

Falsificar la versió és l’únic drecera que cal rebutjar de ple. Els gestors de paquets confien en el que diu el fitxer de versió, així que un identificador falsejat us dona una instal·lació que cap dels dos projectes no us ajudarà a depurar.

Si dues versions actuals ho satisfan tot, trieu la que pugueu seguir les notes d’actualització sense endevinar, i deixeu de buscar. Després registreu la versió, l’arquitectura, els responsables dels serveis i el pas de restauració en un sol lloc, perquè la propera persona que toqui la targeta SD necessitarà les quatre coses.