Les clients du hotspot du Pi n'atteignent pas le LAN domestique via un VPN TUN

Les clients Wi-Fi et Ethernet locaux se connectent au hotspot du Pi, prennent une adresse dans sa plage DHCP et chargent des pages internet sans se plaindre. Ces mêmes clients expirent ensuite lorsqu'ils ouvrent un partage de fichiers ou une interface web sur le LAN domestique, tandis que le Pi lui-même atteint ce LAN par le tunnel. Rien dans la couche sans fil n'est cassé. Ce qui manque est un contrat routé : le préfixe du hotspot doit être porté dans l'interface TUN, et quelque chose côté maison doit savoir comment renvoyer les réponses vers lui. Les deux moitiés doivent exister avant qu'un seul paquet puisse boucler l'aller-retour.

Trois attachements pour trois tâches différentes

Un pont Ethernet Linux transmet les trames selon l'adresse MAC de destination. OpenVPN en mode TUN transporte des paquets IP et n'a aucune couche MAC, donc ajouter un pont local n'inscrit jamais le tunnel comme port. La documentation du noyau sur TUN/TAP explique cette séparation : un périphérique TAP ressemble à une interface Ethernet, un périphérique TUN non. Une conception qui ponte deux ports locaux puis route est un routeur, quoi qu'en disent les noms d'interfaces.

Cette distinction tranche la propriété. Le sous-réseau des clients, leur passerelle par défaut et l'autorité DHCP sur cette plage appartiennent au plan local du Pi. Les diffusions DHCP domestiques ne traversent pas un tunnel routé, et aucun réglage de pont ne change cela ; pointer les clients vers un serveur DHCP domestique est une conception de relais distincte et délibérée, avec ses propres modes de défaillance.

Gardez aussi le modem hors du pont client. Un attachement PPP n'est pas un périphérique Ethernet avec une autre étiquette, et la logique de route par défaut documentée de pppd s'exécute après la négociation IPCP et retire sa route lorsque ce lien tombe. Copier un modèle DHCP et renommer chaque usb0 en ppp0 ne prouve rien sur la passerelle, la métrique ou le cycle de vie.

Choisissez les préfixes avant de modifier une quelconque configuration

Les préfixes qui se chevauchent coûtent plus de soirées que les règles de pare-feu, car un chevauchement envoie la recherche de route vers la mauvaise interface même lorsque le tunnel est sain. Commencez par lister ce qui existe déjà sur le Pi, puis lisez le résultat comme quatre bassins distincts.

ip -4 addr show scope global
ip -4 route show table main
ip -4 route get 192.168.77.10

Le premier bassin est l'adresse underlay que l'opérateur a donnée au modem ; elle doit rester hors de tout plan tourné vers les clients. Le second est le sous-réseau du tunnel choisi par le serveur, souvent un /24 privé à lui. Le troisième est le pont du hotspot, et le quatrième est le préfixe domestique que vous voulez atteindre. Dans ce parcours, le hotspot reçoit 172.28.90.0/24 avec le pont sur 172.28.90.1, et le LAN de services domestique conserve 192.168.77.0/24, ce qui évite les valeurs par défaut 192.168.1.0/24 et 10.0.0.0/24 livrées avec les routeurs grand public et la plage opérateur 100.64.0.0/10.

Annoncez l'adresse du pont comme passerelle dans la plage DHCP du hotspot et rien d'autre. Ne donnez jamais aux clients du hotspot une adresse domestique comme passerelle ; ils n'ont aucun chemin au niveau liaison vers ce segment.

Routez chaque direction du côté qui la possède

Le Pi a besoin d'une route pour le préfixe domestique à travers le tunnel. Les serveurs en mode serveur poussent normalement cette route, donc confirmez d'abord que le transfert est actif et que le noyau résout une adresse domestique depuis tun0.

sysctl net.ipv4.ip_forward
ip route add 192.168.77.0/24 dev tun0
ip -4 route get 192.168.77.10

Si ip route get signale encore l'interface underlay, arrêtez-vous là ; rien de plus loin sur le chemin ne peut réparer une recherche erronée.

