Présentation
RÉSUMÉ
Cet article présente succinctement les principales topologies et technologies utilisées pour mettre en place des VPN (Virtual Private Network) ou RPV (Réseau Privé Virtuel).
Après avoir abordé les fonctions d’un VPN, l’article décrit les deux possibilités d’exploitation (par l’entreprise ou un opérateur) des VPN, puis les topologies classiques : maillage total, étoile, Hub and Spoke, hybride.
L’impact d’un VPN d’entreprise est également envisagé avant de décrire brièvement les principaux protocoles : IPsec, SSL, GRE, MPLS, ainsi que les services privés de VPN fournis par des sociétés commerciales.
Lire cet article issu d'une ressource documentaire complète, actualisée et validée par des comités scientifiques.
Lire l’articleAuteur(s)
-
Jean-Paul ARCHIER : Formateur et Consultant Réseau - JPACONSEIL
INTRODUCTION
Il est très fréquent que les échanges entre différents sites d’une même entreprise, entre entreprises, ou bien encore entre des télétravailleurs et leur entreprise se fassent au travers du réseau Internet. Il est alors impératif que l’utilisation de ce réseau, sur lequel les communications sont potentiellement accessibles par des tiers, ne compromette pas la sécurité de ces échanges. Il y a notamment un risque de capture des données échangées, mais aussi d’altération de ces dernières. Pour pallier ces risques, le moyen le plus classique est l’utilisation de VPN (Virtual Private Network) ou RPV (Réseau Privé Virtuel) entre les interlocuteurs.
Un VPN permet également de contourner les contraintes et filtrages qui peuvent être imposés dans certains pays pour limiter l’accès à l’information des résidents ou la capacité de ces derniers à transmettre des messages ou des documents au reste du monde.
Un VPN peut donc être bâti entre des réseaux complets, entre un ordinateur et un réseau distant, ou bien encore entre deux ordinateurs, en se basant sur des techniques et protocoles très variés. Le choix de ces derniers se fera selon les objectifs à atteindre, les contraintes techniques ou réglementaires, mais aussi selon les compétences nécessaires à leur mise en œuvre ou à leur maintenance. La gestion de ces VPN peut être totalement assumée par l’entreprise ou bien confiée à un opérateur.
Dans le premier cas, cela nécessite des compétences en interne ou le recours à des prestataires. Le coût peut donc varier sensiblement. Dans le cas de VPN délégués à un opérateur, le budget évidemment beaucoup plus élevé et la durée d’engagement généralement associée à ces contrats font qu’il est nécessaire de mener une réflexion approfondie avant un déploiement de cet ordre.
Pour ce qui est de l’usage à titre particulier, le choix se fera surtout selon le budget nécessaire si l’on recourt à un abonnement auprès d’un tiers, ainsi que sur les possibilités offertes par le VPN proposé, notamment les capacités à contourner les filtrages ou à se délocaliser virtuellement en utilisant des serveurs situés dans un pays différent du pays de résidence. La diversité des protocoles proposés, ainsi que le nombre et la localisation des serveurs VPN, seront également des critères importants pour choisir entre les différents prestataires disponibles. Il est également possible pour un particulier de bâtir un VPN avec son domicile lorsqu’il est à l’extérieur, s’il dispose des compétences et de l’infrastructure.
Cet article est réservé aux abonnés.
Il vous reste 93 % à découvrir.
Déjà abonné ? Se connecter
MOTS-CLÉS
pare-feu MPLS VPN Maillage chiffrement réseau privé virtuel IPsec
VERSIONS
- Version archivée 1 de oct. 2004 par Mohammed ACHEMLAL, Michel DUDET
DOI (Digital Object Identifier)
Présentation
Principaux protocoles de VPNArticle inclus dans l'offre
"Sécurité des systèmes d'information"
(83 articles)
Actualisée et enrichie d’articles validés par nos comités scientifiques.
Quiz, médias, tableaux, formules, vidéos, etc.
Opérationnels et didactiques, pour garantir l'acquisition des compétences transverses.
Un ensemble de services exclusifs en complément des ressources.
4. Impacts de l’utilisation d’un VPN d’entreprise
La mise en place de VPN entre deux sites, ou entre un poste nomade et un site, est supposée rendre transparent l’accès aux ressources situées sur le site de destination, mais ce n’est pas totalement vrai car le fait de passer par un VPN peut avoir quelques conséquences.
4.1 Modification du MTU et fragmentation
La mise en place d’un VPN implique l’encapsulation des données d’origine dans un nouveau paquet avec ajout d’un en-tête spécifique au protocole utilisé. Or, la quantité de données transportables en un seul paquet est limitée à une valeur très dépendante du support utilisé. On utilise généralement la valeur dite MTU (Maximum Transmission Unit).
Par exemple, sur Ethernet, une trame peut contenir 1 518 octets (1 522 avec un VLAN), dont 18 octets d’en-tête et de FCS (Frame Check Sequence), ce qui laisse un MTU de 1 500 octets. Dans le cas du PPPoE (Point To Point Protocol over Ethernet), souvent utilisé pour les liens ADSL ou VDSL, ce sera 1 492 octets, voire moins. Et cela peut être encore différent sur le parcours entre les deux sites.
Pour illustrer très simplement notre propos, et comme montré par la figure 13, nous allons prendre comme hypothèse que le lien WAN a aussi un MTU de 1 500 octets.
Si un poste du site A émet un paquet IP à destination de B il va se baser le plus souvent sur le MTU local de 1 500 octets pour découper les données à transmettre. Posons comme hypothèse qu’il envoie trois trames (T1, T2, T3) avec, respectivement, 1 500, 1 500 et 600 octets pour obtenir un ensemble de données utiles de 3 600 octets.
Lorsque ces trames vont arriver sur le firewall, ce dernier va devoir extraire les 1 500 octets de T1 pour les placer sur le lien WAN, mais lorsqu’il va encapsuler ces octets dans le VPN, il va devoir ajouter l’encapsulation du VPN.
Nous allons prendre comme hypothèse que l’encapsulation VPN nécessite d’ajouter environ 50 octets. Or, comme il ne peut placer sur le lien WAN qu’une trame avec 1 500 octets, cela signifie qu’il va fragmenter la trame T1 en T1a avec 1 450 octets des données utiles (payload) et T1b avec les 50 octets restants. Il en est de même pour T2.
Nous aurons donc besoin au total de cinq trames représentant les 3 600 octets de données utiles, plus 250 octets d’encapsulation...
Cet article est réservé aux abonnés.
Il vous reste 92 % à découvrir.
Déjà abonné ? Se connecter
Impacts de l’utilisation d’un VPN d’entreprise
Article inclus dans l'offre
"Sécurité des systèmes d'information"
(83 articles)
Actualisée et enrichie d’articles validés par nos comités scientifiques.
Quiz, médias, tableaux, formules, vidéos, etc.
Opérationnels et didactiques, pour garantir l'acquisition des compétences transverses.
Un ensemble de services exclusifs en complément des ressources.
BIBLIOGRAPHIE
-
(1) - DONENFELD (J.A.) - Wireguard : Next Generation Kernel Network Tunnel - (2020). PDF disponible en ligne https://www.wireguard. com/papers/wireguard.pdf
-
(2) - BERTLETT (G.), INAMDAR (A.) - IKEv2 IPsec Virtual Private Networks: Understanding and Deploying IKEv2, IPsec VPNs, and FlexVPN in Cisco IOS. - Cisco Press (2016).
-
(3) - ARCHIER (J.-P.) - LES VPN Fonctionnement, mise en œuvre et maintenance. - Éditions ENI (2013).
-
(4) - DE GHEIN (L.) - MPLS Fundamentals. - Cisco Press (2016).
-
(5) - OPPLIGER (R.) - SSL and TLS : Theory and Practice. - 3e edition. Artech House (2023).
-
(6) - National Institute of Standards and Technology - SHA-3 Standard : Permutation-Based Hash and Extendable-Output Functions. - PDF...
DANS NOS BASES DOCUMENTAIRES
ANNEXES
RFC 1191 – MOGUL J., DOERING S. Path MTU Discovery – Novembre 1996
RFC 1321 – RIVEST R. – The MD5 Message-Digest Algorithm – Avril 1992
RFC 1701 – HANKS S., LI T., FARINACCI D., TRAINA P. Generic Routing Encapsulation (GRE) – Octobre 1994
RFC 1702 – HANKS S., LI T., FARINACCI D., TRAINA P. Generic Routing Encapsulation over IPv4 networks – Octobre 1994
RFC 2784 – FARINACCI D., HANKS S., MEYER D., TRAINA P. Generic Routing Encapsulation (GRE) – Mars 2000
RFC 2890 – DOMMETY G. Key and Sequence Number Extension to GRE – Septembre 2000
RFC 3031 – ROSEN E., VISWANATHAN A., CALLON R. – Multiprotocol Label Switching Architecture – Janvier 2001
RFC 3931 – LAU j., TOWNSLEY E., GOYRET E. Layer Two Tunneling Protocol version 3 – Mars 2005
RFC 3948 – HUTTUNEN A., SWANDER V., VOLPE V., DIBURRO L., STENBERG M. UDP Encapsulation of IPsec ESP Packets – Janvier 2005
RFC 4301 – KENT S., SEO K. – Security Architecture for the Internet Protocol (IPSEC) – Décembre 2005
RFC 4302 – KENT S. – IP Authentication Header (AH) – Décembre 2005
RFC 4821 – MATHIS M., HEFFNER J. Packetization Layer Path MTU Discovery – Mars 2007
RFC 5462 – ANDERSSON L., ASATI R. – Multiprotocol Label Switching (MPLS) Label Stack Entry: “EXP” Field Renamed to “Traffic Class” Field – Février 2009
RFC 6071 FRANKEL S., KRISHNAN A. IPsec and IKE Documentation Roadmap – Fevrier 2011
RFC 6178 SMITH D., MULLOOLY J., JAEGER W., SCHOLL T. Label Edge Router
Forwarding of IPv4 Packets – Mars 2011
RFC 6234 EASTLAKE D., HANSEN T., US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF) – Mai 2011
RFC 7296 – KAUFMAN C., HOFFMAN P., NIR Y., ERONEN P. KIVINEN T. – Internet Key Exchange Protocol version 2 IKEv2 – Octobre 2014
RFC 7568 – BARNES R., THOMSON H., PIRONTI A., LANGLEY A....
Cet article est réservé aux abonnés.
Il vous reste 94 % à découvrir.
Déjà abonné ? Se connecter
Article inclus dans l'offre
"Sécurité des systèmes d'information"
(83 articles)
Actualisée et enrichie d’articles validés par nos comités scientifiques.
Quiz, médias, tableaux, formules, vidéos, etc.
Opérationnels et didactiques, pour garantir l'acquisition des compétences transverses.
Un ensemble de services exclusifs en complément des ressources.
