Sur le tableau de bord de votre système d'exploitation, l'interface du réseau privé virtuel (VPN) affiche une connexion chiffrée active. Les échanges cryptographiques se poursuivent normalement et le dispositif d'arrêt d'urgence (Kill Switch) signale une protection opérationnelle. Pourtant, sur un réseau Wi-Fi public, chaque requête HTTP, chaque résolution DNS et chaque donnée applicative transmise par votre navigateur s'échappe directement vers la passerelle d'un attaquant sous forme de trames Ethernet en clair.

Cette technique d'interception porte la référence de vulnérabilité CVE-2024-3661, baptisée TunnelVision. Découverte par les chercheurs de Leviathan Security Group, TunnelVision ne repose pas sur une faille cryptographique complexe ou une corruption de mémoire. Elle détourne une fonctionnalité administrative standardisée dans le protocole DHCP dès 2002 : l'option DHCP 121 (définie dans la RFC 3442, The Classless Static Route Option).

En injectant des entrées de routage statique lors de l'attribution initiale de l'adresse IP locale, un agresseur partageant le même réseau local (LAN) manipule la table de routage du noyau de votre système d'exploitation, déviant les paquets hors du tunnel VPN sans jamais interrompre la session chiffrée.

[Application Utilisateur / Navigateur Web]
                     │
                     ▼
       [Table de Routage du Noyau OS]
       ┌─────────────────────────────┐
       │ Évaluation de Préfixe Long  │
       └─────────────┬───────────────┘
                     │
       ┌─────────────┴───────────────────────────────┐
       │                                             │
[Route par Défaut du VPN]             [Routes Injectées par DHCP Option 121]
  Préfixe : 0.0.0.0/0 (Métrique 1)      Préfixe : 0.0.0.0/1 + 128.0.0.0/1
  Interface : tun0 (Chiffrée)           Interface : wlan0 (Physique en clair)
       │                                             │
       │ (Ignorée : préfixe plus court)              │ (Sélectionnée : préfixe plus long !)
       │                                             ▼
       ▼                                [Passerelle Malveillante / Écoute]
 [Serveur VPN Sécurisé]                   (Capture intégrale du trafic brut)

Les rouages de TunnelVision : la règle du préfixe le plus long

Pour comprendre la vulnérabilité des architectures VPN classiques face à TunnelVision, il faut examiner le mécanisme fondamental régissant l'acheminement des paquets IP : la règle de correspondance de préfixe le plus long (Longest Prefix Match - LPM).

Lorsqu'un système d'exploitation oriente un paquet réseau vers sa destination, il interroge sa table de routage. Si plusieurs règles s'appliquent à l'adresse IP visée, le noyau retient obligatoirement la route dont le masque de sous-réseau est le plus restrictif (la longueur de préfixe la plus élevée en nombre de bits), sans tenir compte des métriques de coût ni du caractère virtuel de l'interface.

Les clients VPN traditionnels capturent le trafic général en configurant une route par défaut (Default Route) :

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.8.0.1        0.0.0.0         UG    50     0        0 tun0

La route par défaut 0.0.0.0/0 englobe la totalité des adresses Internet, mais sa longueur de préfixe est de zéro bit (/0), ce qui lui confère la priorité de correspondance la plus faible du système.

Lorsqu'un appareil s'associe à un point d'accès Wi-Fi compromis et émet une requête DHCP Discover, le serveur DHCP malveillant contrôlé par l'attaquant répond en incluant l'option 121. La norme RFC 3442 autorise ce serveur à transmettre directement des routes statiques sans classe à la machine cliente.

L'agresseur transmet alors deux routes couvrant l'intégralité de l'espace d'adressage IPv4 :

  1. 0.0.0.0/1 via la passerelle locale de l'attaquant 192.168.1.1 (couvrant 0.0.0.0 à 127.255.255.255)
  2. 128.0.0.0/1 via la passerelle locale de l'attaquant 192.168.1.1 (couvrant 128.0.0.0 à 255.255.255.255)

La longueur de préfixe /1 étant supérieure à /0, le sous-système réseau du noyau achemine systématiquement les paquets vers l'interface physique non chiffrée wlan0. Le trafic s'échappe ainsi sur le réseau local en clair, offrant à l'attaquant une visibilité complète sur la navigation de l'utilisateur.

