Quel VPN permet vraiment le split tunneling sous Linux ? J’ai compris que « par application » et « par réseau » n’étaient pas la même chose

Mon ancien portable sous Windows avait une option que je n’avais jamais considérée comme particulièrement sophistiquée : split tunneling.

Je cochais une application.
Elle passait hors du VPN.
Le reste restait dedans.

Puis j’ai installé Linux sur cette machine et découvert que le même mot pouvait cacher des choses beaucoup plus différentes.

À 17 h 18, j’avais besoin d’envoyer une version au client avant 18 h. Le fichier se trouvait sur un NAS de mon réseau local. Mon terminal devait aussi rester connecté en SSH à un Raspberry Pi qui exécutait notre environnement de test.

Le VPN était actif.
Internet fonctionnait.
Le NAS, lui, avait disparu.
ssh 192.168.50.32

Timeout.
Je coupais le VPN : le NAS revenait et SSH répondait immédiatement.

Je le réactivais : Internet repartait dans le tunnel et mon réseau local redevenait inaccessible.

Ma recherche semblait évidente :
Quel VPN permet le split tunneling sous Linux ?
Une heure plus tard, j’avais compris que ce n’était pas encore la bonne question.

Le problème est devenu plus fréquent depuis que davantage de vieux PC passent sous Linux

J’avais justement recyclé ce portable après la fin du support standard de Windows 10, intervenue le 14 octobre 2025.

Je n’étais manifestement pas le seul à tenter ce genre de migration. Zorin indiquait en avril 2026 que Zorin OS 18 avait dépassé 3,3 millions de téléchargements en six mois, avec une partie importante de son positionnement tournée vers les utilisateurs venant de Windows.

Pour moi, le passage avait été étonnamment simple.
Navigateur : bon.
Docker : bon.
SSH : bon.

NAS : bon.

Puis j’avais réinstallé mon VPN et retrouvé un détail auquel je n’avais presque jamais pensé sous Windows : les fonctions affichées sous le même nom ne se comportent pas forcément de la même façon sous Linux.

Je ne voulais pas « enlever le terminal du VPN ».
Je voulais quelque chose de plus précis :
tout ce qui allait vers Internet devait continuer à utiliser le tunnel ;
tout ce qui allait vers 192.168.50.0/24, mon réseau local, devait rester local.

Cette différence paraît minuscule.
Elle a changé tout le choix du VPN.

Mon premier essai avait bien le split tunneling — mais pas celui dont j’avais besoin

J’ai commencé avec Proton.

Ce choix était parfaitement logique. Son application Linux actuelle propose bien le split tunneling dans son interface graphique sur Ubuntu, Fedora et Arch, avec une activation supplémentaire possible sous Debian. Elle permet désormais deux logiques simples : exclure certaines applications du VPN, ou au contraire n’inclure que certaines applications dans le tunnel.

Sur le papier, c’était exactement la fonction que je cherchais.
J’ai donc essayé d’exclure mon terminal.
SSH est revenu.
ssh 192.168.50.32

Connexion immédiate.
J’ai pu accéder au Raspberry Pi.
Pendant quelques secondes, j’ai cru que j’avais terminé.

Puis j’ai lancé depuis ce même terminal une commande qui devait récupérer un paquet externe.

Elle utilisait elle aussi la connexion directe.
C’était normal : j’avais exclu l’application, pas uniquement la destination locale.
Voilà le problème.
Mon terminal n’était pas une seule activité.

Il servait à SSH sur mon LAN, à pousser du code, à télécharger des dépendances, à vérifier des API et à accéder à des machines distantes.

L’exclure entièrement du VPN revenait à dire :
« Cette pièce de la maison n’utilise jamais la porte sécurisée. »
Moi, je voulais simplement dire :
« Pour aller dans le garage, ne fais pas le tour du quartier. »

Des utilisateurs Linux continuaient d’ailleurs à tomber sur cette différence en 2026. En juillet, un utilisateur de Proton expliquait avoir réussi sous Windows en excluant une adresse IP, puis découvrir que l’interface Linux lui proposait surtout de sélectionner des applications alors que son vrai besoin concernait des VLAN locaux.

Ce n’était donc pas un bug exotique de ma machine.
J’utilisais simplement la mauvaise granularité.

Sous Linux, « split tunneling » peut désigner trois problèmes différents

C’est là que j’ai arrêté de chercher uniquement la phrase supports split tunneling sur les pages produit.

Il faut d’abord savoir ce qu’on veut séparer.

Par application, Firefox passe dans le VPN, Spotify sort directement. Pour ce besoin, une interface graphique comme celle de Proton peut être très pratique.

Par destination, tout le système reste dans le VPN, sauf le NAS, un serveur local, un VLAN professionnel ou quelques adresses précises.

Par interface ou règle réseau, Ethernet reste par exemple réservé au LAN tandis qu’un autre trafic prend le tunnel.

Linux sait faire les trois. NetworkManager dispose de tables de routage, de métriques et de règles permettant de décider qu’une connexion ne devient pas la route par défaut ou que certains réseaux utilisent une table différente.

WireGuard documente lui aussi le routage par règles et l’utilisation de tables distinctes.

Mais c’est précisément le piège : le fait que Linux puisse le faire ne signifie pas que l’application VPN vous donne un bouton clair pour le faire.

