Un brin de réseau

L2VPN vs L3VPN

Le VPN (Virtual Private Network), ou tunneling, est l'un des termes le plus répandu du monde réseau, à la fois chez le grand public et les professionnels. Retour sur la signification de cet acronyme, en particulier dans le contexte opérateur.

Vépéène ?

La RFC 4026 constitue un bon point de départ pour cet article, son but étant justement de rassembler et clarifier la terminologie des VPN fournis par les opérateurs—d'où le nom de PPVPN (Provider Provisioned Virtual Private Network). Le terme de VPN y est bien défini :

    VPN is a generic term that covers the use of public or private
    networks to create groups of users that are separated from other
    network users and that may communicate among them as if they were on
    a private network.  It is possible to enhance the level of separation
    (e.g., by end-to-end encryption), but this is outside the scope of
    IETF VPN working group charters.  This VPN definition is from
    [RFC2764].
    

Autrement dit, un VPN est un service qui fournit—à l'instar d'une interconnexion physique dédiée—une interconnexion logique dédiée, c'est-à-dire sur un réseau mutualisé (public comme l'Internet ou privé comme le backbone d'un opérateur) et via un mécanisme de segmentation du trafic. Le chiffrement du trafic est possible mais pas systématique.

À titre d'exemple, les MPLS VPN que fournissent les opérateurs aux entreprises ne sont pas chiffrés, ces dernières faisant confiance à la nature privée des backbones. Pour autant, elles peuvent ajouter leur propre couche de chiffrement en établissant un VPN chiffré sur le VPN fourni (par exemple, avec GETVPN). Quel est alors l'intérêt de passer par un backbone privé ? Cela permet de bénéficier de SLA (Service-Level Agreement) et d'une QoS maîtrisée de bout-en-bout, ce qui n'est pas le cas sur Internet. Les VPN établis sur Internet sont—c'est fortement recommandé—par nature chiffrés (par exemple, avec IPsec ou OpenVPN) pour des raisons de confidentialité des données. C'est l'aspect principalement retenu (et recherché) par le grand public.

Comme indiqué à la fin de l'extrait précédent, la définition est en réalité tirée de la RFC 2764 qui, déjà dans les années 2000, apportait une première classification des VPN. Elle est particulièrement intéressante et nous reviendrons dessus plus bas.

Quelles différences ?

Nous allons comparer L2VPN et L3VPN selon deux aspects : technique et fonctionnel.

Point de vue technique

Un VPN permet de transporter des PDU (Protocol Data Unit) :

• Si des L2PDU sont transportées, il s'agit d'un L2VPN.
• Si des L3PDU sont transportées, il s'agit d'un L3VPN.

Techniquement, ce n'est pas plus compliqué. Théoriquement, il faudrait aussi préciser le type de la PDU transporté : L2VPN Ethernet, L3VPN IP, etc. Car en effet, dans le temps, d'autres types de PDU ont pu (L2VPN FR-ATM, L3VPN IPX, etc.) ou pourront être transportés. Bon… Dans les faits, je n'ai jamais vu autre chose que Ethernet et IP.

