VPN : Le réglage unique qui rend votre tunnel rapide… et peu sûr

Le réglage : split tunneling, le cheat code de la performance

Le split tunneling consiste à choisir d’envoyer certains flux via le VPN et le reste directement sur Internet (ou vers d’autres réseaux) en utilisant votre route par défaut locale. Le full-tunnel (parfois « force tunnel ») envoie essentiellement tout par le VPN : Internet, SaaS, mises à jour, DNS—tout.

Du point de vue de l’utilisateur, le split tunneling ressemble à de la magie. Netflix tamponne moins. Zoom s’améliore. « Le VPN » cesse d’être accusé de tout, de la latence à l’angoisse existentielle.

Du point de vue de l’opérateur, le split tunneling est une décision de politique déguisée en réglage de performance. Vous n’« accélérez pas le tunnel ». Vous réduisez la dépendance au tunnel. Cela peut être intelligent. Cela peut aussi être le moment où, sans le savoir, vous autorisez des réseaux non fiables à devenir partie de votre modèle de menace.

Le bouton exact que vous tournez

• Portée du routage : Les clients installent-ils des routes 0.0.0.0/0 (et ::/0) vers l’interface VPN, ou seulement des routes pour les sous-réseaux d’entreprise ?
• Portée du DNS : Les clients utilisent-ils des résolveurs d’entreprise pour toutes les requêtes, ou seulement pour les domaines internes ? L’imposez-vous ?
• Contrôle d’egress : La surveillance de sécurité, le DLP, l’inspection TLS et la journalisation se font-ils à l’egress corporate… ou pas ?

Si vous retenez une chose : le split tunneling n’est pas juste du routage ; c’est de la responsabilité. Le full-tunnel fait peser la responsabilité du trafic du client sur le réseau corporate. Le split tunneling fait du réseau local du client une partie du chemin. C’est un monde différent.

Pourquoi le split tunneling est plus rapide (et pourquoi on blâme le full-tunnel)

La performance est une chaîne. Le surcoût du VPN n’est qu’un maillon. Le full-tunnel est souvent plus lent parce qu’il force le trafic à travers des points d’étranglement supplémentaires :

1) Hairpinning et inflation de chemin

Le full-tunnel signifie qu’un utilisateur à Berlin accédant à un SaaS hébergé à Francfort peut router ainsi : Berlin → concentrateur VPN corporate en Virginie → retour à Francfort. Ce n’est pas un « surcoût de chiffrement ». C’est la géographie qui punit une topologie médiocre.

2) Les middleboxes de sécurité deviennent le goulot

Quand vous êtes en full-tunnel, vous appliquez souvent aussi :

• Filtrage DNS central
• Politiques proxy
• Passerelles CASB
• Inspection DLP
• Interception SSL/TLS (lorsque permis)

Tout cela peut être des choix corrects. Ils ajoutent aussi de la latence, réduisent le débit, et échouent de façons créatives sous forte charge.

3) Les problèmes MTU/MSS apparaissent d’abord en full-tunnel

L’encapsulation VPN réduit la MTU effective. Si vous ne clamperez pas le MSS ou ne fixez pas une MTU raisonnable, vous obtenez de la fragmentation ou un PMTUD noirci. Symptômes : certains sites chargent, d’autres bloquent ; les gros uploads tombent ; SMB est misérable ; « ça marche sur le hotspot » devient l’outil de diagnostic maudit.

4) Votre concentrateur VPN devient votre passerelle Internet

Avec le full-tunnel, vous avez créé un point d’egress centralisé. Cela concentre la bande passante, l’état NAT, conntrack, le CPU pour le chiffrement et les logs. Si la planification de capacité était optimiste, les utilisateurs le sentiront immédiatement.

Le split tunneling donne l’impression d’être rapide parce qu’il évite ces points d’étranglement pour le trafic non-corporate. Il ne rend pas le VPN intrinsèquement plus rapide ; il rend le VPN moins impliqué.

Blague n°1 : Activer le split tunneling pour régler la performance, c’est comme réparer la circulation en retirant les panneaux routiers. Bien sûr, ça circule—jusqu’à ce qu’il faille expliquer l’accident.

Comment le split tunneling casse vos hypothèses de sécurité

Les modèles de sécurité reposent sur des hypothèses. Le split tunneling invalide discrètement quelques-unes des plus communes.

Hypothèse A : « Si vous êtes sur le VPN, vous êtes sur un réseau de confiance »

Avec le split tunneling, vous êtes sur deux réseaux à la fois : corporate et local. Votre laptop devient un appareil doublement connecté. Si le trafic du réseau local peut atteindre votre machine, et que votre machine peut atteindre des ressources corporate, vous avez créé un pont. Son exploitabilité dépend du pare-feu d’hôte, de la posture de l’endpoint et de la segmentation. Mais l’hypothèse est déjà rompue.

