Transit IP protégé : routage, filtrage et livraison du trafic

Les limites du modèle classique face au DDoS

Avant de comprendre le transit protégé, il faut comprendre pourquoi le modèle classique ne fonctionne plus dès qu’un service commence à attirer des attaques sérieuses ou récurrentes.

Dans un environnement standard, le trafic malveillant arrive trop près de la production avant qu’un filtrage vraiment décisif ne s’applique. C’est précisément là que naissent la saturation, la hausse de facture et les réponses d’urgence trop destructrices.

Saturation réseau

Une attaque volumétrique peut dépasser 100 Gbps, voire plusieurs Tbps. Un port 10G, 25G ou même 100G peut être rempli bien avant que le service n’ait une chance de se défendre.

Explosion des coûts

Non. L’effet dépend de la période facturée, du point de mesure, de la durée des échantillons et de la proportion des valeurs élevées. Comparez le commit contractuel au P95 mesuré ; ne le déduisez pas du pic maximal.

Blackhole de l’IP

Dans beaucoup d’environnements, la réponse d’urgence devient le blackhole de l’adresse attaquée. Le reste du réseau survit peut-être, mais le client ciblé reste hors ligne.

Qu’est-ce qu’un transit IP protégé anti-DDoS ?

Le transit IP protégé associe une connectivité Internet à un filtrage DDoS en amont du point de livraison convenu. L’objectif est de réduire le trafic d’attaque tout en maintenant l’accès aux services. Le résultat dépend du trafic, de la politique, de la capacité disponible et du chemin de livraison.

Fonctionnement réel d’un transit protégé

Le trafic des préfixes protégés est attiré par la politique de routage convenue. BGP détermine la joignabilité ; l’infrastructure de mitigation effectue le filtrage. Les chemins permanents et à la demande ont des contraintes différentes de convergence et d’exploitation.

Le trafic filtré est remis par la connexion prévue au contrat. Validez capacité de réception, MTU, chemin retour et échanges applicatifs avant la production. La capacité globale de mitigation ne représente pas le débit réservé à un port ou à un tunnel individuel.

1. Routage

   Vérifier les préfixes annoncés, les autorisations et l’entrée prévue.

2. Observation

   Comparer débit, paquets par seconde et symptômes applicatifs au trafic normal.

3. Filtrage

   Appliquer la politique choisie et vérifier son état effectif.

4. Livraison

   Contrôler le chemin de réception et les transactions légitimes réussies.

Détection, application des règles et vérification

La mitigation compare le trafic observé aux seuils et aux règles configurés. Détection, décision, application et rétablissement du service sont des étapes distinctes. Leurs délais dépendent de l’échantillonnage, de l’attaque, de la configuration et du chemin réseau.

Ce guide n’établit pas de délai de réaction mesuré de bout en bout. Lors de la qualification, relevez le début du trafic anormal, l’application de la règle et le rétablissement des transactions légitimes. Une décision locale rapide ne démontre pas, à elle seule, le retour à la normale sur tout le réseau.

Livraison du trafic propre

La livraison peut conserver l’infrastructure existante si l’adressage, le routage et la capacité du point de terminaison le permettent. L’encapsulation transporte les paquets ; elle n’identifie pas elle-même les attaques.

GRE / IPIP

Livraison L3 vers un équipement existant ; vérifier le réseau sous-jacent, la MTU et le retour.

VXLAN

Option de transport Ethernet et de segmentation ; tenir compte de la surcharge supplémentaire.

Cross-connect

Interconnexion physique dont le port, le VLAN, la redondance et la capacité doivent être confirmés.

Routeur VM

Point de routage ou de terminaison de tunnel. Le débit utile dépend du chemin virtualisé et des ressources allouées.

Cas d’usage concrets

Protéger un serveur existant

Ajouter une couche de protection à un dédié OVH, Hetzner ou autre sans déplacer toute l’infrastructure.

Héberger son propre filtrage

Utiliser un serveur dédié avec logique XDP ou autre pour terminer le filtrage après le dégrossissement amont.

Gaming

FiveM, Minecraft et autres services sensibles à la latence ont besoin d’une mitigation rapide, propre et peu intrusive.

SaaS, APIs et services critiques

Les usages non standards et les flux applicatifs atypiques bénéficient fortement d’une mitigation construite autour du trafic réel.

Évaluer le filtrage avec du trafic légitime

Mesurez les paquets acceptés et rejetés, les ouvertures de connexion réussies, les pertes et les temps de réponse applicatifs. Réduire l’attaque est utile si le service reste utilisable. Aucune politique ne doit être supposée sans faux positifs ni impact sur les performances.

La capacité des ports, le débit en paquets, l’encapsulation et les équipements de réception limitent la livraison. Évaluez les contrôles UDP ou TCP par source face aux NAT partagés, VPN et pics légitimes. Une même adresse peut représenter plusieurs utilisateurs.

FlowSpec peut réduire en amont un motif d’attaque vérifié avant un lien contraint. Contrôlez sa portée, l’action prise en charge, le retrait et l’effet sur le trafic légitime. Une règle trop large peut interrompre le service alors que le graphe d’attaque s’améliore.

Erreurs fréquentes à éviter

Une bonne solution anti-DDoS doit protéger le lien, la facture, l’expérience utilisateur et la logique métier du service. Si elle ne couvre qu’un seul de ces aspects, elle reste incomplète.

• Se baser uniquement sur le Gbps alors que le PPS est souvent le vrai facteur limitant.
• Choisir une protection trop générique pour un trafic qui sort des grands cas standards.
• Négliger le routage alors que le symétrique et l’asymétrique n’ont pas du tout les mêmes implications économiques et réseau.
• Penser qu’un transit protégé remplace toute logique complémentaire alors qu’une approche multi-couche reste souvent idéale.

Questions fréquentes