VPN de bureau pour applications ERP/CRM : prévenir les blocages et délais d’attente de la bonne façon

décembre 25, 2025 • février 3, 2026 • Lecture : 28 min • Views: 8

Cet article vous a aidé ?

Rien n’entame autant la confiance dans « l’IT » qu’un écran ERP qui se fige juste au moment où quelqu’un enregistre des factures. Le curseur tourne, la session expire, et soudain votre équipe finance reproduit le rituel ancien : tout fermer, rouvrir, ressaisir, jurer doucement.

Les VPN sont souvent accusés parce qu’ils sont visibles. Parfois c’est justifié. Le plus souvent, le VPN est l’endroit où un comportement d’application fragile rencontre latence, perte de paquets, bizarreries MTU, confusion DNS et pare-feu à états avec une mémoire courte. Voici comment faire en sorte que ce bazar se comporte en production — sans deviner.

Ce que sont réellement les « blocages » (et pourquoi ce n’est pas mystique)

Quand les utilisateurs disent « l’ERP s’est figé », le système fait généralement exactement ce que vous lui avez demandé : attendre. Il attend une réponse réseau, un aller-retour base de données, la libération d’un verrou de fichier, ou la renégociation d’une session TLS. La plupart des applications métier (ERP/CRM) sont bavardes : beaucoup de petites requêtes, beaucoup de dépendances et beaucoup d’hypothèses sur une qualité réseau de type LAN.

Les VPN changent la physique :

La latence augmente (même un « bon » VPN ajoute quelques à plusieurs dizaines de millisecondes).
La perte de paquets devient visible (Wi‑Fi, LTE et les FAI grand public adorent la micro-perte).
Le PMTU/MTU casse (surcharge d’encapsulation, ICMP bloqué et fragmentation soudaine).
Le routage/DNS change (split DNS, NRPT, atteignabilité du résolveur, suffixes de recherche).
Les dispositifs à état imposent des timeouts (NAT, pare-feu, proxies, IDS).

Les applications ERP/CRM amplifient ces effets car elles ont souvent :

Des sessions longue durée avec des keepalives fragiles.
Des timeouts codés en dur réglés pour des LANs de bureau.
Des protocoles mixtes (HTTP(S), WebSockets, SMB, drivers DB, RDP/ICA, parfois tous dans un même « flux »).
Des pics de gros payloads (export de rapports, pièces jointes, mises à jour client).

Le travail n’est pas « rendre le VPN plus rapide ». Le travail est rendre le VPN prévisible, et garder les flux critiques de l’application à l’abri des pièges connus.

Faits intéressants et contexte historique (à ressortir en réunion)

IPsec a été standardisé dans les années 1990 avec l’objectif de sécuriser l’IP lui‑même, pas seulement le trafic web. Cette vision « niveau réseau » explique pourquoi il est encore omniprésent dans les VPN site-à-site.
Les VPN SSL sont devenus populaires car le port 443/HTTPS passe. Ce n’était pas de l’élégance — c’était de la survie à l’époque des sorties verrouillées.
Le « meltdown » TCP-over-TCP est connu depuis des décennies : encapsuler du TCP dans un VPN TCP peut provoquer des retransmissions en cascade et des débits épouvantables en cas de perte.
La découverte de PMTU dépend d’ICMP pour fonctionner correctement. Bloquer l’ICMP « pour la sécurité » est un moyen fiable de créer des timeouts mystérieux.
Le NAT et les pare-feu à états ont transformé le réseau en bail : si vous n’envoyez rien périodiquement, votre « connexion » peut être supprimée en cours de session, même si les deux extrémités sont OK.
Les éditeurs ERP ont historiquement optimisé pour les LANs parce que les ERP vivaient là : serveurs on‑prem, clients lourds et réseaux bureaux à faible latence. Le cloud et le travail à distance ont exposé ces hypothèses.
SMB a longtemps été sensible à la latence. Il s’est amélioré (SMB2/3), mais il punit encore les RTT élevés et la perte, surtout avec de petites I/O et des opérations métadonnées bavardes.
Les retransmissions Wi‑Fi peuvent ressembler à une « perte aléatoire » au niveau VPN. Le chiffrement VPN masque la visibilité applicative, donc l’équipe réseau voit souvent seulement de « l’UDP chiffré » et hausse les épaules.
Le TLS moderne peut reprendre des sessions rapidement, mais les middleboxes qui inspectent ou proxyent peuvent casser ces optimisations, forçant plus de handshakes et plus d’attentes.

Mode opératoire de diagnostic rapide : trouver le goulot vite

Si vous ne faites rien d’autre, faites ceci dans l’ordre. Le but est d’arrêter les débats et de commencer l’isolation.

1) Déterminez si c’est de la latence, de la perte ou du MTU

Latence : l’application fonctionne mais est lente partout ; chaque clic attend.
Perte/jitter : l’application « se fige » puis rattrape son retard ; les sessions tombent ; des reconnexions surviennent ; voix/vidéo sont aussi affectées.
MTU/MSS : les petites choses fonctionnent ; les gros uploads/downloads bloquent ; des pages spécifiques plantent ; l’enregistrement échoue ; certains sites TLS se chargent à moitié.