Hypothèse B : « La supervision corporate voit votre trafic sortant »

Le full-tunnel rend plausible que le trafic web, le DNS et certaines télémétries passent par les contrôles corporate. Avec le split tunneling, un utilisateur peut être « sur le VPN » tandis que son trafic Internet contourne entièrement vos logs d’egress. Cela affecte :

• Les délais d’investigation
• L’application du DLP
• La détection des communications C2 de malwares
• La résidence des données / contrôles réglementaires

Hypothèse C : « Le DNS est centralisé, donc nous pouvons contrôler et détecter »

Le split tunneling s’accompagne souvent d’un DNS fractionné : les noms internes vont aux résolveurs corporate, les noms externes vont aux résolveurs locaux. Si mal implémenté, vous ferez fuiter des requêtes internes vers des résolveurs publics, ou vous créerez des résolutions ambiguës qui cassent des applications d’une manière qui ressemble à de la « instabilité VPN ».

Hypothèse D : « La politique du client VPN est applicable »

Sur des appareils gérés, vous pouvez appliquer des routes, du DNS et des politiques de pare-feu. Sur du BYOD, votre contrôle est plus faible. Le split tunneling sur BYOD est une politique que vous ne pouvez pas auditer de façon fiable. C’est une mauvaise combinaison.

Hypothèse E : « Les mouvements latéraux commencent à l’intérieur du corporate »

Avec le split tunneling, la surface d’attaque inclut les réseaux locaux : cafés, hôtels, chaos d’objets connectés à la maison. Si l’endpoint est compromis via une exposition locale (AP malveillant, attaques broadcast locales, services exposés), l’attaquant a désormais un chemin VPN vers le corporate.

Que faire face à cette réalité

Si vous choisissez le split tunneling, agissez comme si vous l’aviez choisi. Ne prétendez pas conserver une posture full-tunnel. Au lieu de cela :

• Renforcez les endpoints : pare-feu hôte en refus par défaut pour les inbound, contrôles de posture stricts, patching rapide.
• Rendez l’accès corporate « zéro confiance » : accès par application, politiques basées sur l’identité, moindre privilège, identifiants de courte durée.
• Segmentez les réseaux internes pour que « utilisateur VPN » ne signifie pas « voit tout ».
• Journalisez là où ça compte : identité, décisions d’accès, signaux d’endpoint—pas seulement les logs d’egress.

Et si vous avez besoin du full-tunnel pour conformité ou supervision, alors engagez-vous et ingéniez-le : egress régionaux, capacité, correction MTU et DNS sensé.

Faits intéressants et contexte historique (la version courte et utile)

1. IPsec (IKE) est devenu courant à la fin des années 1990 quand les entreprises avaient besoin de liaisons site-à-site sécurisées sans circuits privés dédiés.
2. PPTP a été largement déployé dans les années 1990 parce qu’il était facile, pas parce qu’il était bon. Il est ensuite devenu synonyme de « n’utilisez pas ça ».
3. Les VPN SSL ont émergé au début des années 2000 alors que le NAT et les firewalls rendaient les déploiements classiques d’IPsec clients pénibles ; les tunnels compatibles HTTPS ont gagné les batailles politiques.
4. Le NAT traversal a changé l’ergonomie des VPN : IPsec NAT-T (encapsulation UDP) a rendu les VPN plus viables derrière des routeurs grand public et le Wi‑Fi d’hôtel.
5. Le « full tunnel » est devenu le défaut à mesure que les stacks de sécurité centralisés grandissaient ; il s’alignait sur les proxies web, le filtrage DNS central et plus tard les patterns DLP/CASB.
6. Le split tunneling fait débat depuis des décennies parce que c’est une question de politique : faites-vous confiance à l’endpoint et au réseau local ?
7. Les problèmes de MTU se sont aggravés à mesure que les couches d’encapsulation s’accumulaient (VPN + VLAN + overlays cloud). PMTUD est fragile en conditions réelles.
8. WireGuard (milieu-fin des années 2010) a popularisé un modèle plus simple avec de la crypto légère et une configuration épurée, rendant l’idée d’un « VPN rapide » plus réaliste.
9. L’ère du travail à distance liée au COVID a transformé les concentrateurs VPN en services à échelle Internet du jour au lendemain, exposant les péchés de planification de capacité et forçant des choix rapides comme le split tunneling.

Trois mini-récits d’entreprise depuis le terrain

Mini-récit 1 : L’incident causé par une fausse hypothèse

Une entreprise de taille moyenne a déployé le split tunneling pour réduire la charge sur ses passerelles VPN surchargées. Ça a marché. Les tickets « VPN lent » ont chuté en une semaine, et la direction a considéré ça comme une victoire.

