Les routes DHCP peuvent-elles faire sortir votre trafic du tunnel VPN ?

Le chiffrement commence à une frontière, et cette frontière est une décision de routage que le point de terminaison prend avant qu’aucun paquet ne soit encapsulé. Un réseau qui ne voit jamais vos clés peut quand même remettre à votre machine une route qu’il préfère à celle du tunnel lui-même. Deux défaillances se confondent ici : lire un paquet déjà dans le tunnel, et détourner un paquet qui n’y a jamais été placé.

La distinction compte parce que la seconde défaillance est plus facile à organiser et bien plus facile à manquer. Elle se manifeste par une requête sortie par la mauvaise interface alors que le client signalait encore une connexion saine.

Deux façons dont un réseau peut vous affecter

Un paquet qui atteint le tunnel a sa charge utile cachée à chaque saut qu’il traverse, et cette protection tient même quand le chemin vous surprend. Un paquet qui n’atteint jamais le tunnel est une requête ordinaire depuis votre adresse, envoyée là où la table de routage la désignait. La première défaillance exige un chiffrement cassé ou un pair compromis, tandis que la seconde n’exige qu’un message de configuration auquel votre machine a choisi de faire confiance. Cette asymétrie explique pourquoi la moitié routage mérite sa propre revue.

L’équipement sur le chemin n’a pas besoin de vos clés pour influencer le second cas. Il lui suffit que votre point de terminaison accepte une route, un résolveur ou une règle de politique qui en produise une.

expected:  app -> tunnel device -> encapsulation -> internet
observed:  app -> wlan0        -> plaintext     -> internet

D’où peut venir une route avant que le tunnel existe

DHCP distribue plus qu’un bail d’adresse. L’option de route statique sans classe peut porter des préfixes de destination et des sauts suivants, et RFC 3442 examine les conséquences de sécurité d’une adresse de routeur erronée : trafic détourné, un déni de service, ou un observateur posté sur le chemin. Un client qui accepte ces routes avant que le tunnel soit monté peut se retrouver avec un chemin préféré qui n’a rien à voir avec votre fournisseur.

Rien de tout cela ne rend l’injection de routes universelle. Le client doit accepter l’option, le préfixe doit couvrir le trafic qui vous importe, le saut suivant choisi doit être joignable, et la politique d’application doit autoriser le paquet à sortir par ce chemin. Retirez l’un de ces éléments et la même réponse devient inoffensive. C’est aussi pourquoi deux machines sur un même réseau peuvent se comporter différemment, puisqu’elles n’exécutent pas le même client, la même politique, ni même la même famille d’adresses.

IPv6 mérite sa propre passe, car les annonces de routeur portent une route par défaut via un code différent de celui de l’option DHCPv4. Un test qui n’inspecte que la table v4 ne l’a pas couvert.

Vérifiez le chemin que le noyau choisit réellement

Les recherches de route ont une réponse, alors interrogez-les au lieu de déduire d’un voyant d’état. Les commandes ci-dessous montrent la route et la source choisies pour une destination, ainsi que les règles qui peuvent supplanter la table principale. Exécutez-les pendant que vous êtes connecté et de nouveau après une reconnexion, car un renouvellement de bail peut changer la réponse.

ip route get 203.0.113.10
ip route show table all | grep -E '^(default|203\.0\.113)'
ip rule show
resolvectl query example.com

Lisez la sortie pour deux choses : l’interface nommée dans la route et l’adresse source choisie. Une route de tunnel nomme le périphérique tunnel, une route qui fuit nomme le physique, et la différence est visible sans rien déchiffrer. Si la réponse change entre deux exécutions, conservez les deux sorties et comparez les règles qui les ont produites.

Ne vous arrêtez pas à la route par défaut. Une exception d’application, un préfixe de tunnel divisé ou une seconde règle de politique peuvent porter une destination précise autour du tunnel alors que la route par défaut pointe encore dedans.

Décidez où l’application doit vivre

Trois conditions décident si l’application côté client suffit ou s’il vous faut quelque chose en dehors. Si le client installe et défend des routes pour chaque famille d’adresses que vous utilisez, un tunnel qui possède la route par défaut suffit généralement. Si la machine doit joindre des ressources locales tandis que tout le reste demeure dans le tunnel, ces exceptions doivent être énumérées et assumées plutôt que laissées à ce que le réseau d’accès a annoncé. Et si la plateforme peut lier le trafic à une interface par application, cette liaison est une garantie plus forte qu’une route que n’importe quoi peut supplanter.

Quel que soit votre choix, écrivez la décision là où vit la configuration. Une règle qui existe parce que quelqu’un l’a tapée pendant un incident ne survivra pas au prochain redémarrage, alors gardez les exceptions locales et de démarrage étroites et notez pourquoi chacune existe.

Réexécutez les commandes de recherche après chaque mise à jour du client et chaque changement de réseau, et comparez avec la dernière sortie enregistrée. La table de routage est la frontière d’application, alors traitez-la comme telle.