VPN par application ou split tunneling ? Ce qu’une route Mac peut décider

Deux applications ouvrent des connexions vers le même serveur de bureau, et une seule d’entre elles devrait utiliser le tunnel. Une route ne peut pas exprimer ce souhait, car les tables de routage sont indexées sur des destinations et n’ont aucune notion du processus qui a ouvert la socket. Ce que les gens demandent et ce dont ils ont besoin sont souvent deux choses différentes. Séparez les deux avant de modifier la moindre configuration.

Le sélecteur est une destination, jamais un processus

Chaque décision de routage part d’une adresse de destination et aboutit à une interface. Le noyau ne demande jamais quel binaire a envoyé le paquet, et sur macOS pf ne route pas non plus par processus, si bien qu’une règle de pare-feu ne peut pas placer une application sur un autre chemin. C’est pourquoi le même serveur, atteint par un navigateur et par un outil de reporting, emprunte un seul chemin pour les deux. La séparation au niveau applicatif doit donc venir d’autre chose que d’une route : un greffon VPN qui possède la socket, un proxy qui prend la connexion au nom de l’application, ou une pile réseau distincte. Aucune de ces solutions n’est une modification de routage.

Deux applications qui parlent à une même adresse constituent le test le plus net d’une conception. Si la réponse ne peut pas différer entre elles, la conception est fondée sur la destination, quel que soit son nom.

Ce qu’un split tunneling ordinaire apporte réellement

Un split tunnel installe des routes pour les préfixes privés et laisse tout le reste sur le chemin physique. C’est généralement ce que la demande signifie : atteindre le serveur du bureau par le tunnel, garder la navigation publique en direct. C’est simple, tous les clients courants le prennent en charge, et il est appliqué par le même mécanisme que n’importe quelle autre route. Vérifiez la destination précise avec route -n get plutôt que de lire la route par défaut, car un split tunnel laisse souvent celle-ci intacte.

Modifier la route par défaut à la main n’est une conversion vers rien du tout. Cela se heurte à la restauration des routes du client et, dans les clients qui installent une politique de protection, peut laisser la machine dans un état que ni vous ni le client n’attendez. Configurez plutôt le split tunnel dans les réglages pris en charge du client.

Ce qu’un VPN par application sur macOS exige

Un vrai VPN par application sur macOS est une fonctionnalité Network Extension pilotée par un profil de configuration. Une charge utile de gestion associe des applications choisies à une configuration VPN, et le système achemine ensuite le trafic de ces applications en conséquence. C’est un déploiement géré, ce qui implique un MDM, un profil signé et un administrateur qui possède les deux.

Installer le client à la main ne crée pas cette association, et le panneau de réglages ordinaire ne rend pas les applications sélectionnables individuellement. Un fournisseur peut exposer ses propres règles d’application, et celles-ci suivent sa documentation plutôt qu’une règle générale.

Trois voies vers une séparation par application sans MDM

Là où la gestion n’est pas disponible, un proxy est la réponse pratique. Réglez la configuration proxy propre à l’application, ou utilisez un fichier PAC qui sélectionne par destination et par protocole pour cette application seule.

Un proxy local termine la connexion et la réémet à travers le tunnel, si bien que l’application n’a jamais besoin d’une route. La deuxième option est une pile réseau distincte : une machine virtuelle ou un conteneur doté de sa propre route par défaut, que l’application atteint par une adresse locale. La troisième consiste à accepter le routage par destination et à abandonner l’exigence, ce qui est honnête lorsque les deux applications peuvent utiliser le tunnel. Les trois sont testables, et aucune ne prétend qu’une route connaît les processus.

Rédigez la demande pour que la réponse soit sans ambiguïté

Décrivez le flux de travail plutôt que le mécanisme : quelle application a besoin de quel service, si une autre application doit être tenue à l’écart de ce même service, et ce qui doit se passer pendant que le tunnel est indisponible. Ces trois réponses choisissent la conception. Elles indiquent aussi à l’administrateur si la demande est une modification de routage ou un projet de déploiement.

Incluez explicitement le cas de l’application exclue. Un client qui arrête une application lorsque son chemin protégé est indisponible se comporte différemment de celui qui la laisse retomber sur l’interface physique, et les utilisateurs remarquent immédiatement cette différence. Nommez l’attente dans le ticket. Vérifiez ensuite sur la machine réelle, car le même produit se comporte souvent différemment sur macOS et sur Windows, et sa documentation macOS est la seule source fiable sur ce que font ses réglages.