Puis une alerte de sécurité est apparue : un portail d’administration interne avait été accédé depuis un compte utilisateur à une heure inhabituelle. Les logs montraient que l’utilisateur était connecté au VPN, ce qui a initialement rassuré tout le monde : « il était sur le réseau corporate, donc c’est bon. »

Ce n’était pas bon. L’endpoint avait été compromis sur un réseau domestique par un infostealer banal qui a ensuite escaladé via des sessions de navigateur en cache. À cause du split tunneling, le trafic de commande-et-contrôle de l’attaquant n’est jamais passé par l’egress corporate. Le premier vrai indice est venu de la télémétrie d’identité, pas des logs réseau.

La partie douloureuse n’était pas la compromission ; c’était la chronologie. L’équipe a perdu des jours parce qu’elle a cherché au mauvais endroit : dans les logs proxy et firewall qui n’avaient jamais vu le trafic.

La solution n’a pas été « interdire le split tunneling ». Ils l’ont conservé, mais ont changé le modèle : contrôle d’accès conditionnel renforcé, réauthentification pour les portails admin, déclencheurs d’isolation d’endpoint, et formation explicite des répondants : « sur VPN » ne signifie pas « nous avons vu le trafic ».

Mini-récit 2 : L’optimisation qui a mal tourné

Une organisation d’ingénierie a décidé d’accélérer les workflows des développeurs distants. Ils ont activé le split tunneling et exempté aussi quelques sous-réseaux cloud du VPN pour « réduire la latence » vers les services CI. Ça a gagné quelques secondes sur certains builds. Tout le monde était content.

Deux semaines plus tard, bizarrerie : des téléchargements de paquets internes récupéraient parfois les mauvais artefacts. Pas malveillant. Juste faux. Les développeurs voyaient des mismatches de checksum intermittents, principalement depuis des connexions domestiques.

La cause racine était ennuyeuse et brutale : leur domaine d’artefact interne utilisait du split-horizon DNS, mais la configuration fractionnée résolvait occasionnellement des points de terminaison externes via le résolveur local lorsque le DNS du VPN répondait lentement. Une partie du trafic empruntait la route non-VPN, frappait un mirror public et renvoyait des artefacts qui ne correspondaient pas aux attentes internes. Les contrôles d’intégrité les ont sauvés d’un incident de chaîne d’approvisionnement, mais la productivité s’est effondrée.

Ils ont corrigé cela en étant moins « malins » : les domaines internes utilisaient toujours le DNS corporate, et ces serveurs DNS corporate ont été rendus accessibles et rapides depuis partout. Ils ont aussi resserré les règles de routage pour que les sous-domaines internes ne fuient jamais vers des résolveurs locaux.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une société de services financiers appliquait une politique full-tunnel pour les laptops gérés. Ils avaient aussi l’habitude, qui paraissait excessive, d’exiger qu’à chaque changement VPN il y ait un plan de rollback et une « liste de tests smoke » exécutée depuis trois réseaux (fibre à domicile, hotspot mobile et un Wi‑Fi invité hostile).

Lors d’une mise à jour routine du client VPN, une régression MTU subtile est apparue chez un ISP. Les grosses réponses HTTPS se bloquaient ; les petites passaient. Les développeurs pouvaient se connecter, mais cloner de gros repos échouait, et certaines applications internes se chargeaient partiellement puis gelaient.

Les tests smoke l’ont détecté en staging avec le motif exact : « marche sur hotspot, échoue sur la fibre ». L’équipe a rollbacké avant un impact large, puis retesté avec captures de paquets. Le problème était un manque de clamp MSS après un changement côté client.

Pas d’exploits. Pas de nuit blanche. Juste une checklist, une matrice de tests horrible, et quelqu’un qui avait déjà subi ça. Cette pratique s’est payée d’elle-même en une panne évitée.

Mode d’emploi de diagnostic rapide : quoi vérifier en premier/deuxième/troisième

Voici la séquence « arrêtez de deviner ». Exécutez-la dans l’ordre. Chaque étape vous indique où chercher ensuite.

Premier : identifier si le problème est la portée du routage ou la santé du tunnel

• La destination lente doit-elle passer par le tunnel ou non ?
• La route par défaut passe-t-elle par le VPN (full-tunnel) ou locale (split-tunnel) ?
• Le DNS pour cette destination provient-il des résolveurs corporate ou locaux ?

Si le trafic ne va pas là où vous pensez, toutes les autres mesures sont du bruit.

Deuxième : vérifier MTU/MSS et les motifs « certains sites plantent »

• Les petites pages chargent, les gros téléchargements se bloquent : suspectez MTU/PMTUD/MSS.
• Ça marche sur hotspot mais pas sur l’ISP domestique : suspectez MTU ou filtrage ISP.

Troisième : CPU local et limites crypto vs limites réseau

