GRE, IPsec ou GRE dans IPsec pour un tunnel site à site

Relier deux sites par un tunnel revient à choisir ce que le tunnel doit savoir faire : transporter n’importe quel trafic, le protéger, ou les deux. GRE (Generic Routing Encapsulation) transporte sans protéger, IPsec (Internet Protocol Security) protège en limitant ce qu’il transporte, et leur combinaison cumule les deux avantages en payant le prix en octets, en configuration et en points de panne. La bonne réponse dépend moins de la sécurité visée que du routage qu’on veut faire passer dedans.

→ Lire l’explication complète de la marmotte

GRE, IPsec et GRE dans IPsec : ce que chaque encapsulation apporte

Décrit par les RFC (Request for Comments) 2784 et 2890, GRE emballe un paquet dans un autre : un nouvel en-tête IP (Internet Protocol) de 20 octets, un en-tête GRE de 4 octets (8 avec le champ clé), et le paquet d’origine intact derrière, sous le numéro de protocole IP 47. Il transporte à peu près tout : IPv4 (IP version 4), IPv6 (IP version 6), le multicast, donc les protocoles de routage. Il ne chiffre rien et n’authentifie rien. Le champ « clé » de GRE n’est pas un secret : c’est un identifiant de tunnel qui circule lisible, et le traiter comme un mot de passe relève de la superstition.

IPsec protège au niveau IP. Sa pièce maîtresse est ESP (Encapsulating Security Payload, RFC 4303, protocole IP 50) : confidentialité, intégrité de chaque paquet par un ICV (Integrity Check Value) et protection contre le rejeu. Son cousin AH (Authentication Header, protocole 51) n’assure que l’intégrité et ne survit pas à une traduction d’adresses : il n’a plus sa place dans une architecture neuve. Les clés sont négociées par IKEv2 (Internet Key Exchange version 2, RFC 7296) sur UDP (User Datagram Protocol) 500, puis 4500 dès qu’un NAT (Network Address Translation) se trouve sur le chemin, ESP étant alors encapsulé dans UDP (NAT-T, RFC 3948).

Le point qui décide de tout : un IPsec « à politique » (policy-based) chiffre ce qui correspond à des sélecteurs de trafic, en pratique des paires de sous-réseaux. Il n’offre pas d’interface, donc pas de table de routage à alimenter, et pas de multicast : OSPF (Open Shortest Path First), dont les annonces partent vers 224.0.0.5, n’y passe pas. Un IPsec « à routage » (route-based) expose au contraire une interface virtuelle, la VTI (Virtual Tunnel Interface) : le système de routage y envoie ce qu’il veut, et BGP (Border Gateway Protocol) s’y installe comme sur n’importe quel lien.

GRE dans IPsec combine les deux couches : GRE fournit l’interface et le transport du multicast, IPsec chiffre le tunnel GRE entier, souvent en mode transport avec un sélecteur réduit au protocole 47 entre les deux adresses publiques. C’était la seule façon de faire passer du routage dynamique dans un tunnel chiffré avant que les VTI se généralisent ; c’est devenu une option parmi d’autres.

Le compromis central se lit ainsi : GRE apporte la souplesse du routage, IPsec la protection, et chaque couche ajoutée coûte des octets par paquet et réduit d’autant la MTU (Maximum Transmission Unit, la taille maximale d’un paquet sur un lien), ajoute une configuration de plus à maintenir et une cause de panne de plus à diagnostiquer. La position par défaut en découle : IPsec à routage (VTI) avec IKEv2 et BGP. GRE dans IPsec seulement quand il faut du multicast applicatif, un protocole de routage qui exige le multicast sur une plateforme sans VTI, ou un trafic non IP. GRE nu uniquement à l’intérieur d’un réseau déjà maîtrisé ou déjà chiffré, jamais à travers Internet.

L’arbre de décision ci-dessous résume l’ordre des questions : le multicast d’abord, la plateforme ensuite, la sécurité du chemin enfin.

MTU et fragmentation dans un tunnel

Chaque encapsulation mange de la MTU, qui vaut 1500 octets sur Ethernet. Ordres de grandeur en IPv4 : GRE coûte 24 octets ; ESP en mode tunnel avec AES-GCM (Advanced Encryption Standard en mode Galois/Counter) coûte de 54 à 57 octets selon le bourrage ; NAT-T en ajoute 8 ; GRE dans IPsec en mode transport cumule de 58 à 61 octets, 66 à 69 derrière un NAT. Fixer la MTU de l’interface de tunnel à 1400 octets laisse une marge confortable pour tous ces cas, y compris un en-tête IPv6 de 40 octets côté transport.

