Le routage asymétrique n’est pas automatiquement un problème en Anti-DDoS. Le vrai sujet est de savoir quelles fonctions exigent une symétrie stricte, comment le trafic propre revient vers la production et si le fournisseur dépend de mécanismes comme le SYN proxy. Ce guide explique quand l’asymétrie pose réellement souci, pourquoi certains acteurs la supportent mal, et pourquoi chez Peeryx elle n’altère pas la qualité du filtrage.
Ce n’est pas l’asymétrie en soi, mais les mécanismes stateful et le mode de retour du trafic propre.
Les solutions qui dépendent d’un SYN proxy ou d’une logique TCP stateful tolèrent souvent mal l’asymétrie.
Notre filtrage n’est pas dépendant d’un SYN proxy classique et le TCP reset de secours fonctionne en symétrique comme en asymétrique.
On parle de routage asymétrique quand le chemin aller et le chemin retour d’un flux ne sont pas identiques. En pratique, un paquet peut entrer dans votre infrastructure via un point de mitigation, un transit ou un tunnel, alors que la réponse repart par un autre lien, un autre fournisseur, un autre site ou un autre chemin de sortie.
Ce comportement est fréquent sur Internet et n’est pas, à lui seul, un défaut. Le problème apparaît quand l’architecture Anti-DDoS suppose implicitement une symétrie qu’elle n’a pas réellement : firewall stateful trop strict, analyse incomplète, tunnel de retour mal défini, mauvaise relivraison du trafic propre, ou dépendance à une appliance qui doit voir les deux sens du flux pour bien fonctionner.
En Anti-DDoS, mal comprendre le routage asymétrique conduit souvent à de faux diagnostics. Certaines solutions supportent mal l’asymétrie parce qu’elles reposent sur un SYN proxy ou sur d’autres briques stateful qui exigent de voir les deux sens d’une session TCP. Dans ce cas, l’asymétrie devient effectivement un sujet critique.
À l’inverse, quand la mitigation ne dépend pas de cette logique, l’asymétrie n’altère pas forcément la qualité du filtrage. Sur la majorité des protocoles, ce qui compte surtout est la qualité de la détection, la relivraison du trafic propre et la cohérence du chemin retour vers la production.
Une asymétrie mal pensée peut créer des coupures ou des comportements incohérents même si la mitigation volumétrique fonctionne.
Les équipes doivent savoir où elles observent le trafic et quelles mesures restent fiables.
Pare-feux, NAT, ACL stateful et certaines fonctions applicatives supportent plus ou moins bien l’asymétrie.
Le trafic propre doit revenir vers la bonne destination, avec la bonne MTU, le bon chemin et une logique opérationnelle claire.
Il n’existe pas un seul bon modèle. Le bon choix dépend du fournisseur Anti-DDoS, des mécanismes réellement utilisés, des préfixes, des liens disponibles et de la façon dont le trafic propre revient vers la production.
Certains acteurs s’appuient sur un SYN proxy ou sur une logique de validation TCP qui tolère mal l’asymétrie. D’autres architectures n’en ont pas besoin au quotidien et peuvent fonctionner proprement avec un routage asymétrique contrôlé, tant que le handoff est clair et que les composants stateful sont au bon endroit.
| Modèle | Ce qu’il apporte | Limite principale | Pertinent quand |
|---|---|---|---|
| Asymétrie tolérée et assumée | Souplesse réseau et intégration plus simple | Demande une bonne compréhension des composants stateful | Les deux sens du flux n’ont pas besoin de traverser exactement la même couche |
| Mitigation + retour propre contrôlé | Architecture plus lisible pour la relivraison | Nécessite un design propre des tunnels, routes et MTU | Vous voulez protéger sans perdre la maîtrise du chemin retour |
| Modèle plus symétrique | Comportement plus simple pour certains équipements | Moins de flexibilité et parfois plus de contraintes opérateur | Vous avez des fonctions stateful ou des appliances qui supportent mal l’asymétrie |
| Architecture hybride | Bon compromis entre contrôle, exploitation et compatibilité | Plus de rigueur de design | Vous combinez plusieurs sites, plusieurs liens ou plusieurs profils de services |
Chez Peeryx, le bon réflexe consiste à partir du chemin du trafic avant de parler du filtre lui-même. Il faut cartographier où le trafic entre, où il est nettoyé, où il est remis et quelles fonctions ont réellement besoin de voir les deux sens du flux.
Notre mitigation ne repose pas sur un SYN proxy classique. En pratique, le filtrage s’appuie d’abord sur la génération de règles intelligentes. En sécurité supplémentaire, une vérification de type 3-way handshake sous forme de TCP reset peut s’activer automatiquement uniquement en cas d’extrême nécessité si une attaque TCP n’était pas stoppée par les règles générées. Ce mécanisme fonctionne aussi bien en symétrique qu’en asymétrique, en réinitialisant uniquement la première connexion TCP de chaque IP source, sans gêner les connexions suivantes. À ce jour, aucun client n’en a eu besoin en production, mais cette sécurité existe si nécessaire.
Identifier clairement le trajet aller, le trajet retour et les variations possibles selon le préfixe, le service ou le site.
Pare-feux stateful, NAT, middleboxes, métriques, sondes, tunnels et fonctions qui ont besoin de voir les deux sens.
Cross-connect, GRE, IPIP, VXLAN, Router VM ou autre handoff propre selon le besoin.
Valider le comportement non seulement pendant l’attaque, mais aussi en trafic légitime et en situation dégradée.
Le sujet est particulièrement pertinent si vous comparez plusieurs fournisseurs Anti-DDoS, si vous annoncez vos propres préfixes, si vous utilisez plusieurs liens ou plusieurs sites, ou si vous devez faire revenir du trafic propre vers une infrastructure existante.
Il est encore plus important quand un fournisseur dépend de mécanismes stateful sensibles à l’asymétrie. À l’inverse, sur les protocoles et les architectures qui ne reposent pas sur cette logique, la question centrale devient surtout la qualité du handoff et la cohérence du retour propre.
Prenons un service protégé dont le trafic entrant passe par Marseille pour être nettoyé, tandis que le trafic sortant repart ensuite par un autre lien plus proche de l’utilisateur final. Dans une telle architecture, l’asymétrie peut au contraire être bénéfique : le chemin retour plus court réduit souvent fortement la latence perçue, parfois presque de moitié selon la géographie du client.
Chez Peeryx, ce modèle n’abaisse pas la qualité du filtrage sur les autres protocoles. Ce qui compte est que l’entrée soit correctement protégée et que le trafic propre soit remis au bon endroit, avec une production conçue pour accepter ce retour.
Entrée via Marseille, trafic propre remis vers la production, sortie locale plus proche du client pour une meilleure latence.
Fournisseur dépendant d’un mécanisme TCP stateful sensible à l’asymétrie alors que votre réseau n’est pas symétrique.
L’erreur la plus fréquente consiste à croire que le routage asymétrique est mauvais par principe. En réalité, tout dépend des mécanismes de mitigation réellement utilisés et des briques stateful présentes dans l’architecture.
Une autre erreur consiste à oublier d’expliquer comment le trafic propre revient vers la production, ou à choisir un fournisseur dont la logique TCP dépend d’une symétrie stricte alors que votre réseau est conçu pour fonctionner de manière asymétrique.
Le problème réel est souvent ailleurs : stateful mal placé, retour propre flou ou mauvaise exploitation.
Certains équipements supportent mal que les deux sens du flux ne passent pas au même endroit.
Sans schéma clair du chemin du trafic, les équipes perdent du temps et se trompent pendant l’incident.
Le mode de remise du trafic propre doit être défini dès le départ.
Peeryx ne vend pas une théorie vague sur la symétrie. L’approche consiste à regarder les préfixes, les liens, la logique de handoff, les composants stateful et les vrais besoins de production.
Surtout, notre filtrage n’est pas dépendant d’un SYN proxy classique. Pour le TCP, une sécurité supplémentaire par TCP reset peut s’activer seulement en cas d’extrême nécessité et fonctionne aussi bien en symétrique qu’en asymétrique. Pour le reste des protocoles, la qualité du filtrage ne change pas, tandis que l’asymétrie peut même améliorer la latence quand l’entrée passe par Peeryx et que la sortie reste locale.
Le chemin du trafic et le handoff sont analysés avant la promesse commerciale.
Préfixes, BGP, tunnels, modèles hybrides et continuité de production.
L’objectif est de protéger sans rendre le réseau incompréhensible à exploiter.
Non. Il peut être parfaitement acceptable si les composants sensibles, le handoff et la relivraison du trafic propre sont conçus en conséquence.
Parce que certaines briques stateful, certains firewalls, certains NAT ou certains outils d’analyse ont besoin de voir les deux sens du flux de manière cohérente.
Très souvent, le point critique est le retour du trafic propre et la façon dont il arrive vers la production.
Non. Ils aident à définir un mode de remise du trafic, mais ils ne remplacent pas une vraie logique de design réseau.
Parce qu’un mauvais cadrage de l’asymétrie peut dégrader la disponibilité, la visibilité opérationnelle et la qualité de livraison du trafic propre.
Le routage asymétrique n’est ni un tabou absolu ni un détail sans importance. En Anti-DDoS, il faut surtout comprendre quelles briques doivent voir quoi, comment le trafic propre revient, et quel niveau de symétrie votre architecture exige réellement.
Le bon design consiste à protéger sans perdre la lisibilité du réseau. Plus votre environnement est sérieux, plus cette discipline fait la différence entre une mitigation crédible et une architecture qui devient difficile à exploiter.
Expliquez vos préfixes, vos liens, votre logique de handoff et vos composants stateful : nous pouvons vous aider à cadrer une architecture propre, compatible avec un routage symétrique ou asymétrique.
