Pourquoi un VPN en tunnel complet masque vos VLAN locaux routés

L'interrupteur « allow local network » d'un client VPN donne l'impression de couvrir tout ce qui se trouve dans le bâtiment. En pratique, il ajoute généralement quelques exceptions d'adresses privées à la route par défaut du tunnel et s'arrête là. Votre VLAN de stockage ne reste joignable que si une route pour ce préfixe précis survit à l'arrivée du tunnel, et sur beaucoup de clients ce n'est pas le cas.

C'est une question de routage plutôt qu'un réglage du VPN, ce qui est une bonne nouvelle : elle a une réponse concrète.

Ce que allow-local-network couvre vraiment

Les clients implémentent cette option différemment. Certains ajoutent des routes pour le sous-réseau auquel la machine est rattachée, d'autres ajoutent les plages RFC 1918, et quelques-uns n'excluent que la passerelle par défaut. Aucun ne sait que votre routeur de bureau sert aussi un VLAN de stockage, un segment de laboratoire ou un sous-réseau d'imprimantes, car ces préfixes ne sont pas sur le câble que le client voit. Lisez la documentation du client lui-même pour le comportement exact au lieu de supposer que l'étiquette décrit votre topologie.

La distinction compte surtout dans une conception en tunnel complet, où le client remplace délibérément la route par défaut pour que tout le trafic passe par le VPN. C'est tout l'intérêt de la conception, et c'est aussi ce qui fait disparaître les réseaux locaux routés. Ils n'étaient jamais couverts par une route propre ; ils roulaient sur la route par défaut qui vient d'être remplacée. Un client ne peut pas router ce dont il ignore l'existence, et il n'apprend que les préfixes attachés à sa propre interface. Tout le reste doit être décrit par quelqu'un qui connaît la topologie.

Les routes connectées s'arrêtent au premier routeur

Un poste de travail en 192.168.10.20/24 avec la passerelle 192.168.10.1 obtient automatiquement une route connectée pour 192.168.10.0/24. Le VLAN de stockage en 192.168.20.0/24 est un autre préfixe, joignable uniquement via cette passerelle, et le poste n'a aucune route pour lui au-delà de la route par défaut. Avant que le tunnel monte, la route par défaut ordinaire envoie par hasard le trafic de stockage vers 192.168.10.1 et tout fonctionne.

Quand le VPN installe une route par défaut en tunnel complet, les paquets vers 192.168.20.1 suivent la nouvelle route par défaut dans le tunnel. La passerelle distante n'a aucune idée de l'endroit où vit ce préfixe, elle les jette donc ou les transfère vers un endroit inutile. Rien n'était mal configuré sur le VLAN de stockage ; son chemin était emprunté, et le prêt a été rappelé.

La tentation est de recourir à une exception large, comme une paire de routes /1 ou une seconde route par défaut. Résistez-y. Plus l'exception est étroite, plus il est facile de l'expliquer, de l'auditer et de la retirer lorsque le réseau change.

Mettez l'exception dans la table qui gagne

Dans une même table de routage, un /24 bat un /0 ou un /1 par correspondance du préfixe le plus long, une route précise vers le VLAN de stockage via la passerelle locale suffit donc, à condition que la table soit consultée. Sous Linux, la forme ordinaire est courte :

ip route add 192.168.20.0/24 via 192.168.10.1 dev eth0

Le routage par politique complique cette garantie. Une règle antérieure peut envoyer le trafic vers une table dont la route par défaut pointe dans le tunnel, et la table principale qui contient votre /24 n'est alors jamais atteinte. Vérifiez les règles avant de supposer que la route fait autorité, car une entrée d'apparence correcte dans la mauvaise table explique une panne qui ressemble à une route cassée.

Rendez ensuite l'entrée persistante via le mécanisme pris en charge par le client ou le gestionnaire de réseau qui possède l'interface. Une route tapée dans l'invite disparaît à la prochaine reconnexion, et une route liée à une seule passerelle Wi-Fi n'est pas transposable au réseau suivant que l'ordinateur portable visite.

Les noms et les politiques ne suivent pas les routes

Réparer la route restaure les paquets, pas les noms. Si les appareils locaux sont résolus via un résolveur imposé qui n'en sait rien, le montage échoue toujours même si l'adresse est joignable. Les noms locaux ont besoin d'un arrangement DNS local ou scindé, et c'est une décision distincte de l'exception de route.

La politique est encore autre chose. Le filtre d'accès local d'un client VPN peut interdire délibérément le trafic vers les plages privées, et une route ne passe pas outre cette règle. Sur un réseau non fiable, une adresse privée n'est pas non plus la preuve que la destination est votre serveur de stockage, l'exception doit donc être aussi précise que la route elle-même.

Un contrat que vous pouvez transmettre

La conception finale doit se lire comme une courte liste : le trafic Internet général suit le tunnel, et ces préfixes locaux nommés conservent leur chemin via le routeur local. Notez les préfixes, le prochain saut et le suffixe DNS qui les accompagne, et gardez la liste assez courte pour que quelqu'un puisse la vérifier sans lire une table de routage.

Surveillez le chevauchement entre plages locales et distantes. Un VLAN de stockage qui partage un préfixe avec quelque chose derrière le VPN se résoudra vers la route la plus précise, et le comportement qui en résulte est déroutant d'une manière qui semble intermittente. Renuméroter un côté est généralement moins coûteux que de déboguer l'ambiguïté pour toujours.

Testez le contrat deux fois : une fois avec le tunnel monté et une fois avec le tunnel descendu. Si le chemin local ne fonctionne que dans un de ces états, l'exception n'est pas encore un contrat.