Diagnostiquer le routage asymétrique : outils, séquence de vérification et contre-mesures

Le routage asymétrique n’est pas une exception dans les réseaux modernes avec multi‑homing, équilibreurs de charge et orchestration de conteneurs, mais un scénario d’exploitation plausible. Cela devient problématique dès qu’il existe sur le chemin des dispositifs à état (pare‑feu à état, NAT/Conntrack, équilibreurs de charge avec logique de session) qui attendent le chemin de retour. Cet article fournit une séquence de vérification éprouvée et peu invasive, explique les outils principaux et présente des contre‑mesures pragmatiques — y compris pour les environnements Kubernetes.

Pourquoi le routage asymétrique pose problème en exploitation

Le routage IP autorise des chemins aller et retour différents. Cela est souvent souhaitable (répartition de charge, redondance). Toutefois, si une composante à état est présente sur l’un des chemins, cela entraîne des pertes de paquets ou des connexions interrompues. Termes importants expliqués brièvement : Stateful Firewall vérifie l’état des sessions, NAT (Network Address Translation) modifie la source/la destination et nécessite des tables cohérentes, Conntrack est le Linux‑mécanisme du noyau pour le suivi des connexions, rp_filter (Reverse Path Filter) rejette les paquets dont le chemin de retour n’est pas plausible.

Indicateurs précoces : quand vérifier immédiatement l’asymétrie

Avant d’apporter des modifications, vérifiez les symptômes particulièrement typiques :

• Le SYN du client atteint le serveur, le SYN/ACK quitte le serveur mais n’atteint pas le client.
• Coupures de connexion uniquement depuis certains réseaux source ou via certains opérateurs.
• Comportement différent entre UDP et TCP (UDP semble plus robuste, car les dispositifs à état ne l’inspectent pas).
• Problèmes uniquement pour certaines valeurs MTU / lors de transferts volumineux (PMTUD/ICMP impliqués).

Séquence de vérification : structurée, synchronisée, peu invasive

Appliquez le principe : observer d’abord, modifier ensuite. Ordre typique :

Périmètre et plan de reproduction

Définissez la source, la destination, le protocole, le port, l’heure et les nœuds concernés (pour Kubernetes : Namespace, Service, Pod, Node). Fixez une fenêtre temporelle pour réaliser les captures de manière synchronisée.

Traceroute et mtr en mode protocole

Les routes ICMP peuvent différer du chemin TCP/UDP. Utilisez traceroute/mtr en TCP pour cartographier le chemin utilisé par votre service.

mtr -T -P 443 -r -c 20 
traceroute -T -p 443 

Vérifier le routage d’hôte et les politiques

Sur Linux, ip route get et ip rule indiquent quelle table et quelle interface seront utilisées pour les réponses. Le PBR (Policy‑Based Routing) utilise des règles (ip rule) et des tables de routage supplémentaires ; les VRF isolent complètement les tables.

ip route get 
ip route get  from 
ip rule show
ip route show table all

Contrôler rp_filter de façon ciblée

Le filtrage du chemin inverse peut rejeter un trafic multi‑homing légitime. Vérifiez les paramètres globaux et par interface.

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf..rp_filter

Pour des modifications persistantes, créez un fichier dans /etc/sysctl.d/ :

# /etc/sysctl.d/99-rpfilter.conf
net.ipv4.conf.all.rp_filter=2
net.ipv4.conf.default.rp_filter=2
net.ipv4.conf.eth0.rp_filter=2

Captures tcpdump des deux côtés : l’étalon‑or

Des captures synchronisées sur le client, les routeurs/pare‑feu concernés, le serveur ou les nœuds Kubernetes produisent la preuve. Filtrez sur le 5‑tuple (Src IP, Dst IP, Src Port, Dst Port, Proto) pour obtenir des correspondances univoques.

# Client (oder Edge)
sudo tcpdump -ni any host  and tcp port 443 -w /tmp/cap-client.pcap

# Server (oder Node/POD)
sudo tcpdump -ni any host  and tcp port 443 -w /tmp/cap-server.pcap

