6 min de lecture Intermédiaire 5.9k

Monter un tunnel GRE côté client Linux pour Remote Transit IP

Publié le 18 mai 2026 à 16:02

Configurer un tunnel GRE entre ton serveur Linux et le backbone VeryCloud (AS198825) : commandes `ip tunnel`, persistance systemd-networkd ou Netplan, MTU, dépannage IP proto 47 bloqué par les FAI résidentiels.

Introduction

GRE (Generic Routing Encapsulation, RFC 2784) est le transport standard pour livrer du transit BGP à distance. C'est un tunnel L3 simple, sans chiffrement, qui ajoute juste 24 octets de header (4 GRE + 20 IPv4) ou 44 octets (4 GRE + 40 IPv6). Léger, supporté nativement par Linux, Cisco, Arista, OPNsense, Mikrotik.

Limite principale : GRE utilise IP protocol 47, qui est souvent filtré par les box résidentielles (Bouygues Bbox notamment). Si c'est ton cas, va voir le tuto WireGuard ou VXLAN.

Prérequis

Un serveur Linux avec une IP publique fixe (PUB_CLIENT)
Le mail technique VeryCloud avec ton plan d'adressage : PUB_VC (endpoint VeryCloud), 169.254.X.1/30 (IP tunnel VeryCloud), 169.254.X.2/30 (IP tunnel toi), 2a0e:XXXX:XXXX::/127 v6
Root / sudo
Le module kernel ip_gre (présent dans 100% des distros récentes)

Étape 1 : Vérifier le support GRE

sudo modprobe ip_gre
sudo modprobe ip6_gre
lsmod | grep gre

Tu dois voir ip_gre et ip6_gre chargés. Si non, ton kernel est trop minimaliste (rare).

Étape 2 : Créer le tunnel GRE IPv4

Pour un tunnel standard (encapsulation IPv4-in-IPv4) :

sudo ip tunnel add gre-vc mode gre \
    remote PUB_VC \
    local PUB_CLIENT \
    ttl 255

sudo ip link set gre-vc up
sudo ip addr add 169.254.X.2/30 dev gre-vc

Pour un tunnel dual-stack (transporter v4 ET v6 dans le même tunnel GRE) :

sudo ip link add gre-vc type gretap \
    remote PUB_VC \
    local PUB_CLIENT \
    ttl 255

sudo ip link set gre-vc up
sudo ip addr add 169.254.X.2/30 dev gre-vc
sudo ip -6 addr add 2a0e:XXXX:XXXX::1/127 dev gre-vc

💡 gretap est un tunnel GRE en mode tap (L2). En pratique, pour du transit IP simple, mode gre suffit, et tu adresses v4+v6 dessus.

Étape 3 : MTU et fragmentation

GRE ajoute 24 octets de header IPv4 (28 si tu actives les options checksum/key). Sur un lien Ethernet standard MTU=1500, ton MTU effective côté tunnel est 1476.

sudo ip link set gre-vc mtu 1476

TCP-MSS clamping pour éviter les sessions TCP qui se cassent à cause d'un MSS mal calculé :

sudo iptables -t mangle -A FORWARD -o gre-vc -p tcp --tcp-flags SYN,RST SYN \
    -j TCPMSS --clamp-mss-to-pmtu

sudo ip6tables -t mangle -A FORWARD -o gre-vc -p tcp --tcp-flags SYN,RST SYN \
    -j TCPMSS --clamp-mss-to-pmtu

⚠️ Le clamping est obligatoire en pratique. Sans, certains sites web/services se chargeront à moitié.

Étape 4 : Tester la connectivité du tunnel

# Ping IPv4 sur le tunnel
ping 169.254.X.1

# Ping IPv6
ping6 2a0e:XXXX:XXXX::0

Si ça répond, le tunnel est UP. Si non, voir le dépannage.

Étape 5 : Persistance avec systemd-networkd

Pour que le tunnel survive aux reboots, on utilise systemd-networkd (Debian 12+, Ubuntu 22.04+).

/etc/systemd/network/10-gre-vc.netdev :

[NetDev]
Name=gre-vc
Kind=gre

[Tunnel]
Local=PUB_CLIENT
Remote=PUB_VC
TTL=255

/etc/systemd/network/10-gre-vc.network :