• CPU élevé sur le client pendant un transfert : surcoût de chiffrement ou problème pile réseau/kernel.
• CPU bas mais faible débit : suspectez chemin/latence, perte de paquets, ou goulot de passerelle.

Quatrième : capacité de la passerelle et middleboxes

• Vérifiez le CPU, la mémoire, le conntrack, les drops NIC de la passerelle VPN.
• Vérifiez firewalls/proxies effectuant inspection ou shaping.

Cinquième : mesurer où la latence est introduite

• La latence est-elle dans le handshake VPN ? DNS ? établissement TCP ? handshake TLS ? couche applicative ?
• Utilisez traceroute et des captures de paquets pour choisir la couche à incriminer.

Tâches pratiques : commandes, ce que signifie la sortie, et la décision à prendre

Voici les tâches que j’exécute réellement quand quelqu’un dit « le VPN est lent » ou « le split tunneling l’a réparé ». Adaptez les noms d’interface et adresses à votre environnement.

Task 1: Confirm the VPN interface and assigned address

cr0x@server:~$ ip -brief addr
lo               UNKNOWN        127.0.0.1/8 ::1/128
eth0             UP             10.10.20.15/24 fe80::5054:ff:fe12:3456/64
wg0              UP             10.99.0.12/32

Sens : wg0 existe et est up ; l’adresse VPN est 10.99.0.12/32.

Décision : Si l’interface VPN est absente ou DOWN, arrêtez. Réparez la connectivité client avant d’ajuster la performance.

Task 2: Determine whether you’re full-tunnel or split-tunnel

cr0x@server:~$ ip route show default
default via 10.10.20.1 dev eth0 proto dhcp src 10.10.20.15 metric 100

Sens : La route par défaut est locale via eth0. C’est du split tunneling (du moins pour la valeur par défaut IPv4).

Décision : Si vous attendiez du full-tunnel, votre politique n’est pas appliquée ou est écrasée. Réparez le routage avant de courir après le débit.

Task 3: Check if corporate networks are routed to the VPN

cr0x@server:~$ ip route | grep -E '10\.50\.|172\.16\.|192\.168\.200'
10.50.0.0/16 dev wg0 proto static
192.168.200.0/24 dev wg0 proto static

Sens : Seuls des préfixes spécifiques vont vers le VPN. C’est du split tunneling par conception.

Décision : Confirmez que la liste de préfixes correspond à la réalité. L’absence d’un sous-réseau ressemble à « le VPN n’atteint pas l’app » et est mal diagnostiquée comme lenteur.

Task 4: Confirm actual path selection to a destination

cr0x@server:~$ ip route get 10.50.12.34
10.50.12.34 dev wg0 src 10.99.0.12 uid 1000
    cache

Sens : Le trafic vers 10.50.12.34 utilisera wg0.

Décision : Si il route via eth0 ou une autre interface, votre politique split est fausse (ou vous avez des routes conflictuelles).

Task 5: Check DNS resolver in use (systemd-resolved example)

cr0x@server:~$ resolvectl status
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 2 (eth0)
    Current Scopes: DNS
         Protocols: +DefaultRoute
Current DNS Server: 1.1.1.1
       DNS Servers: 1.1.1.1 1.0.0.1

Link 3 (wg0)
    Current Scopes: DNS
         Protocols: -DefaultRoute
       DNS Servers: 10.50.0.53
        DNS Domain: corp.example

Sens : Le DNS externe va à 1.1.1.1, le domaine interne corp.example va à 10.50.0.53 via le VPN.

Décision : Si les résolutions internes vont vers des résolveurs publics, vous avez une fuite DNS et probablement des erreurs de résolution intermittentes. Corrigez la politique de DNS fractionné.

Task 6: Validate internal name resolution goes to corporate DNS

cr0x@server:~$ dig +short @10.50.0.53 intranet.corp.example
10.50.12.34

Sens : Le DNS corporate résout le nom interne.

Décision : Si ça timeoute, votre chemin VPN vers le DNS est rompu ou filtré. Priorisez la reachabilité DNS—les applications « ressentent » la lenteur quand le DNS est lent.

Task 7: Spot DNS leakage by comparing resolvers

cr0x@server:~$ dig +time=1 +tries=1 @1.1.1.1 intranet.corp.example
; <<>> DiG 9.18.24-1 <<>> +time=1 +tries=1 @1.1.1.1 intranet.corp.example
;; connection timed out; no servers could be reached

Sens : Le résolveur public ne connaît pas le domaine interne (bon signe). S’il répondait, vous auriez probablement publié quelque chose que vous ne vouliez pas.

Décision : Si des clients interrogent le DNS public pour des zones internes, corrigez le routage DNS ou imposez les paramètres de résolveur.

Task 8: Check MTU on interfaces

