Hotspot Pi con Pi-hole e VPN: assegna un compito a ogni servizio

Un telefono si unisce all'hotspot del Pi, riceve un indirizzo e la pagina continua a non caricarsi. Il Pi esegue un helper per l'hotspot, Pi-hole e un client VPN, e ognuno crede di possedere una parte del percorso. La maggior parte di queste configurazioni fallisce non perché un componente è guasto, ma perché due componenti svolgono lo stesso compito. Assegna un proprietario per ogni funzione prima di regolare uno qualsiasi di essi.

Assegna un proprietario per funzione

Qui contano quattro funzioni, e ognuna richiede esattamente un proprietario. La tabella seguente indica la funzione, un proprietario praticabile e che cosa va storto quando due servizi la rivendicano.

La sovrapposizione di solito arriva un pacchetto alla volta. L'helper dell'hotspot installa la propria istanza di dnsmasq, Pi-hole vuole la porta 53 e il client VPN aggiunge rotte. Ogni passo sembra ragionevole da solo e, insieme, producono una macchina in cui il secondo servizio ad avviarsi cambia silenziosamente il comportamento del primo.

Annota i proprietari prima di abilitare qualsiasi altra cosa. Una breve tabella nelle note di configurazione evita che un'installazione successiva si impossessi di una funzione che aveva già un proprietario.

Scegli una sola rete e tienila lontana dal tunnel

Scegli la rete dell'hotspot, l'indirizzo del Pi su di essa, il pool DHCP e il resolver che i client ricevono. Tieni quella rete separata dalla LAN a monte e dalla rete del tunnel VPN, perché sottoreti sovrapposte trasformano un problema di routing in un progetto di traduzione degli indirizzi. Una rete che si sovrappone al tunnel rende il Pi un router accidentale tra due prefissi identici. Scrivi la rete e il pool nella configurazione dell'hotspot invece di lasciarli a un valore predefinito.

Se la modalità condivisa di NetworkManager possiede l'hotspot, ispeziona la connessione effettiva prima di aggiungere un server DHCP. La modalità condivisa avvia i propri helper e abilita l'inoltro, quindi è già il proprietario del piano degli indirizzi per quell'interfaccia. Aggiungere un secondo server perché è disponibile crea offerte in competizione anziché ridondanza.

Decidi l'IPv6 in modo deliberato. Gli annunci dei router e il DHCPv6 provengono, in molte configurazioni, da un helper diverso da quello di DHCPv4, e lasciare IPv6 attivo mentre la policy VPN copre solo IPv4 offre ai client un percorso che aggira il tunnel. O pianifichi il lato IPv6 o lo disabiliti sull'interfaccia dell'hotspot con una motivazione scritta.

Chi risponde davvero sulla porta 53

Elenca ogni processo in ascolto sulla porta 53 prima di cambiare una configurazione. Su un Pi che esegue uno stub di resolver locale, Pi-hole e un helper di condivisione, l'elenco degli ascoltatori è l'unica mappa affidabile di chi risponde alle query:

sudo ss -lunpt '( sport = :53 )'
ip -4 addr show
ip route

La guida alle interfacce di Pi-hole spiega che una modalità di ricezione limitata a una sola interfaccia può comunque usare un socket wildcard e scartare gli arrivi altrove. Non è la stessa cosa di collegarsi solo alle interfacce selezionate, che è la configurazione prevista quando un altro servizio DNS deve condividere la macchina.

Normalmente due processi non possono collegarsi allo stesso indirizzo e alla stessa porta, anche se SO_REUSEPORT può far riuscire un bind condiviso; anche in quel caso, un listener wildcard può prendere gli arrivi destinati al servizio più ristretto. Scegli la modalità documentata per il ruolo che vuoi e riavvia i servizi nell'ordine previsto.

Tieni la pagina di amministrazione di Pi-hole fuori dalla rete dell'hotspot. I client hanno bisogno di un resolver, non dell'interfaccia web o dell'API che può cambiare la configurazione del resolver.

Due tratte DNS, una policy ciascuna

Una query del client viaggia dal telefono al Pi, e una query separata viaggia dal Pi al suo resolver upstream. Una regola di routing che corrisponde al traffico inoltrato dell'hotspot non si applica automaticamente alla seconda tratta, perché il Pi genera quel traffico localmente. Se la VPN deve trasportare il DNS, il percorso locale ha bisogno di una propria policy.

Attento ai loop. Puntare l'upstream di Pi-hole verso un indirizzo servito dal Pi stesso, direttamente o tramite un port-forward, produce query che girano finché non scadono. Dagli un upstream reale o un forwarder condizionale per i domini a cui non sa rispondere.

Decidi cosa succede quando il tunnel cade. Tornare al resolver locale mantiene viva la navigazione ma può far trapelare i nomi fuori dalla VPN; bloccare mantiene intatta la policy e trasforma il disservizio in un errore visibile. Entrambe le scelte sono difendibili, ma vanno scelte, non ereditate da un valore predefinito.

Verifica il percorso e il comportamento in caso di caduta

Prova a livelli: il client ottiene un indirizzo, il client risolve un nome tramite il Pi, il Pi risolve tramite l'upstream previsto e un'applicazione completa una richiesta. Un ping riuscito non dice nulla sul DNS, e una risoluzione riuscita non dice nulla sull'inoltro.

dig @192.168.70.1 example.com
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/
ip -4 route get 1.1.1.1

Poi ferma il tunnel e ripeti. Il comportamento previsto dovrebbe comparire entro pochi secondi, non dopo un riavvio manuale di Pi-hole o del servizio hotspot. Controlla l'impostazione del resolver del client durante il disservizio, perché un resolver pubblico secondario continuerà a rispondere anche quando la policy prevedeva un errore.

Tieni un solo proprietario per inoltro e NAT e verificalo da un client, non dal Pi stesso. Una richiesta che esce dal Pi con successo può comunque essere scartata al ritorno, e il client è l'unico punto in cui l'intero percorso è visibile.