Les appareils domestiques n'ont aucune route vers 172.28.90.0/24, donc leurs réponses suivent la passerelle par défaut et meurent au routeur. Deux réparations prises en charge existent. Soit vous ajoutez une route statique sur le routeur domestique qui pointe le préfixe du hotspot vers l'adresse LAN du serveur VPN, soit, lorsque le serveur est lui-même la passerelle, vous enregistrez le préfixe du client dans la table de routage propre du serveur. En mode multi-clients d'OpenVPN, le répertoire spécifique au client porte cette association : un fichier nommé d'après le nom commun du certificat du client, contenant iroute 172.28.90.0 255.255.255.0 plus la ligne route correspondante qui l'installe dans le noyau du serveur. Une route de noyau devinée sur le serveur n'est pas la même déclaration que dire au serveur quel client possède le préfixe.

Ne déplacez pas le service DHCP du réseau domestique sur le serveur VPN pour faire fonctionner cela. Remplacer la passerelle par défaut de toute une maison est un changement bien plus vaste qu'ajouter une route de retour privée, et cela entraîne DNS, réservations d'adresses et tout appareil qui ignore le nouveau bail dans la panne.

Ouvrez le transfert sans deviner le pare-feu

Le transfert activé ne signifie pas que le paquet est autorisé à passer. Le trafic du pont vers le tunnel heurte encore les règles de filtrage, et une politique de transfert par défaut drop abandonne le trafic du hotspot tandis que le trafic propre du Pi continue de fonctionner, ce qui produit exactement le symptôme divisé ci-dessus.

iptables -S FORWARD
iptables -t nat -S POSTROUTING
nft list ruleset

Cherchez une règle d'acceptation de br0 vers tun0 et la direction de réponse correspondante, ainsi qu'une règle postrouting susceptible de réécrire la source. Si la politique de la chaîne est drop et qu'aucune règle ne correspond, ajoutez les acceptations étroites et retestez plutôt que de basculer la politique en accept.

La traduction est un choix de politique, pas une obligation. Le NAT source vers le LAN domestique fait ressembler chaque client du hotspot à l'adresse du tunnel du Pi, ce qui perd l'attribution par client dans les journaux domestiques et casse les services qui attendent la source d'origine. Le routage sans NAT garde les adresses des clients visibles mais dépend de la route de retour ci-dessus. Choisissez-en une et traitez DNS et IPv6 de la même manière, car un chemin IPv4 qui fonctionne à côté d'un chemin IPv6 cassé se lit encore comme à moitié cassé dans un navigateur.

Vérifiez l'aller-retour, puis cassez-le exprès

Testez depuis un client du hotspot, jamais depuis le Pi, car le trafic propre du Pi contourne à la fois le chemin aller et le chemin retour. Observez les deux interfaces pendant qu'un client tente d'atteindre un service domestique.

tcpdump -ni br0 host 192.168.77.10
tcpdump -ni tun0 host 192.168.77.10
ping -c 3 192.168.77.10

Lisez les deux captures ensemble. Les requêtes sur br0 qui n'apparaissent jamais sur tun0 signifient que le Pi ne transfère pas ou que la route pointe ailleurs. Les requêtes sur tun0 sans réponses signifient que le côté domestique n'a pas de route de retour ou que le serveur a filtré le paquet. Les réponses sur tun0 qui ne réapparaissent jamais sur br0 signifient que la règle de filtrage inverse manque, où le tunnel semble parfait et le client ne voit toujours rien.

Cassez ensuite le chemin délibérément. Coupez la connexion du modem et remontez-la, puis relancez les contrôles de route et de capture ; une route qui survit au tunnel mais disparaît à la reconnexion appartient au profil de connexion, pas à une commande ponctuelle. Confirmez que le transport du tunnel sort toujours par l'underlay et non par lui-même, la boucle classique lorsqu'une route par défaut poussée est acceptée sans route d'hôte vers le pair.

N'acceptez la conception que lorsqu'un client du hotspot peut résoudre un nom domestique, ouvrir un service TCP et garder une session vivante pendant une reconnexion du modem. Si une application exige vraiment une découverte au niveau Ethernet sur le segment domestique, choisissez une conception Layer 2 prise en charge plutôt que de décrire le pont local comme ponté et d'attendre l'apparition de la diffusion.