Le timing est important : si le SYN arrive au serveur et que le SYN/ACK quitte le serveur, mais qu’il n’est pas visible dans la capture côté client, cela indique un problème de chemin de retour.

Conntrack et diagnostic d’état

Conntrack gère les états de connexion dans le noyau. Des entrées invalides ou manquantes indiquent un manque de gestion NAT/état.

sudo conntrack -L -p tcp --dport 443 | tail -n 20
sudo conntrack -S   # Statistik
cat /proc/net/stat/nf_conntrack

Interprétation : Une entrée avec le statut UNREPLIED ou des entrées disparaissant rapidement indiquent des paquets de retour manquants ou des timeouts agressifs.

Kubernetes: zusätzliche Fallstricke und konkrete Checks

Kubernetes augmente la complexité : load balancer, kube‑proxy (iptables/ipvs/eBPF), CNI‑overlays et SNAT influencent l’adresse source et les chemins de retour. Vérifiez les configurations de Service et les captures au niveau des nœuds et des Pods.

ExternalTrafficPolicy et SNAT

Pour les Services, il existe deux modes de fonctionnement pour ExternalTrafficPolicy : Cluster (par défaut, permet l’acheminement vers n’importe quel Node, peut provoquer du SNAT) et Local (conserve l’IP client, exige que le LB n’adresse que les nœuds avec des endpoints locaux). Choisissez en fonction de votre topologie de pare‑feu.

kubectl get svc -n   -o yaml
# Umstellen (Beispiel)
kubectl patch svc -n   -p '{"spec": {"externalTrafficPolicy": "Local"}}'

Captures dans les Pods et sur les nœuds

Utilisez un Debug‑Pod privilégié ou un DaemonSet pour effectuer des captures sur les interfaces hôtes. Cela montre si du SNAT a lieu et quel nœud renvoie la réponse.

# Beispiel: privilegierter Debug-Pod
kubectl run -i --tty debug --image=corfr/tcpdump --privileged --rm -- bash
# dann im Pod
tcpdump -ni any host  and tcp port  -w /tmp/pod.cap

Kube‑proxy, IPVS et eBPF

Kube‑proxy en mode iptables applique des règles NAT ; IPVS fonctionne avec des serveurs virtuels et peut avoir d’autres décisions de hachage/chemin ; les proxies eBPF (p. ex. Cilium) offrent une meilleure observabilité et peuvent éviter le SNAT de façon optionnelle. Vérifiez quel mode vous utilisez et quelles en sont les conséquences pour la décision du chemin de retour.

Mesures correctives : quelles solutions sont praticables et quand

1) Forcer la symétrie via PBR

Si le multihoming est la cause, forcez les réponses à emprunter la même interface que le paquet entrant. Cela se fait via ip rule et des tables de routage séparées.

# Beispiel PBR
ip rule add from 192.0.2.0/24 table 100
ip route add default via 192.0.2.1 dev eth1 table 100
ip route show table 100
ip rule show

Limitations : le PBR n’aide que si l’adresse source est stable et connue et si aucun proxy NAT en amont ne modifie la source.

2) Placer les composants à état de manière cohérente

Approche : soit regrouper les fonctions à état en un lieu déterministe (p. ex. un cluster NAT/pare‑feu central), soit exploiter des appliances stateful avec synchronisation d’état (opérationnellement coûteux). Pour des pare‑feu actif/actif, la réplication d’état est possible mais lourde et sujette aux erreurs.

3) Adapter les pare‑feu/ACL plutôt que de désactiver rp_filter de manière générale

Mettre rp_filter en « loose » peut aider à court terme, mais réduit la protection contre le spoofing. Mieux vaut : adapter les règles du pare‑feu pour autoriser les sources SNAT et les chemins de retour attendus.

4) Répartition de charge et affinité (stickiness)

Avec des load balancers externes, la session‑stickiness ou une méthode de hachage peut déterminer quel backend prend en charge le flux. C’est un contournement pragmatique lorsque la symétrie ne peut pas être entièrement rétablie.

5) Renforcer l’observabilité