Dans un L3VPN IP, chaque site est dans un réseau différent et l'opérateur a une « patte » dans chaque réseau (en .254 par exemple) qui représente la gateway pour le client. Dans un L2VPN Ethernet, l'opérateur ignore ce qui est encapsulé dans les trames transportées. Son rôle est de fournir un switch virtuel qui, classiquement, traite le niveau trames et assure le MAC learning-forwarding (dans le cas d'une topologie multipoint, comme représenté ci-dessus ; la topologie point-à-point existe également). Le client peut ainsi encapsuler ce qu'il souhaite sur ses trames : IP souvent mais aussi ARP, PPPoE, MPLS ou tout autre protocole fonctionnant sur Ethernet—et nous comprenons la terminologie Cisco AToM (Any Transport over MPLS) pour désigner le L2VPN Ethernet implémenté par MPLS. Dans le cas où IP est encapsulé (cas le plus courant donc), les sites peuvent être dans le même réseau tel un LAN classique ou dans des réseaux différents si des routeurs sont placés de part et d'autre du switch virtuel.

Le terme tunneling est souvent employé car, effectivement, un VPN est tel un tunnel : il correspond à un chemin d'un point A à un point B (point-à-point) ou entre plusieurs points (multipoints) frayé dans un certain environnement (une montagne, une mer, une grande ville, …). Dans des termes plus techniques, on appelle le chemin « réseau d'overlay » (celui du client) et l'environnement « réseau d'underlay » (celui de l'opérateur) et il y a donc « un réseau sur le réseau ». Bien comprendre que la PDU transportée dans le tunnel n'a pas connaissance de l'environnement extérieur. Ainsi, un VPN ignore comment il est implémenté sur le réseau de l'opérateur. Cela peut, par exemple, être via Ethernet, ATM ou MPLS ou via une combinaison des trois—car des protocoles différents sont utilisés dans les réseaux d'accès et dans les réseaux de cœur.

Point de vue fonctionnel

Peut-être vous demandez-vous, à juste titre, ce qui pousse un client à choisir entre L2VPN et L3VPN. Ces deux services, s'ils permettent tous deux une interconnexion de sites, répondent en effet à des besoins différents.

Le L2VPN pour les opérateurs. C'est très répandu, et ce, pour des besoins de collecte de flux. Ceci a été abordé dans l'article Carrier Ethernet sous le terme de DIVOP (Division Opérateurs). Le principe est le suivant : un opérateur A souhaite fournir des services à des clients mais ne possède pas de connectivité physique vers ceux-ci. L'opérateur B possède cette connectivité et propose de la louer à l'opérateur A sous la forme d'une livraison Ethernet agrégée et dans un PoP (Point of Presence) commun. Autrement dit, l'opérateur B propose de livrer les trames Ethernet des clients à l'opérateur A : il s'agit bien d'un L2VPN Ethernet, couramment qualifié de porte de collecte. Chez Orange par exemple, une telle porte est appelée C2E ou CELAN. Noter que les portes de collecte existent aussi en L3 en mode L2TP—cas bâtard mais répandu qui requiert une interconnexion IP entre opérateurs et qui permet de livrer des « trames » PPP (voir l'article sur L2TP)—ou en mode DHCP.

Le L2VPN pour les entreprises. Cela existe de plus en plus. À mon sens, cela pourrait être davantage répandu (d'où le travail du MEF). Historiquement, le L3VPN semble être apparu avant le L2VPN avec, par conséquent, l'habitude d'établir une connectivité L3 avec son opérateur. Cependant, si le client n'a besoin que d'une interconnexion de sites—sans accès Internet ni VoIP ou qu'il veut souscrire ceci chez un autre opérateur—le L2VPN peut suffire et est généralement plus simple à configurer pour les deux parties. En effet, comme expliqué plus haut, l'opérateur ne traite que les trames et est agnostique ce qui est encapsulé par le client. Peu de coordination est nécessaire, hormis pour les potentiels VLAN du client (et encore, il est possible de les transporter de façon transparente).

Le L3VPN pour les entreprises. C'est le service le plus répandu. Les entreprises prennent à la fois L3VPN, accès Internet et VoIP—comme les particuliers prennent à la fois accès Internet, VoIP et IPTV. En effet, quitte à router avec un opérateur, autant tout prendre chez lui par simplicité et avec un potentiel lien de secours (chez le même opérateur ou un autre). L'opérateur accompagne généralement davantage l'entreprise dans la démarche qu'avec du L2VPN, car il y a nécessairement davantage de coordination (quels réseaux privés router ? quelles adresses IP publiques allouer au client ? le client veut-il du NAT ? etc.).

Jouer sur les mots

Il est difficile d'établir un historique précis et parfaitement fidèle de l'évolution des VPN tant il y eu de travaux et de termes différents. Dans les deux RFC mentionnées en début d'article sont rassemblés plusieurs de ces termes (en gras, ceux majoritairement utilisés aujourd'hui) :

On pourra donc retenir les termes de PW et VPLS pour désigner les L2VPN et le terme de L3VPN pour désigner…les L3VPN. Néanmoins, les autres termes sont encore utilisés par les équipementiers. Par exemple, Huawei utilise VLL et Nokia utilise VPRN. Cisco utilise VPDN pour les accès L2TP et, étrangement, parle de « xconnect » pour désigner les PW. Finalement, le mérite revient à la RFC 2764 pour avoir—il y a environ vingt ans à l'heure où j'écris ces lignes—défini une terminologie encore usitée aujourd'hui.

Un VLAN est-il un L2VPN ?

La RFC 4026 fait bien d'évoquer le VLAN comme synonyme de L2VPN. En effet, la différence est mince et ce n'est pas par hasard que ces acronymes contiennent tous deux les mots virtual et network. Pour être précis, je dirais qu'un VLAN est un mécanisme d'implémentation d'un L2VPN Ethernet (multipoint ou point-à-point). Prenons l'exemple :

        Untagged frames            Untagged frames
               :                         :
               :  +-------------------+  :
               :  |                   |  :
    [Site a1]-----|----- VLAN 10 -----|-----[Site a2]
                  |                   |
    [Site b1]-----|----- VLAN 20 -----|-----[Site b2]
                  |                   |
    [Site c1]-----|----- VLAN 30 -----|-----[Site c3]
    [Site c2]-----|---------|---------|-----[Site c4]
                  |                   |
                  +-------------------+
                    Ethernet backbone
    

Trois services sont représentés :

• Un L2VPN Ethernet point-à-point entre les sites a1 a2.
• Un L2VPN Ethernet point-à-point entre les sites b1 b2.
• Un L2VPN Ethernet multipoint entre les sites c1 c2 c3 c4.

Les VLAN permettent la segmentation du trafic sur le réseau mutualisé et permettent le « transport » des trames Ethernet de bout-en-bout. Les clients ne voient pas les VLAN de transport (10, 20 et 30) de l'opérateur : ils envoient des trames non taguées et celles-ci sont transportées en l'état entre les sites. Si les clients émettent le besoin d'envoyer des VLAN dans leur L2VPN, le mécanisme de QinQ pourra être employé—les C-VLAN correspondant aux VLAN client et les S-VLAN aux VLAN de transport de l'opérateur (ceux du schéma en fait). De simples VLAN permettent donc bien l'implémentation de L2VPN Ethernet.

En réalité, un backbone opérateur n'est pas un unique et grand réseau Ethernet (quoique je l'ai déjà vu dans mon expérience et ce n'est pas une bonne pratique). Les réseaux Ethernet existent souvent en tant que réseaux d'accès au backbone IP/MPLS de l'opérateur (constitué de routeurs donc). L'exemple précédent reste valable mais localement. C'est ainsi, dans un projet sur lequel j'ai travaillé, que nous implémentions les L2VPN Ethernet : avec du VLAN (QinQ) à l'accès et du MPLS au cœur. En conclusion, on perçoit bien ici la notion de service : le L2VPN (comme le L3VPN) est un service pouvant être implémenté par diverses technologies souvent combinées entre elles dû à l'hétérogénéité inévitable et souvent volontaire des réseaux.

Et Frame Relay ? Et ATM ?

J'ai commencé volontairement par la notion de VLAN car c'est un exemple actuel et qui parlera sans doute à la plupart d'entre nous, jeunes que nous sont… Mais c'est sans oublier Frame Relay et ATM qui sont sans conteste les précurseurs du tunneling et du VPN (et de MPLS). On retrouve en effet la notion de circuit virtuel sur réseau mutualisé avec le DLCI Frame Relay et le VPI-VCI ATM. Avec les RFC 2427 et RFC 2684, il est possible d'envoyer de l'Ethernet et de l'IP sur Frame Relay et ATM, ce qui correspond aux notions de L2VPN et L3VPN. Ma connaissance de ces protocoles étant limitée, je ne me risquerais pas à aller plus loin…

MPLS et les VPN

MPLS rime souvent avec VPN : voyons pourquoi avec précision.

Le premier niveau de label

Comme nous l'avons vu dans l'article MPLS LDP, avant même de parler MPLS, un opérateur a tout d'abord un backbone pur IP—ou, théoriquement, d'après la RFC de MPLS, de tout autre protocole L3, ce qui justifie le terme Multiprotocol :

      MPLS stands for "Multiprotocol" Label Switching, multiprotocol
      because its techniques are applicable to ANY network layer protocol.
      In this document, however, we focus on the use of IP as the network
      layer protocol.
    

Une fois MPLS (et LDP) activé sur ce backbone IP, on parle alors de backbone IP/MPLS : des LSP sont établis par LDP entre les LSR. Un LSP est tel un tunnel entre deux LSR dans lequel sont transportés les paquets IP :

      +----------+
      |    IP    |
      +----------+
      |   MPLS   | <- LSP label
      +----------+
      | Ethernet |
      +----------+
      | Physical |
      +----------+
    

Il y a donc ici une première notion de L3VPN : le paquet IP en haut de la pile est transporté, en l'état, d'un point A à un point B via MPLS. Il est encapsulé dans MPLS au LSR source et est désencapsulé au LSR destinataire. Sur le chemin, il reste cloisonné dans MPLS dont le label change à chaque hop (le fameux label switching). Ceci dit, ce n'est pas vraiment cette première notion de L3VPN qui nous intéresse. Pourquoi cela ? Car les paquets IP encapsulés dans ce premier niveau de MPLS sont généralement ceux de l'opérateur lui-même : ICMP-SNMP pour superviser les liens, SSH pour accéder à distance aux LSR, entre autres. Tout au plus, il peut y avoir les paquets IP du trafic Internet des clients si l'opérateur a décidé de les transporter ainsi.

Les questions suivantes peuvent alors se poser :

• Comment profiter des LSP établis pour transporter les paquets IP des LAN clients, sans recouvrement avec d'autres clients et l'opérateur ?
• Comment profiter des LSP établis pour transporter autre chose que de l'IP (disons de l'Ethernet) ?

