Guide concret pour protéger un serveur dédié déjà en production chez OVH, Hetzner ou un autre hébergeur sans migrer toute l’infrastructure, en utilisant un tunnel GRE avec ou sans BGP.
Protection sans migration complète
Vous pouvez ajouter une couche anti-DDoS sans reconstruire tout votre environnement de production.
Un tunnel GRE permet souvent une mise en place plus rapide qu’une migration complète.
Tunnel seul, GRE + BGP ou IP protégées : le bon schéma dépend surtout de votre architecture.
MTU, retour de trafic, routage et capacité réelle du serveur doivent être validés proprement.
Beaucoup d’entreprises, d’hébergeurs de jeux, de plateformes SaaS ou de services exposés sur Internet ont déjà leurs serveurs dédiés chez OVH, Hetzner ou un autre fournisseur. Quand les attaques DDoS commencent, la première idée entendue est souvent : il faut tout migrer. En pratique, ce n’est ni la seule option, ni toujours la meilleure.
Dans de nombreux cas, une architecture anti-DDoS avec tunnel GRE, avec ou sans BGP, permet de protéger le service tout en gardant le serveur là où il est déjà en production. L’enjeu n’est donc pas seulement de bloquer une attaque, mais de choisir une méthode réaliste, stable et exploitable au quotidien.
Le scénario le plus fréquent est simple : le client a déjà un serveur dédié chez Hetzner, OVH ou un hébergeur similaire. Les services tournent déjà, les IP sont utilisées en production, les sauvegardes sont en place, le monitoring fonctionne, et parfois plusieurs machines dépendent déjà de cet environnement.
Quand les attaques DDoS deviennent récurrentes, le problème n’est pas uniquement applicatif. Le lien peut saturer avant que l’application ait le temps de répondre, la latence grimpe, l’expérience utilisateur se dégrade, et une migration faite dans l’urgence crée souvent plus de risque que de stabilité.
C’est précisément pour ce type de besoin qu’une protection via GRE, avec ou sans BGP, devient pertinente : on ajoute une couche de mitigation en amont sans casser toute la production existante.
Migrer l’ensemble d’une infrastructure peut sembler logique sur le papier, mais en production la réalité est différente. Le client doit souvent préserver des dépendances réseau, des habitudes d’exploitation, des scripts, des licences, des flux inter-serveurs, parfois même des contraintes commerciales ou contractuelles.
L’objectif rationnel n’est donc pas de déplacer systématiquement tout ce qui existe. L’objectif est d’ajouter une protection efficace sans augmenter inutilement le risque opérationnel.
Refaire une architecture entière pendant une période d’attaque ou d’instabilité est rarement la meilleure décision.
Le client garde ses serveurs, ses habitudes d’exploitation, son stockage, son monitoring et ses dépendances locales.
Un tunnel GRE bien intégré permet souvent une mise en service plus rapide qu’une migration complète de production.
On peut commencer par protéger un service exposé, puis étendre progressivement selon les besoins réels.
Un tunnel GRE permet d’encapsuler le trafic propre entre l’infrastructure de mitigation et votre serveur dédié ou votre routeur. L’idée est que le trafic public arrive d’abord sur la couche anti-DDoS, soit filtré, puis soit renvoyé vers votre machine au travers du tunnel.
Dans ce modèle, votre serveur final reste chez OVH, Hetzner ou ailleurs. Il ne reçoit plus directement le trafic brut venant d’Internet : il reçoit le trafic après nettoyage, ce qui permet de conserver l’environnement existant tout en ajoutant une vraie couche de protection réseau.
Cette approche est particulièrement utile pour les services déjà en production, les plateformes de jeux, les applications métiers ou les infrastructures qui ne peuvent pas être déplacées du jour au lendemain.
Les IP protégées ou les préfixes annoncés arrivent d’abord sur l’infrastructure anti-DDoS.
Le but est d’arrêter le trafic malveillant avant qu’il n’atteigne votre environnement de production.
Le trafic propre est envoyé via GRE vers votre dédié ou votre routeur.
Votre application reste sur son hébergeur actuel, mais derrière une couche de protection dédiée.
Le BGP sert surtout quand le client veut annoncer ses propres préfixes IP, garder la maîtrise du routage ou intégrer la protection dans une architecture réseau plus avancée. C’est très utile pour certains profils, mais ce n’est pas obligatoire dans tous les cas.
Dans de nombreux déploiements, nous pouvons aussi utiliser nos propres IP protégées anti-DDoS, puis router ce trafic propre vers le serveur dédié OVH ou Hetzner au travers du tunnel GRE. Dans ce scénario, le client n’a pas besoin d’annoncer ses propres blocs pour démarrer.
Autrement dit, BGP est un levier d’architecture et de souplesse. Ce n’est pas un prérequis absolu pour protéger un service hébergé ailleurs.
Idéal si vous avez un ASN, vos préfixes, ou si vous voulez garder un contrôle réseau plus fin.
Approche plus simple quand vous cherchez surtout une protection rapide sans complexifier le routage.
Le trafic arrive sur des IP protégées puis est renvoyé vers votre dédié à travers le tunnel.
Il est possible de démarrer simplement, puis d’évoluer plus tard vers une architecture avec BGP si le besoin change.
Le bon choix dépend du niveau de contrôle réseau recherché, de la rapidité de déploiement souhaitée et du fait que vous utilisiez ou non vos propres préfixes IP. Il n’existe pas un seul schéma valable pour tous les clients.
Souvent le meilleur choix pour protéger rapidement un dédié déjà en production, sans ASN ni annonce BGP à gérer.
Plus adapté si vous possédez vos IP, voulez garder vos annonces et intégrer la protection dans une architecture réseau plus souple.
Très pratique pour démarrer vite, tester la latence, valider l’intégration et éviter de déplacer tout votre adressage immédiatement.
Pertinent pour des environnements plus gros ou des clients déjà présents en datacenter avec des besoins de livraison plus directs.
Une bonne solution de protection ne doit pas être vendue comme magique. Il faut aussi comprendre ce que cette architecture apporte réellement, et ce qu’elle impose de vérifier côté client.
Le principal intérêt est de préserver les serveurs déjà en place au lieu d’imposer une migration complète.
Vous pouvez protéger un service, puis élargir le périmètre lorsque l’architecture est validée.
MTU, routage de retour, firewall, règles locales et capacité réelle de la machine doivent être vérifiés sérieusement.
Si l’application, le serveur ou l’architecture interne sont déjà saturés hors attaque, la protection réseau seule ne réglera pas tout.
Chez Peeryx, l’idée n’est pas de pousser une migration totale par principe. Nous cherchons d’abord à comprendre l’infrastructure existante, le mode de livraison le plus cohérent et le niveau de contrôle réseau réellement nécessaire.
Selon le cas, cela peut passer par des IP protégées routées vers votre dédié via GRE, par une architecture avec BGP si vous voulez garder vos annonces, ou par une montée en charge progressive pour sécuriser d’abord les services les plus exposés.
Imaginons un client qui héberge déjà un serveur de jeu ou un backend applicatif chez Hetzner. Il veut garder cette machine parce que tout son environnement est déjà prêt, mais il subit des attaques régulières et ne veut pas tout migrer d’un coup.
Le déploiement le plus propre consiste souvent à faire arriver le trafic public sur une couche anti-DDoS dédiée, filtrer l’attaque, puis renvoyer uniquement le trafic légitime via un tunnel GRE vers le serveur Hetzner. Si le client possède ses propres IP ou souhaite plus de contrôle, on peut ajouter le BGP. Sinon, il peut très bien démarrer avec des IP protégées fournies côté anti-DDoS.
On vérifie le type de service, la sensibilité à la latence, le mode d’exploitation et la capacité du serveur à recevoir le trafic propre.
Tunnel seul, tunnel + BGP ou IP protégées selon le niveau de contrôle recherché.
On valide le GRE, le retour de trafic, le MTU et la stabilité générale avant bascule réelle.
Le client garde son infra, tout en bénéficiant d’une couche anti-DDoS mieux adaptée à son cas réel.
La plupart des problèmes ne viennent pas du principe GRE ou BGP lui-même, mais d’un mauvais cadrage initial ou d’une architecture trop simplifiée sur le papier.
Oui. C’est même l’un des cas les plus fréquents : le serveur reste chez Hetzner et reçoit le trafic légitime via GRE après mitigation en amont.
Non. Le BGP est utile pour certains clients, mais un tunnel GRE avec des IP protégées peut suffire pour beaucoup de déploiements.
Oui. Le principe reste le même : le trafic est nettoyé en amont puis acheminé vers le serveur OVH via une architecture adaptée.
Oui. C’est souvent la meilleure manière d’avancer : démarrer simple, valider la production, puis ajouter du BGP si cela devient utile.
Oui, précisément parce qu’elle permet d’ajouter une couche de protection sans imposer une migration complète dès le départ.
Protéger un serveur dédié Hetzner ou OVH contre les attaques DDoS ne veut pas forcément dire tout migrer. Dans de nombreux cas, une architecture avec tunnel GRE, avec ou sans BGP, permet d’ajouter une vraie couche de mitigation tout en gardant l’environnement déjà en place.
Le bon schéma dépend ensuite de votre réalité technique : besoin de vos propres IP, volonté de garder la maîtrise du routage, simplicité de déploiement recherchée, ou besoin de démarrer vite avec des IP protégées déjà opérées côté anti-DDoS.
L’enjeu n’est donc pas seulement de bloquer une attaque, mais de choisir une architecture crédible, propre et exploitable en production.
Décrivez-nous votre infrastructure actuelle, votre hébergeur, vos contraintes réseau et votre niveau de contrôle souhaité. Nous vous dirons s’il vaut mieux partir sur un GRE simple, un GRE + BGP ou une livraison via IP protégées.
