Blog
Tunnels GRE pour l'IPv4 : quand il en faut un et comment le mettre en place
Un tunnel vous permet d'utiliser des adresses IPv4 sur un serveur qui ne pourrait pas les porter autrement. Le bloc est annoncé par un réseau qui peut l'annoncer, et le tunnel transporte son trafic jusqu'à votre serveur et retour. C'est la réponse lorsque votre fournisseur ne propose pas le BYOIP (bring your own IP, l'importation de vos propres adresses), lorsque vous n'avez pas de numéro d'AS, ou lorsqu'il vous faut moins que les 256 adresses qu'Internet achemine seules.
Ce que fait réellement le tunnel
Les paquets destinés à votre bloc arrivent au réseau qui l'annonce. Là, chaque paquet est encapsulé dans un nouveau, adressé à votre serveur, et envoyé par l'Internet ordinaire. Votre serveur le désencapsule et voit le paquet d'origine, comme si les adresses étaient configurées sur une interface locale.
Original packet: [IP header | data]
GRE packet: [outer IP | GRE header | IP header | data]Les réponses suivent le même chemin en sens inverse : votre serveur les encapsule, les envoie à l'autre extrémité du tunnel, et ce réseau les délivre. Ce chemin de retour est l'étape que la plupart des configurations ratent, et la configuration ci-dessous montre pourquoi.
Quand un tunnel l'emporte sur le BYOIP
Le BYOIP permet à un fournisseur cloud ou d'hébergement d'annoncer votre bloc depuis son propre réseau (quels fournisseurs le font). Là où il est disponible et où vous avez au moins un /24, c'est l'option la plus propre : pas de saut supplémentaire, pas de point de défaillance supplémentaire, et toute la bande passante du fournisseur. Un tunnel est le meilleur choix dans quatre cas.
- Votre fournisseur ne propose pas le BYOIP. Scaleway, par exemple, le dit clairement dans sa documentation, et plusieurs autres ne l'acceptent que sur demande, pour certains de leurs produits, comme Infomaniak, TransIP et UpCloud. D'autres, parmi lesquels Contabo, Exoscale, Hostinger et Akamai Cloud, ne publient aucune procédure.
- Il vous faut moins de 256 adresses. Un /24 est le plus petit bloc que les réseaux acceptent dans leurs tables de routage, et le BYOIP d'aucun fournisseur ne descend en dessous. Un tunnel peut livrer un /29, ou une seule adresse.
- Vous n'avez pas d'ASN, et le fournisseur en veut un. Certains fournisseurs n'acceptent vos adresses que par une session BGP avec votre propre numéro d'AS. Un tunnel n'exige ni l'un ni l'autre.
- Vous voulez les mêmes adresses à plusieurs endroits, ou la liberté de déménager. L'annonce reste où elle est ; le tunnel va partout où va votre serveur.
Le prix est un détour. Le trafic passe par l'autre extrémité du tunnel avant de vous atteindre : choisissez donc une extrémité proche de votre serveur, et retenez que c'est la capacité du tunnel, et non le port de votre serveur, qui fixe le plafond.
GRE ou WireGuard
Tous deux transportent le même trafic ; ils diffèrent par ce qu'exige le chemin entre les deux extrémités.
| GRE | WireGuard | |
|---|---|---|
| Chiffrement | Aucun | Oui |
| Surcoût sur IPv4 | 24 octets | 60 octets |
| Derrière du NAT ou du CGNAT | Ne fonctionne pas de façon fiable | Fonctionne |
| Prise en charge | La plupart des routeurs et le noyau Linux | Le noyau Linux, FreeBSD, OpenBSD, MikroTik RouterOS 7, OpenWrt et EdgeOS ; consultez la documentation de votre constructeur avant d'y compter sur un routeur d'opérateur |
| Idéal quand | Le chemin est de confiance et le débit compte avant tout | Le trafic traverse des réseaux que vous ne contrôlez pas, ou l'extrémité n'a pas d'adresse publique |
La liste des plateformes de WireGuard et la documentation RouterOS de MikroTik indiquent où il fonctionne (vérifié le 22 octobre 2026).
Si votre extrémité se trouve derrière du NAT, le choix est fait pour vous : WireGuard. Il en va de même pour Azure, qui bloque le GRE dans ses réseaux virtuels.
MTU et MSS : la panne classique
L'encapsulation ajoute des en-têtes : le plus grand paquet qui tient dans le tunnel est donc plus petit que les 1 500 octets d'un lien Ethernet ordinaire, soit 1 476 octets pour du GRE sur IPv4, et WireGuard fonctionne couramment à 1 420. Si c'est mal réglé, vous voyez le symptôme classique : les petites requêtes passent, tandis que les gros téléchargements et les négociations TLS restent bloqués, car les paquets qui ne tiennent pas sont rejetés et les messages qui devraient le signaler sont souvent filtrés en route.
Deux réglages l'évitent. Donnez à l'interface du tunnel la bonne valeur de MTU, et limitez la taille maximale de segment TCP (MSS) sur le trafic que vous acheminez par le tunnel, pour que les deux extrémités s'accordent à envoyer des paquets qui tiennent. Nous envoyons les deux valeurs avec chaque tunnel, et les modifions sur demande.
Une configuration Linux minimale
L'exemple ci-dessous amène un bloc à un seul serveur Linux par GRE. Les adresses sont des plages de documentation : 203.0.113.1 est l'adresse publique de votre serveur, 198.51.100.1 l'autre extrémité du tunnel, et 192.0.2.0/24 le bloc.
# 1. The tunnel, from your server to the far end
ip tunnel add gre1 mode gre local 203.0.113.1 remote 198.51.100.1 ttl 255
ip link set gre1 mtu 1476 up
ip addr add 10.0.0.2/30 dev gre1
# 2. An address from the block on the server itself
ip addr add 192.0.2.10/32 dev lo
# 3. Replies from the block go back through the tunnel
ip rule add from 192.0.2.0/24 lookup 100
ip route add default via 10.0.0.1 dev gre1 table 100L'étape 3 est celle qu'on oublie. Sans elle, les réponses de 192.0.2.10 sortent par la liaison montante de votre fournisseur, avec une adresse source que ce fournisseur ne vous a jamais attribuée, et ses filtres anti-usurpation les rejettent. Si votre distribution active un filtrage strict du chemin inverse (reverse-path filtering), passez-le aussi en mode souple pour le tunnel (sysctl -w net.ipv4.conf.gre1.rp_filter=2).
Si le serveur achemine le bloc vers des machines virtuelles ou des conteneurs, limitez le MSS sur le trafic qu'il transfère :
iptables -t mangle -A FORWARD -o gre1 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtuDu BGP dans le tunnel
Si vous avez votre propre numéro d'AS et voulez contrôler l'annonce vous-même, vous pouvez faire tourner une session BGP dans le tunnel au lieu d'une route statique, avec BIRD, FRR ou le démon de votre routeur. La plupart des clients n'en ont pas besoin et choisissent la configuration statique. Si vous annoncez depuis votre propre ASN, le ROA doit indiquer cet ASN (RPKI et ROA).
La place de RTM Networks
Nous annonçons le bloc et le livrons à votre serveur par GRE ou WireGuard, où que se trouve le serveur. Cela fonctionne là où le BYOIP ne fonctionne pas, y compris pour moins de 256 adresses et chez les fournisseurs qui n'acceptent pas du tout vos adresses. Dites-nous où se trouve le serveur et ce qu'il fait tourner, et nous vous recommanderons GRE ou WireGuard et vous enverrons la configuration avec les bonnes valeurs de MTU et de MSS (tunnels GRE et WireGuard).
Contact
Besoin d'un conseil pour votre propre situation ?
Cet article est général ; votre réseau ne l'est pas. Dites-nous avec quoi vous travaillez et nous l'examinerons sérieusement. Nous répondons en général sous 1 à 3 heures ouvrées.