Un deuxième niveau de label

La réponse est dans le titre : avec un deuxième niveau de label ! Le premier niveau est le chemin entre deux LSR. Le deuxième niveau est celui du VPN en question :

      +----------+
      |  IP/Eth  | <- IP (L3VPN) or Ethernet (L2VPN)
      +----------+
      |   MPLS   | <- VPN label
      +----------+
      |   MPLS   | <- LSP label
      +----------+
      | Ethernet |
      +----------+
      | Physical |
      +----------+
    

Notr que cet empilement de label n'est pas le fruit du hasard ou d'une heureuse coïncidence. La notion de label stack a été définie dans la RFC même de MPLS (§3.9) sans parler explicitement des VPN puis utilisée dans la RFC 2547 pour implémenter des MPLS L3VPN. À regarder de plus près l'historique de ces RFC, elles ont quasiment été écrites en parallèle, donc MPLS a aussi été conçu « pour que ça marche ».

En image

Prenons l'exemple ci-dessous :

De gauche à droite :

1. Le CE émet une PDU :
   • s'il s'agit d'un L2VPN, c'est la trame reçue que le PE encapsulera dans MPLS
   • s'il s'agit d'un L3VPN, c'est le paquet reçu que le PE encapsulera dans MPLS
2. Pour que le PE retrouve le VPN associé à la PDU reçue, plusieurs possibilités (notion d'attachment circuit) :
   • le port physique de livraison (si un port = un client)
   • le VLAN de livraison (si un port = plusieurs clients)
   • ou encore la session PPPoE-L2TP (si un port = plusieurs clients, et pour du L3VPN uniquement)
   • Il y a de plus, pour du L3VPN, la notion fondamentale de VRF (VPN Routing and Forwarding). C'est précisément ce qui va permettre à plusieurs clients de ne pas recouvrir leur adressage entre eux et avec celui de l'opérateur. Une VRF est une instance de table de routage dissociée de la table de routage globale de l'opérateur appelée GRT (Global Routing Table). Il peut, par exemple, y en avoir une par client ou une par site client.
3. Le PE encapsule la PDU dans deux labels MPLS : le premier correspond au LSP et va changer de proche-en-proche, le deuxième correspond au VPN et est inchangé de bout-en-bout.
4. Les P n'ont pas connaissance du deuxième niveau de label, ils font le label switching classique sur le premier niveau. C'est tout l'intérêt de la label stack !
5. Le PE de destination retrouve le VPN associé depuis le label VPN et désencapsule la PDU qu'il envoie au CE.

Comment savoir si la PDU encapsulée est une trame ou un paquet ? Car, en effet, MPLS ne comporte pas de champ indiquant le type de protocole encapsulé. C'est la valeur du label VPN qui est déterminante ! Ainsi, le label 35 pourra correspondre à un L2VPN et label 36 à un L3VPN.

On casse le modèle OSI…

C'est en DUT informatique, lors des premiers cours en réseaux, que le modèle OSI (Open Systems Interconnection) m'a été présenté. C'était un soir d'hiver, de 17h30 à 18h30, et il faisait déjà nuit. Le professeur, plutôt jeune, introduisait le TD par : « Je me souviens, quand j'étais plus jeune et que l'on m'a présenté le modèle OSI, j'étais complètement perdu. » Pendant un moment alors je me demandais, et comme pour fuir le raffut quotidien d'une classe de fin de journée : est-ce qu'un jour j'aurai à présenter ce modèle ? que penserai-je de cette phrase d'accroche ?

De mémoire, je n'avais pas trouvé le concept OSI incompréhensible. Au contraire. Peut-être car en logiciel, nous sommes rapidement initiés à la modélisation, soit l'art de faire des modèles de systèmes (et je dirais bien systémiques). Regrouper des choses, définir des rôles, schématiser des relations entre objets… rien de nouveau. Concevoir un modèle commun pour que les open systems puisse communiquer entre eux semblait être la moindre des choses.

Le modèle OSI est une approche conceptuelle des réseaux pour (tenter de) découper et ordonner les problématiques. Un peu comme un affinage successif dans un algorithme. Aussi, on nous présente un modèle à sept couches, chacune d'entre elles ayant un rôle bien défini. Puis finalement, on nous explique que le modèle peut pratiquement se résumer en cinq couches. Soit. Pourquoi pas. Avec du recul, c'est sans surprise. Dans beaucoup de travail de modélisation (et surtout, de post-modélisation de systèmes conçus sur le tas), il y a des cas qui ne rentrent pas dans les cases. Alors, il faut bien définir des cases particulières pour ces cas particuliers.

Et le lien avec les VPN ?

Les VPN ne sont pas vraiment conformes au modèle OSI. Voyons pourquoi en reprenant les exemples précédents (MPLS VPN) :

En bas (en gris) se trouve la pile de l'opérateur correspondant au réseau d'underlay. En haut (en blanc) se trouve la pile du client correspondant au réseau d'overlay. Le MPLS L2VPN fait apparaître quelque chose d'assez flagrant : il y a un comme un modèle OSI dans un modèle OSI ! Ainsi, conceptuellement, le modèle OSI reste valable mais il y a une imbrication claire d'un modèle dans un modèle, ce qui revient à dire « un réseau sur le réseau ». Même remarque pour le MPLS L3VPN mais à partir du niveau 3. Partant de ces exemples, nous pouvons, nous aussi, concevoir notre propre modèle protocolaire de tout VPN :

Voyons maintenant quelques autres piles protocolaires existantes pour implémenter des L2VPN ou L3VPN :

Dans un certain sens, PPPoE est un VPN : le tunnel PPPoE établi permet effectivement de transporter les « trames » PPP—si nous pouvons encore parler de trames—d'un point A à un point B sur un réseau Ethernet (de nature multipoint). Les trames PPP sont cloisonnées dans ce tunnel aussi appelé session PPPoE. À proprement parler, on dira que la session PPPoE transporte le lien PPP. De même, L2TP permet de transporter ce lien PPP sur IP.

Noter qu'il est possible de faire du GRE over IPsec afin de profiter de la sécurité apportée par IPSec. GRE permettant l'encapsulation d'autres protocoles qu'IP (voir les prochaines piles protocolaires), l'intérêt est alors de pouvoir chiffrer n'importe quel type de trafic encapsulé (Ethernet ou MPLS, par exemple). Le DMVPN (Dynamic Multipoint VPN) chez Cisco—ou DSVPN (Dynamic Smart VPN) chez Huawei—a également sa place dans cette catégorie L3VPN. Il s'agit de mécanismes (plan de contrôle avec NHRP et mGRE) permettant de faciliter la mise en place de L3VPN basés sur GRE et IPsec (plan de données). Aussi, sur le plan de données, cela correspond aux piles protocolaires présentées ci-dessus.

Noter que L2TPv3 permet le transport d'autres protocoles qu'Ethernet comme HDLC, ATM, Frame Relay mais surtout MPLS (comme GRE). L'utilisation d'UDP dans L2TPv3 n'est plus obligatoire.

Pour terminer cet article, se dressent ci-dessus des piles protocolaires quelque peu étranges. Il peut en effet arriver qu'un MPLS VPN (L2 ou L3) doive traverser un réseau non-MPLS. Dans ce cas, le LSP qui—comme nous l'avons vu plus haut—est tel un tunnel point-à-point entre deux LSR a la possibilité d'être remplacé par un autre protocole assurant ce rôle. Le MPLS VPN label (gris clair) est transporté d'un point à un autre sur le réseau d'underlay (gris foncé) et en sommet de pile se trouve la PDU du client (Ethernet ou IP). Enfin, il serait aussi possible de faire du MPLS/PPP/L2TPv2/UDP/IP/Ethernet/Phy (non représenté ici) plutôt que du MPLS/L2TPv3/IP/Ethernet/Phy. Cela fonctionnerait mais avec davantage d'overhead.

Ainsi, cette dernière remarque fait apparaître l'inconvénient majeur des VPN qui sera la conclusion de cet article : l'overhead non négligeable engendré par les encapsulations successives. Cela a pour effet de réduire le débit utile (celui perçu par l'utilisateur final), les MTU ne pouvant être augmentées partout sur les chemins empruntés.