VPN, tunnels, bastions et interconnexions protégées
- Accueil
- Fondations techniques
- Réseaux
- VPN, tunnels, bastions et interconnexions protégées
Parcours « Administrateur système » — étape 09/15
08Filtrage, segmentation, NAC et Zero Trust10Active Directory délégations et chemins d’attaque
VPN, tunnels, bastions et interconnexions protégées
Section intitulée « VPN, tunnels, bastions et interconnexions protégées »Un VPN (Virtual Private Network) prolonge un réseau privé à travers un réseau qui ne l’est pas, le plus souvent internet. Il le fait au moyen d’un tunnel : des paquets emballés dans d’autres paquets, généralement chiffrés. Le tunnel règle la question du transport ; il ne dit rien de ce que l’utilisateur a le droit d’atteindre une fois arrivé. Cette fiche traite des tunnels, de l’accès distant sécurisé avec bastion et authentification forte, et des interconnexions entre sites et clouds, avec leurs limites.
Un tunnel sous une montagne permet de traverser un terrain hostile sans s’y exposer, mais encore faut-il décider qui a le droit d’y entrer et où il mène. Ce chapitre présente les passages protégés qui relient des sites ou des personnes éloignées au réseau d’une organisation, et le poste de garde qui contrôle les accès sensibles.
→ Lire l’explication complète de la marmotte
Pourquoi tunneler
Section intitulée « Pourquoi tunneler »Tunnel et encapsulation
Section intitulée « Tunnel et encapsulation »Un tunnel prend un paquet complet, l’enveloppe dans un nouvel en-tête et l’achemine jusqu’à l’autre extrémité, qui le déballe et le remet sur son réseau comme s’il venait d’un voisin. Le réseau traversé ne voit que l’enveloppe. Le chiffrement n’est pas une propriété du tunnel : certains tunnels en ont, d’autres non.
| Tunnel | Encapsulation | Surcoût typique | Chiffrement |
|---|---|---|---|
| IP-in-IP | IP dans IP (protocole 4) | 20 octets | non |
| GRE | IP, protocole 47, puis tout protocole | 24 octets | non |
| VXLAN | Ethernet dans UDP 4789 | 50 octets | non |
| IPsec ESP | ESP (protocole 50), ou UDP 4500 derrière un NAT | environ 50 à 70 octets selon algorithmes | oui |
| WireGuard | UDP, port configurable | 60 octets en IPv4, 80 en IPv6 | oui |
| OpenVPN | TLS sur UDP 1194 par défaut, ou TCP | variable | oui |
| Tunnel SSH | flux TCP dans une session SSH | variable | oui |
GRE (Generic Routing Encapsulation, RFC 2784) et IP-in-IP transportent sans protéger ; on les combine souvent avec IPsec pour faire passer du multicast ou des protocoles de routage. VXLAN (Virtual eXtensible LAN) étend un segment de niveau 2 au-dessus d’IP, pour les centres de données plutôt que pour l’accès distant. IPsec (Internet Protocol Security) chiffre au niveau IP, avec IKEv2 (Internet Key Exchange version 2, RFC 7296) pour l’établissement des clés sur UDP 500 et 4500. WireGuard, intégré au noyau Linux depuis la version 5.6 (2020), mise sur un code réduit et des algorithmes fixes (Curve25519, ChaCha20-Poly1305). OpenVPN et les SSL VPN commerciaux s’appuient sur TLS (Transport Layer Security), soit avec un client lourd qui crée une interface réseau, soit par un portail web qui publie quelques applications. Le tunnel SSH relaie un port (ssh -L 5432:db.interne:5432 bastion) ou fournit un proxy SOCKS (ssh -D 1080) : pratique pour un besoin ponctuel, peu adapté comme accès permanent. Les mécanismes cryptographiques sont détaillés dans TLS ou tunnel VPN IPsec.
Le choix du protocole dépend du contexte plus que de la mode : IPsec reste la langue commune entre équipements de constructeurs différents et avec les clouds publics ; WireGuard brille par sa simplicité entre systèmes qui le supportent ; un SSL VPN passe là où seul le port 443 sort.
Client-à-site, site-à-site, tunnels techniques
Section intitulée « Client-à-site, site-à-site, tunnels techniques »Le VPN client-à-site relie un poste isolé (télétravail, astreinte) au réseau de l’organisation : le client s’authentifie auprès d’un concentrateur et reçoit une adresse interne. Le VPN site-à-site relie deux réseaux par leurs passerelles : les postes ignorent son existence et voient simplement des routes. Les tunnels techniques relient des équipements pour un besoin précis : réplication entre centres de données, liaison de supervision, accès d’un prestataire à une seule application.
Routage, DNS, MTU et politique
Section intitulée « Routage, DNS, MTU et politique »Un tunnel qui monte n’est que la moitié du travail. Il faut des routes : quels préfixes passent dans le tunnel. En full tunnel, tout le trafic du poste emprunte le VPN, y compris vers internet, ce qui permet d’appliquer le filtrage de l’organisation mais charge le concentrateur. En split tunnel, seuls les préfixes internes y passent et le reste sort directement par la connexion locale : plus léger, mais le poste est alors à la fois sur internet et sur le réseau interne, et le trafic internet échappe aux contrôles centraux. Le choix dépend de la manière dont le poste est protégé en dehors du VPN.
Il faut aussi le DNS : les noms internes doivent se résoudre par le serveur interne, sans divulguer les requêtes internes au résolveur du réseau domestique. Il faut enfin régler la MTU (Maximum Transmission Unit), car l’enveloppe mange des octets.
Atelier : diagnostiquer la MTU sur un VPN
Section intitulée « Atelier : diagnostiquer la MTU sur un VPN »Symptôme : la connexion SSH passe, les pages légères s’affichent, mais les gros transferts et certains sites se figent. Le tunnel ajoute ses en-têtes ; un paquet de 1 500 octets ne tient plus dans le lien de 1 500 octets, et le message ICMP « fragmentation nécessaire » qui devrait prévenir l’émetteur est filtré quelque part. C’est le trou noir de la découverte de MTU.
ping -M do -s 1472 10.20.0.10 # 1472 + 8 (ICMP) + 20 (IP) = 1500 : échec ?ping -M do -s 1392 10.20.0.10 # on descend jusqu'à ce que ça passeLa valeur trouvée donne la MTU utilisable dans le tunnel. On corrige en fixant la MTU de l’interface de tunnel (WireGuard prend 1 420 par défaut, pour couvrir le cas IPv6) et en ajustant le MSS (Maximum Segment Size) des connexions TCP à la volée sur la passerelle (MSS clamping), plutôt qu’en ouvrant tout l’ICMP au hasard.
Accès distant sécurisé
Section intitulée « Accès distant sécurisé »Authentification forte et état de l’appareil
Section intitulée « Authentification forte et état de l’appareil »Un VPN protégé par un simple mot de passe est une porte d’entrée pour quiconque a acheté ce mot de passe. L’authentification multifacteur (MFA, Multi-Factor Authentication) est le minimum, de préférence résistante à l’hameçonnage (clés FIDO2, certificats sur matériel). Le contrôle de posture de l’appareil ajoute une seconde question : non plus seulement qui se connecte, mais depuis quoi. Système à jour, chiffrement du disque, antivirus actif, appareil inventorié : un portable non conforme est renvoyé vers un segment de remédiation ou refusé.
Bastion et segmentation
Section intitulée « Bastion et segmentation »Le bastion est un point de passage obligé pour l’administration : l’administrateur se connecte au bastion, qui seul est autorisé à joindre les interfaces de gestion. Les serveurs n’acceptent SSH ou RDP que depuis lui. Un bastion n’est pas un simple serveur SSH exposé : il authentifie fortement, autorise par cible, enregistre les sessions et ne laisse aucun accès direct en dehors de lui. Les solutions de PAM (Privileged Access Management, gestion des accès à privilèges), à ne pas confondre avec les modules d’authentification PAM de Linux (Pluggable Authentication Modules), étendent cette logique : coffre de mots de passe d’administration, injection des secrets sans les révéler, accès accordés pour une durée limitée, enregistrement vidéo ou textuel des sessions.
La segmentation complète le tableau : l’adresse attribuée au client VPN tombe dans un sous-réseau dédié, et le pare-feu décide, par groupe d’utilisateurs, quelles destinations sont permises. Donner accès à tout le réseau par VPN, c’est offrir à un attaquant le mouvement latéral clés en main ; un tunnel n’est pas une segmentation (voir filtrage, segmentation, NAC et Zero Trust).
Journaliser connexions, commandes et flux
Section intitulée « Journaliser connexions, commandes et flux »Trois niveaux de journaux répondent à trois questions. Les connexions VPN : qui, depuis quelle adresse, quand, avec quel appareil, pendant combien de temps. Les flux : quelles destinations la session a jointes, d’après le pare-feu. Les commandes : ce qui a été fait sur les serveurs, d’après le bastion. Sans les trois, l’enquête qui suit le vol d’un compte s’arrête à « il s’est connecté ».
Cycle de vie et révocation
Section intitulée « Cycle de vie et révocation »Chaque accès a une date de début et devrait avoir une date de fin. Le départ d’un salarié ou la fin d’un contrat de prestation doit révoquer d’un seul geste le compte, le certificat client et les sessions en cours. Les comptes VPN liés à l’annuaire de l’organisation se révoquent avec lui ; les comptes locaux du concentrateur, eux, se font oublier, et c’est précisément pour cela qu’il faut les recenser et les revoir régulièrement.
Interconnexions hybrides
Section intitulée « Interconnexions hybrides »VPN, cloud, SD-WAN, MPLS et secours
Section intitulée « VPN, cloud, SD-WAN, MPLS et secours »Les sites et les clouds se relient par plusieurs moyens : liaisons opérateur MPLS (Multiprotocol Label Switching), SD-WAN (Software-Defined Wide Area Network) qui pilote plusieurs accès internet et des tunnels chiffrés, VPN IPsec vers les passerelles des clouds publics, liaisons privées dédiées. Le VPN sert souvent de chemin principal pour les petits sites et de secours pour les liaisons dédiées. Le détail figure dans MPLS, GMPLS, SD-WAN et overlays opérateurs et cloud networking, VPC/VNet.
Atelier : VPN site-à-site siège et cloud
Section intitulée « Atelier : VPN site-à-site siège et cloud »Le siège utilise 10.10.0.0/16, le réseau virtuel du cloud 10.50.0.0/16. Deux tunnels IPsec relient le pare-feu du siège aux deux points de terminaison fournis par le cloud, pour la redondance ; le protocole BGP (Border Gateway Protocol) échange les routes dans les tunnels, ce qui permet la bascule automatique. Le siège annonce uniquement 10.10.20.0/24 (les serveurs utiles) et non tout son /16 ; le cloud annonce 10.50.0.0/16. Le pare-feu du siège n’autorise que les flux prévus, par exemple les serveurs applicatifs du cloud vers la base de données interne sur son port. Si le cloud avait été créé en 10.10.0.0/16, choix par défaut tentant, le chevauchement rendrait le routage impossible sans traduction d’adresses : le plan d’adressage se décide avant le premier tunnel.
Éviter chevauchements et routes trop larges
Section intitulée « Éviter chevauchements et routes trop larges »Une route trop large, un 0.0.0.0/0 ou un 10.0.0.0/8 annoncé par négligence, attire dans le tunnel du trafic qui n’a rien à y faire et transforme chaque site en point d’entrée vers tous les autres. On annonce les préfixes au plus juste, on filtre ce que l’on accepte, et on tient un registre des plages utilisées par chaque site et chaque cloud.
Tester la bascule et le mode dégradé
Section intitulée « Tester la bascule et le mode dégradé »Une liaison de secours non testée n’existe que sur le schéma. On coupe régulièrement le chemin principal, en fenêtre de maintenance, pour vérifier que les routes basculent, que les applications le supportent et que la capacité du secours suffit. On documente aussi le mode dégradé : quels services restent accessibles, lesquels sont volontairement suspendus.
À ne pas confondre
Section intitulée « À ne pas confondre »Le VPN n’est pas le Zero Trust : le premier accorde une place sur le réseau, le second décide à chaque requête, selon l’identité et l’état de l’appareil, de l’accès à une application précise (modèle décrit par la publication SP 800-207 du NIST, National Institute of Standards and Technology). Le chiffrement du tunnel n’est pas une autorisation : il garantit que le trajet est privé, y compris celui d’un attaquant connecté avec un compte volé. Et un bastion n’est pas un serveur SSH ouvert sur internet avec un nom flatteur.
🐝 Ce qui arrive si on s’en passe
Section intitulée « 🐝 Ce qui arrive si on s’en passe »Sans bastion ni journalisation des sessions, un compte d’administration volé ouvre des connexions directes vers les serveurs, et l’enquête qui suit ne retrouve ni les commandes passées ni l’ordre des machines visitées. Sans contrôle de l’état de l’appareil, un portable infecté se connecte avec les mêmes droits que son propriétaire et prolonge l’infection jusqu’au cœur du réseau, tunnel chiffré compris : le chiffrement protège alors le trajet de l’attaquant aussi bien que celui de l’utilisateur. Sans routes limitées, les réseaux interconnectés se chevauchent et chaque site devient une entrée vers tous les autres. Sans révocation, enfin, un prestataire parti depuis des mois conserve un accès que personne ne pense à surveiller.
🦫 Explication de la marmotte 🍫
Section intitulée « 🦫 Explication de la marmotte 🍫 »Un tunnel consiste à placer des paquets de données à l’intérieur d’autres paquets pour les faire voyager à travers un réseau qui n’est pas sûr, souvent internet. Le plus souvent, le contenu est chiffré : un observateur sur le trajet voit seulement que les deux extrémités échangent quelque chose. On distingue le tunnel qui relie un poste isolé, par exemple en télétravail, au réseau de l’organisation, et celui qui relie deux sites entiers, ou un site à un service en ligne. Pour que les données passent, il faut régler le routage, c’est-à-dire quelles adresses empruntent le tunnel, la résolution des noms, et la taille maximale des paquets, réduite par cet emballage supplémentaire. Chiffrer le trajet ne suffit pas : une fois entré, un utilisateur ne doit atteindre que ce dont il a besoin, faute de quoi un compte volé donne accès à tout le réseau et permet de passer d’une machine à l’autre. L’accès se protège donc par une vérification de l’identité en plusieurs étapes, un contrôle de l’état de l’appareil, un découpage du réseau en zones et une machine intermédiaire, le bastion, par laquelle passent toutes les connexions d’administration. Les connexions, les commandes et les flux sont enregistrés. Quand une personne part ou qu’un appareil est perdu, son accès est retiré. Les liaisons de secours et le mode dégradé se testent régulièrement.
À lire aussi
- GRE, IPsec ou GRE dans IPsec pour un tunnel site à siteChoisir entre GRE, IPsec et GRE dans IPsec pour relier deux sites, selon le chiffrement, le routage dynamique, le multicast et le coût en MTU.
- WireGuard et VPN maillés, fonctionnement, AllowedIPs et limitesCe que WireGuard garantit, ce qu'il laisse volontairement de côté, et ce que les réseaux maillés bâtis dessus changent pour l'architecture et la confiance.
- Résolution locale, ICMP, MTU et multicastExpliquer les protocoles qui rendent IP utilisable localement et diagnostiquable : ARP, Neighbor Discovery, ICMP, ICMPv6, MTU, fragmentation, multicast et IGMP.
- Couches, normes et vocabulaire de paquetsConstruire le vocabulaire nécessaire pour lire une communication réseau : couche, protocole, encapsulation, trame, paquet, segment, datagramme, message et plans réseau.
Pages voisines
La citent
- Protocole SSH, clés d'hôte, authentification et durcissement
- RDP exposé sur Internet : risques, durcissement et détection
- WireGuard et VPN maillés, fonctionnement, AllowedIPs et limites
- IPv4, CIDR et plans d’adressage
- Résolution locale, ICMP, MTU et multicast
- Services applicatifs, partage et protocoles hérités
- Accès terrestres, fibre, cuivre et réseaux câblés
VPN, tunnels, bastions et interconnexions protégées
Elle cite
- Lien dans les deux sens :Filtrage, segmentation, NAC et Zero Trust
- Lien dans les deux sens :TLS ou tunnel VPN IPsec contre l'homme du milieu
- Lien dans les deux sens :Interfaces, pilotes et démarrage par le réseau
- Lien dans les deux sens :Cloud networking, VPC/VNet, CDN et équilibrage
- MPLS, GMPLS, SD-WAN et overlays opérateurs
: les deux pages se citent l’une l’autre.
