Pourquoi le DNS du routeur contourne-t-il le tunnel VPN ?

Les requêtes des clients suivent le tunnel, tandis que les requêtes propres du routeur sortent par le WAN, et la règle de pare-feu qui régit l’une n’a aucun effet sur l’autre. La raison n’est pas un défaut : une requête transférée et une requête que le routeur génère lui-même sont deux flux distincts, et chacun est comparé à une partie différente de la configuration. Ne capturer que la moitié cliente donne une réponse assurée sur un chemin que la seconde moitié n’utilise jamais. Le remède consiste à diriger délibérément le résolveur du routeur, puis à tester les deux chemins séparément.

À quel flux la capture de paquets appartient réellement

Une requête implique deux échanges. Un client du LAN envoie une requête au résolveur du routeur, et celle-ci arrive comme trafic transféré sur l’interface LAN, si bien qu’une route de politique ou une règle NAT écrite pour les paquets transférés peut la reconnaître. Le routeur répond ensuite depuis le cache ou, en cas d’absence, ouvre sa propre requête vers un serveur amont.

Cette seconde requête a le routeur pour source et pour destination propre, et la plateforme choisit son chemin dans un autre bloc de configuration. Les deux échanges portent le même nom, et aucun n’est une copie de l’autre. Une capture prise côté LAN prouve donc où est allé le paquet du client et ne dit rien du paquet sortant.

La vérification pratique consiste à observer les deux côtés en même temps. Sur le routeur, listez la socket du résolveur, interrogez-la localement et capturez l’interface WAN :

sockstat -4 -l | grep :53
dig +short @127.0.0.1 example.com
tcpdump -ni igb0 udp port 53

Si la liste des sockets montre un écouteur lié à l’adresse de loopback ou du LAN, le routeur répond localement au lieu de transférer vers un autre hôte. La capture montre alors si la requête amont qui en résulte sort par l’interface du tunnel ou par le WAN, et c’est la réponse que la règle de route de politique n’aurait jamais donnée.

Pourquoi la route de politique ne voit jamais la seconde requête

Les règles de pare-feu s’écrivent pour une interface, une source, une destination et un port, et elles sont évaluées pour les paquets qui traversent la machine. Une requête que le routeur génère ne traverse rien, car un processus local la remet directement à la table de routage. Routage par politique et NAT ne s’appliquent donc qu’au chemin transféré, et c’est pourquoi un jeu de règles peut sembler complet tout en laissant le DNS du routeur hors du tunnel.

La distinction survit à chaque réécriture du micrologiciel parce qu’elle découle du chemin du paquet et non d’une fonction. Tout ce que la machine génère pour elle-même, qu’il s’agisse des requêtes du résolveur, de la synchronisation de l’heure, des vérifications de mise à jour ou de l’accès aux miroirs de paquets, est d’origine locale et tombe dans le même angle mort. C’est aussi pourquoi un test effectué depuis un ordinateur portable ne prouve rien sur le routeur.

Où le résolveur de pfSense décide de son propre chemin amont

pfSense rend la séparation visible. Le trafic des clients peut être routé par politique via une passerelle VPN tandis que le trafic propre du pare-feu suit le réglage sortant du résolveur plutôt que les règles du LAN. Dans l’interface web, ce réglage se trouve sous Services > DNS Resolver > Outgoing Network Interfaces, et sa valeur est la liste des interfaces que le résolveur peut utiliser pour les requêtes amont.

Nommer là l’interface du tunnel, et seulement celle-là, est ce qui fait suivre le tunnel aux requêtes propres du routeur. Laissé par défaut, le résolveur choisit une sortie dans la table de routage, qui sur un hôte à double WAN ou VPN est souvent le WAN.

D’autres micrologiciels exposent la même décision sous une autre étiquette : une liste de serveurs amont liée à une adresse source, un mode de simple transfert ou une politique de routes documentée. Le réglage à chercher est toujours celui qui choisit une sortie ou une source pour les requêtes générées localement. La référence de configuration du résolveur documente cette option pour pfSense et mérite d’être lue avant le changement.

Choisissez le comportement en cas de panne avant le réglage

Quand le tunnel tombe, deux comportements sont défendables : arrêter les requêtes amont pour que rien ne fuie, ou basculer vers un résolveur approuvé sur un chemin connu. Les deux sont des politiques, et aucun n’est ce que l’on obtient par défaut. Décidez lequel le réseau a besoin avant de toucher à la liste des interfaces.

La fermeture en cas de panne est plus facile à défendre, mais elle transforme une coupure de tunnel en coupure de résolution de noms pour chaque appareil derrière le routeur. Le repli garde le bureau utilisable, au prix d’un échange amont hors du tunnel qui doit être acceptable volontairement et non par accident. Écrivez le choix, car la prochaine personne qui verra une adresse de résolveur hors du VPN le lira comme une fuite, sauf si une note dit le contraire. Cette note est ce qui sépare un repli documenté d’une constatation inexpliquée dans la revue du prochain trimestre.

Deux cas compliquent la décision. Les noms privés peuvent nécessiter un résolveur interne que le tunnel atteint, et un navigateur ou une application doté de son propre DNS chiffré peut contourner entièrement le routeur, si bien que le résolveur configuré n’est pas toujours celui qu’une application donnée utilise.

Testez les deux chemins et gardez les résultats séparés

Un test DNS dans le navigateur répond à une question étroite : quels résolveurs ce navigateur a-t-il utilisés, dans les conditions de ce test. Il n’inventorie pas les appareils du réseau et ne peut pas voir une requête que le routeur a générée pour lui-même. Traitez sa sortie comme un point de données et non comme un audit.

Depuis un client du LAN, demandez au routeur un nom public, puis un nom privé que seule votre zone interne devrait résoudre. Un échec sur la seule seconde requête indique un transfert de noms et non le tunnel :

dig @192.168.1.1 example.com
dig @192.168.1.1 intranet.example.lan

Faites ensuite tomber le tunnel et répétez les deux requêtes. Des réponses refusées signifient que le résolveur se ferme en cas de panne ; une réponse réussie indique un résolveur de repli et le chemin qu’il a utilisé. Comparez cela à la note que vous avez écrite et à une capture sur l’interface WAN prise dans la même minute.

Gardez les observations séparées dans le journal : l’échange du client avec le routeur, l’échange du routeur avec l’amont et la configuration qui a décidé du second. Un changement de routage ultérieur sollicitera ce second échange sans prévenir. Une réponse qui arrive d’ailleurs que du point de terminaison VPN n’est pas une fuite en soi ; elle ne le devient que lorsque la configuration a choisi ce chemin par accident.