Le réseau domestique : une frontière mal comprise
Un collaborateur en télétravail sur son réseau domestique n'est pas dans le réseau de l'entreprise — même avec un VPN actif. Le VPN chiffre le transit entre son terminal et l'infrastructure de l'organisation, mais le réseau local domestique reste un environnement non maîtrisé.
La surface d'attaque réelle d'un poste en télétravail inclut : le routeur domestique (souvent avec firmware non mis à jour depuis des années — la base installée de routeurs grand public est une des surfaces les moins patchées d'Internet), les équipements IoT sur le même réseau (ampoules connectées, caméras, assistants vocaux — certains sans possibilité de mise à jour), les autres terminaux du foyer (ordinateurs personnels des enfants, tablettes sans MDM), et le réseau des voisins si le Wi-Fi est mal configuré.
Un attaquant qui compromet le routeur du collaborateur peut intercepter du trafic avant que le tunnel VPN ne soit établi — notamment les requêtes DNS si le client VPN ne démarre pas automatiquement au démarrage du système. Il peut également tenter une attaque ARP spoofing pour intercepter le trafic local avant la connexion VPN.
Déployer le client VPN en mode always-on avec kill switch : le terminal ne peut pas accéder à Internet si le tunnel VPN n'est pas actif. Cette configuration élimine la fenêtre d'exposition entre le démarrage du poste et l'établissement du tunnel. Sur Windows, Network Lock via OpenVPN ou la fonctionnalité native de kill switch de WireGuard implémentent ce comportement.
BYOD : la limite structurelle du VPN traditionnel
Le Bring Your Own Device introduit un problème fondamental : l'organisation déploie un agent VPN sur un terminal qu'elle ne contrôle pas. Elle ne peut pas garantir que le terminal est à jour, qu'il dispose d'un antivirus actif, que le disque est chiffré, ou que l'utilisateur n'y a pas installé un logiciel compromis.
Un VPN traditionnel qui ouvre un accès réseau large à un terminal personnel mal sécurisé aggrave la surface d'attaque plutôt qu'il ne la réduit — le terminal personnel non géré devient un vecteur d'entrée direct dans le SI de l'organisation, avec l'accès réseau offert par le VPN.
Nomadisme et accès depuis l'étranger
Un collaborateur qui se connecte depuis un pays tiers expose l'organisation à deux catégories de risques distincts qui ne répondent pas aux mêmes mesures techniques.
Risque réseau : les environnements non maîtrisés
Les réseaux Wi-Fi d'hôtels, d'aéroports, de conférences et d'espaces de coworking sont des environnements hostiles pour un usage professionnel. Les attaques documentées sur ces réseaux incluent : Evil Twin (faux point d'accès imitant le réseau légitime), captive portal malveillant (injection de contenu dans le trafic non chiffré avant connexion VPN), et écoute passive du trafic non chiffré. Le VPN en mode always-on est la mesure adéquate pour ce risque.
Des incidents ciblés ont été documentés lors de conférences sectorielles spécialisées — cybersécurité, défense, énergie — où des attaquants déploient des faux points d'accès en sachant que les participants ont des accès à des informations sensibles. Ce n'est pas un risque théorique.
Risque juridictionnel : le point de sortie VPN
Si le point de sortie VPN est localisé dans le même pays que le collaborateur nomade, le tunnel chiffré protège le transit depuis le terminal jusqu'au point de sortie — mais le trafic décrypté sort ensuite dans la juridiction locale. Un observateur local (autorité locale, FAI) voit le trafic décrypté depuis le point de sortie VPN.
Pour une protection complète, le point de sortie VPN doit être localisé dans une juridiction de confiance — typiquement en Europe pour une organisation française. Vérifier la localisation réelle des points de sortie du fournisseur, pas seulement leur présentation marketing.
Cas particuliers : pays avec restrictions VPN
Dans plusieurs pays, l'usage de protocoles VPN commerciaux est légalement restreint ou techniquement bloqué. La Chine (Great Firewall) bloque les protocoles VPN commerciaux par deep packet inspection — WireGuard, OpenVPN sur UDP et IPsec sont détectés et bloqués. Des techniques d'obfuscation (Shadowsocks, obfs4, tunnels WebSocket sur HTTPS) peuvent contourner cette détection, mais leur légalité en Chine est ambiguë pour des entités étrangères.
Des restrictions similaires s'appliquent en Russie, en Iran, aux Émirats arabes unis (en partie), et dans plusieurs pays d'Asie centrale. Un collaborateur envoyé dans ces zones doit être informé en amont des contraintes légales locales, équipé d'une solution approuvée (y compris potentiellement une ligne de données mobiles avec un opérateur local), et conscient que l'utilisation d'un VPN non approuvé peut constituer une infraction locale.
VPN site-à-site : interconnexion de bureaux
Pour une organisation avec plusieurs bureaux géographiques, les tunnels VPN site-à-site permettent d'interconnecter les réseaux locaux des différents sites via Internet chiffré, sans transiter par un concentrateur central.
La configuration standard : IPsec en mode tunnel entre les routeurs ou pare-feux de chaque site. Les plages IP des deux sites sont routées à travers le tunnel. Les connexions inter-sites sont transparentes pour les utilisateurs — ils accèdent aux ressources de l'autre site comme s'ils étaient sur le même réseau local.
Points de surveillance opérationnelle : le renouvellement automatique des Security Associations (SA) entre sites. Une SA expirée sans renouvellement produit une coupure silencieuse du tunnel — le trafic inter-sites échoue sans message d'erreur explicite côté utilisateur. Monitorer l'état des tunnels site-à-site avec des vérifications régulières (ping inter-site, alertes SNMP ou Netflow) est indispensable pour une infrastructure critique.
Split DNS : résolution intelligente selon la destination
Le split DNS est une configuration où les requêtes DNS à destination de domaines internes (intranet.entreprise.fr, app.local) sont résolues par les serveurs DNS internes via le tunnel VPN, tandis que les domaines publics sont résolus par les résolveurs publics locaux (ou via le tunnel selon la politique full/split).
Cette configuration réduit la charge sur les serveurs DNS internes, améliore la performance des résolutions publiques, et maintient la résolution correcte des noms internes depuis l'extérieur. Elle nécessite une configuration explicite sur le client VPN (via les paramètres DHCP poussés par le serveur VPN, ou via la configuration du système d'exploitation).
Le risque à surveiller : si les domaines internes ne sont pas exhaustivement listés dans la configuration split DNS, certaines requêtes internes peuvent partir vers les résolveurs publics — exposant la structure interne des noms de domaine à un observateur réseau ou aux résolveurs tiers.
Checklist avant déploiement télétravail
- Les terminaux distants sont-ils tous gérés et inventoriés dans un MDM ? Si non, ZTNA ou vérification de posture plutôt que VPN à accès réseau large.
- Le MFA est-il activé sur la connexion VPN ? Sans MFA, la compromission d'un mot de passe suffit à accéder au SI interne.
- Le client VPN est-il configuré en always-on avec kill switch ? Sans ça, la fenêtre entre le démarrage et la connexion VPN est exposée.
- La politique de split tunneling est-elle documentée et auditée ? Le trafic exclu du tunnel est-il identifié et son niveau d'exposition accepté ?
- Les collaborateurs en déplacement international sont-ils informés des restrictions VPN dans les pays à risque avant le départ ?
- Les logs d'accès VPN sont-ils intégrés dans le SIEM pour détection d'anomalies (connexions depuis des IP inhabituelles, horaires atypiques) ?
- Le fournisseur VPN (si managé) a-t-il signé un DPA conforme RGPD ? Sa juridiction est-elle compatible avec vos exigences de confidentialité ?
La page sur VPN, Zero Trust et SASE fournit la grille de décision pour choisir entre ces approches selon le contexte organisationnel. La page sur le déploiement détaille les configurations techniques (PKI, MFA, split tunneling) mentionnées dans cette checklist.