Tunnel divisé par application ou par destination : lequel choisir

Le tunnel divisé par application et par destination ne sont pas deux réglages pour la même tâche. L'un demande quel processus envoie un paquet ; l'autre demande où va ce paquet. Une règle conçue pour la première question échoue silencieusement quand le trafic vient d'un processus auxiliaire, et une règle conçue pour la seconde échoue quand un nom d'hôte se résout en une adresse que vous n'avez jamais répertoriée. Choisissez l'objet qui correspond à l'exigence, puis prouvez-le avec deux paquets de test : un qui doit utiliser le tunnel et un qui ne doit pas.

Les deux règles agissent à des couches différentes

Une règle d'application s'applique au-dessus de la couche réseau, contre l'identité que le système d'exploitation attribue à l'émetteur. Sous Android, c'est l'UID derrière un paquet, et le service VPN décide par UID si le trafic entre dans le tunnel. Rien n'est demandé sur la destination, donc l'application sélectionnée peut tout atteindre et aucune autre application ne peut atteindre le réseau interne.

Une règle de destination s'applique au paquet lui-même. L'interface du tunnel possède un ensemble de préfixes, la table de routage y envoie le trafic correspondant, et le processus émetteur n'a aucune importance. C'est pourquoi une règle de destination couvre un service, une imprimante ou un traitement par lots que personne n'a pensé à répertorier, et pourquoi elle ne peut pas s'exprimer comme ce programme précis sur une plateforme dont le client ne regarde jamais le processus.

Les règles d'application conviennent aux clients mobiles et aux agents gérés

Android expose le choix directement : VpnService.Builder.addAllowedApplication() et addDisallowedApplication() prennent des noms de paquets et appliquent la décision par UID, comme décrit dans le guide du développeur VPN d'Android. iOS dispose d'un équivalent via des règles VPN par application liées aux identifiants de bundle, généralement fournies par un profil MDM plutôt que saisies à la main.

Les clients de bureau sont le point faible. La plupart des clients VPN Windows et macOS routent par destination et n'offrent aucun sélecteur par processus, car le pilote du tunnel voit des paquets, pas des processus. Si votre plan dépend du tunnel pour une seule application sur un ordinateur portable, vérifiez les capacités réelles du client avant de concevoir autour ; vous choisissez peut-être entre une liste de destinations et une seconde machine.

Un corollaire que les gens oublient : vous ne pouvez pas imiter une règle d'application avec des routes sur ces plateformes. Ajouter une route d'hôte pour le serveur de l'application tunnelise le trafic de tout le monde vers ce serveur, y compris le navigateur et le programme de mise à jour.

Les règles de destination conviennent aux listes de sous-réseaux et à la joignabilité des sites

WireGuard rend le modèle explicite. AllowedIPs est un routage par clé cryptographique : un paquet interne dont la destination tombe dans la liste d'un pair est chiffré vers ce pair, et tout le reste sort en clair par le chemin normal. Il n'y a aucun processus à nommer et aucune ambiguïté sur ce qui est inclus.

OpenVPN arrive au même point via la table de routage poussée. route-nopull empêche le serveur d'imposer des routes, après quoi une route 10.20.0.0 255.255.0.0 vpn_gateway côté client couvre exactement le préfixe du bureau. IPv6 est une instruction séparée dans chacun de ces clients, et l'oublier est la façon la plus courante de fuir autour d'un split IPv4 qui semble correct.

Un nom d'hôte n'est pas une route. Si le profil propose un champ de domaine, traitez-le comme un nom que le client résout une fois, non comme une plage d'adresses permanente ; les réseaux de diffusion de contenu et les répartiteurs de charge donneront d'autres adresses demain.

Là où les deux modèles cèdent : auxiliaires, services partagés, résolveurs

Les processus auxiliaires cassent les règles d'application d'une manière qui ressemble à une panne du serveur. Le programme de mise à jour d'un navigateur, un rapporteur de plantage, un service de synchronisation exécuté en SYSTEM et un WebView intégré à un autre paquet sont autant d'identités distinctes, donc tunneliser le navigateur peut laisser la requête réelle hors du tunnel. L'inverse est tout aussi déroutant : une application exclue qui appelle une bibliothèque partagée à l'intérieur d'un processus tunnelisé voit toujours son trafic passer par le tunnel.

Les règles de destination cassent sur les services partagés et sur les noms. Les partages de fichiers, les imprimantes, le DNS interne et le serveur de licences vivent à des adresses, donc un tunnel pour une seule application donne accès au navigateur tandis que le lecteur mappé reste mort. Cette différence de couverture n'est pas un défaut de l'un ou l'autre modèle, mais c'est la raison pour laquelle un tunnel pour une seule application produit si souvent que le VPN est actif et le partage a disparu.

Les résolveurs traversent les deux. Si le client définit des serveurs DNS internes mais que le système d'exploitation utilise DNS over HTTPS vers un résolveur public, la réponse vient de l'extérieur du tunnel et la règle de destination peut ne jamais correspondre. Vérifiez quel résolveur a réellement répondu avant de conclure que la règle est fausse, et confirmez côté client s'il a installé le résolveur du tunnel. Un split qui laisse le DNS hors du tunnel semble parfait dans la table de routage et échoue quand même sur chaque nom interne.

Marche à suivre : choisir, appliquer, vérifier

Partez de l'exigence, pas du menu. Si l'objectif est seule cette application peut utiliser le tunnel, il vous faut des règles d'application et une plateforme qui les prend en charge. Si l'objectif est ces réseaux sont joignables via le tunnel, il vous faut des préfixes. Si la réponse est les deux, implémentez-les comme deux contrôles distincts et notez lequel possède quelle défaillance.

Appliquez la forme la plus étroite que vous puissiez exprimer, puis vérifiez en interrogeant la table de routage plutôt que l'icône d'état du client :

ip route get 10.20.30.40
ip -6 route get 2001:db8:10::40
wg show wg0 allowed-ips
Get-NetRoute -DestinationPrefix 10.20.0.0/16
Find-NetRoute -RemoteIPAddress 10.20.30.40

Les deux premières lignes nomment l'interface qu'utiliserait une destination réelle ; wg show affiche la liste de préfixes configurée ; sous Windows, Find-NetRoute répond à la même question que la pile répondra à l'envoi du paquet. Si l'interface est le tunnel, la règle a correspondu.

Testez ensuite un second paquet qui devrait être exclu, depuis une autre application, vers la même destination. Notez dans le ticket la version du client, le type de règle, la liste de préfixes ou de paquets et les deux résultats observés. C'est cette paire de résultats qui dit à l'ingénieur suivant si la politique est mal configurée ou si le trafic n'y a jamais appartenu.