cr0x@server:~$ ip link show wg0
3: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/none

Sens : La MTU WireGuard est 1420, une valeur sûre courante.

Décision : Si la MTU est trop élevée (par ex. 1500 sur un chemin encapsulé), attendez-vous à des trous noirs. Envisagez d’abaisser la MTU ou d’appliquer du MSS clamping.

Task 9: Reproduce MTU/PMTUD issues with ping “do not fragment”

cr0x@server:~$ ping -M do -s 1372 -c 3 10.50.12.34
PING 10.50.12.34 (10.50.12.34) 1372(1400) bytes of data.
1380 bytes from 10.50.12.34: icmp_seq=1 ttl=63 time=42.1 ms
1380 bytes from 10.50.12.34: icmp_seq=2 ttl=63 time=41.7 ms
1380 bytes from 10.50.12.34: icmp_seq=3 ttl=63 time=42.5 ms

--- 10.50.12.34 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2004ms

Sens : Des paquets de cette taille passent sans fragmentation.

Décision : Si vous voyez « Frag needed » ou des timeouts à des tailles modérées, ajustez MTU/MSS. C’est souvent la cause cachée du « VPN lent ».

Task 10: Check TCP MSS clamping rules (iptables example)

cr0x@server:~$ sudo iptables -t mangle -S | grep -i mss
-A FORWARD -o wg0 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Sens : Le MSS clamping est activé pour le TCP forwardé dans le tunnel.

Décision : Si absent et que vous observez des symptômes MTU, ajoutez du MSS clamping (ou corrigez la MTU). Si présent mais inefficace, votre trafic peut ne pas traverser cette machine.

Task 11: Measure raw throughput with iperf3 through the tunnel

cr0x@server:~$ iperf3 -c 10.50.12.34 -t 10
Connecting to host 10.50.12.34, port 5201
[  5] local 10.99.0.12 port 53322 connected to 10.50.12.34 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  11.2 MBytes  94.0 Mbits/sec    0   1.12 MBytes
[  5]   1.00-2.00   sec  10.8 MBytes  90.4 Mbits/sec    3   1.02 MBytes
[  5]   2.00-3.00   sec  10.6 MBytes  88.8 Mbits/sec    1   1.05 MBytes
[  5]   3.00-4.00   sec  10.9 MBytes  91.2 Mbits/sec    0   1.09 MBytes
[  5]   4.00-5.00   sec  10.7 MBytes  89.6 Mbits/sec    2   1.01 MBytes
[  5]   5.00-6.00   sec  10.8 MBytes  90.4 Mbits/sec    0   1.08 MBytes
[  5]   6.00-7.00   sec  10.7 MBytes  89.6 Mbits/sec    1   1.03 MBytes
[  5]   7.00-8.00   sec  10.9 MBytes  91.2 Mbits/sec    0   1.10 MBytes
[  5]   8.00-9.00   sec  10.7 MBytes  89.6 Mbits/sec    2   1.00 MBytes
[  5]   9.00-10.00  sec  10.8 MBytes  90.4 Mbits/sec    0   1.06 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   108 MBytes  90.6 Mbits/sec   12             sender
[  5]   0.00-10.00  sec   107 MBytes  90.0 Mbits/sec                  receiver

Sens : ~90 Mbit/s via le tunnel, quelques retransmissions mais pas catastrophiques.

Décision : Si le débit est faible et les retransmissions importantes, suspectez perte/MTU/chemin. Si le débit est plafonné avec peu de perte, suspectez CPU/crypto ou shaping.

Task 12: Check client-side CPU pressure during transfer

cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.5.0-21-generic (laptop) 	02/04/2026 	_x86_64_	(8 CPU)

02:11:30 PM  CPU    %usr   %nice    %sys %iowait   %irq  %soft  %steal  %guest  %gnice   %idle
02:11:31 PM  all   18.21    0.00    6.12    0.11   0.00   1.33    0.00    0.00    0.00   74.23
02:11:32 PM  all   19.02    0.00    6.41    0.00   0.00   1.58    0.00    0.00    0.00   72.99
02:11:33 PM  all   17.88    0.00    6.05    0.00   0.00   1.49    0.00    0.00    0.00   74.58

Sens : Le CPU n’est pas saturé ; le client n’est probablement pas lié par la crypto.

Décision : Si le CPU est proche de 100% pendant le transfert, des chiffrements plus rapides/du offload hardware ou un autre protocole VPN peuvent compter plus que la politique de routage.

Task 13: Identify packet loss and jitter to the VPN gateway

