Point d’accès Pi avec Pi-hole et VPN : attribuez une tâche à chaque service

Un téléphone rejoint le point d’accès du Pi, obtient une adresse, et la page échoue toujours. Le Pi exécute un assistant de point d’accès, Pi-hole et un client VPN, et chacun croit posséder une partie du chemin. La plupart de ces montages échouent non parce qu’un composant est cassé, mais parce que deux composants font le même travail. Attribuez un propriétaire par fonction avant d’en régler un seul.

Attribuez un propriétaire par fonction

Quatre fonctions comptent ici, et chacune a besoin d’exactement un propriétaire. Le tableau ci-dessous nomme la fonction, un propriétaire viable et ce qui échoue lorsque deux services la revendiquent.

Le chevauchement arrive généralement un paquet à la fois. L’assistant du point d’accès installe sa propre instance de dnsmasq, Pi-hole veut le port 53, et le client VPN ajoute des routes. Chaque étape semble raisonnable seule, et ensemble elles produisent une machine où le second service démarré modifie discrètement le comportement du premier.

Notez les propriétaires avant d’activer quoi que ce soit d’autre. Un court tableau dans les notes de montage empêche une installation ultérieure de reprendre une fonction qui avait déjà un propriétaire.

Choisissez une plage et tenez-la à l’écart du tunnel

Choisissez la plage du point d’accès, l’adresse du Pi dedans, la piscine DHCP et le résolveur que reçoivent les clients. Gardez cette plage séparée du LAN amont et de la plage du tunnel VPN, car des sous-réseaux qui se chevauchent transforment un problème de routage en projet de traduction d’adresses. Une plage qui chevauche le tunnel fait du Pi un routeur accidentel entre deux préfixes identiques. Écrivez la plage et la piscine dans la configuration du point d’accès au lieu de les laisser à une valeur par défaut.

Si le mode partagé de NetworkManager possède le point d’accès, inspectez la connexion effective avant d’ajouter un serveur DHCP. Le mode partagé démarre ses propres assistants et active le transfert, il est donc déjà propriétaire du plan d’adressage de cette interface. Ajouter un second serveur parce qu’il est disponible crée des offres concurrentes plutôt qu’une redondance.

Décidez d’IPv6 délibérément. Les annonces de routeur et DHCPv6 viennent, dans beaucoup de montages, d’un assistant différent de DHCPv4, et laisser IPv6 actif alors que la politique VPN ne couvre qu’IPv4 donne aux clients un chemin qui contourne le tunnel. Soit vous planifiez le côté IPv6, soit vous le désactivez sur l’interface du point d’accès avec une raison écrite.

Qui répond réellement sur le port 53

Listez chaque processus qui écoute sur le port 53 avant de modifier une configuration. Sur un Pi qui exécute un stub de résolveur local, Pi-hole et un assistant de partage, la liste des écouteurs est la seule carte fiable de qui répond aux requêtes :

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

Le guide des interfaces de Pi-hole explique qu’un mode de réception limité à une interface peut tout de même utiliser une socket générique et écarter les arrivées ailleurs. Ce n’est pas la même chose que de lier uniquement des interfaces choisies, qui est la disposition prévue lorsqu’un autre service DNS doit partager la machine.

Deux processus ne peuvent normalement pas lier la même adresse et le même port, même si SO_REUSEPORT peut faire réussir une liaison partagée ; même alors, un écouteur générique peut prendre les arrivées destinées au service plus étroit. Choisissez le mode documenté pour le rôle que vous voulez et redémarrez les services dans l’ordre prévu.

Gardez la page d’administration de Pi-hole hors du réseau du point d’accès. Les clients ont besoin d’un résolveur, pas de l’interface web ou de l’API qui peut modifier la configuration du résolveur.

Deux pattes DNS, une politique pour chacune

Une requête client voyage du téléphone au Pi, et une requête distincte voyage du Pi à son résolveur amont. Une règle de routage qui correspond au trafic du point d’accès transféré ne s’applique pas automatiquement à la seconde patte, car le Pi génère ce trafic localement. Si le VPN doit transporter le DNS, le chemin local a besoin de sa propre politique.

Surveillez les boucles. Pointer le résolveur amont de Pi-hole vers une adresse que le Pi sert lui-même, directement ou via un transfert de port, produit des requêtes qui tournent jusqu’à expiration. Donnez-lui un vrai résolveur amont ou un redirecteur conditionnel pour les domaines auxquels il ne peut pas répondre.

Décidez de ce qui se passe lorsque le tunnel tombe. Revenir au résolveur local maintient la navigation vivante mais peut fuiter des noms hors du VPN ; bloquer préserve la politique et transforme la panne en erreur visible. Chaque choix est défendable, mais il doit être choisi plutôt qu’hérité d’une valeur par défaut.

Prouvez le chemin et le comportement en panne

Testez par couches : le client obtient une adresse, le client résout un nom via le Pi, le Pi résout via le résolveur amont prévu, et une application termine une requête. Un ping réussi ne dit rien du DNS, et une résolution réussie ne dit rien du transfert.

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

Arrêtez ensuite le tunnel et répétez. Le comportement prévu doit apparaître en quelques secondes, pas après un redémarrage manuel de Pi-hole ou du service du point d’accès. Vérifiez le réglage du résolveur du client pendant la panne, car un résolveur public secondaire continuera de répondre même lorsque la politique attendait un échec.

Gardez un seul propriétaire pour le transfert et le NAT et vérifiez-le depuis un client, pas depuis le Pi lui-même. Une requête qui quitte le Pi avec succès peut encore être abandonnée sur le chemin du retour, et le client est le seul endroit où tout le chemin est visible.