2) Prouvez si le VPN est sur le chemin du trafic ERP/CRM

Vérifiez le routage (client) et confirmez si vous êtes en full-tunnel ou split-tunnel pour les endpoints ERP/CRM.
Vérifiez le DNS : résolvez-vous le nom ERP vers la bonne IP (interne vs publique) ?

3) Identifiez le point d’étranglement : Wi‑Fi client, uplink bureau, concentrateur VPN ou backend applicatif

Comparez le comportement depuis : LAN du bureau, domicile via VPN, domicile sans VPN (si l’ERP est SaaS), et un hôte de test dans le même sous‑réseau que les serveurs ERP.
Recherchez des performances asymétriques : téléchargement rapide/upload lent indique souvent shaping, bufferbloat ou policing.

4) Ne déboguez pas l’ERP tant que le tunnel n’est pas ennuyeux

Quand le transport est stable — pas de pics de perte, pas de problèmes MTU, pas de basculements DNS — alors vous êtes autorisé à incriminer l’application. Avant cela, vous ne faites que du bruit.

Une citation à garder à portée de main : « L’espoir n’est pas une stratégie. » —idée souvent paraphrasée utilisée en ops et ingénierie

Les modes de défaillance usuels : latence, perte, MTU, DNS et état de session

Latence : la mort par mille allers-retours

Les applications ERP/CRM font fréquemment une requête par action UI, parfois des dizaines. Ajoutez 30–60 ms de RTT VPN et un workflow avec 200 appels séquentiels devient une pause café. C’est pourquoi une « montée en bande passante » ne règle pas : le problème est le délai, pas le débit.

Sources typiques :

Concentrateur VPN éloigné des utilisateurs (mauvaise géographie).
Routage en boucle : utilisateur → VPN → datacenter → SaaS → repasse par le VPN, à cause du full tunnel et de la « sécurité ».
DNS forçant des chemins internes quand l’externe serait plus rapide (ou inversement).
RDP/ICA sur VPN sur Wi‑Fi avec bufferbloat (pics de latence sous charge).

Perte de paquets et jitter : le bouton « gel »

La perte affecte tout, mais elle touche particulièrement les applications interactives et bavardes. Un taux de perte de 0,5 % peut transformer une bonne journée en tempête de tickets. Le chiffrement VPN rend aussi la classification QoS plus difficile à moins d’en tenir compte.

Sources courantes :

Wi‑Fi grand public, surtout en environnements encombrés.
Congestion du FAI et shaping en heures de pointe.
VPNs basés sur UDP sur des réseaux qui dépriorisent l’UDP.
Saturation CPU du concentrateur VPN (la crypto n’est pas gratuite).

MTU et MSS : la catégorie « marche jusqu’à ce que ça ne marche plus »

L’encapsulation ajoute de l’overhead. Si vous ne l’en tenez pas compte, vous obtenez fragmentation ou blackholing. Le symptôme classique : la connexion fonctionne, la navigation fonctionne, puis un export de rapport se bloque à jamais. Ou les pièces jointes expirent. Ou une page se charge à moitié et s’arrête.

Sources courantes :

ICMP bloqué quelque part sur le chemin, brisant la PMTUD.
Overhead VPN non compensé par le clamp MSS.
Tunnels mixtes (ex. VPN imbriqués) avec MTU incohérentes.

DNS et routage : les saboteurs silencieux

Les pannes VPN ressemblent souvent à des pannes applicatives parce que la résolution et le routage décident quel serveur vous atteignez. Le split DNS peut être correct, mais seulement si le client peut atteindre le résolveur de façon fiable et l’utilise de façon cohérente.

Schémas qui causent des problèmes :

L’ERP résout vers une IP privée, mais le split tunnel ne la route pas.
Plusieurs suffixes DNS poussent le client à essayer d’abord le mauvais nom (repli lent).
Les requêtes DNS passent par le VPN, mais les réponses vont direct (ou inversement) et sont droppées.

État de session et timeouts d’inactivité : théâtre des déconnexions en journée

Les sessions ERP/CRM peuvent être des cookies HTTP, des JWT, des sessions DB ou des WebSockets longue durée. Les VPN ajoutent une autre couche de session, et entre les deux se trouvent NATs et pare-feu avec timers d’inactivité. Quand une couche expire silencieusement, l’utilisateur subit un « gel » jusqu’à ce que l’application abandonne.

C’est là que les keepalives et les timeouts comptent. Pas une légende. De l’ingénierie.

Blague #1 : Un VPN ressemble à un ascenseur : tout le monde ne le remarque que lorsqu’il s’arrête entre deux étages.

Tâches pratiques : commandes, sorties et décisions (12+)

Ce sont des vérifications pratiques que vous pouvez exécuter depuis un jump host Linux, une passerelle VPN ou une VM de dépannage proche du segment utilisateur. Les sorties ci‑dessous sont représentatives. Utilisez-les pour décider quoi corriger ensuite.