cr0x@server:~$ mtr -rwzbc 50 vpn-gw.corp.example
Start: 2026-02-04T14:12:10+0000
HOST: laptop                        Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 10.10.20.1                  0.0%    50    1.2   1.3   0.9   3.9   0.5
  2.|-- 100.64.0.1                  0.0%    50    6.7   6.9   5.8  11.2   1.0
  3.|-- 203.0.113.10                0.0%    50   18.0  18.3  16.7  25.9   1.9
  4.|-- vpn-gw.corp.example         0.0%    50   42.8  43.1  40.9  52.0   2.1

Sens : Pas de perte, latence stable. Bon underlay.

Décision : Si de la perte apparaît avant la passerelle, régler le VPN ne corrigera pas l’underlay. Envisagez des réseaux alternatifs, une escalade auprès de l’ISP, ou des passerelles multi-régions.

Task 14: Confirm whether your public IP changes with VPN (quick full-tunnel check)

cr0x@server:~$ curl -4 ifconfig.me
198.51.100.44

Sens : C’est votre adresse d’egress IPv4 actuelle. En full-tunnel, elle devrait correspondre à l’egress corporate ; en split-tunnel, elle correspondra à l’ISP local.

Décision : Si la politique exige l’egress corporate et que vous voyez une adresse ISP, vous n’êtes pas en full-tunnel (ou vous fuyez).

Task 15: Check WireGuard handshake and transfer counters

cr0x@server:~$ sudo wg show
interface: wg0
  public key: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX=
  private key: (hidden)
  listening port: 51820

peer: YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY=
  endpoint: 203.0.113.50:51820
  allowed ips: 10.50.0.0/16, 192.168.200.0/24
  latest handshake: 23 seconds ago
  transfer: 1.92 GiB received, 336.45 MiB sent
  persistent keepalive: every 25 seconds

Sens : Le handshake est récent ; le tunnel est vivant ; les routes sont split via allowed ips.

Décision : Si le handshake est ancien et que le trafic stagne, suspectez des timeouts NAT, UDP bloqué, ou des problèmes de roaming. Envisagez un keepalive ou un VPN basé sur TCP en secours.

Task 16: Inspect conntrack pressure on a Linux VPN gateway

cr0x@server:~$ sudo sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max
net.netfilter.nf_conntrack_count = 248912
net.netfilter.nf_conntrack_max = 262144

Sens : Conntrack approche le maximum ; de nouvelles connexions peuvent être dropped ou bloquées. Les utilisateurs diront « VPN lent ».

Décision : Augmentez le max conntrack (en tenant compte de la RAM), réduisez la charge egress full-tunnel, ou scalez les passerelles.

Blague n°2 : L’optimisation de performance VPN, c’est l’art d’accélérer les paquets en en déplaçant moins. Les comptables appellent ça « optimisation des coûts ».

Erreurs courantes : symptômes → cause racine → correction

1) « Le VPN est lent, mais seulement pour certains sites »

Symptôme : Petites pages chargent ; gros assets bloquent ; téléchargements s’arrêtent ; Slack marche mais votre tableau de bord interne ne se rend pas complètement.

Cause racine : PMTUD/MTU noirci dû à l’encapsulation, ou absence de MSS clamping.

Correction : Abaissez la MTU du tunnel et/ou clamez le MSS sur le chemin qui forwarde dans le tunnel. Vérifiez avec des pings DF et une capture de paquets.

2) « Activer le split tunneling a tout réparé »

Symptôme : La performance s’améliore drastiquement quand le split tunneling est activé.

Cause racine : Le chemin full-tunnel fait du hairpinning via un egress lointain, ou l’egress/proxy est surchargé.

Correction : Ajoutez des passerelles/egress régionaux, contournez l’inspection lourde pour des destinations à risque réduit où c’est acceptable, ou utilisez un VPN par application plutôt que tout-ou-rien.

3) « L’appli interne est lente seulement sur le VPN ; le ping est ok »

Symptôme : La latence ICMP semble normale ; l’appli est lente, surtout lors de la connexion ou des appels API.

Cause racine : Latence DNS, délais de handshake TLS, boucles d’auth proxy, ou perte de paquets affectant TCP plus que ICMP.

Correction : Mesurez le temps de requête DNS, le temps de connexion TCP et le handshake TLS. Ne faites pas du ping votre unique religion de performance.

4) « Après activation du split tunneling, on n’atteint plus certains sous-réseaux internes »

Symptôme : Seules des parties du réseau corporate sont joignables ; certains hôtes time-outent.

Cause racine : Routes/allowed IPs manquantes, plages RFC1918 qui se chevauchent avec les réseaux domestiques, ou métriques de route conflictuelles.

Correction : Ajoutez des routes explicites, évitez les espaces d’adressage qui se chevauchent quand c’est possible, ou utilisez NAT/traduction pour l’accès distant. Vérifiez avec ip route get.

5) « On a activé le full-tunnel pour la sécurité et maintenant Zoom est inutilisable »