[Match]
Name=gre-vc

[Network]
Address=169.254.X.2/30
Address=2a0e:XXXX:XXXX::1/127
LinkLocalAddressing=no

[Link]
MTUBytes=1476

Activation :

sudo systemctl enable --now systemd-networkd
sudo systemctl restart systemd-networkd
networkctl status gre-vc

Étape 6 : Persistance avec Netplan (Ubuntu)

Si tu es sur Ubuntu et que tu préfères Netplan, dans /etc/netplan/60-gre-vc.yaml :

network:
  version: 2
  tunnels:
    gre-vc:
      mode: gre
      local: PUB_CLIENT
      remote: PUB_VC
      mtu: 1476
      addresses:
        - 169.254.X.2/30
        - 2a0e:XXXX:XXXX::1/127

Puis sudo netplan apply.

Étape 7 : Route vers la peer-IP du tunnel

Selon ta config, les IPs du tunnel sont directement joignables via le /30 ou /127. Mais si tu as plusieurs tunnels ou des routes plus complexes, vérifie :

ip route show dev gre-vc
ip -6 route show dev gre-vc

Étape 8 : Préparer pour BGP

Le tunnel est UP, les IPs du tunnel pinguent, tu peux maintenant lancer ton démon BGP (BIRD, FRR, Quagga) avec ces IPs comme peer-IP. Voir les tutos transit-bird2-bgp-v4-v6 ou transit-frr-bgp-v4-v6.

💡 Avant le BGP, autorise TCP/179 entre les IPs du tunnel dans ton firewall :

sudo iptables -A INPUT -p tcp --dport 179 -s 169.254.X.1 -j ACCEPT
sudo iptables -A INPUT -p tcp --sport 179 -s 169.254.X.1 -j ACCEPT

sudo ip6tables -A INPUT -p tcp --dport 179 -s 2a0e:XXXX:XXXX::0 -j ACCEPT
sudo ip6tables -A INPUT -p tcp --sport 179 -s 2a0e:XXXX:XXXX::0 -j ACCEPT

Dépannage

ping sur l'IP du tunnel ne répond pas

Vérifie côté VeryCloud que le tunnel est bien provisionné (mail technique reçu)
Côté toi : ip tunnel show doit lister gre-vc, ip link show gre-vc doit être UP
tcpdump -i any proto gre pour voir si les paquets GRE arrivent

IP proto 47 bloqué (cas FAI résidentiels)

Symptôme classique : aucun paquet GRE ne sort de ta box, ou ne revient
Bouygues Bbox filtre activement proto 47 sur les abonnements grand public
SFR Box parfois aussi
Solution : passer en WireGuard ou VXLAN (voir tutos dédiés)
Ou : héberger derrière un VPS public qui relaie le GRE

Le tunnel monte mais perd des paquets

MTU mal réglé : reteste avec MTU plus bas (1400 puis remonte)
TCP-MSS clamping pas en place
Vérifie qu'il n'y a pas un NAT qui pose problème

Operation not supported à la création du tunnel

Module ip_gre non chargé : sudo modprobe ip_gre
Sur conteneur LXC / Docker : il faut un kernel host qui supporte GRE et des capabilities (NET_ADMIN)

Le tunnel se recrée à chaque reboot

Tu as oublié la persistance systemd-networkd ou Netplan (étape 5 ou 6)

Commandes utiles

# Voir tous les tunnels GRE
ip -d link show type gre
ip tunnel show

# Statistiques du tunnel
ip -s link show gre-vc

# Tcpdump sur le tunnel
sudo tcpdump -i gre-vc -nn

# Tcpdump sur les paquets GRE encapsules
sudo tcpdump -i eth0 proto gre -nn

# Supprimer un tunnel
sudo ip tunnel del gre-vc

Conclusion

GRE sous Linux = 3 commandes pour créer, une fois pour la vie pour la persistance. C'est le transport canonique du Remote Transit IP quand ton FAI ne fait pas la blague de filtrer le proto 47. Combine avec un firewall propre, MSS clamping, et tu as une base solide pour ta session BGP.

Pour aller plus loin : VXLAN si proto 47 bloqué, WireGuard pour chiffrer, BIRD 2 / FRR pour la session BGP par-dessus.