Task 1 — Confirmer la route vers le point de terminaison ERP/CRM

cr0x@server:~$ ip route get 10.42.8.25
10.42.8.25 via 10.8.0.1 dev tun0 src 10.8.0.23 uid 1000
    cache

Ce que cela signifie : Le trafic vers 10.42.8.25 passe par l’interface tunnel VPN (tun0) via 10.8.0.1.

Décision : Si cela devrait être en split-tunnel (ex. SaaS), changez la politique. S’il doit passer par le VPN, continuez à diagnostiquer la santé du tunnel.

Task 2 — Vérifier la résolution DNS et si elle correspond à votre intention

cr0x@server:~$ getent hosts erp.internal.example
10.42.8.25     erp.internal.example

Ce que cela signifie : Le nom résout en une adresse privée.

Décision : Assurez-vous que le routage inclut 10.42.0.0/16 via le VPN. Si les utilisateurs doivent atteindre une IP publique/SaaS, corrigez le split DNS ou le forwarding conditionnel.

Task 3 — Mesurer la latence de base et le jitter (vite et sale)

cr0x@server:~$ ping -c 20 10.42.8.25
PING 10.42.8.25 (10.42.8.25) 56(84) bytes of data.
64 bytes from 10.42.8.25: icmp_seq=1 ttl=62 time=38.2 ms
64 bytes from 10.42.8.25: icmp_seq=2 ttl=62 time=41.7 ms
64 bytes from 10.42.8.25: icmp_seq=3 ttl=62 time=120.5 ms
...
--- 10.42.8.25 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19021ms
rtt min/avg/max/mdev = 37.8/52.3/120.5/18.4 ms

Ce que cela signifie : Pas de perte, mais des pics de jitter (max 120 ms). Ça ressemble à des « gels » dans les applis interactives.

Décision : Investiguer bufferbloat/shaping (routeur domestique, uplink FAI), queueing VPN ou concentrateur surchargé. Ne touchez pas encore à l’ERP.

Task 4 — Détecter la perte de paquets sous charge avec un ping long

cr0x@server:~$ ping -i 0.2 -c 200 10.42.8.25
...
--- 10.42.8.25 ping statistics ---
200 packets transmitted, 196 received, 2% packet loss, time 40123ms
rtt min/avg/max/mdev = 39.1/55.7/310.2/42.8 ms

Ce que cela signifie : 2 % de perte suffit à ruiner un ERP bavard, surtout sur TCP.

Décision : Prioriser la correction de la perte : Wi‑Fi, FAI, policing UDP, ou drops du dispositif VPN. Envisagez de changer le transport VPN, d’ajuster les keepalives et d’imposer le filaire pour les utilisateurs critiques.

Task 5 — Vérifier le Path MTU avec un ping « ne pas fragmenter »

cr0x@server:~$ ping -M do -s 1472 -c 3 10.42.8.25
PING 10.42.8.25 (10.42.8.25) 1472(1500) bytes of data.
ping: local error: message too long, mtu=1420
ping: local error: message too long, mtu=1420
ping: local error: message too long, mtu=1420

Ce que cela signifie : L’MTU effective sur le chemin est 1420, pas 1500.

Décision : Clamp MSS ou régler le MTU du tunnel pour éviter fragmentation/blackholes. Si ICMP est bloqué, corrigez cela aussi — sinon vous continuerez à chasser des fantômes.

Task 6 — Confirmer le MTU de l’interface sur le client/passerelle VPN

cr0x@server:~$ ip link show tun0
7: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1400 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 500
    link/none

Ce que cela signifie : Le MTU du tunnel est 1400. C’est courant pour certains setups VPN, mais il doit refléter la réalité.

Décision : Si votre test PMTU montre 1420, 1400 est sûr. Si le PMTU est plus petit que le MTU du tunnel, vous fragmenterez ou subirez des blackholes — ajustez.

Task 7 — Vérifier le clamp TCP MSS sur une passerelle Linux (iptables)

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

Ce que cela signifie : Les paquets SYN sortant par tun0 auront leur MSS ajustée au PMTU.

Décision : Si des problèmes MTU sont suspectés et que ceci manque, ajoutez-le (ou l’équivalent sur votre firewall). S’il est présent, cherchez ailleurs.

Task 8 — Confirmer le transport VPN et éviter TCP-over-TCP quand possible

cr0x@server:~$ sudo ss -Htanp | grep -E 'openvpn|wg|strongswan' | head
ESTAB 0 0 10.0.0.5:1194 198.51.100.20:51432 users:(("openvpn",pid=1342,fd=6))

Ce que cela signifie : Le serveur OpenVPN utilise une session TCP (ESTAB) sur le port 1194.

Décision : Si vous tunnelisez beaucoup de trafic TCP applicatif, envisagez fortement un transport VPN basé sur UDP (ou WireGuard/IPsec) sauf contrainte. Le VPN TCP peut marcher, mais il est fragile sous perte.

Task 9 — Vérifier l’impact des timeouts de firewall/NAT (conntrack)