Symptôme : Jitter audio/vidéo, perte de paquets, mauvaise qualité d’appel.

Cause racine : Trafic temps réel forcé via un egress lointain et des middleboxes d’inspection ; marquages DSCP perdus ; surcharge d’état NAT.

Correction : Utilisez le split tunneling pour des services temps réel approuvés (si la politique le permet), ou déployez un breakout local/SD‑WAN proche des utilisateurs. Priorisez les chemins UDP.

6) « Les utilisateurs sont ‘sur VPN’ mais le DNS interne échoue aléatoirement »

Symptôme : Les noms internes se résolvent parfois, parfois time-outent ; changer de réseau « règle » le problème.

Cause racine : Mauvaise configuration DNS fractionné, serveurs DNS uniquement joignables via un chemin tunnel spécifique, ou sélection du résolveur qui bascule.

Correction : Rendez le DNS corporate accessible et redondant, épinglez les zones internes aux résolveurs corporate, et définissez des règles de routage claires pour le trafic DNS.

7) « La sécurité veut le full-tunnel, le réseau veut le split, personne n’est content »

Symptôme : Débat sans fin, aucune décision, beaucoup d’exceptions.

Cause racine : Vous essayez d’utiliser un tunnel réseau comme contrôle de sécurité universel.

Correction : Remontez les contrôles dans la pile : posture de l’appareil, proxies conscientes de l’identité, accès au niveau applicatif et segmentation. Puis choisissez split/full sur la base d’exigences mesurables, pas d’intuitions.

Listes de contrôle / plan étape par étape

Checklist décisionnelle : devriez-vous autoriser le split tunneling ?

1. Conformité : Avez-vous des exigences qui imposent un egress corporate pour tout le trafic ? Si oui, privilégiez le full-tunnel et ingérez les efforts pour l’ingénierie.
2. Contrôle des appareils : Les endpoints sont-ils gérés avec un pare-feu hôte et des contrôles de posture applicables ? Si non, soyez très prudent avec le split tunneling.
3. Segmentation interne : Si un client est compromis, peut‑il atteindre « tout » via le VPN ? Si oui, vous comptez sur le tunnel comme fossé. Corrigez la segmentation d’abord.
4. Stratégie de supervision : L’IR peut‑il réussir avec identité + télémétrie endpoint si la visibilité d’egress est réduite ? Si non, ne prétendez pas que le split tunneling est anodin.
5. Topologie : Avez-vous des passerelles/egress régionaux ? Si non, votre expérience full-tunnel sera lente pour des utilisateurs distants ; soit investissez, soit acceptez le split tunneling avec garde‑fous.

Checklist performance : rendre le full-tunnel supportable

1. Placez les passerelles près des utilisateurs (régionalement) et testez le basculement.
2. Dimensionnez correctement bande passante, conntrack/état NAT et CPU pour le chiffrement.
3. Corrigez MTU/MSS délibérément ; ne « comptez pas sur PMTUD ».
4. Rendez le DNS rapide, redondant et joignable ; mesurez‑le.
5. Décidez ce qui est inspecté et ce qui ne l’est pas ; documentez les exceptions comme politique, pas comme connaissance tribale.
6. Mesurez l’expérience utilisateur avec des tests synthétiques depuis des réseaux last-mile typiques.

Checklist sécurité : si vous faites du split tunneling, faites-le en connaissance de cause

1. Pare-feu hôte en refus par défaut ; bloquez l’inbound depuis le sous-réseau local sauf si nécessaire.
2. Utilisez l’accès par application ou des proxies conscients de l’identité pour les applications critiques.
3. Appliquez le MFA et des authentifications renforcées pour les opérations sensibles.
4. Raccourcissez la durée de vie des identifiants ; réduisez la dépendance aux sessions longues.
5. Renforcez le DNS : zones internes aux résolveurs corporate ; empêchez les fuites de requêtes internes.
6. Instrumentez endpoints et identité ; supposez une visibilité réseau réduite.
7. Restreignez les routes VPN au strict nécessaire ; « tout RFC1918 » est paresseux et dangereux.

Plan de changement : déployer le split tunneling sans chaos

1. Définir le périmètre : Quel trafic est exclu (route par défaut Internet ? SaaS spécifiques ? media en temps réel ?) et pourquoi.
2. Modéliser les menaces : Risques de double connexion, chemins d’exfiltration, fuites DNS et lacunes de visibilité pour les répondants.
3. Piloter : Commencez avec un groupe contrôlé sur appareils gérés ; collectez télémétrie performance et sécurité.
4. Garde-fous : Appliquez des règles de pare-feu hôte, des checks de posture et de la segmentation interne avant un déploiement large.
5. Mesurer : Utilisez iperf3, latence DNS et tests synthétiques applicatifs avant/après.
6. Documenter : Mettez à jour les runbooks IR : où les logs existent et où ils n’existent pas.
7. Rollback : Gardez un chemin en un clic pour revenir au full-tunnel en cas d’incident.

