Point d'accès VPN ponté : quelle route par défaut le téléphone utilise-t-il ?

Le téléphone de votre point d'accès ponté obtient son adresse et sa passerelle de quelque part, et ce n'est pas la route par défaut du Pi. Changer la route par défaut du Pi change où le Pi envoie son propre trafic. Le téléphone continue d'utiliser la passerelle qui lui a été indiquée, et lorsque cette passerelle se trouve sur le LAN distant, ses trames traversent simplement le pont. Deux consommateurs, deux décisions. Les séparer explique la plupart des signalements de point d'accès sans internet alors que le Pi lui-même fonctionne.

Deux appareils, deux décisions de passerelle différentes

Le Pi a sa propre pile IP et sa propre route par défaut. Le téléphone a sa propre pile IP et sa propre route par défaut.

Ce tableau est tout le modèle. La passerelle du téléphone est une adresse sur le LAN distant, et ses trames sont transmises en couche 2 vers ce routeur. La route par défaut du Pi concerne son propre transport extérieur, qui doit atteindre le pair VPN par l'uplink de déplacement.

Un pont transmet des trames, il ne route pas les paquets

Un pont Linux transmet les trames Ethernet selon la MAC de destination, et c'est tout ce qu'il fait entre ses ports. La trame du téléphone adressée à la MAC du routeur distant est commutée vers le port TAP et traverse le tunnel sans toucher à la table de routage du Pi. C'est pourquoi une route par défaut cassée du Pi peut laisser le téléphone fonctionner, et pourquoi une route correcte ne peut pas réparer un téléphone à qui l'on a donné la mauvaise passerelle.

TAP transporte des trames Ethernet et peut être un port de pont. TUN transporte des paquets IP et ne peut pas. Si votre conception a remplacé l'un par l'autre, le pont n'est pas un pont et le reste ne s'applique pas.

Décidez qui distribue le bail du téléphone

L'option 3 de DHCP est l'option routeur, et elle indique au client quelle passerelle utiliser pour son sous-réseau. Lorsque le serveur DHCP du LAN distant est le seul distributeur, le téléphone obtient une passerelle distante et la conception est cohérente. Lorsque autre chose, côté déplacement, répond en premier, le téléphone obtient une passerelle locale, son trafic internet sort par l'uplink de déplacement, et son trafic vers le LAN distant n'a aucun chemin du tout.

N'exécutez qu'un seul distributeur pour ce domaine de diffusion, et notez ce qu'il distribue.

Le Pi est un cas à part même lorsqu'il prend une adresse dans le même bail. Décidez délibérément s'il doit installer les routes que le bail propose, car une route par défaut distante importée peut entraîner le transport VPN du Pi dans le tunnel qu'il cherche à maintenir en vie. Avec systemd-networkd, cette décision est UseRoutes= dans la section DHCP ; avec dhclient, c'est l'option routers dans la liste de requêtes.

Gardez l'uplink hors du LAN ponté

L'interface qui porte la connexion VPN extérieure du Pi ne doit pas devenir un port de pont. Si elle le devient, le transport chiffré est commuté dans le LAN étendu et le tunnel finit par transporter ses propres paquets extérieurs, ce qui échoue d'une manière qui ressemble à une perte de paquets plutôt qu'à une boucle. Gardez aussi explicites la capacité AP et la prise en charge du pont. Une interface sans fil en mode station ne peut généralement pas être un port de pont, car l'en-tête 802.11 n'a pas de place pour la seconde adresse MAC dont un pont a besoin.

Définissez le domaine de diffusion étendu, un plan d'adressage et le filtrage de trames que vous voulez réellement. Autoriser l'écoute VPN sur le Pi ne donne pas à chaque client ponté l'accès aux services de gestion du Pi. Ce sont des règles distinctes, et les traiter comme une seule est la façon dont un point d'accès devient discrètement une porte ouverte.

Testez les quatre choses séparément quand cela casse

Lorsque le téléphone ne peut pas atteindre le LAN distant, quatre observations séparent les causes. Exécutez-les dans cet ordre et arrêtez-vous à la première qui échoue.

ip route show default
bridge link show
ip -4 neigh show dev br0
tcpdump -ni br0 arp or icmp

Commencez par le bail : le téléphone détient-il une adresse et une passerelle sur le sous-réseau distant ? Regardez ensuite le pont, et confirmez que le port AP et le port TAP transmettent tous les deux. Lisez ensuite la table des voisins, car une entrée non résolue pour le routeur distant signifie que les trames partent et que rien ne répond. Enfin, observez les trames sur le pont pendant que le téléphone fait un ping, ce qui vous dit si la panne se situe sous IP ou non.

Notez quel appareil possède chaque route par défaut lorsque vous avez terminé. Une ligne de documentation transforme la sortie locale ou distante en une décision client délibérée, et la référence du pont mérite d'être conservée à côté.