+--------------------------+-----------------+-------------------+-----------------------+
| Entrée de Routage        | Longueur Préfixe| Interface Sortie  | Priorité d'Aiguillage |
+--------------------------+-----------------+-------------------+-----------------------+
| Route par Défaut (0.0/0) | /0 (Générale)   | tun0 (Chiffrée)   | Supplantée par /1     |
| Option 121 (0.0.0.0/1)   | /1 (Spécifique) | wlan0 (En clair)  | Retenue (1re moitié)  |
| Option 121 (128.0.0.0/1) | /1 (Spécifique) | wlan0 (En clair)  | Retenue (2de moitié)  |
| Hôte Unique (/32)        | /32 (Exacte)    | wlan0 (En clair)  | Priorité absolue      |
+--------------------------+-----------------+-------------------+-----------------------+

Les faiblesses du Kill Switch classique face à l'Option 121

De nombreux utilisateurs supposent que la fonction Kill Switch de leur application VPN écarte ce type de risque. Pourtant, la plupart des mécanismes d'arrêt d'urgence ont été conçus pour réagir à une rupture de tunnel et non à un empoisonnement de la table de routage :

  • Surveillance passive de l'adaptateur virtuel : Le Kill Switch classique surveille l'état opérationnel du processus VPN et du pilote virtuel (tun0). Lors d'une attaque TunnelVision, la liaison chiffrée reste active et répond aux vérifications usuelles ; le coupe-circuit ne détecte donc aucune anomalie.
  • Règles d'exception pour le réseau local : Pour permettre l'accès aux imprimantes réseau ou aux serveurs de fichiers partagés (NAS), les pare-feu autorisent fréquemment les communications vers les adresses locales. L'option 121 déguisant l'accès à Internet sous forme de liaisons de passerelle locale, les règles de filtrage laissent passer les paquets non chiffrés.
  • Comportement par défaut des systèmes : Windows et plusieurs distributions Linux intègrent automatiquement les routes de la RFC 3442 issues du DHCP, exposant les machines à cette déviation sans configuration renforcée.

Mesures architecturales de protection

Pour neutraliser la menace TunnelVision, la défense doit s'appuyer sur une isolation réseau structurelle au niveau du système d'exploitation.

[Applications Clientes (Navigateur, Messagerie)]
                        │
                        ▼
     [Espace de Noms Réseau (Network Namespace)] <── (Cloisonnement Étanche)
                        │
                        ▼
             [Interface tun0 / wg0]
                        │ (Canal Chiffré WireGuard)
                        ▼
  [Espace Physique Hôte : wlan0] ──> [Seuls les Paquets Chiffrés Sortent]

1. Espaces de noms réseau (Network Namespaces)

Sous Linux, les espaces de noms réseau créent une barrière infranchissable. En confinant les applications de l'utilisateur dans un espace de noms distinct ne contenant que l'interface VPN virtuelle (wg0 ou tun0), les processus n'ont aucune visibilité sur l'adaptateur physique wlan0. Même si un serveur DHCP hostile pollue la table de routage hôte, les applications isolées ne peuvent utiliser ces routes locales.

2. Routage par règles (Policy-Based Routing) et marquage pare-feu

Les implémentations rigoureuses de WireGuard (wg-quick) exploitent le marquage de paquets (fwmark) :

# Redirection du trafic non marqué vers la table 51820
ip rule add not fwmark 51820 table 51820
ip rule add table main suppress_prefixlength 0

La directive suppress_prefixlength 0 empêche la table de routage générale de détourner le trafic via des routes plus spécifiques, forçant les paquets applicatifs à emprunter la table sécurisée du VPN.

3. Rejet de l'Option 121 dans la configuration DHCP

Sur les postes de travail conventionnels, il est conseillé de désactiver la prise en compte des routes sans classe dans le fichier de configuration du client DHCP (/etc/dhcp/dhclient.conf) en retirant rfc3442-classless-static-routes des requêtes émises.

4. Filtrage et cloisonnement au niveau du protocole RiceGuard

Le protocole RiceGuard de VPNRice applique un verrouillage strict au niveau du pilote de noyau. Grâce à des crochets de filtrage nftables/eBPF intégrés, RiceGuard interdit la sortie physique de tout paquet applicatif en clair ciblant des réseaux extérieurs : toute tentative de déviation induite par DHCP est rejetée immédiatement à la source.

Conseils de sécurité sur les réseaux publics

  • Examiner les tables de routage actives : Après connexion à un Wi-Fi public, lancez ip route show sous Linux ou route print sous Windows pour repérer d'éventuelles routes suspectes en /1.
  • Privilégier le partage de connexion cellulaire : Pour les communications sensibles, privilégiez le partage de connexion 4G/5G sécurisé par mot de passe plutôt que les réseaux ouverts où un faux serveur DHCP peut être déployé.
  • Contrôler l'adresse IP publique : Effectuez une vérification régulière de votre adresse de sortie via des services en ligne (curl https://ipinfo.io) pour vous assurer que les flux transitent effectivement par le serveur VPN distant.