La citation d’ingénierie (parce que c’est vraiment un problème d’exploitation)

Idée paraphrasée — Werner Vogels : « Tout échoue, tout le temps. »

Le split tunneling est un amplificateur de modes de défaillance : il change où les défaillances surviennent et quelles équipes peuvent les voir. Si vous l’adoptez, mettez à jour votre observabilité et votre mémoire musculaire d’incident en conséquence.

FAQ

1) Quel est précisément le « réglage unique » qui rend le VPN rapide et peu sûr ?

Le split tunneling. Il améliore la vitesse perçue en laissant le trafic non-corporate contourner le chemin VPN et les contrôles d’egress corporate. Cela réduit aussi la visibilité centralisée et peut introduire des risques liés à la double connexion.

2) Le split tunneling est-il toujours peu sûr ?

Non. Il est moins sûr par rapport à un modèle qui suppose « VPN = réseau de confiance et surveillé ». Avec une sécurité endpoint forte, de la segmentation et des contrôles basés sur l’identité, le split tunneling peut être un compromis acceptable.

3) Pourquoi le full-tunnel ralentit-il tant les SaaS ?

Généralement topology et middleboxes : hairpinning via des passerelles distantes, plus proxies/DLP/stacks d’inspection. Le surcoût crypto est rarement le principal coupable sur du hardware moderne.

4) Puis-je garder le full-tunnel mais améliorer la performance ?

Oui : passerelles régionales, breakout local avec application de politiques, capacité suffisante pour NAT/conntrack, MTU/MSS corrects et DNS rapide. Le full-tunnel n’est pas condamné ; il est souvent sous-dimensionné.

5) Quelle est la façon la plus rapide de confirmer si le trafic passe par le VPN ?

Vérifiez la route par défaut et un lookup de route vers la cible avec ip route get. Pour l’egress Internet, comparez l’IP publique lorsqu’on est connecté.

6) Quel est le bug « VPN lent » le plus courant qui n’est pas lié au débit ?

Les problèmes MTU/MSS. Ils causent des blocages et des retransmissions qui donnent l’impression de lenteur et n’apparaissent que pour certains sites ou tailles de charge utile.

7) Le split tunneling provoque-t-il des fuites DNS ?

Il peut, surtout avec des configurations DNS fractionné mal épinglées. Si des requêtes internes vont à des résolveurs locaux, vous ferez fuiter des métadonnées et obtiendrez des comportements d’application instables.

8) WireGuard est-il intrinsèquement plus rapide qu’OpenVPN ?

Souvent oui—conception plus simple, intégration noyau sur plusieurs plateformes et crypto moderne. Mais votre goulot peut toujours être la perte d’underlay, la capacité de la passerelle ou l’inspection d’egress. Un tunnel plus rapide ne résout pas un chemin lent.

9) Comment des réseaux domestiques qui se chevauchent cassent-ils le split tunneling ?

Si le corporate utilise les mêmes plages privées que la maison (courant avec 192.168.1.0/24), les routes peuvent préférer le réseau local et le trafic « interne » n’entrera jamais dans le VPN. Corrigez avec des adresses non chevauchantes, du NAT ou des stratégies de routage/traduction explicites.

10) Que devons-nous journaliser si le split tunneling réduit la visibilité réseau ?

Événements d’identité, signaux de posture des appareils, métadonnées de session VPN et logs d’accès applicatif. Traitez l’endpoint et l’application comme la nouvelle périmètre—parce que c’est le cas.

Prochaines étapes pratiques

Si vous hésitez entre « rapide » et « sécurisé », vous perdez déjà du temps. Faites plutôt ceci :

1. Mesurez le goulot actuel en utilisant le mode d’emploi de diagnostic rapide. Prouvez si le problème est le routage, le MTU, la perte, la capacité de la passerelle ou l’inspection.
2. Si vous avez besoin du full-tunnel, ingéniez-le : passerelles régionales, MTU/MSS corrects, assez d’état conntrack/NAT et DNS qui ne vacille pas sous charge.
3. Si vous choisissez le split tunneling, changez le modèle de sécurité : endpoints renforcés, segmentation et contrôles basés identité. Mettez à jour les runbooks IR pour refléter la réalité.
4. Rédigez la politique en langage clair : ce qui contourne le tunnel, ce qui ne le fait jamais, et quelles sont les exceptions. Testez ensuite sur des réseaux réels, pas seulement sur le Wi‑Fi du bureau.

Le tunnel n’est pas votre produit. L’accès fiable l’est. Le split tunneling peut être un outil, mais ce n’est pas un repas gratuit—plutôt un déjeuner qui vient avec un audit surprise.