Le choix de la topologie VPN conditionne les performances, la résilience, la surface d'attaque et la complexité opérationnelle. Cette page documente les modèles principaux, leurs compromis et leurs prérequis d'infrastructure.
Tous les clients VPN se connectent à un concentrateur central (hub). Le hub assure la terminaison des tunnels, l'authentification et le routage vers les ressources internes. Modèle dominant pour l'accès distant des collaborateurs — simple à opérer, facile à monitorer.
Le concentrateur est un goulot d'étranglement par conception. Dimensionner pour le pic de connexions simultanées avec une marge minimale de 30 %. Paramètres clés : nombre de tunnels simultanés, débit agrégé (en Gbit/s), charge CPU pour les opérations cryptographiques (AES-NI indispensable sur x86), et latence de négociation IKEv2 sous charge.
Pour WireGuard, le concentrateur peut être un simple VPS Linux — le protocole est intégré au noyau et les performances par cœur CPU sont excellentes. Pour IPsec avec IKEv2, des appliances dédiées ou des instances cloud dimensionnées sont généralement nécessaires au-delà de 200 connexions simultanées.
Un concentrateur unique est un SPOF (Single Point of Failure) inacceptable pour un accès distant opérationnellement critique. Deux architectures HA :
WireGuard gère nativement le changement d'adresse IP du concentrateur — le client se reconnecte automatiquement. IPsec nécessite MOBIKE (RFC 4555) configuré explicitement côté client et serveur. OpenVPN requiert une reconnexion complète. Tester le comportement de chaque protocole lors d'un failover avant mise en production.
Dans une architecture mesh, chaque site établit des tunnels directs avec tous les autres sites. Pas de concentrateur central — le trafic inter-sites emprunte le chemin le plus court. Latence optimale pour les communications entre bureaux.
La complexité du mesh croît en O(n²) avec le nombre de sites : 4 sites = 6 tunnels, 10 sites = 45 tunnels, 20 sites = 190 tunnels. Au-delà de 5 à 8 sites, l'administration manuelle des clés et des routes devient problématique. Des outils de plan de contrôle comme Headscale (open source, auto-hébergeable) ou Tailscale (SaaS) automatisent la distribution des clés WireGuard et la gestion des routes dans un mesh.
La politique de tunneling détermine quels flux transitent par le tunnel VPN et lesquels sortent directement par l'interface locale du client. C'est l'un des paramètres de déploiement qui a le plus d'impact sur la sécurité réelle — et l'un des moins documentés.
L'intégralité du trafic du client transite par le tunnel VPN et sort par le concentrateur. L'observateur sur le réseau local du client ne voit que du trafic chiffré vers le concentrateur. Aucune fuite DNS possible. Charge sur le concentrateur proportionnelle au trafic total des clients — y compris le trafic cloud (Teams, Office 365, Salesforce) qui n'a pas besoin de passer par le SI interne.
Seul le trafic à destination des plages IP internes (RFC 1918 ou plages spécifiques) entre dans le tunnel. Le trafic Internet sort directement par l'interface locale. Réduit la charge sur le concentrateur et améliore les performances pour les services cloud. Expose le trafic exclu du tunnel aux risques du réseau local de l'utilisateur.
En split tunnel, les requêtes DNS pour les domaines exclus du tunnel sont résolues localement — visibles par tout observateur réseau. Sur un réseau hostile, un attaquant peut inférer les domaines consultés même si le contenu des échanges est chiffré par HTTPS. Mitigation : forcer toutes les requêtes DNS dans le tunnel, ou déployer DoH/DoT avec un resolver de confiance pour le trafic exclu.
Tout le trafic passe dans le tunnel sauf une liste d'exclusions explicites. Plus sécurisé que le split tunnel classique en termes de surface exposée, mais nécessite une maintenance active de la liste d'exclusions à mesure que de nouveaux services cloud sont adoptés. Configuration recommandée pour les environnements avec des exigences de confidentialité élevées mais contraintes de performance sur certains services.
| Mode | Sécurité réseau | Performance | Charge concentrateur | Cas d'usage |
|---|---|---|---|---|
| Full tunnel | Maximale | Réduite (latence) | Élevée | Données sensibles, secteurs réglementés |
| Split tunnel | Partielle | Optimale | Faible | Usage général, télétravail courant |
| Split inversé | Élevée | Bonne | Moyenne | Compromis sécurité/performance |
Le VPN traditionnel accorde un accès réseau après authentification initiale. Une fois le tunnel établi, l'utilisateur peut atteindre potentiellement toutes les ressources du réseau interne accessibles depuis son segment — c'est le problème du mouvement latéral.
ZTNA (Zero Trust Network Access, NIST SP 800-207) remplace l'accès réseau par un accès applicatif granulaire. Chaque requête est évaluée indépendamment sur : l'identité de l'utilisateur (IdP + MFA), la posture du terminal (MDM — OS à jour, antivirus, chiffrement disque), et le contexte (heure, localisation, comportement habituel). Le Policy Decision Point (PDP) évalue, le Policy Enforcement Point (PEP) applique.
Une organisation qui n'a pas ces trois fondations en place ne peut pas migrer vers ZTNA sans investissement préalable significatif — souvent plus coûteux que le déploiement ZTNA lui-même. VPN + microsegmentation interne est souvent la voie la plus réaliste pour une PME sans ces prérequis.
La page Sécurité avancée détaille le problème du mouvement latéral et les mesures de microsegmentation complémentaires au VPN.