À long terme, les Flow‑Logs (NetFlow/IPFIX), les Firewall Session Logs, le traçage eBPF ou des métriques centralisées MRTG/Prometheus sont utiles pour identifier rapidement les nœuds de retour et détecter les régressions après des changements.

Rollback, gestion des changements et listes de contrôle

Les modifications du routage et des pare‑feu sont critiques. Testez par petites étapes et sauvegardez les configurations précédentes.

# Konfiguration sichern
ip -details route show table all > /tmp/routes.$(date +%F_%H%M).txt
ip rule show > /tmp/iprules.$(date +%F_%H%M).txt
sudo nft list ruleset > /tmp/nft.rules.$(date +%F_%H%M).txt
kubectl get svc -A -o yaml > /tmp/all-svcs.$(date +%F_%H%M).yaml

Documentez les points de rollback et assurez‑vous qu’ils sont restaurables de façon automatisée (Ansible/Playbooks, Git‑ops). Surveillez les compteurs conntrack, les retransmissions et les compteurs de drop du pare‑feu après chaque modification.

Si les modifications ne donnent rien : mesures d’escalade

• Mise en miroir temporaire des flux (Flow‑Mirroring) ou SPAN sur le routeur pour observer les paquets de retour.
• Reconfigurer le load balancer au niveau du pool (Stickiness, Only‑Local‑Nodes).
• Désactivation temporaire des fonctionnalités stateful (uniquement après évaluation claire des risques).

Check‑list pratique (version courte)

1. Définir le périmètre et planifier les captures.
2. TCP‑traceroute et captures tcpdump des deux côtés.
3. Vérifier ip route/ip rule/rp_filter.
4. Analyser les entrées conntrack et les Firewall‑Session‑Logs.
5. Kubernetes : vérifier ExternalTrafficPolicy, SNAT, captures Node/Pod.
6. Effectuer le plus petit changement possible, mettre le monitoring en place, définir un point de rollback clair.

Conclusion

Le routage asymétrique peut être diagnostiqué de manière fiable si vous procédez systématiquement : définir le périmètre, réaliser des captures des deux côtés, vérifier l’état de l’hôte et du noyau (routing, rp_filter, conntrack) et prendre en compte les spécificités Kubernetes. Opérationnellement, trois approches sont pertinentes : symétrie via le routage/PBR, placement cohérent des fonctions stateful ou contournements comme la stickiness au niveau du load balancer. Documentation et points de retour sont obligatoires pour chaque modification. Avec une bonne observabilité, le temps de diagnostic passe de heures à minutes.

Routage asymétrique : perspectives architecture, exploitation et observabilité

Outre le diagnostic pur, il est utile d’examiner le routage asymétrique sous l’angle de l’architecture et de l’exploitation. Quelles composantes du chemin de données sont stateful, lesquelles modifient la Source‑IP ou le Next‑Hop, et quels mécanismes de mesure/déploiement avez‑vous pour réagir rapidement ? Les points suivants fournissent des indications pratiques pour la prise de décision, l’évaluation des risques et les processus opérationnels intégrés.

Risques liés aux ruptures d’état cachées

Les risques opérationnels typiques surviennent lorsqu’un flux crée de l’état à un point (par ex. pare‑feu/NAT) et que la réponse de retour emprunte un autre chemin dépourvu d’information d’état. Sur le plan opérationnel, cela provoque des erreurs intermittentes difficiles à reproduire. Aperçu des risques :

• Pannes imprévisibles lors de changements de version ou de politique sur les pare‑feu/load balancers.
• Saturation du conntrack lors de pics de charge, entraînant le rejet de nouvelles connexions.
• Interception par service‑mesh/sidecar, redirigeant des paquets ou effectuant du SNAT.

Conntrack et tuning du noyau comme outil opérationnel

Les limites et timeouts de Conntrack sont souvent des causes négligées. Lorsque les tables sont saturées, les nouvelles connexions ne sont plus suivies, ce qui peut se manifester par des pertes asymétriques. Vérifiez et augmentez légèrement les limites et adaptez les timeouts au profil de votre trafic.

