Tunnel GRE entre sites

Un tunnel GRE (Generic Routing Encapsulation) encapsule des paquets IP dans d'autres paquets IP. HolyCloud peut l'utiliser pour renvoyer du trafic filtré (anti-DDoS) ou pour relier deux sites via Internet. Ce guide décrit la configuration type sur Linux ; toute mise en production GRE avec HolyCloud doit être validée par le support.

Prérequis

• Deux points de terminaison avec IP publiques (VPS, serveur dédié, routeur)
• Accès root sur les serveurs Linux
• Modules noyau ip_gre disponibles
• Paramètres fournis par HolyCloud si tunnel vers scrubbing : IP locales tunnel, préfixes autorisés

Ne créez pas de tunnel GRE vers l'infrastructure HolyCloud sans documentation d'IP de peering et de clés éventuelles.

Schéma logique

[Site A — VPS 203.0.113.10] === GRE encapsulation ===> [Site B — 198.51.100.20]
         gre0 10.10.10.1/30                              gre0 10.10.10.2/30

Le trafic applicatif utilise les IP privées du tunnel ; l'encapsulation traverse Internet entre les IP publiques.

Site A — création interface GRE

modprobe ip_gre
ip tunnel add gre0 mode gre remote 198.51.100.20 local 203.0.113.10 ttl 255
ip addr add 10.10.10.1/30 dev gre0
ip link set gre0 up

• local : IP publique locale (sortie vers Internet)
• remote : IP publique du peer distant
• 10.10.10.1/30 : IP point à point côté A (B sera .2)

Site B — configuration miroir

modprobe ip_gre
ip tunnel add gre0 mode gre remote 203.0.113.10 local 198.51.100.20 ttl 255
ip addr add 10.10.10.2/30 dev gre0
ip link set gre0 up

Test de connectivité

Sur A :

ping -c 4 10.10.10.2

Capture pour vérifier l'encapsulation :

tcpdump -i eth0 host 198.51.100.20 and proto gre

Routage via le tunnel

Exemple : réseau privé 192.168.50.0/24 derrière le site B, accessible depuis A :

Sur Site A :

ip route add 192.168.50.0/24 via 10.10.10.2 dev gre0

Sur Site B (retour vers LAN A 192.168.40.0/24) :

ip route add 192.168.40.0/24 via 10.10.10.1 dev gre0

Activez le forwarding IP si le VPS fait routeur :

sysctl -w net.ipv4.ip_forward=1

Pare-feu : autoriser proto 47 (GRE) et le sous-réseau tunnel.

iptables -A INPUT -p gre -j ACCEPT
# ou nftables équivalent

Persistance au reboot (netplan / Debian)

Fichier /etc/systemd/network/gre0.netdev (systemd-networkd) ou script @reboot.

Exemple /etc/network/interfaces.d/gre0 (ifupdown) :

auto gre0
iface gre0 inet static
    address 10.10.10.1
    netmask 255.255.255.252
    pre-up ip tunnel add gre0 mode gre remote 198.51.100.20 local 203.0.113.10 ttl 255
    post-down ip tunnel del gre0

Adaptez à votre distribution (netplan Ubuntu, NetworkManager, etc.).

GRE et anti-DDoS HolyCloud

Dans les offres scrubbing avancées :

Internet → [Centre filtrage] --GRE--> gre0 sur votre serveur → services locaux

Particularités :

• Seul le trafic nettoyé arrive sur gre0.
• L'IP publique « brute » peut être retirée de l'interface principale pendant l'attaque.
• MTU réduit (souvent 1476 ou moins) — ajustez mtu sur gre0 et MSS TCP :

ip link set gre0 mtu 1476

iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Sécurité

• GRE n'est pas chiffré — pour confidentialité, superposez IPsec ou WireGuard.
• Filtrez sur les routeurs : n'accepter GRE que depuis l'IP remote connue.
• Sur Windows Server : GRE possible mais hors scope ; privilégiez Linux ou routeur dédié pour scénarios HolyCloud documentés.

Dépannage

| Symptôme | Action |

|----------|--------|

| ping tunnel KO | Pare-feu bloque proto 47 ; mauvaise IP local/remote |

| MTU / fragmentation | Baisser MTU gre0 ; MSS clamp |

| Route asymétrique | Vérifier ip route des deux côtés |

| Tunnel up, pas de LAN distant | ip_forward ; routes statiques ; NAT mal placé |

ip -d link show gre0
ip route get 192.168.50.1

Besoin d'aide ?

Demande GRE provisioning : fournissez IP publiques des deux extrémités, préfixes à router, besoin IPv6 (GRE over IPv6 possible). Le support HolyCloud fournit les paramètres officiels et active le peering côté réseau.