Le paquet trop gros a trois destins possibles, tous mauvais s’ils sont subis. Fragmenté après chiffrement, il oblige la passerelle d’en face à réassembler avant de déchiffrer, ce qui coûte du processeur et de la mémoire, et certains chemins jettent les fragments sans prévenir. Refusé avec le bit DF (Don’t Fragment), il doit déclencher un message ICMP (Internet Control Message Protocol) « fragmentation nécessaire » vers l’émetteur, qui réduit sa taille : c’est la PMTUD (Path MTU Discovery). Et si ce message ICMP est filtré quelque part, rien ne revient.

Ce dernier cas fabrique la panne la plus trompeuse du métier, le trou noir de MTU : la connexion TCP (Transmission Control Protocol) s’établit, les petites requêtes passent, et le premier transfert de taille réelle reste suspendu sans aucune erreur. Le schéma suivant montre la séquence, et pourquoi le diagnostic part toujours dans la mauvaise direction (pare-feu applicatif, serveur, application) avant d’arriver au tunnel.

La parade tient en deux réglages et une règle de filtrage : MTU de 1400 sur l’interface de tunnel, réécriture de la MSS (Maximum Segment Size, la taille maximale des données d’un segment TCP) à 1360 octets sur les connexions qui traversent le tunnel, et ICMP type 3 code 4 autorisé de bout en bout. En IPv6, aucun routeur ne fragmente : le message ICMPv6 (ICMP pour IPv6) « Packet Too Big » est vital, et le filtrer revient à installer le trou noir volontairement. Vingt ans de réseau apprennent qu’une règle « bloquer tout l’ICMP, par sécurité » coûte plus d’heures de diagnostic que toutes les attaques ICMP réunies.

Routage dynamique et multicast dans le tunnel

OSPF au travers de GRE fonctionne sans surprise tant qu’une règle est respectée : la route vers l’adresse de destination du tunnel doit être apprise par le réseau de transport, jamais par le tunnel lui-même. Si OSPF annonce l’adresse publique du pair à l’intérieur du tunnel, le routeur finit par vouloir joindre l’extrémité du tunnel en passant par le tunnel, qui tombe, l’adjacence disparaît, la route revient par le transport, le tunnel remonte, et le cycle recommence toutes les quelques dizaines de secondes. Les équipements journalisent ce cas sous le nom de routage récursif ; la parade consiste à filtrer les préfixes du transport hors du protocole de routage du tunnel.

BGP sur une VTI est le choix le plus robuste pour un réseau à plusieurs sites : il n’a pas besoin du multicast, il porte des politiques fines (préférence de sortie, préfixes autorisés par site) et il converge correctement quand on lui adjoint BFD (Bidirectional Forwarding Detection), qui détecte la perte d’un lien en moins d’une seconde au lieu des 90 à 180 secondes du temporisateur d’attente BGP par défaut. Côté IPsec, la DPD (Dead Peer Detection) d’IKEv2 vérifie que le pair répond encore et relance la négociation ; les deux mécanismes se complètent, l’un surveille la session de routage, l’autre l’association de sécurité.

GRE est sans état : sans message de maintien activé explicitement, une interface GRE reste « active » alors que le pair a disparu depuis des heures, et le routage continue d’y envoyer du trafic. Un tunnel qui dit « tout va bien » parce qu’il ne vérifie rien a au moins le mérite de la constance. Le multicast applicatif, routé par PIM (Protocol Independent Multicast) pour la diffusion vidéo ou la réplication de certaines bases, reste le vrai territoire de GRE ; c’est lui, et non OSPF, qui justifie aujourd’hui la double encapsulation.

Dernier piège de production : le routage asymétrique. Quand l’aller passe par un tunnel et le retour par un autre chemin (deuxième tunnel, sortie Internet directe, service de nettoyage anti-déni de service qui renvoie le trafic entrant par GRE), un pare-feu à états voit une réponse sans avoir vu la demande et la jette. La règle est de faire porter l’aller et le retour par la même passerelle, ou de déclarer l’asymétrie aux équipements à états qui la tolèrent ; la page décision de chemin et routes détaille la mécanique.

Exemple : GRE dans IPsec entre deux passerelles Linux

L’exemple relie deux sites dont les passerelles ont des adresses publiques de documentation. Le schéma compare les trois tunnels ; l’exemple correspond au troisième, dont il faut regarder le paquet, en bas : l’adresse publique reste visible, tout le reste, en-tête GRE compris, voyage chiffré.

Côté passerelle A (Linux, noyau récent, strongSwan 5.9 ou plus avec swanctl), l’interface GRE, sa MTU et la réécriture de la MSS :