# Beispiel: persistente Conntrack‑Einstellungen
# /etc/sysctl.d/99-conntrack.conf
net.netfilter.nf_conntrack_max=524288
net.netfilter.nf_conntrack_tcp_timeout_established=86400
sysctl --system

Après modification, vérifiez les valeurs et l’utilisation :

cat /proc/sys/net/netfilter/nf_conntrack_max
cat /proc/net/stat/nf_conntrack

Observabilité : métriques, tests synthétiques, eBPF

Sans télémétrie continue, les chemins asymétriques restent des problèmes fantômes. Mettez en place trois niveaux :

1. De base : journaux de sessions du firewall/routeur et compteurs Conntrack (exportables vers Prometheus).
2. Synthétique : sondes TCP‑SYN périodiques et ciblées le long des chemins critiques pour vérifier le comportement du chemin de retour.
3. Deep‑Tracing : eBPF‑tracing (p. ex. Cilium, bpftrace) pour la corrélation persistante des flux entre hôtes.

# Einfacher SYN‑Probe (nicht invasiv):
hping3 -S -p 443 --count 3 --fast 198.51.100.23
# oder curl für Endpunktverifikation
curl -sS --max-time 5 https://198.51.100.23/healthz

Pour Prometheus, vous pouvez collecter les valeurs Conntrack via node_exporter ou Textfile‑Collector. Exemple de format Textfile :

# /var/lib/node_exporter/textfile_collector/conntrack.prom
# HELP node_conntrack_entries Anzahl der Conntrack‑Einträge
node_conntrack_entries 12345

Kubernetes & Service‑Mesh : conseils d’intégration

Les service mesh et les overlays CNI modifient souvent le flux (Sidecar‑SNAT, redirection de trafic). Mesures pratiques :

• Pour les chemins critiques côté gateway, vérifier le contournement des sidecars (p. ex. gateway/ingress sans sidecar ou avec hostNetwork).
• Utilisez l’observabilité eBPF/CNI (p. ex. Cilium Hubble) pour corréler Node↔Pod↔Service.
• Pour un LB externe : permettre ExternalTrafficPolicy=Local + LB‑Stickiness comme compromis pour obtenir des chemins de retour déterministes.

Gestion des changements, déploiements Canary et escalade

Les modifications de routing/firewalls doivent être effectuées en étapes Canary : petit sous‑réseau, clients limités, monitoring automatique avec triggers d’alerte. Définissez des seuils d’escalade clairs (utilisation de Conntrack, taux de retransmission, taux de drops du firewall). Automatisez les rollbacks via Ansible/playbook afin qu’une erreur soit réversible dans un délai défini.

En bref : ne considérez pas le routage asymétrique uniquement comme un cas de debug, mais comme un sujet d’architecture. Avec le tuning de Conntrack, une observabilité ciblée, le traçage eBPF et une procédure de changement Canary disciplinée, vous réduirez le risque opérationnel et augmenterez la vitesse de réaction en cas d’incidents réels.

Règles d’architecture et d’exploitation pour la prévention

Considérez les chemins asymétriques comme un enjeu d’architecture, pas seulement un cas de debug. Séparez les fonctions réseau transitives (routing/ECMP) des services stateful (NAT, firewalls, load‑balancer) et définissez des chemins clairs : les composants stateful doivent être accessibles de manière déterministe ou utiliser State‑Sync. Utilisez des BGP‑communities ou du Source‑Based‑Routing pour imposer le déterminisme des chemins de retour dans des scénarios multi‑homing.

Sur le plan opérationnel : définissez des seuils pour l’utilisation de Conntrack, les retransmissions et les drops du pare‑feu en tant qu’alertes, automatisez des sondes SYN synthétiques dans votre monitoring et intégrez les modifications de politique de routage dans un workflow GitOps avec des étapes canary testées. Documentez explicitement les dépendances vis‑à‑vis des composants logiciels d’entreprise individuels qui reposent sur des adresses IP côté client ou sur l’affinité de session, et conservez les journaux de session pour des analyses forensiques.

Pour ce sujet, le routage asymétrique et les boucles de routage sont également importants. L’article replace ces aspects de manière compréhensible et montre ce qui compte au quotidien.