Et je n’avais pas envie de transformer mon envoi client en exercice ip rule, fwmark et tables de routage.

J’ai vérifié le petit VPN que j’utilisais déjà ailleurs — et la limite était importante

À ce stade, j’ai regardé le service que j’utilisais déjà sur d’autres appareils parce que son fonctionnement est presque l’inverse de mes bricolages Linux habituels : choisir une situation, connecter, travailler.

Pour un Wi-Fi public ou un réseau qui gêne certains tunnels, cette simplicité m’avait déjà évité beaucoup de réglages.

Mais cette fois, j’avais besoin d’un vrai contrôle Linux.

Et il fallait accepter une réponse moins confortable : au moment où j’écris ces lignes, sa page de téléchargement publique liste iPhone, Android, macOS et Windows. Linux n’y figure pas.

Je préfère cette limite claire à une phrase ambiguë laissant croire qu’un produit possède une fonction Linux qu’il ne revendique pas officiellement.

Le service reste celui que je garde volontiers sur mes appareils de voyage pris en charge, justement parce que je veux y passer moins de temps dans les paramètres.

Mais sur ce PC Linux précis, cela ne résolvait pas mon problème.
Il fallait continuer.

Le deuxième VPN m’a enfin permis de séparer une destination plutôt qu’un programme

C’est Mullvad qui correspondait mieux à ce cas.

Son application Linux propose du split tunneling par application, y compris depuis la ligne de commande, mais surtout sa documentation avancée va plus loin et prévoit l’exclusion d’adresses IP ou de ports sous Linux.

Cette fois, le modèle correspondait à ma demande.
Je n’avais plus à décider si le terminal entier était « dedans » ou « dehors ».
Je pouvais traiter le LAN comme le LAN.

J’ai remis le trafic Internet derrière le VPN et exclu uniquement le sous-réseau local nécessaire.

Puis j’ai recommencé mes trois tests.
D’abord le NAS.
Il s’est ouvert.
Ensuite :

ssh 192.168.50.32
Le Raspberry Pi a répondu.
Enfin, depuis le même terminal, j’ai vérifié une destination Internet.
Elle utilisait toujours la route VPN.

C’était exactement ce que je cherchais depuis le début.
Pas une application exclue.
Une destination exclue.

J’ai copié l’archive depuis le NAS, lancé le test sur le Raspberry Pi, récupéré une dépendance distante et envoyé le fichier au client sans couper le tunnel.

17 h 46.
Upload terminé.
Le moment le plus satisfaisant n’a même pas été de voir le fichier arriver à 100 %.

C’était de constater que je pouvais passer d’une commande locale à une commande Internet dans le même terminal, sans réfléchir à la route utilisée.

C’est là que le mot « split tunneling » a cessé de m’aider

Avant cet incident, j’aurais comparé les VPN avec une ligne assez simple :
Split tunneling : oui / non.
Aujourd’hui, sous Linux, cette ligne ne me suffit plus.

Un fournisseur peut parfaitement proposer du split tunneling tout en ne couvrant que les applications.

Pour beaucoup de gens, c’est exactement ce qu’il faut.
Si votre objectif est :
Firefox dans le VPN ;
une application bancaire hors VPN ;

Steam hors du tunnel ;
alors Proton ou le split tunneling classique de Mullvad répondent proprement au problème.
Mais si votre objectif ressemble au mien —
Internet dans le tunnel ;

NAS local en direct ;
SSH local en direct ;
tout en conservant le même terminal et les mêmes outils —
la vraie question devient :

le client sait-il séparer des routes, des IP ou des sous-réseaux, et pas seulement des applications ?

Cette nuance explique aussi pourquoi certaines discussions Linux deviennent si confuses. Un utilisateur rapportait début 2026 qu’il avait configuré Firefox comme application incluse dans le tunnel, mais que son accès SSH continuait à se comporter de manière inattendue.

Le mot était correct.
Le niveau auquel la règle s’appliquait ne l’était pas.

Ce que je regarderai désormais avant de choisir

Si je voulais aujourd’hui uniquement faire passer Firefox dans un VPN sous Ubuntu, je ne construirais pas une architecture réseau compliquée. Une application Linux avec un mode « inclure uniquement cette application » suffit.

Si je devais faire exactement ce que je faisais ce soir-là — conserver un LAN, un NAS, un Raspberry Pi ou un VLAN directement accessible tout en gardant le reste du poste dans le tunnel — je regarderais d’abord la capacité à gérer des destinations et des routes.

Et si je veux simplement une connexion VPN facile sur mes appareils de voyage pris en charge, sans transformer chaque connexion en projet réseau, je garde volontiers le petit service que j’utilise déjà pour ce rôle.

Ce ne sont pas trois façons de répondre à la même question.
Ce sont trois problèmes différents que le terme split tunneling mélange trop facilement.
À 17 h 18, je cherchais un VPN affichant une case « split tunneling ».

À 17 h 46, mon NAS était accessible, SSH fonctionnait et mes commandes Internet restaient dans le VPN.

Sous Linux, c’est devenu mon critère : je ne demande plus si un VPN sait diviser le trafic ; je vérifie exactement à quel endroit il sait le diviser.