cr0x@server:~$ sudo conntrack -S
cpu=0 found=23145 invalid=12 insert=89234 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=123

Ce que cela signifie : Un non‑zéro invalid et beaucoup de search_restart peuvent indiquer du stress. Ce n’est pas une preuve, mais une odeur.

Décision : Si les utilisateurs se plaignent de drops sous charge, examinez la taille de la table conntrack et les timeouts. Augmentez la capacité ou réduisez le churn de sessions (ex. split tunnel pour SaaS).

Task 10 — Voir si vous atteignez les limites de la table conntrack

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

Ce que cela signifie : Vous êtes proche de la limite. Quand la table se remplit, de nouveaux flux sont droppés. Les utilisateurs appellent ça « gel ».

Décision : Augmenter nf_conntrack_max (et la RAM), réduire le trafic full-tunnel inutile, ou scaler la passerelle.

Task 11 — Identifier si la passerelle est CPU-bound (crypto)

cr0x@server:~$ top -b -n 1 | head -n 12
top - 12:43:11 up 31 days,  4:02,  2 users,  load average: 7.92, 7.10, 6.55
Tasks: 221 total,   1 running, 220 sleeping,   0 stopped,   0 zombie
%Cpu(s):  6.1 us,  2.0 sy,  0.0 ni, 75.2 id, 16.3 si,  0.0 st
MiB Mem :  32000.0 total,  1100.3 free,  9800.2 used,  21100.1 buff/cache
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 1342 root      20   0  1450m  220m   12m S  220.0   0.7  80:12.43 openvpn

Ce que cela signifie : Softirq élevé (si) et un process VPN consommant plusieurs cœurs. Cela peut indiquer un goulet de traitement des paquets.

Décision : Activer AES-NI/offload crypto si disponible, tuner les interruptions/RPS, ou migrer vers une pile VPN plus efficace. Parfois la solution est « acheter une machine plus grosse », et oui, c’est de l’ingénierie.

Task 12 — Vérifier les erreurs/drops d’interface sur la passerelle

cr0x@server:~$ ip -s link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq state UP mode DEFAULT group default qlen 1000
    RX:  bytes  packets  errors  dropped  missed  mcast
    9876543210  8123456  0       12453    0       112233
    TX:  bytes  packets  errors  dropped  carrier collsns
    8765432109  7456789  0       9821     0       0

Ce que cela signifie : Il y a des drops. Certains drops sont normaux sous shaping, mais une croissance persistante pendant les plaintes est un indice.

Décision : Inspecter le qdisc, les tailles de ring NIC et les politiques de shaping. Si les drops corrèlent avec les blocages ERP, c’est un problème réseau, pas ERP.

Task 13 — Valider QoS/discipline de queue sur Linux (contrôle du bufferbloat)

cr0x@server:~$ tc qdisc show dev eth0
qdisc fq_codel 0: root refcnt 2 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn

Ce que cela signifie : fq_codel aide à réduire le bufferbloat et la latence sous charge.

Décision : Si vous voyez un pfifo_fast basique ou des buffers énormes et que les utilisateurs se plaignent de gels lors d’uploads, implémentez un AQM moderne (fq_codel/cake) là où c’est possible.

Task 14 — Capturer une preuve de blackholing MTU avec tcpdump

cr0x@server:~$ sudo tcpdump -ni tun0 host 10.42.8.25 and icmp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on tun0, link-type RAW (Raw IP), snapshot length 262144 bytes
12:47:01.112233 IP 10.8.0.23 > 10.42.8.25: ICMP echo request, id 3921, seq 1, length 1480
12:47:01.112987 IP 10.42.8.25 > 10.8.0.23: ICMP unreachable - need to frag (mtu 1420), length 556

Ce que cela signifie : PMTUD fonctionne (vous avez reçu un « need to frag » avec un MTU). Bien — maintenant cloquez le MSS et stoppez les paquets surdimensionnés.

Décision : Si vous ne voyez jamais l’ICMP « need to frag », suspectez un filtrage ICMP et corrigez-le, ou fixez un MTU conservateur.

Task 15 — Valider la reachabilité applicative et le temps de handshake TLS

cr0x@server:~$ curl -sk -o /dev/null -w "dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n" https://erp.internal.example/login
dns=0.004 connect=0.037 tls=0.210 ttfb=0.612 total=0.613

Ce que cela signifie : Le handshake TLS prend 210 ms ; le time-to-first-byte est 612 ms. Ça peut être normal, mais si ça explose pendant des « gels », vous avez une instabilité de chemin ou une saturation backend.

Décision : Si DNS/connect/tls fluctuent, corrigez le réseau/VPN. Si seul le TTFB augmente alors que les timings réseau sont stables, enquêtez sur les couches web/app/base de données.

Task 16 — Vérifier les routages asymétriques (cassent souvent les dispositifs à état)

cr0x@server:~$ traceroute -n 10.42.8.25 | head -n 8
traceroute to 10.42.8.25 (10.42.8.25), 30 hops max, 60 byte packets
 1  10.8.0.1   2.011 ms  1.902 ms  2.144 ms
 2  10.10.0.1  8.220 ms  8.101 ms  8.333 ms
 3  10.42.0.1  35.009 ms  34.882 ms  35.120 ms
 4  10.42.8.25 38.551 ms  38.420 ms  38.600 ms

