Table de routage VPN sous macOS : redirection du trafic, routes par défaut et priorités

Un VPN ne “protège” pas le trafic par magie : il modifie la topologie réseau locale en reconfigurant le routage du système. Sous macOS, ce basculement repose principalement sur la table de routage maintenue par le kernel, qui détermine à tout instant quelle interface doit être utilisée pour atteindre une destination donnée.

Lorsqu’un tunnel VPN est activé, le système introduit généralement une interface virtuelle (souvent utunX) puis modifie les routes afin que tout ou partie du trafic soit redirigé vers cette interface. Ce comportement peut être observé et vérifié à l’aide des outils système standard.

1. Rappels : rôle de la table de routage

La table de routage associe des préfixes (destinations réseau) à des next hops (passerelles) et à une interface de sortie. Lorsqu’un paquet doit être envoyé, le kernel applique un principe de longest prefix match : la route la plus spécifique (masque le plus long) est choisie en priorité.

Dans un scénario simple sans VPN :

• les destinations locales (LAN) sont routées via l’interface physique (ex : en0)
• la destination “par défaut” (default) est routée vers le routeur local

2. Observation de la table de routage sous macOS

La table de routage peut être affichée avec :

netstat -rn

Sans VPN, la route par défaut ressemble souvent à :

default 192.168.1.1 en0

Après activation d’un VPN, cette route est fréquemment remplacée par une route pointant vers l’interface virtuelle :

default 10.0.0.1 utun0

Dans ce modèle, le VPN devient la sortie par défaut vers Internet.

3. Route par défaut : mécanisme et implications

La route default agit comme un fallback : elle est utilisée lorsque aucune route plus spécifique ne correspond à la destination.

Lorsqu’un VPN “prend la main” sur le trafic, il impose :

• une nouvelle route par défaut vers l’interface utun
• des routes spécifiques pour préserver certaines destinations locales (ex : LAN)
• parfois un split tunnel (uniquement certains préfixes routés via le VPN)

Le changement de route par défaut est l’opération la plus visible et la plus déterminante : il transforme immédiatement la topologie réseau du poste.

4. Full tunnel vs split tunnel : différence de routage

Deux modes principaux existent au niveau du routage :

4.1 Full tunnel

Tout le trafic passe par le tunnel, ce qui correspond généralement à :

• route par défaut via utunX
• routes locales (ex : 192.168.0.0/16) conservées via en0 pour accéder au LAN

Exemple conceptuel :

default 10.0.0.1 utun0
192.168.1/24 link#... en0

4.2 Split tunnel

Seuls certains préfixes sont routés via le VPN. Dans ce cas, la route par défaut reste sur l’interface physique, et des routes spécifiques sont ajoutées vers utun.

Exemple conceptuel :

default 192.168.1.1 en0
203.0.113.0/24 10.0.0.1 utun0
198.51.100.0/24 10.0.0.1 utun0

Le split tunneling repose donc sur l’ajout de routes plus spécifiques que la route par défaut.

5. Routes, métriques et priorités

Les décisions de routage ne dépendent pas uniquement du préfixe. macOS maintient également des attributs influençant la sélection de routes en cas d’égalité ou de chemins multiples.

Sur certains systèmes, des notions de métriques ou de priorité entrent en jeu, notamment dans des scénarios multi-homing (Wi-Fi + Ethernet) ou lors de l’activation d’un tunnel qui coexiste avec d’autres interfaces virtuelles.

Pour vérifier la route utilisée pour une destination spécifique :

route -n get 8.8.8.8

Exemple de sortie attendue (conceptuelle) :

route to: 8.8.8.8
destination: default
gateway: 10.0.0.1
interface: utun0

Cette commande permet de valider empiriquement l’interface réellement utilisée pour une destination donnée.

6. Rôle des routes locales et de l’accès au LAN

Un point critique dans la configuration de routage VPN est la gestion du LAN. Beaucoup de configurations VPN cherchent à :

• faire passer le trafic Internet via le VPN
• conserver l’accès aux ressources locales (imprimantes, NAS, routeur)

Pour cela, des routes spécifiques pointant vers l’interface physique restent en place pour les préfixes privés (RFC1918) :

• 10.0.0.0/8
• 172.16.0.0/12
• 192.168.0.0/16

Une implémentation peut volontairement modifier ce comportement, mais techniquement, c’est la présence ou l’absence de routes spécifiques qui détermine l’accès au LAN.

7. Interaction entre routage et DNS

Le routage du trafic IP et la résolution DNS sont deux mécanismes distincts. Un VPN peut rediriger tout le trafic IP tout en laissant les requêtes DNS sortir via l’interface physique si la configuration DNS n’est pas modifiée.

Pour analyser le DNS sous macOS :

scutil --dns

Pour vérifier l’interface de sortie vers un résolveur DNS :

route -n get <IP_DU_RESOLVEUR>

Cette distinction est essentielle : un tunnel correctement routé n’implique pas automatiquement une résolution DNS cohérente avec le tunnel.

8. Cas particulier : IPv6 et double table de routage

IPv6 dispose d’un routage indépendant d’IPv4. Un VPN peut rediriger IPv4 via utun tout en laissant IPv6 sortir via l’interface physique si le tunnel ne gère pas IPv6 ou si le routage IPv6 n’est pas modifié.

La table IPv6 peut être observée avec :

netstat -rn -f inet6

Un diagnostic complet du routage VPN exige donc d’observer :

• la table IPv4
• la table IPv6
• la route réellement utilisée pour des destinations spécifiques

9. Vérification empirique : cohérence du routage avec tcpdump

Le routage observé dans netstat doit idéalement être corrélé à une observation du trafic.

Sur l’interface tunnel :

sudo tcpdump -i utun0

Sur l’interface physique :

sudo tcpdump -i en0

En configuration full tunnel, on doit observer :

• sur utun : paquets IP “internes” (flux logiques)
• sur en0 : flux chiffré vers l’endpoint du tunnel

La cohérence entre table de routage et observation du trafic est l’un des meilleurs moyens de valider qu’un tunnel est effectivement actif et utilisé.

10. Le routage comme mécanisme central du VPN

Sous macOS, un tunnel VPN fonctionne parce que :

• une interface virtuelle est créée (utun)
• la table de routage est modifiée
• le trafic est redirigé vers le tunnel

Sans cette reconfiguration de routage, le tunnel ne serait qu’un canal chiffré inactif du point de vue des applications.

La compréhension de la table de routage est donc indispensable pour analyser un VPN sous macOS, diagnostiquer une fuite de trafic (IPv6, DNS) ou comprendre les limites d’une configuration gratuite soumise à des contraintes opérationnelles.