# Interface GRE entre les deux adresses publiques (passerelle B : symétrique)
ip tunnel add gre1 mode gre local 203.0.113.1 remote 203.0.113.2 ttl 64
ip addr add 10.255.0.1/30 dev gre1
ip link set gre1 mtu 1400 up

# MSS des connexions TCP qui sortent par le tunnel : 1400 - 40 octets d'en-têtes
iptables -t mangle -A FORWARD -o gre1 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1360

La protection IPsec ne vise que le protocole 47 entre les deux adresses publiques, en mode transport, avec une authentification par certificat propre à chaque passerelle :

# /etc/swanctl/conf.d/gre-ab.conf (passerelle A)
connections {
  gre-ab {
    version = 2
    local_addrs = 203.0.113.1
    remote_addrs = 203.0.113.2
    proposals = aes256gcm16-prfsha384-ecp384
    dpd_delay = 30s
    local {
      auth = pubkey
      certs = passerelle-a.pem
    }
    remote {
      auth = pubkey
      id = "CN=passerelle-b"
    }
    children {
      gre {
        mode = transport
        local_ts = 203.0.113.1[gre]
        remote_ts = 203.0.113.2[gre]
        esp_proposals = aes256gcm16-ecp384
        dpd_action = restart
        start_action = trap
      }
    }
  }
}

Vérifications après swanctl --load-all : swanctl --list-sas doit montrer l’association « gre » installée en mode transport ; ping -M do -s 1372 10.255.0.2 (1372 octets de données plus 28 d’en-têtes ICMP et IP font 1400) doit passer, et la même commande avec -s 1373 doit échouer proprement avec un message de MTU, pas se taire. Une capture sur l’interface publique (tcpdump -ni eth0 esp) ne doit montrer que de l’ESP, aucun paquet GRE lisible : si du GRE apparaît, le sélecteur ne correspond pas et le tunnel passe non chiffré à côté d’IPsec, ce qui est exactement le défaut que la configuration prétend éviter.

Surface d’attaque d’un tunnel GRE ou IPsec

GRE nu est une porte d’entrée : une passerelle accepte et désencapsule tout paquet de protocole 47 dont l’adresse source ressemble à celle du pair. Un attaquant capable d’usurper cette adresse injecte ainsi des paquets directement dans le réseau interne, derrière le pare-feu. Filtrer le protocole 47 sur la seule adresse du pair et activer l’uRPF (unicast Reverse Path Forwarding) réduisent le risque sans le supprimer, puisque l’usurpation reste possible depuis certains chemins. Seule l’authentification d’IPsec ferme cette porte.

Côté IPsec, les faiblesses sont connues et toutes évitables :

IKEv1 (première version d’IKE) en mode agressif avec clé partagée : le condensat échangé permet une attaque hors ligne par dictionnaire sur la PSK (Pre-Shared Key). IKEv2 seulement, et des certificats plutôt qu’une PSK.
Une seule PSK pour tous les sites : la compromission d’une passerelle ouvre tout le maillage. Une identité par passerelle, révocable seule.
Groupes DH (Diffie-Hellman) faibles (groupes 1, 2 et 5 encore présents dans des configurations par défaut anciennes) et ESP sans chiffrement (« null ») autorisé dans les propositions : à retirer explicitement.
Révocation non vérifiée : sans contrôle de CRL (Certificate Revocation List) ni d’OCSP (Online Certificate Status Protocol), un certificat de passerelle volé reste accepté jusqu’à son expiration.
Déni de service sur IKE : une avalanche de demandes d’ouverture épuise la mémoire de la passerelle ; IKEv2 prévoit un mécanisme de cookie qui oblige l’émetteur à prouver qu’il reçoit les réponses avant de coûter quoi que ce soit.

Ce que le tunnel ne garantit pas, quelle que soit la variante : la protection s’arrête aux passerelles. Entre la passerelle et le serveur, sur chaque site, le trafic circule non chiffré ; seul TLS (Transport Layer Security) de bout en bout protège ce segment, comme le montre la comparaison entre TLS et un tunnel IPsec. Le tunnel ne filtre rien non plus : un site compromis atteint l’autre aussi facilement qu’un site sain, et le cloisonnement doit venir de règles de filtrage à la sortie du tunnel (filtrage et segmentation). Il ne cache pas les métadonnées (adresses publiques des sites, volumes, horaires) et n’assure aucune disponibilité : un seul opérateur de transport, c’est un seul point de panne chiffré. Un tunnel IPsec entre deux réseaux plats reste un câble très bien protégé entre deux salles sans portes.

Exploitation : clés, rotation, supervision et reprise