Ce que cela signifie : Le chemin aller semble sain. L’asymétrie concerne le chemin de retour, vous devez donc toujours vérifier le routage côté sous‑réseau ERP.

Décision : Si les serveurs ERP renvoient le trafic via un autre pare‑feu que celui qui a vu le SYN, vous verrez des stalls et des resets « aléatoires ». Corrigez la symétrie de routage ou utilisez des règles sans état là où c’est approprié.

Concevoir le VPN pour les applications métiers, pas pour les exploits

Décider : full tunnel vs split tunnel (avec règles responsables)

Le full tunnel est attractif car il donne l’impression de contrôle : « tout le trafic passe par nous ». Il transforme aussi votre VPN en internet du bureau pour chaque utilisateur distant, ce qui est une excellente façon d’apprendre ce que « capacity planning » signifie en temps réel.

Pour ERP/CRM, la meilleure réponse est généralement le tunneling sélectif :

Tunnelisez ce qui doit être privé : ERP on‑prem, APIs internes, services de fichiers liés aux workflows ERP.
Ne pas hairpinner le SaaS : si votre CRM est SaaS, le router via le bureau ajoute latence et domaines de panne sans gain fonctionnel.
Utilisez le split DNS avec précaution : les noms internes résolvent en interne ; les noms publics résolvent publiquement. Gardez ça déterministe.

Les équipes sécurité craignent souvent que le split tunnel signifie « moins sécurisé ». Plus précisément : le split tunnel exige de concevoir des contrôles intentionnels (EDR, posture des appareils, protections DNS et politiques d’egress), pas d’accidentellement tout forcer via hairpinning.

Choisir le bon transport : UDP quand possible, TCP seulement si forcé

Pour les applications métiers interactives, le tunneling basé sur UDP est généralement plus tolérant en cas de perte car il évite les boucles de rétroaction TCP-over-TCP. WireGuard et IPsec performent bien et sont opérationnellement sains. OpenVPN peut convenir aussi, mais évitez le transport TCP sauf contrainte.

Si le réseau bloque l’UDP, vous pouvez réussir avec TCP — attendez‑vous simplement à passer plus de temps sur MTU/MSS et tunings keepalive, et ne prétendez pas que c’est « tout aussi bon ».

Rendre le MTU ennuyeux : le définir, le claquer, le surveiller

Les problèmes MTU sont classiques car intermittents et dépendants de la taille de la charge. Résolvez‑les systématiquement :

Mesurez le PMTU effectif à travers le tunnel.
Définissez le MTU du tunnel légèrement en dessous.
Clampez le TCP MSS à la sortie du tunnel en fonction du PMTU.
Autorisez les ICMP « fragmentation needed » (type 3 code 4) à travers les pare‑feu pertinents.

Si quelqu’un dit « nous bloquons l’ICMP pour la sécurité », donnez‑lui un pager. Pas comme une menace. Comme expérience d’apprentissage.

Garder les connexions vivantes (parce que les middleboxes oublient)

Les timers d’inactivité ne sont pas théoriques. Ils sont réglés par des NAT, des pare‑feu et parfois le concentrateur VPN lui‑même. Quand un client ERP laisse une session idle pendant que l’utilisateur lit un écran, le transport sous‑jacent peut devenir inactif aussi.

Utilisez :

Keepalives VPN à un intervalle inférieur au plus court timeout d’état sur le chemin.
Keepalives applicatifs quand disponibles (ping/pong WebSocket, paramètres de keepalive DB).
Tuning des timeouts de session du pare‑feu pour les flux applicatifs reconnus.

Réduire les dépendances bavardes : proximité couche applicative ou apps publiées

La manière la plus fiable de faire tenir un ERP bavard sur un réseau pas toujours parfait est d’arrêter d’envoyer chaque aller‑retour sur le VPN. Deux patterns courants :

Bureau virtuel / application publiée proche de l’ERP (RDP/ICA) : seuls pixels/keystrokes traversent le WAN. Vous échangez des préférences UX contre de la stabilité.
Frontends web et APIs proches de la base de données : gardez les appels DB bavards à l’intérieur du datacenter, pas à travers le VPN.

Oui, c’est architectural. C’est le but. On ne peut pas « tuner » la physique indéfiniment.

Observer comme un adulte : mesurer l’expérience utilisateur, pas seulement le tunnel up/down

« VPN connecté » est un métrique de vanité. Vous avez besoin de :

RTT et perte vers les sous‑réseaux internes clés.
Paquets droppés sur le tunnel, rekeys, renégociations.
CPU passerelle, softirq, drops NIC.
Timings applicatifs (TTFB, taux d’erreur, drops de session).

Corrélez. Les rapports de gel qui coïncident avec des drops passerelle sont réseau. Les rapports qui coïncident avec des attentes de verrou DB sont applicatif. Votre travail est d’arrêter le manège des blâmes.

Trois mini-récits tirés de la vie d’entreprise

Mini‑récit n°1 — L’incident causé par une mauvaise hypothèse

L’entreprise venait de déplacer sa couche web ERP dans un sous‑réseau privé et l’a publiée via un VPN. Le personnel distant s’est plaint que « chaque après‑midi » l’ERP se figeait lors de l’upload de PDFs de factures. L’équipe infra voyait des graphiques propres : tunnels VPN up, CPU ok, bande passante non saturée. Ils ont logué « bug ERP » et escaladé auprès du vendeur.

Le vendeur a demandé des HAR logs. Les logs montraient un schéma : les petites API réussissaient, mais la requête d’upload stagnait puis expirait. Quelqu’un a évoqué le MTU. La pièce s’est tue — le MTU est le genre de chose que l’on se rappelle exister juste avant qu’il ne ruine votre semaine.

Ils ont testé le PMTU à travers le tunnel et trouvé un MTU effectif de 1412 à cause d’un équipement WAN en amont. Le VPN était configuré avec MTU 1500 parce que « Ethernet c’est 1500 », ce qui est vrai autant que « le déjeuner est à midi » : ça dépend d’où vous êtes et qui décide.

La correction fut simple : clamp MSS sur la passerelle et définir le MTU du tunnel de façon conservatrice. Les freezes d’upload ont disparu immédiatement. La vraie leçon du postmortem n’était pas le MTU. C’était l’hypothèse erronée que « si les petites requêtes fonctionnent, le réseau va bien ». La sensibilité à la taille du payload est un indice important.

Mini‑récit n°2 — L’optimisation qui a échoué

Une autre organisation voulait « accélérer » le VPN. Quelqu’un a remarqué que l’UDP était parfois bloqué sur les Wi‑Fi d’hôtels, donc ils ont switché le VPN sur TCP globalement « pour la fiabilité ». Ça a aidé quelques voyageurs à se connecter plus souvent. Les tickets ont baissé pendant deux semaines. Puis ce fut la clôture mensuelle.

Pendant la période critique, la réactivité ERP est passée de « correcte » à « figée » pour certains utilisateurs distants. Le VPN restait connecté, mais le débit s’effondrait dès qu’il y avait une perte légère. Les utilisateurs rapportaient que l’ERP se bloquait 20–60 secondes puis rattrapait tout d’un coup.

Les captures de paquets montraient le comportement classique TCP-over-TCP : retransmissions imbriquées, fenêtres de congestion qui s’effondraient, et le tunnel amplifiant la dégradation — dans le mauvais sens. Leur « optimisation » avait amélioré la connectivité dans des réseaux hostiles mais rendu la gigue normale bien plus destructrice.

La correction n’était pas de ridiculiser l’auteur du changement. C’était de rétablir l’UDP par défaut, d’ajouter un profil fallback TCP pour les environnements qui en ont besoin, et de faire choisir les clients selon la reachabilité. La fiabilité n’est pas « choisir TCP ». La fiabilité, c’est « concevoir pour le réseau que vous avez vraiment ».

Mini‑récit n°3 — La pratique ennuyeuse mais correcte qui a sauvé la journée

Une entreprise de fabrication exploitait un ERP on‑prem avec un client lourd qui parlait à une base de données et à un partage de fichiers. Le travail à distance augmentait, et ils savaient que le VPN deviendrait une nouvelle dépendance. Ils ont fait deux choses peu sexy dès le départ : documenter les flux ERP critiques (quels serveurs, quels ports, quels protocoles) et mettre en place des sondes continues depuis le subnet VPN vers ces endpoints.

Des mois plus tard, une mise à jour de politique firewall est passée. Personne n’a touché à la config VPN. Pourtant, le lendemain matin, les utilisateurs distants voyaient des freezes intermittents à l’ouverture des pièces jointes. Le helpdesk a escaladé rapidement parce que le tableau de bord de monitoring montrait déjà un changement : le temps de réponse SMB depuis le subnet VPN avait bondi, et il y avait de nouveaux resets TCP sur le chemin du serveur d’attachements.

Parce que l’équipe avait la cartographie des flux, elle n’a pas perdu une demi-journée à tester des théories au hasard. Ils ont trouvé un mismatch de timeout de session sur un pare‑feu pour les flux SMB venant du pool VPN et ont reverté cette politique spécifique. L’éditeur ERP n’a jamais été sollicité. La finance n’a jamais eu à ressaisir quoi que ce soit.

Rien d’héroïque. C’est pourquoi ça a marché. L’observabilité ennuyeuse et les baselines connues battent le drame à chaque fois.

Erreurs courantes : symptômes → cause racine → correction

Voici la partie que vous pouvez coller dans un système de tickets pour paraître sage.

1) « La connexion marche, mais les uploads/downloads se bloquent »

Symptômes : Pièces jointes, export de rapports ou pages spécifiques stagnent ; petites API OK.
Cause racine : Blackholing MTU ou fragmentation ; PMTUD cassée à cause du filtrage ICMP ; pas de clamp MSS.
Correction : Mesurer PMTU, définir MTU tunnel de façon conservatrice, clamp MSS à la sortie, autoriser ICMP « frag needed ».

