VPN d’entreprise : split tunnel, pièges et bonnes pratiques

On voit souvent le VPN d’entreprise comme un truc simple. Tu te connectes, ça chiffre, et voilà, tu es « dans le réseau ». En vrai, ça se complique vite. Surtout dès qu’on parle de split tunneling. Et encore plus quand on doit jongler entre sécurité, performance, applicatifs SaaS, télétravail, et des utilisateurs qui… ben, veulent juste que « ça marche ».

Dans cet article, on va poser les bases, puis rentrer dans le dur : split tunnel ou full tunnel, ce que ça change concrètement, les pièges qui reviennent tout le temps, et les bonnes pratiques que tu peux appliquer dans un contexte d’entreprise, ou en labo BTS SIO option SISR.

Petite note au passage : si tu veux des labs concrets sur routage, firewall, DNS, proxy, logs, et tout ce qui tourne autour, garde un onglet ouvert sur BTS SIO2 SISR Tech Lab (https://sio1blog.blogspot.com/). C’est typiquement le genre de sujets qui se travaille mieux en manip qu’en théorie.

VPN d’entreprise : de quoi on parle exactement

Un VPN d’entreprise, ce n’est pas juste « un tunnel chiffré ». C’est un ensemble :

• un client (ou un OS qui fait client)
• un serveur ou concentrateur (VPN gateway, firewall, appliance, cloud VPN)
• une authentification (AD, LDAP, SSO, certificats, MFA)
• des politiques de routage (qui passe dans le tunnel, qui n’y passe pas)
• des contrôles (filtrage, inspection, posture device, logs)

Et la grande question, celle qui impacte presque tout derrière :

Est ce que le VPN doit transporter tout le trafic réseau du poste, ou seulement une partie.

C’est là qu’arrive le split tunnel.

Split tunnel : définition simple, et pourquoi ça existe

Le split tunneling consiste à n’envoyer dans le VPN que certains flux. Typiquement, les flux destinés aux réseaux internes de l’entreprise, genre 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, ou des préfixes plus précis.

Tout le reste, par exemple YouTube, Teams perso, Spotify, mises à jour Windows, navigation web, part directement vers Internet via la connexion locale de l’utilisateur.

Pourquoi on fait ça ?

• Performance : éviter d’aspirer tout Internet dans le tunnel
• Capacité : réduire la charge sur le concentrateur VPN et la bande passante siège
• Latence : accès SaaS plus rapide en direct
• Coût : moins de transit, moins de dimensionnement
• Résilience : si le VPN est lent, l’utilisateur garde Internet

Mais évidemment, ça ouvre des angles morts.

Full tunnel : l’autre approche, plus « contrôle total »

En full tunnel, le poste envoie tout son trafic vers le VPN. Donc même aller sur un site public passe par :

poste → tunnel VPN → sortie Internet de l’entreprise → site web

Avantages :

• contrôle centralisé (proxy, filtrage URL, inspection TLS si vous faites ça)
• journalisation plus simple
• réduction des risques liés au réseau local de l’utilisateur
• politiques cohérentes : un poste est « comme au bureau »

Inconvénients :

• le VPN devient un goulot
• le siège devient un point de sortie unique
• latence parfois horrible sur du SaaS mondial
• plus de risques de saturation, donc tickets support, donc nuits blanches

Split tunnel : les pièges classiques (ceux qui reviennent en boucle)

On peut faire du split tunnel proprement. Mais en entreprise, les problèmes viennent souvent de détails. Et les détails réseau, c’est rarement « juste un détail ».

1. Le DNS qui part dans tous les sens

Le cas le plus courant.

Tu es en split tunnel, tu veux accéder à intranet.entreprise.local ou app.corp.example. Si le poste utilise le DNS du réseau local de l’utilisateur, ça ne résout pas. Ou pire, ça résout vers autre chose.

Deux scénarios moches :

• fuite DNS : les requêtes DNS internes partent vers un résolveur public
• résolution incohérente : un FQDN interne renvoie une IP interne, mais le routage ne suit pas, ou l’inverse

Bon réflexe : décider clairement si le DNS « corp » doit être forcé via le tunnel, et comment tu gères les suffixes DNS.

Quelques patterns :

• split tunnel, mais DNS d’entreprise imposé quand le VPN est up
• split tunnel avec DNS split horizon ou politiques par suffixe (selon solutions)
• full tunnel pour simplifier, si tu as un parc et une infra qui tiennent

2. Les applications modernes qui utilisent des IP qui bougent

Tu définis des routes vers 10.10.0.0/16 et c’est bon. Sauf que l’app métier est désormais derrière un service cloud privé, ou un SaaS avec des IP qui changent. Ou bien elle est publiée via un WAF, un CDN, et tu ne maîtrises plus vraiment les préfixes.

Résultat : tu split tunnel une partie, l’autre part en direct, l’app ne marche plus. Ou marche un jour sur deux.

Bon réflexe : préférer des approches basées sur FQDN quand la techno le permet, ou passer par un proxy ou un ZTNA si le VPN classique devient ingérable.

3. Le poste devient un pont involontaire entre deux réseaux

C’est le risque « historique » du split tunnel.

Ton poste est connecté :

• d’un côté au LAN perso ou au Wi-Fi d’un hôtel
• de l’autre au réseau interne via VPN

Si tu ne contrôles pas, tu peux te retrouver avec un poste qui sert de passerelle, volontairement ou non. Et là, tu ouvres des chemins que tu ne voulais pas.

Bon réflexe : activer des protections côté client :

• blocage du forwarding IP
• pare-feu local verrouillé
• politiques de segmentation et de filtrage strict sur le client VPN

4. L’utilisateur contourne la sécurité sans s’en rendre compte

En split tunnel, l’utilisateur accède à Internet directement. Donc :

• pas de filtrage web corporate
• pas de DLP réseau centralisé
• parfois pas d’inspection
• logs éclatés

Si ton modèle de sécurité repose sur « tout passe par le siège », le split tunnel casse ce modèle.

Bon réflexe : déplacer une partie des contrôles sur le poste :

• EDR
• DNS filtering agent
• proxy agent
• politique navigateur
• MDM

5. Accès aux ressources internes trop large

Côté VPN, on voit encore des configs où « quand tu es connecté, tu vois tout le 10.0.0.0/8 ». C’est confortable. Mais c’est aussi une autoroute latérale pour un poste compromis.

Bon réflexe : appliquer le principe du moindre privilège :

• routes uniquement vers les sous-réseaux nécessaires
• ACL côté firewall sur l’interface VPN
• segmentation par groupes (RH, IT, étudiants, prestataires)
• bastion pour l’administration

Bonnes pratiques : ce qui marche vraiment en entreprise

Ici, on va être concret. Pas parfait sur le papier, mais réaliste.

1. Choisir split ou full tunnel selon l’usage, pas selon l’habitude

Quelques repères simples :

• full tunnel si tu dois appliquer des politiques strictes, si le parc est homogène, si tu veux centraliser les logs, ou si le risque « réseau local hostile » est critique
• split tunnel si tu as beaucoup de télétravail, des usages SaaS lourds, et une infra VPN qui ne doit pas devenir ton point de rupture

Et oui, tu peux mixer : full tunnel pour certains profils, split pour d’autres. C’est souvent la meilleure réponse.

2. Documenter la politique DNS noir sur blanc

Tu veux éviter les tickets « intranet ne marche pas » à 8 h 12.

Checklist DNS :

• quels DNS sont poussés par le VPN
• quels suffixes DNS sont ajoutés
• est ce que le DoH est autorisé ou non
• comment tu gères les noms internes versus publics
• comment tu journalises les requêtes utiles (sans tomber dans le flicage inutile)

Astuce labo : en environnement BTS, tu peux simuler ça facilement avec un Bind ou un Windows DNS, puis observer les requêtes et réponses, et les routes. Ça fait un super TP à publier ensuite sur BTS SIO2 SISR Tech Lab si tu veux partager ton retour.

3. Ne pas faire confiance au réseau local de l’utilisateur

Même si tu es en split tunnel, considère le réseau local comme non fiable.

Minimum recommandé :

• pare-feu poste activé, règles entrantes strictes
• désactivation du partage inutile
• mise à jour OS et navigateur
• MFA pour l’accès VPN
• certificats machine si possible

4. Segmenter et filtrer côté serveur VPN

Le tunnel ne doit pas être « un câble magique dans le LAN ».

Bonnes pratiques :

• interface VPN dans une zone dédiée (DMZ VPN)
• règles firewall précises vers les VLAN internes
• journalisation des flux VPN vers ressources critiques
• accès admin uniquement via bastion, pas en direct depuis le VPN utilisateur

Et surtout : séparer VPN utilisateurs et VPN administrateurs. Vraiment.

5. Prévoir le cas des mises à jour et du trafic lourd

Un grand classique : full tunnel + mises à jour Windows + Teams + OneDrive = VPN KO.

Solutions :

• split tunnel pour certains flux Microsoft 365 (selon recommandations et contexte)
• caches et points de distribution (WSUS, Delivery Optimization, caches proxy)
• QoS sur le concentrateur, ou limitation par profil
• sortie Internet locale contrôlée via agent

L’idée, c’est d’éviter que le VPN devienne une paille dans laquelle tout le monde boit en même temps.

6. Logs, supervision, et dépannage : penser « opérationnel »

Un VPN, c’est aussi des incidents. Donc il faut pouvoir répondre :

• qui s’est connecté
• quand
• depuis quelle IP
• quel groupe, quelle politique
• quelles routes appliquées
• quels échecs d’authentification
• quels volumes

Si tu n’as pas ça, tu fais du support à l’aveugle.

Bon minimum :

• logs centralisés (syslog, SIEM, au moins un collecteur)
• tableau de bord des connexions actives
• alertes sur échecs MFA, tentatives bruteforce, anomalies de localisation

7. Tester les scénarios réels, pas uniquement « ping marche »

En validation, on voit trop souvent :

• ping d’un serveur, c’est bon
• RDP marche, c’est bon

Non. Tester aussi :

• résolution DNS interne
• accès à une appli web interne avec SSO
• accès à un partage SMB si c’est autorisé
• impression, si encore utilisé
• latence SaaS
• bascule Wi-Fi vers 4G
• reprise après veille du PC

Et documenter ce qui est attendu. Sinon le jour où ça casse, chacun a sa propre définition de « normal ».

Split tunnel : cas où ça devient une mauvaise idée

Il y a des contextes où, même si ça soulage le réseau, le split tunnel te met en risque trop fort.

Quelques exemples :

• postes d’admins, ou équipes qui touchent à la prod
• environnements très régulés (selon contraintes)
• absence totale d’EDR ou de contrôle poste
• besoin d’audit complet du trafic sortant

Dans ces cas, mieux vaut du full tunnel, ou carrément passer à une approche ZTNA avec contrôle applicatif fin.

Mini check-list de déploiement (pratique, à copier)

À valider avant mise en prod :

1. Authentification forte : MFA obligatoire
2. Profils distincts : utilisateurs, admins, prestataires
3. Routes minimales : seulement ce qui est nécessaire
4. DNS maîtrisé : serveurs poussés, suffixes, fuite DNS testée
5. Pare-feu : filtrage côté VPN et côté poste
6. Journalisation : connexions, échecs, flux vers ressources sensibles
7. Supervision : capacité, latence, saturation, alertes
8. Tests réels : SaaS, intranet, bascule réseau, veille, reprise

Conclusion : le split tunnel n’est ni bon ni mauvais, il est exigeant

Le split tunnel, c’est un compromis. Tu gagnes en performance, tu perds en contrôle centralisé, et tu dois compenser ailleurs. Si tu ne compenses pas, tu crées des angles morts. Et les angles morts en sécu, ça finit toujours par coûter quelque chose.

Si tu devais retenir une seule idée : le choix split versus full doit être guidé par le risque et l’exploitation, pas par la mode ni par un copier coller de config.

Et si tu veux pousser le sujet en mode pratique, fais toi un petit lab : un serveur VPN, deux sous-réseaux internes, un DNS interne, un proxy ou un firewall, puis tu testes split tunnel, full tunnel, fuite DNS, accès SaaS, et tu notes ce que tu observes. C’est typiquement le genre de contenu qui a sa place sur BTS SIO2 SISR Tech Lab (https://sio1blog.blogspot.com/), et qui aide vraiment les autres à comprendre.

Questions fréquemment posées

Qu'est-ce qu'un VPN d'entreprise et quels sont ses composants essentiels ?

Un VPN d'entreprise est un ensemble intégré comprenant un client (ou un OS qui fait client), un serveur ou concentrateur (comme une gateway VPN, firewall, appliance ou cloud VPN), une authentification (via AD, LDAP, SSO, certificats, MFA), des politiques de routage (définissant quels flux passent dans le tunnel) et des contrôles (filtrage, inspection, posture device, logs). Ce système permet de sécuriser les connexions entre les utilisateurs distants et le réseau interne de l'entreprise.

Quelle est la différence entre le split tunneling et le full tunneling dans un VPN d'entreprise ?

Le split tunneling consiste à n'envoyer dans le VPN que certains flux spécifiques, généralement ceux destinés aux réseaux internes de l'entreprise, tandis que le reste du trafic Internet passe directement par la connexion locale de l'utilisateur. Le full tunneling envoie tout le trafic réseau via le VPN, ce qui permet un contrôle centralisé mais peut entraîner une latence plus élevée et une charge accrue sur les infrastructures du siège.

Quels sont les avantages du split tunneling pour les entreprises ?

Le split tunneling offre plusieurs avantages : amélioration des performances en évitant d'acheminer tout le trafic Internet via le tunnel VPN, réduction de la charge sur le concentrateur VPN et la bande passante du siège, latence réduite pour l'accès aux applications SaaS en direct, diminution des coûts liés au transit et dimensionnement réseau, ainsi qu'une meilleure résilience puisque l'utilisateur conserve un accès direct à Internet même si le VPN est lent.

Quels risques ou pièges sont associés au split tunneling dans un contexte professionnel ?

Les principaux pièges du split tunneling incluent les fuites DNS où les requêtes internes partent vers des résolveurs publics non sécurisés, la résolution incohérente des noms de domaine internes pouvant mener à des erreurs d'accès aux ressources, ainsi que des angles morts de sécurité car une partie du trafic échappe au contrôle centralisé. Il est crucial de gérer correctement la politique DNS et les suffixes pour éviter ces problèmes.

Pourquoi certaines entreprises préfèrent-elles utiliser le full tunnel malgré ses inconvénients ?

Le full tunnel offre un contrôle total sur tout le trafic réseau du poste utilisateur : cela facilite la mise en place de politiques cohérentes comme le filtrage URL, l'inspection TLS et la journalisation centralisée. De plus, cela réduit les risques liés aux réseaux locaux non sécurisés. Cette approche assure que l'utilisateur est « comme au bureau » quel que soit son lieu de connexion.

Comment gérer efficacement les problématiques DNS lors de l'utilisation du split tunneling ?

Pour éviter les fuites DNS et garantir une résolution cohérente des noms internes en split tunneling, il faut décider clairement si les requêtes DNS doivent être forcées via le tunnel VPN. La gestion des suffixes DNS est également essentielle. Des patterns adaptés permettent d'assurer que les requêtes vers des domaines internes utilisent les serveurs DNS corporatifs tandis que celles vers Internet passent par la connexion locale.