Pi-hole e VPN su un solo Pi: il sistema operativo è ancora supportato?

Su una macchina che combina Pi-hole e VPN si confondono due cose: la famiglia di distribuzione installata e la release più l’architettura che i componenti supportano davvero. Una scheda che avvia un’immagine dimostra che il kernel gira; non dimostra che il binario FTL di Pi-hole e il vostro installer VPN puntino allo stesso spazio utente. La prova vera è una sovrapposizione quadrupla tra supporto della scheda, ramo di release, architettura dei pacchetti e un percorso di aggiornamento che potete gestire da soli. Perdete uno solo di questi quattro appoggi e l’apparecchio funziona questa settimana, per poi lasciarvi a piedi al prossimo aggiornamento di sicurezza.

Il ramo di release stabilisce il supporto, non il nome della famiglia

Chiedete contro quale release il progetto testa ancora, poi scrivete la risposta come stringa di versione anziché come Debian. La pagina dei prerequisiti di Pi-hole elenca i sistemi operativi supportati e le architetture FTL precompilate come due requisiti separati, limita il supporto alle release che la distribuzione stessa mantiene ancora e avverte che varianti o configurazioni insolite possono fallire anche dentro l’elenco supportato. Quella formulazione conta: una famiglia supportata non copre ogni suo membro.

Un’immagine vecchia che si avvia ancora sul vostro Pi non è prova di supporto. La scheda va bene, l’indice dei pacchetti è obsoleto, e la discordanza emerge più tardi, quando un installer tira una dipendenza che la release non può più soddisfare.

Il lato VPN ha più pezzi, ognuno con la propria finestra: il demone del tunnel, l’helper di installazione che ne scrive la configurazione, l’app client del fornitore e il pacchetto di integrazione della distribuzione sono quattro progetti separati. Un installer che riconosce la vostra distribuzione e un installer che produce un servizio che la release può tenere in funzione sono affermazioni diverse. Cercate l’elenco delle piattaforme del demone stesso, poi verificate se l’helper che intendete eseguire è stato toccato da quando quella release è uscita. Dove un progetto dichiara supporto solo fino a una release nominata, trattate la successiva come non testata finché non l’avete avviata voi.

Fate corrispondere il target binario allo spazio utente che avete

L’architettura è il guasto più silenzioso. Un kernel a 64 bit con uno spazio utente a 32 bit è una combinazione reale e supportata su diverse schede, e fa girare un binario FTL a 32 bit senza lamentarsi, fino al momento in cui installate qualcosa pubblicato solo per arm64. Stampate entrambe le metà prima di scegliere un’immagine, e tenete l’output accanto alle vostre note.

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

Se quelle due righe di architettura non concordano, siete su un allestimento misto: praticabile per Pi-hole da solo, fragile appena un secondo servizio vuole librerie native. Riflashare un’immagine pulita a 64 bit è di solito più veloce che ricostruire la toolchain che ha prodotto la discordanza.

Anche il marketing della scheda non risolve la questione. Dimensione della memoria e modello di CPU non dicono nulla su quale libc colleghino i vostri pacchetti, quindi decidete dai valori stampati, mai dalla pagina del prodotto.

Una macchina, due servizi, un solo proprietario della rete

Decidete chi possiede indirizzamento, resolver e tunnel prima che il primo pacchetto salga, altrimenti due servizi rivendicheranno lo stesso compito e nessuno vincerà pulito. Date al Pi un indirizzo statico fuori dal pool DHCP che il vostro router distribuisce, e tenete il tunnel sulla sua sottorete: 192.168.50.10 per il Pi e 10.42.0.0/24 per il tunnel è una suddivisione praticabile, e i numeri stessi sono arbitrari finché non collidono con ciò che il router serve già. Poi annotate quale componente risponde sulla porta 53, quale distribuisce DHCP se lo usate e quale possiede la rotta predefinita mentre il tunnel è attivo. Su un’immagine senza interfaccia grafica quell’ultimo compito spetta a NetworkManager o systemd-networkd, e installare un client del fornitore che riscrive anche la configurazione del resolver è il modo in cui la gente finisce con un tunnel vivo e un DNS morto.

Condividere la macchina va bene. Condividere un ruolo no. Pi-hole vuole essere l’unico ascoltatore sulla porta 53, e il demone VPN vuole spingere la propria impostazione DNS ai client, quindi scegliete a quale dei due i client devono fidarsi e configurate l’altro per restare fuori dai piedi.

Tenete il percorso di amministrazione fuori dal tunnel quando potete. Se resolver e tunnel cadono insieme, volete ancora SSH raggiungibile sull’indirizzo LAN, e questo significa che il servizio di gestione non deve dipendere da nessuno dei due.

Fate del prossimo aggiornamento parte della scelta

Una release che non potete aggiornare è un tetto di supporto che avete già accettato. Testate la meccanica di aggiornamento su una scheda di riserva prima che l’apparecchio porti il DNS della vostra casa, e leggete cosa dicono i progetti sul saltare tra rami invece di dare per scontato che un aggiornamento di pacchetto basti.

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

I pacchetti trattenuti sono la ragione abituale per cui un aggiornamento sembra riuscito e non cambia nulla. Liberate le trattenute di proposito, una alla volta, e annotate quale servizio aveva bisogno del pin.

Prima del salto esportate la configurazione di Pi-hole, i lease statici e ogni profilo di tunnel, e confermate di poterli ripristinare su un’immagine nuova. Dopo il salto provate il DNS ordinario dei client, la risorsa privata dietro il tunnel, una riconnessione e qualsiasi regola di inoltro sul gateway. Una macchina che si avvia e risponde al ping non ha superato quasi nulla.

Quando nessuna release unica va bene per entrambi i servizi

A volte la sovrapposizione è vuota: l’helper VPN è passato a una release più recente del pacchetto Pi-hole che potete installare, oppure l’immagine del fornitore della scheda è indietro rispetto a entrambe. In quel caso separate i ruoli invece di modificare i metadati della release per accontentare un installer. Due dispositivi piccoli, o un dispositivo più un container per il secondo servizio, costano meno di un apparecchio la cui storia di supporto si regge su una bugia.

Falsificare la versione è l’unica scorciatoia da rifiutare di netto. I gestori di pacchetti credono a ciò che dice il file di release, quindi un identificatore falsificato vi dà un’installazione che nessuno dei due progetti aiuterà a diagnosticare.

Se due release attuali soddisfano tutto, scegliete quella le cui note di aggiornamento potete seguire senza tirare a indovinare, e smettete di cercare. Poi registrate versione, architettura, proprietari dei servizi e passo di ripristino in un solo posto, perché la prossima persona che tocca la scheda SD avrà bisogno di tutti e quattro.