Prérequis de plateforme : une pile IPsec qui sait exposer une interface de tunnel (sous Linux, le noyau et strongSwan 5.9 ou plus récent ; ailleurs, un équipement qui propose une VTI) ; l’ouverture de UDP 500 et 4500 et du protocole 50 entre les passerelles (le protocole 47 seulement si GRE circule non chiffré, ce qui ne devrait plus arriver hors réseau maîtrisé) ; une heure juste sur chaque passerelle, car un certificat se valide par rapport à l’horloge (résolution de noms, adressage et heure du réseau).

Clés et rotation : une paire de clés et un certificat par passerelle, émis par une autorité interne dédiée, avec une clé privée qui ne quitte pas l’équipement : TPM (Trusted Platform Module) ou HSM (Hardware Security Module) quand la plateforme le permet. Les clés de session se renouvellent seules : strongSwan renégocie par défaut l’association IKE toutes les quatre heures et les associations ESP toutes les heures, et l’option de réauthentification « avant coupure » évite le trou de quelques secondes pendant le changement. Le renouvellement des certificats, lui, ne se fait pas seul : un calendrier, une alerte trente jours avant l’échéance, et un test de bascule sur une passerelle à la fois.

Supervision : état des associations IKE et ESP, échecs de renégociation, déclenchements de DPD, état des sessions BGP et BFD, compteurs de paquets ESP dans les deux sens (un sens à zéro signale un filtrage ou un sélecteur faux), erreurs d’anti-rejeu, et paquets jetés pour cause de MTU. Le compteur le plus parlant reste l’asymétrie : un tunnel qui envoie beaucoup et ne reçoit rien est un tunnel en panne qui se croit vivant.

Sauvegarde et reprise : la configuration se versionne comme du code, les clés privées ne figurent jamais non chiffrées dans une sauvegarde, et la reprise repose sur deux tunnels portés par deux opérateurs de transport différents, avec BGP pour basculer de l’un à l’autre. Une bascule qui n’a jamais été testée n’est pas une reprise, c’est une hypothèse ; la page continuité et sauvegardes donne la méthode d’essai.

🐝 Ce qui arrive si on s’en passe

Sans IPsec autour de GRE, tout ce qui circule entre les sites traverse Internet lisible et modifiable : adresses internes, annonces de routage, données applicatives. Une passerelle qui accepte du GRE non authentifié laisse un attaquant capable d’usurper l’adresse du pair injecter des paquets directement derrière le pare-feu, et des annonces de routage forgées détournent le trafic d’un site entier. Sans réglage de MTU et de MSS, la panne prend la forme de transferts suspendus sans erreur, qu’on attribue à l’application. Sans supervision des associations et des compteurs, un tunnel tombé ou passé non chiffré continue d’afficher un état actif, et la perte de la protection n’est découverte qu’après coup, sans trace exploitable.

🦫 Explication de la marmotte 🍫

Pour relier deux sites par Internet, chaque site a une machine d’entrée, appelée passerelle. Quand un ordinateur du premier site envoie un message à un serveur du second, sa passerelle prend le message entier et le glisse dans un nouveau paquet adressé à l’autre passerelle : c’est l’encapsulation. La méthode la plus légère s’arrête là : le message reste lisible et modifiable par toutes les machines traversées. Une méthode protégée ajoute deux protections : elle brouille le contenu avec une clé secrète, et elle ajoute un code de contrôle qui révèle la moindre modification. Les deux passerelles se mettent d’abord d’accord sur ces clés en prouvant leur identité avec un certificat. La méthode légère sait transporter les messages que les routeurs s’échangent pour se signaler les chemins disponibles, ce qu’une partie des montages protégés ne sait pas faire ; d’où l’idée de glisser la méthode légère à l’intérieur de la méthode protégée pour avoir les deux. Chaque couche ajoutée allonge les paquets. Si un paquet devient trop long pour un tronçon du trajet, il doit être découpé, ou l’émetteur doit être prévenu de réduire sa taille. Quand ce message d’alerte est bloqué en route, les petits échanges passent mais les gros restent coincés sans aucun message d’erreur. Enfin, la protection s’arrête aux passerelles : à l’intérieur de chaque site, les messages circulent à nouveau sans brouillage.

Pages voisines

La citent

GRE, IPsec ou GRE dans IPsec pour un tunnel site à site

Elle cite

GRE, IPsec ou GRE dans IPsec pour un tunnel site à site

GRE, IPsec ou GRE dans IPsec pour un tunnel site à site

GRE, IPsec et GRE dans IPsec : ce que chaque encapsulation apporte

MTU et fragmentation dans un tunnel

Routage dynamique et multicast dans le tunnel

Exemple : GRE dans IPsec entre deux passerelles Linux

Surface d’attaque d’un tunnel GRE ou IPsec

Exploitation : clés, rotation, supervision et reprise

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines