8 min de lecture Avancé 5.2k

Protéger un serveur distant avec un tunnel GRE et l'IP Remote Transit VeryCloud

Publié le 16 mai 2026 à 19:32

Routez le trafic d'un serveur hébergé n'importe où dans le monde à travers un tunnel GRE jusqu'à VeryCloud, et profitez de l'Anti-DDoS Netrix sur votre IP publique. Idéal pour protéger un serveur OVH, AWS, Hetzner, ou même une connexion résidentielle business.

Introduction

Vous avez un serveur chez OVH, AWS, ou un hébergeur qui ne fournit pas d'Anti-DDoS, et qui subit des attaques régulièrement ? Le service Remote Transit IP de VeryCloud résout ce problème : VeryCloud vous fournit une IP publique protégée Netrix, et le trafic est routé vers votre serveur distant via un tunnel GRE (Generic Routing Encapsulation).

Du point de vue d'Internet, votre serveur a l'IP de VeryCloud. Toutes les attaques sont absorbées par Netrix avant d'atteindre votre serveur.

Prérequis

Un service Remote Transit IP souscrit chez VeryCloud (IP publique + tunnel)
Un serveur distant (Linux, Windows, OVH, AWS, etc.) avec IP publique routable
Accès root au serveur distant
Protocole IP 47 (GRE) non bloqué sur le réseau du serveur distant (point d'attention critique, voir étape 1)

Étape 1 : Vérifier que le protocole GRE n'est pas filtré

Le GRE n'utilise pas un port TCP/UDP : c'est un protocole IP de niveau 4 (numéro 47). Certains réseaux le filtrent par défaut :

Bbox / Bouygues Telecom (résidentiel) : ❌ GRE filtré par défaut
Freebox : ✅ GRE autorisé (en mode bridge ou avec firewall ouvert)
OVH / Hetzner / Scaleway / AWS : ✅ GRE généralement autorisé

Avant de souscrire au Remote Transit, ouvrez un ticket à votre FAI ou hébergeur pour confirmer que IP Protocol 47 est autorisé en entrée et sortie sur votre serveur.

Test depuis votre serveur distant :

# Tenter d'envoyer un paquet GRE vers VeryCloud
sudo modprobe ip_gre
# Si pas d'erreur, GRE est supporté côté kernel.
# Le filtrage réseau ne se voit qu'au moment de monter le tunnel.

Étape 2 : Récupérer les informations de tunnel chez VeryCloud

Après souscription, VeryCloud vous fournit dans l'espace client :

IP publique attribuée (ex: 82.26.157.20) — celle qui sera visible sur Internet
IP point-à-point côté VeryCloud (ex: 10.10.0.1)
IP point-à-point côté client (ex: 10.10.0.2)
Endpoint GRE VeryCloud (ex: 185.X.X.X)

Notez ces 4 valeurs.

Étape 3 : Monter le tunnel GRE sur Linux

Avec iproute2 (méthode moderne)

# Charger le module
sudo modprobe ip_gre

# Créer le tunnel
sudo ip tunnel add tun0 mode gre \
    remote 185.X.X.X \
    local IP_DE_VOTRE_SERVEUR \
    ttl 255

# Attribuer l'IP point-à-point côté client
sudo ip addr add 10.10.0.2/30 dev tun0

# Activer l'interface
sudo ip link set tun0 up

# Vérifier
ip addr show tun0

Configurer la route par défaut vers le tunnel

C'est l'étape qui fait que tout le trafic sortant passe par VeryCloud. Sans ça, le serveur garde son IP publique d'origine.

# Ajouter une route spécifique pour atteindre VeryCloud sans passer par le tunnel
sudo ip route add 185.X.X.X via $(ip route show default | awk '{print $3}') dev $(ip route show default | awk '{print $5}')

# Remplacer la route par défaut par le tunnel
sudo ip route del default
sudo ip route add default via 10.10.0.1 dev tun0

Attention : à partir de ce moment, votre serveur ne sera plus accessible depuis l'extérieur via son IP d'origine ! Pour vous reconnecter, utilisez la nouvelle IP VeryCloud (82.26.157.20).

Étape 4 : Configurer l'IP publique VeryCloud sur le serveur

# Ajouter l'IP virtuelle sur une interface dummy
sudo ip link add veryclouddummy type dummy
sudo ip addr add 82.26.157.20/32 dev veryclouddummy
sudo ip link set veryclouddummy up

Votre serveur écoute désormais sur 82.26.157.20 (l'IP VeryCloud).

Étape 5 : Tester la connectivité

Depuis l'extérieur (votre PC) :

# Vérifier que l'IP VeryCloud répond
ping 82.26.157.20

# Tester le HTTP si web actif
curl -I http://82.26.157.20

Depuis le serveur distant :

# Vérifier la sortie via VeryCloud
curl -s https://api.ipify.org
# Doit retourner 82.26.157.20 (et non votre IP d'origine)

Étape 6 : Persistance du tunnel (au reboot)

Sans config persistante, le tunnel disparaît au redémarrage. Plusieurs options :

Option A : Service systemd

sudo nano /etc/systemd/system/gre-tunnel.service

[Unit]
Description=GRE Tunnel to VeryCloud
After=network.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/local/bin/setup-gre.sh
ExecStop=/usr/local/bin/teardown-gre.sh

[Install]
WantedBy=multi-user.target

sudo nano /usr/local/bin/setup-gre.sh

#!/bin/bash
modprobe ip_gre

ip tunnel add tun0 mode gre remote 185.X.X.X local IP_DE_VOTRE_SERVEUR ttl 255
ip addr add 10.10.0.2/30 dev tun0
ip link set tun0 up

ip route add 185.X.X.X via $(ip route show default | awk '{print $3}') dev $(ip route show default | awk '{print $5}')
ip route del default
ip route add default via 10.10.0.1 dev tun0

ip link add veryclouddummy type dummy
ip addr add 82.26.157.20/32 dev veryclouddummy
ip link set veryclouddummy up

sudo nano /usr/local/bin/teardown-gre.sh

#!/bin/bash
ip tunnel del tun0
ip link del veryclouddummy

sudo chmod +x /usr/local/bin/setup-gre.sh /usr/local/bin/teardown-gre.sh
sudo systemctl daemon-reload
sudo systemctl enable --now gre-tunnel

Option B : Netplan (Ubuntu 22.04+)

sudo nano /etc/netplan/99-gre.yaml

network:
  version: 2
  tunnels:
    tun0:
      mode: gre
      local: IP_DE_VOTRE_SERVEUR
      remote: 185.X.X.X
      addresses:
        - 10.10.0.2/30
      routes:
        - to: 0.0.0.0/0
          via: 10.10.0.1

sudo netplan apply

Étape 7 : Configurer Windows Server (cas alternatif)

Sur Windows, GRE est supporté nativement mais nécessite PowerShell admin.

# Activer le routage IP
New-ItemProperty -Path "HKLM:\System\CurrentControlSet\Services\Tcpip\Parameters" -Name "IPEnableRouter" -Value 1 -PropertyType DWord -Force

# Créer le tunnel GRE (RAS API)
# (Plus complexe sous Windows, voir Add-VpnConnection avec mode "Gre" si disponible)

Pour Windows, VeryCloud recommande plutôt l'usage de WireGuard ou OpenVPN en tant que tunnel alternatif. Ouvrez un ticket pour discuter de la meilleure approche selon votre cas.

Étape 8 : Configurer le firewall

Avec le tunnel actif, votre firewall doit autoriser le protocole GRE :

# UFW
sudo ufw allow proto gre from 185.X.X.X

# iptables
sudo iptables -A INPUT -p gre -s 185.X.X.X -j ACCEPT
sudo iptables -A OUTPUT -p gre -d 185.X.X.X -j ACCEPT

Étape 9 : Routage avancé — protéger uniquement certains services

Si vous ne voulez pas tout faire passer par VeryCloud (ex: garder SSH sur l'IP d'origine pour gérer le serveur), utilisez policy routing :

# Créer une table de routage dédiée
echo "100 verycloud" | sudo tee -a /etc/iproute2/rt_tables

# Tout le trafic provenant de l'IP VeryCloud passe par le tunnel
sudo ip rule add from 82.26.157.20 table verycloud
sudo ip route add default via 10.10.0.1 dev tun0 table verycloud

Désormais :

SSH sur IP originale → passe par la connexion classique
Web sur IP VeryCloud → passe par le tunnel et est protégé

Étape 10 : Vérifier la protection Anti-DDoS

Avec le tunnel actif, toute attaque vers 82.26.157.20 est mitigée par Netrix avant d'arriver chez vous. Vous pouvez vérifier :

Dans l'espace client VeryCloud : statistiques d'attaques mitigées
Vos logs (Nginx, application) ne montrent plus les sources d'attaque (juste le trafic légitime)

Dépannage

Le tunnel monte mais aucun trafic ne passe

Le protocole 47 est filtré quelque part. Inspectez :

sudo tcpdump -i any proto gre -n

Si vous ne voyez que des paquets sortants et aucun retour, le filtrage est côté FAI/réseau. Solution : changez de FAI/hébergeur ou contactez-le pour ouvrir.

MTU et fragmentation

GRE ajoute 24 octets d'overhead. Si vos paquets sont fragmentés, des connexions HTTPS/web peuvent échouer.

Adaptez le MTU :

sudo ip link set tun0 mtu 1476
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Boucle de routage

Si vous mettez l'IP VeryCloud 82.26.157.20 comme via dans une route au lieu de 10.10.0.1, le serveur essaie d'atteindre son propre IP = boucle. Toujours utiliser l'IP point-à-point client (10.10.0.2 côté client, 10.10.0.1 côté VeryCloud comme gateway).

Connexion perdue après ajout de la route par défaut

Vous vous êtes verrouillé ! Si vous accédiez en SSH via l'IP d'origine, le changement de route casse la session.

Solution : avant de basculer la default route, ouvrez une seconde session via screen ou tmux, ou utilisez le KVM noVNC de l'espace client VeryCloud / OVH pour reprendre la main.

Commandes utiles

# Voir tous les tunnels actifs
ip tunnel show

# Voir les routes
ip route show
ip route show table all

# Démonter le tunnel
sudo ip tunnel del tun0

# Inspecter le trafic GRE
sudo tcpdump -i any proto gre -n

# Tester un ping à travers le tunnel
ping -I tun0 8.8.8.8

# Voir l'IP publique vue de l'extérieur
curl -s https://api.ipify.org

Conclusion

Vous protégez désormais un serveur distant avec l'Anti-DDoS Netrix VeryCloud, sans déplacer physiquement le serveur. C'est la solution idéale pour :

Continuer à utiliser une infra OVH/Scaleway/AWS existante
Héberger sur un serveur résidentiel business (Free, abonnement pro)
Mutualiser une protection Netrix entre plusieurs sites

Pour les usages très haute performance (Gaming compétitif, faible latence), VeryCloud recommande d'héberger directement chez VeryCloud plutôt que de tunneliser, car chaque saut réseau ajoute 5-15ms.

Ressources

Documentation Anti-DDoS VeryCloud : https://verycloud.fr/as198825
RFC GRE : https://tools.ietf.org/html/rfc2784
Tuto VeryCloud — Combiner Cloudflare et Netrix : https://verycloud.fr/docs/article/cloudflare-netrix-ddosprotection
Ouvrir un ticket pour Remote Transit IP : https://manager.verycloud.fr