hostapd et OpenVPN sur un seul Pi : à qui appartient la route par défaut ?

hostapd et un client OpenVPN peuvent partager un Pi lorsque le pont conserve sa propre route par défaut et que le tunnel conserve un chemin vers son serveur. Commandes et retour arrière.

Les téléphones s'associent au point d'accès, reçoivent une adresse, puis n'atteignent plus rien du tout dès que le tunnel monte. hostapd est généralement sain dans cet état, et OpenVPN aussi ; ce qui casse, c'est la route par défaut, qui soit n'a jamais existé sur le pont, soit a été remplacée par le tunnel sans laisser de chemin vers le serveur VPN lui-même. Ce guide remet cette route à sa place et prouve le résultat depuis un client plutôt que depuis le Pi. Chaque étape est réversible, et rien ici ne modifie la configuration du tunnel tant que vous ne savez pas quel trafic vous voulez à l'intérieur.

Inventoriez les interfaces avant de modifier quoi que ce soit

La disposition habituelle place la radio sans fil et le port filaire dans br0, lance hostapd sur le pont et distribue des baux depuis dnsmasq, tandis qu'un client OpenVPN crée tun0. Trois exigences distinctes ressemblent alors à une seule : les clients du point d'accès ont besoin du Pi comme passerelle, le Pi a besoin d'une route vers Internet pour joindre son serveur, et le pont a besoin d'une adresse de passerelle que ces clients peuvent utiliser.

Lisez l'état actuel avant de le changer, car ces quatre commandes séparent un problème d'interface d'un problème de routage.

ip -br addr
ip route show
ip link show master br0
bridge link show

Si br0 porte une adresse mais aucune route par défaut, les clients atteignent le Pi et rien au-delà. Si la route par défaut pointe vers tun0 alors que le tunnel est arrêté, le Pi n'a aucun chemin fonctionnel, et le symptôme côté client est exactement le même. Les deux cas se ressemblent depuis un téléphone, c'est pourquoi la table de routage doit être lue directement.

Donnez au pont une route par défaut qui lui appartienne

Raspberry Pi OS laisse souvent le pont sans route par défaut lorsque le pont est apparu après l'écriture du fichier d'interface. Le bloc appartient à /etc/dhcpcd.conf, et il doit nommer le routeur amont plutôt que le Pi.

interface br0
static ip_address=192.168.50.2/24
static routers=192.168.50.1
static domain_name_servers=192.168.50.1

Dans cet exemple, 192.168.50.1 est le routeur existant et 192.168.50.2 est l'adresse du pont du Pi dans le même sous-réseau, remplacez donc par votre propre plan au lieu de copier les nombres. Les membres du pont ne doivent pas non plus demander de routeur, sinon le Pi se retrouve avec des routes par défaut concurrentes dont la gagnante dépend de la métrique et du timing plutôt que de l'intention.

Après systemctl restart dhcpcd, ip route show default doit lister br0 une fois et aucun doublon depuis le port filaire. Confirmez la recherche plutôt que la table, car une entrée obsolète peut siéger à côté d'une gagnante : ip -4 route get 203.0.113.10 doit nommer br0. Cette adresse vient de la plage de documentation TEST-NET-3, elle ne peut donc pas entrer en collision avec un vrai serveur pendant que vous lisez ceci.

Empêchez le tunnel de détourner le chemin vers son propre serveur

Un client OpenVPN qui accepte redirect-gateway prend la route par défaut et la dirige dans le tunnel. C'est correct quand chaque client du point d'accès doit utiliser le VPN, et faux quand seules certaines destinations le doivent. Quoi qu'il en soit, la connexion propre du Pi au serveur ne doit pas voyager à l'intérieur du tunnel qu'il est encore en train de construire. OpenVPN ajoute une route d'hôte vers le distant via la passerelle d'origine lorsqu'il redirige la route par défaut, et c'est exactement le comportement qui maintient le transport en vie ; si cette route manque, le tunnel s'effondre dès qu'il s'établit.

Une comparaison rapide de ce chemin de transport avant et après la connexion vaut les dix secondes. ip -4 route get 203.0.113.10 doit nommer l'équipement sous-jacent dans les deux états, seule la métrique change. S'il nomme tun0 après la montée du tunnel, la route d'hôte n'a jamais été installée et la prochaine reconnexion échouera.

Lorsque seuls certains préfixes doivent traverser le tunnel, utilisez route-nopull et ajoutez les routes voulues à la main, ou poussez un ensemble plus étroit depuis le serveur. Le pont conserve la route par défaut dans ce schéma, et le DNS devient la décision suivante : le transfert de dnsmasq vers un résolveur domestique n'a de sens que pour les noms qui y vivent réellement.

Décidez de l'histoire du transfert et du NAT

Un tunnel complet exige le transfert activé sur le Pi et une passerelle côté distant disposée à router le sous-réseau du point d'accès. Vérifiez le transfert avant tout le reste, car un zéro rend chaque changement de route sans importance.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADE

La règle NAT est le raccourci qui fonctionne lorsque le serveur n'accepte pas le préfixe du point d'accès, au prix de voir chaque client apparaître comme l'adresse de tunnel du Pi dans les journaux du côté distant. Router le préfixe sans NAT garde les adresses visibles et dépend d'une route de retour pour 192.168.50.0/24 côté maison.

Notez le choix à côté des règles du pare-feu, car une règle NAT invisible dans la conception devient inexplicable six mois plus tard. Gardez IPv6 dans la même décision ; un chemin IPv4 qui fonctionne à côté d'un chemin IPv6 cassé se lit encore comme à moitié cassé dans un navigateur.

Vérifiez depuis un client, puis revenez proprement en arrière

Testez dans cet ordre depuis un téléphone ou un ordinateur portable sur le point d'accès : un bail de dnsmasq, un ping vers l'adresse du pont, puis une destination de l'autre côté du tunnel. Chaque étape isole une couche au lieu de produire un seul échec inutile.

ip -4 route get 203.0.113.10
ping -c 3 -I br0 203.0.113.10

Confirmez ensuite que le Pi a toujours sa propre sortie : ip route get 203.0.113.10 doit nommer l'équipement sous-jacent, et ping -c 3 -I br0 203.0.113.10 doit répondre si le serveur autorise ICMP. Si les deux premières étapes du client passent et que la troisième échoue, la faute est dans le transfert ou le NAT. Si la deuxième étape échoue, le pont ou le DHCP est encore incomplet.

Le retour arrière est une modification de fichier et deux commandes : supprimez le bloc, redémarrez dhcpcd et remplacez la route par défaut explicitement avec ip route replace default via 192.168.50.1 dev br0. Faites-le avant la fermeture de la fenêtre de maintenance plutôt qu'après, car un Pi qui a perdu sa route par défaut est injoignable depuis le réseau que vous utiliseriez pour le réparer.

Articles similaires