2) « Ça se fige pendant 30 secondes, puis rattrape »

Symptômes : Stalls longs intermittents ; reprend ; surtout sur Wi‑Fi chargé ou en heures de pointe.
Cause racine : Perte/jitter avec backoff de retransmission TCP ; parfois transport VPN TCP amplifiant la perte.
Correction : Privilégier le transport UDP ; réduire les sources de perte (filaire, meilleur Wi‑Fi), appliquer AQM (fq_codel/cake), vérifier drops passerelle.

3) « Le VPN est connecté mais l’ERP dit ‘impossible de joindre le serveur’ »

Symptômes : Tunnel up ; nom résolu ; connexion échoue ou timeout.
Cause racine : Routes split tunnel manquantes ; l’ERP résout en IP interne mais le client route via la gateway par défaut ; ACL manquantes.
Correction : Corriger le push de routes/politiques ; confirmer avec ip route get ; aligner DNS et routage.

4) « Ça marche le matin, ça casse l’après‑midi »

Symptômes : Corrélation horaire ; plus de plaintes lors des appels/uploads.
Cause racine : Congestion et bufferbloat ; saturation uplink WAN ; CPU passerelle sous pic.
Correction : Shaper le trafic ; implémenter AQM ; scaler la passerelle ; arrêter le hairpinning SaaS via VPN.

5) « Seuls certains utilisateurs sont affectés, et ça change »

Symptômes : Sous‑ensembles d’utilisateurs voient des gels ; difficile à reproduire.
Cause racine : Anycast/différences géo vers les POP VPN, variance de chemin ISP, conditions Wi‑Fi, ou différences MTU avec tunnels imbriqués.
Correction : Standardiser les profils clients ; proposer des endpoints VPN régionaux ; recueillir mesures côté client (RTT/perte/MTU).

6) « RDP vers le bureau ERP se fige, mais la navigation web va bien »

Symptômes : RDP/ICA saccade ou gèle ; internet général OK.
Cause racine : UDP bloqué ou shaped, ou jitter élevé ; RDP sensible aux pics de latence ; queueing VPN.
Correction : Assurer un UDP stable si possible ; appliquer QoS en bordure ; réduire les pics de latence avec AQM ; considérer les paramètres UDP de RDP selon l’environnement.

7) « Ça déconnecte constamment quand les utilisateurs lisent »

Symptômes : Utilisateurs inactifs sont déconnectés ; sessions réinitialisées après quelques minutes d’inactivité.
Cause racine : Timeouts NAT/pare‑feu plus courts que les attentes applicatives ; keepalives manquants.
Correction : Mettre des keepalives VPN ; tuner les timeouts de session ; s’assurer que les flux longue durée sont permis et correctement tracés.

Blague #2 : Si votre plan de dépannage est « redémarrer le VPN », vous ne réparez pas le système — vous pratiquez un rituel pour les dieux du paquet.

Listes de contrôle / plan pas-à-pas

Pas‑à‑pas : stabiliser ERP/CRM sur VPN en 10 mouvements

Inventaire des flux : endpoints ERP/CRM, ports, protocoles, dépendances (shares, IdP, APIs).
Décider l’intention de routage : split tunnel pour SaaS ; tunneliser seulement les réseaux internes qui doivent être privés.
Corriger le déterminisme DNS : forwarding conditionnel/split DNS pour que les noms résolvent correctement et de façon consistante.
Mesurer le PMTU à travers le tunnel et standardiser les réglages MTU par profil VPN.
Clamper le MSS en sortie du tunnel pour le TCP.
Privilégier le transport UDP pour le VPN lorsque faisable ; garder TCP fallback comme profil séparé.
Définir des keepalives en dessous du plus court timeout middlebox ; aligner les timers pare‑feu avec la réalité métier.
Implémenter un AQM (fq_codel/cake) en bordure ou sur l’équipement WAN si contrôlé.
Planifier la capacité du concentrateur : CPU (crypto), RAM (conntrack/états), drops NIC et sessions concurrentes.
Monitorer les signaux d’expérience utilisateur : RTT/perte, drops tunnel, échecs DNS, timings HTTP et santé backend.

Checklist : avant de changer quoi que ce soit en production

Pouvez‑vous reproduire le gel et capturer des timestamps ?
Avez‑vous un RTT/perte de baseline depuis un utilisateur connu bon ?
Savez‑vous si le trafic est full-tunnel ou split-tunnel ?
Avez‑vous validé la résolution DNS et que les routes correspondent ?
Avez‑vous testé le PMTU et confirmé le clamp MSS ?
Connaissez‑vous le transport VPN (UDP/TCP) et pourquoi ce choix ?
Avez‑vous vérifié CPU passerelle, drops, utilisation conntrack pendant la fenêtre d’incident ?

Checklist : si vous devez garder le full‑tunnel (la politique l’exige)

