Sur cette page
À retenir
- Connectivité et mitigation sont alignéesLe même modèle gère la joignabilité, le filtrage et le retour du trafic propre.
- Moins de migrations d’urgenceLes services existants peuvent souvent rester en place pendant que le trafic est nettoyé en amont.
- Adapté aux réseaux qui veulent garder la mainBGP, under-ASN, AS-SET, tunnels et cross-connect restent compatibles avec une logique opérateur.
Le problème opérationnel
Le modèle classique est fragmenté. Un fournisseur vend le transit, un autre vend la protection DDoS, et le client découvre pendant l’attaque que les deux ne partagent pas les mêmes hypothèses. Le lien transit sature avant la couche de nettoyage, un tunnel devient le goulot d’étranglement ou le fournisseur propose un blackhole parce que l’attaque dépasse le port local.
Cette fragmentation coûte cher aux clients en production. Un hébergeur ne peut pas changer toutes les IPs clients en pleine crise. Un service gaming ne peut pas accepter une latence aléatoire ou des faux positifs. Une plateforme SaaS ne peut pas passer des heures à rediscuter le routage alors que ses APIs tombent. Le transit protégé est utile parce qu’il part du chemin réseau au lieu d’ajouter la mitigation après coup.
Pourquoi cela compte avant l’attaque
Le premier bénéfice est la prévisibilité. Quand connectivité et mitigation sont vendues comme une seule architecture, le client peut poser des questions précises : où entre le trafic, quelle capacité protège le port, quels préfixes sont acceptés, comment revient le trafic propre et que se passe-t-il au-delà du commit. Cette clarté vaut plus qu’une promesse vague de protection illimitée.
Le deuxième bénéfice est la vitesse opérationnelle. Avec du transit IP protégé, beaucoup de décisions sont prises avant l’incident : sessions BGP, type de livraison, politique de routage, endpoint tunnel, règles firewall et escalade. Pendant l’attaque, l’équipe peut observer et ajuster au lieu d’inventer un nouveau chemin sous pression.
- Connectivité et mitigation sont alignées
- Le même modèle gère la joignabilité, le filtrage et le retour du trafic propre.
- Moins de migrations d’urgence
- Les services existants peuvent souvent rester en place pendant que le trafic est nettoyé en amont.
- Adapté aux réseaux qui veulent garder la main
- BGP, under-ASN, AS-SET, tunnels et cross-connect restent compatibles avec une logique opérateur.
Les approches techniques possibles
Les alternatives ne sont pas mauvaises ; elles répondent à d’autres besoins. Un reverse proxy est excellent pour un service de jeu ou web précis quand le client ne fait pas de routage. Un scrubbing on-demand peut aider si la diversion est acceptable. Un firewall local garde sa valeur après réduction du volume. Mais si l’exposition est réseau, le transit protégé est souvent la meilleure première couche.
La bonne architecture peut combiner plusieurs briques : transit protégé pour le chemin principal, tunnels pour serveurs distants, VM routeur pour les clients qui veulent garder le contrôle BGP, filtrage gaming spécialisé pour les services sensibles à la latence. Le bénéfice vient du placement de chaque fonction à la bonne couche.
- Transit protégé
- Idéal comme chemin par défaut pour des préfixes exposés en permanence.
- Reverse proxy
- Idéal pour des endpoints applicatifs ou gaming sans gestion BGP.
- Scrubbing à la demande
- Utile quand la diversion est acceptable et que le client maîtrise le routage.
- Filtrage local
- Toujours utile après réduction du volume d’attaque en amont.
Cas concret d’utilisation
Une plateforme d’hébergement reçoit des attaques répétées sur différentes IPs clients. Un firewall local ne suffit pas quand le port upstream est saturé. Mettre tous les clients derrière un proxy est irréaliste. Le transit protégé traite le problème de base : le trafic hostile passe par le chemin de mitigation avant d’écraser le côté client, puis le trafic propre revient via le mode choisi.
Pour un fournisseur de jeux, le bénéfice est un peu différent. Il ne s’agit pas seulement de garder le lien debout, mais de préserver la qualité des sessions. Un filtrage trop générique peut laisser le serveur “en ligne” tout en déconnectant les joueurs. Le transit protégé absorbe le volume, puis un filtrage gaming peut être ajouté quand il apporte une vraie valeur.
Cartographier préfixes et services exposés
Séparer l’exposition réseau des services qui relèvent plutôt d’un reverse proxy.
Choisir la livraison par défaut
Cross-connect en datacenter, tunnel pour origine distante, VM routeur pour autonomie BGP.
Définir le handoff propre
Savoir où arrive le trafic filtré et ce qui se passe en congestion.
Garder du contrôle post-filtre
Utiliser des règles locales pour les décisions spécifiques après réduction du gros volume.
Erreurs fréquentes à éviter
- Comparer uniquement les capacités de mitigation affichées.
- Ignorer le 95e percentile, le commit et les règles d’overage.
- Confondre transit protégé et reverse proxy gaming.
- Oublier le retour du trafic propre vers l’origine.
- Choisir un fournisseur incapable d’expliquer la gestion des faux positifs.
FAQ
Le transit IP protégé est-il réservé aux entreprises avec ASN ?
Non. Il est très fort pour les réseaux avec besoins de routage, mais peut être adapté par tunnel ou VM routeur selon le client.
Remplace-t-il tous les firewalls ?
Non. Il réduit la pression amont. Des règles locales ou post-filtre restent utiles pour la politique client.
Peut-il protéger des serveurs existants sans migration ?
Souvent oui, notamment via GRE, IPIP ou VXLAN vers l’origine existante.