Assurez‑vous que l’egress VPN a assez de bande passante et un shaping/AQM sensé.
Évitez de hairpinner le SaaS évident si vous pouvez utiliser des gateways web sécurisées ou des contrôles device à la place.
Épingler les apps métier critiques vers des routes et résolveurs connus‑bons ; éviter le DNS « magique » qui change selon le réseau.
Segmenter les pools VPN (direction/finance vs général) pour que le streaming d’un groupe ne devienne pas le problème de tous.
Logger et alerter sur les renégociations de tunnel, drops passerelle et taux d’échec DNS.

FAQ

1) Devons‑nous utiliser le split tunneling pour ERP/CRM ?

Pour un ERP on‑prem, vous tunnelizerez les sous‑réseaux internes. Pour un CRM/ERP SaaS, le split tunnel est généralement la bonne option pour éviter la latence de hairpin et réduire la charge VPN — si vous disposez de contrôles endpoint et d’un DNS sensé.

2) OpenVPN est‑il « mauvais » pour l’ERP ?

Non. OpenVPN peut très bien fonctionner. Le piège commun est de l’exécuter sur TCP pour l’usage général puis de s’étonner que la performance s’effondre sous perte. Le transport UDP est généralement meilleur pour les applications interactives.

3) Quel MTU devons‑nous définir ?

Mesurez le PMTU sur votre chemin réel. Ensuite choisissez un MTU de tunnel avec une marge. Si vous ne pouvez pas compter sur l’ICMP, choisissez de façon conservatrice et clamppez le MSS. Deviner 1500 parce que « Ethernet » vous assure des nuits blanches.

4) Pourquoi les utilisateurs disent « ça gèle » au lieu de « c’est lent » ?

Parce que beaucoup d’apps bloquent le thread UI en attendant un I/O réseau ou un verrou. La perte de paquets et le backoff de retransmission ressemblent à un gel dur même si le process est vivant.

5) Une montée en bande passante peut‑elle corriger les timeouts ?

Parfois, si vous saturiez un uplink et que tout était mis en file d’attente. Mais la plupart des douleurs ERP/CRM sur VPN sont liées à la latence, au jitter, au MTU ou aux timeouts d’état — pas à la bande passante brute. Mesurez avant d’acheter.

6) Pourquoi ça marche sur un hotspot mobile mais pas sur le Wi‑Fi domestique ?

Comportement last‑mile différent : interférences Wi‑Fi, bufferbloat du routeur, shaping FAI ou gestion UDP. Les hotspots peuvent être des chemins plus propres, ou pires. Le point : ce n’est pas « le VPN », c’est le chemin.

7) Avons‑nous besoin de QoS si tout est chiffré ?

Vous pouvez toujours faire de la QoS sur le tunnel extérieur (par utilisateur/groupe, marquage DSCP avant chiffrement, ou shaping par tunnel). Si vous ne faites rien, le flux le plus bruyant gagne — généralement quelqu’un qui upload une vidéo pendant que la finance poste des écritures.

8) Comment arrêter les déconnexions d’inactivité ?

Définissez des keepalives VPN et alignez les timeouts NAT/pare‑feu. Vérifiez aussi que les rekeys/renégociations ne perturbent pas les sessions longue durée. Si l’app propose son propre keepalive, activez‑le.

9) Le RDP est‑il une bonne solution de contournement pour ERP sur VPN ?

Souvent oui. Si votre ERP est bavard ou utilise SMB/DB directement depuis le client, publier l’application proche des serveurs transforme la douleur WAN en un protocole unique et contrôlable. Ce n’est pas glamour, mais c’est efficace.

10) Quelle est la cause racine la plus fréquente que vous voyez ?

MTU/MSS pour les « blocages à l’upload », et perte/jitter pour les « gels aléatoires ». Troisième place : mauvais choix DNS/routage provoquant hairpin ou mauvais endpoints.

Conclusion : prochaines étapes qui réduisent vraiment les tickets

Les échecs ERP/CRM sur VPN sont prévisibles. Si vous les traitez comme un mystère, vous n’obtiendrez que des mystères. Traitez‑les comme un système avec des propriétés mesurables — RTT, perte, MTU, routage, DNS, timeouts d’état — et ça devient ennuyeux. L’ennui est l’objectif.

Étapes pratiques :

Exécutez le mode opératoire de diagnostic rapide sur un chemin utilisateur affecté et un chemin connu‑bon. Capturez RTT/perte/PMTU et preuves de routage/DNS.
Corrigez MTU/MSS et la gestion ICMP en priorité. C’est peu d’effort et à fort impact.
Cessez de hairpinner le SaaS via le bureau sauf raison validée et spécifique.
Privilégiez le transport VPN basé sur UDP ; gardez TCP en fallback, pas par défaut.
Instrumentez votre passerelle VPN comme si ça comptait : drops, conntrack, CPU/softirq et contrôles d’expérience par chemin vers les endpoints ERP.
Si l’ERP est intrinsèquement bavard, rapprochez l’interaction utilisateur de l’app (apps publiées/VDI) plutôt que d’essayer de perfectionner le WAN.