Asymmetrisches Routing diagnostizieren: Tools, Prüfsequenz und Gegenmaßnahmen

Asymmetrisches Routing ist in modernen Netzen mit Multi‑Homing, Load Balancern und Container‑Orchestrierung keine Ausnahme, sondern ein plausibles Betriebsbild. Problematisch wird es immer dann, wenn im Pfad zustandsbehaftete Geräte (stateful Firewalls, NAT/Conntrack, Load Balancer mit Session‑Logik) stehen, die den Rückweg erwarten. Dieser Beitrag liefert eine erprobte, minimalinvasive Prüfsequenz, erklärt die wichtigsten Tools und zeigt praxisnahe Gegenmaßnahmen — speziell auch für Kubernetes‑Umgebungen.

Warum Asymmetrisches Routing im Betrieb stört

IP‑Routing erlaubt unterschiedliche Hin‑ und Rückwege. Das ist oft erwünscht (Lastverteilung, Redundanz). Stört jedoch eine stateful Komponente auf einem der Pfade, führt das zu Paketverlusten oder abgebrochenen Verbindungen. Wichtige Begriffe kurz erklärt: Stateful Firewall prüft Session‑Zustand, NAT (Network Address Translation) ändert Source/Destination und braucht konsistente Tabellen, Conntrack ist der Linux‑Kernelmechanismus für Connection‑Tracking, rp_filter (Reverse Path Filter) verwirft Pakete, deren Rückroute nicht plausibel ist.

Frühe Indikatoren: wann sofort auf Asymmetrie prüfen

Bevor Sie Änderungen vornehmen, prüfen Sie Symptome, die besonders typisch sind:

• SYN vom Client an Server kommt an, SYN/ACK verlässt Server aber erreichte Client nicht.
• Verbindungsabbrüche nur aus bestimmten Quellnetzen oder über bestimmte Carrier.
• Unterschiedliches Verhalten zwischen UDP und TCP (UDP wirkt robuster, da keine stateful Devices prüfen).
• Probleme nur bei bestimmten MTU‑Werten / bei großen Transfers (PMTUD/ICMP betroffen).

Prüfsequenz: strukturiert, synchronisiert, minimalinvasiv

Arbeiten Sie nach dem Prinzip: erst beobachten, dann ändern. Typische Reihenfolge:

Scope und Reproduktionsplan

Definieren Sie Quelle, Ziel, Protokoll, Port, Uhrzeit und betroffene Nodes (bei Kubernetes: Namespace, Service, Pod, Node). Legen Sie ein Zeitfenster fest, um Captures synchron auszuführen.

Traceroute und mtr im Protokollmodus

ICMP-Routen können vom TCP/UDP‑Pfad abweichen. Nutzen Sie traceroute/mtr mit TCP, um den Pfad für Ihren Dienst abzubilden.

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

Host‑Routing und Policy prüfen

Auf Linux zeigen ip route get und ip rule, welche Tabelle und Interface für Antworten eingesetzt werden. PBR (Policy‑Based Routing) nutzt Regeln (ip rule) und zusätzliche Routing‑Tabellen; VRFs isolieren Tabellen vollständig.

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

rp_filter bewusst prüfen

Reverse Path Filtering kann legitimen Multi‑Homing‑Traffic verwerfen. Prüfen Sie globale und Interface‑Einstellungen.

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

Für persistente Änderungen legen Sie eine Datei in /etc/sysctl.d/ an:

# /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

Beidseitige tcpdump‑Captures: der Goldstandard

Synchronisierte Captures an Client, betroffenen Routern/Firewalls, Server oder Kubernetes‑Nodes erzeugen die Beweislage. Filtern Sie auf 5‑Tuple (Src IP, Dst IP, Src Port, Dst Port, Proto), um eindeutige Matching‑Ergebnisse zu erhalten.

# 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

Wichtig ist das Timing: kommt SYN am Server an und SYN/ACK verlässt den Server, aber wird auf Client‑Capture nicht sichtbar, zeigt das ein Rückwegproblem.

Conntrack und Zustandsdiagnose

Conntrack verwaltet Connection‑States im Kernel. Ungültige oder fehlende Einträge weisen auf fehlende NAT/State‑Handling hin.

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

Interpretation: Ein Eintrag mit Status UNREPLIED oder rasch verschwindende Einträge deuten auf fehlende Rückpakete oder aggressive Timeouts.

Kubernetes: zusätzliche Fallstricke und konkrete Checks

Kubernetes erhöht die Komplexität: Load Balancer, kube‑proxy (iptables/ipvs/eBPF), CNI‑Overlays und SNAT beeinflussen Source‑IP und Rückwege. Prüfen Sie Service‑Konfigurationen und Captures auf Node‑ und Pod‑Ebene.

ExternalTrafficPolicy und SNAT

Bei Services gibt es zwei Betriebsmodi für ExternalTrafficPolicy: Cluster (Default, erlaubt Weiterleitung an jeden Node, kann SNAT verursachen) und Local (behält Client‑IP, erfordert dass der LB nur Nodes mit lokalen Endpoints anspricht). Wählen Sie bewusst basierend auf Ihrer Firewall‑Topologie.

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

Captures in Pods und Nodes

Nutzen Sie einen privilegierten Debug‑Pod oder DaemonSet, um Captures auf Host‑Interfaces durchzuführen. Das zeigt ob SNAT stattfindet und welcher Node die Rückantwort schickt.

# 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 und eBPF

Kube‑proxy in iptables‑Modus führt NAT-Regeln; IPVS arbeitet mit virtuellen Servern und kann andere Hashing/Path‑Entscheidungen haben; eBPF‑Proxys (z. B. Cilium) bieten bessere Observability und können SNAT optional vermeiden. Prüfen Sie, welchen Modus Sie laufen haben und welche Auswirkungen das auf die Return‑Path‑Entscheidung hat.

Gegenmaßnahmen: Wann was praktikabel ist

1) Symmetrie per PBR erzwingen

Wenn Multi‑Homing die Ursache ist, lenken Sie Antworten über dasselbe Interface wie das ankommende Packet. Das geht über ip rule und separate Routing‑Tabellen.

# 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

Limitierungen: PBR hilft nur, wenn Quelladresse stabil und bekannt ist und keine vorgelagerten NAT‑Proxies die Source ändern.

2) Stateful Komponenten konsistent platzieren

Optik: entweder stateful Funktionen an einem deterministischen Ort bündeln (z. B. zentraler NAT/Firewall‑Cluster), oder stateful Appliances mit State‑Sync betreiben (operativ aufwendig). Bei aktiv/aktiv Firewalls ist State‑Replication möglich, aber aufwändig und fehleranfällig.

3) Firewall/ACLs anpassen statt rp_filter pauschal zu deaktivieren

rp_filter auf loose setzen kann kurzfristig helfen, reduziert aber Spoofing‑Schutz. Besser: Firewall‑Regeln so anpassen, dass sie SNAT‑Quellen und erwartete Rückpfade erlauben.

4) Lastverteilung und Stickiness

Bei externen Load Balancern kann Session‑Stickiness oder eine Hashing‑Methode klären, welcher Backend den Flow annimmt. Das ist ein pragmatischer Workaround, wenn Symmetrie nicht vollständig hergestellt werden kann.

5) Beobachtbarkeit ausbauen

Langfristig sind Flow‑Logs (NetFlow/IPFIX), Firewall Session Logs, eBPF‑Tracing oder zentralisierte MRTG/Prometheus‑Metriken hilfreich, um Rückwegknoten schnell zu identifizieren und Regressionen nach Changes zu erkennen.

Rollback, Change‑Management und Checklisten

Änderungen an Routing und Firewall sind kritisch. Testen Sie in kleinen Schritten und sichern Sie Vorher‑Konfigurationen.

# 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

Rollback‑Punkte dokumentieren und automatisiert wiederherstellbar halten (Ansible/Playbooks, Git‑ops). Überwachen Sie Conntrack‑Zähler, Retransmits und Firewall‑Drop‑Zähler nach jeder Änderung.

Wenn Änderungen nichts bringen: eskalative Maßnahmen

• Temporäre Flow‑Mirroring oder SPAN auf dem Router, um Rückwegpakete zu sehen.
• Load Balancer auf Pool‑Level neu konfigurieren (Stickiness, Only‑Local‑Nodes).
• Vorübergehende Abschaltung stateful Features (nur mit klarer Risikobewertung).

Praxis‑Checkliste (Kurzversion)

1. Scope definieren und Captures planen.
2. TCP‑traceroute und beidseitige tcpdump‑Captures.
3. ip route/ip rule/rp_filter prüfen.
4. conntrack‑Einträge und Firewall‑Session‑Logs auswerten.
5. Kubernetes: ExternalTrafficPolicy, SNAT, Node‑/Pod‑Captures prüfen.
6. Kleinste Änderung durchführen, Monitoring aktiv, klarer Rollback‑Punkt.

Fazit

Asymmetrisches Routing lässt sich sicher diagnostizieren, wenn Sie systematisch vorgehen: Scope definieren, beidseitige Captures anfertigen, Host‑ und Kernel‑Zustand (Routing, rp_filter, conntrack) prüfen und Kubernetes‑Spezifika berücksichtigen. Operativ sind drei Wege sinnvoll: Symmetrie per Routing/PBR, konsistente Platzierung stateful Funktionen oder Workarounds wie Stickiness beim Load Balancer. Dokumentation und Rückfallpunkte sind bei jeder Änderung Pflicht. Mit guter Observability reduziert sich die Diagnosezeit von Stunden auf Minuten.

Asymmetrisches Routing: Architektur‑, Betriebs‑ und Observability‑Perspektiven

Neben der reinen Fehlerdiagnose lohnt es sich, asymmetrisches Routing aus einer Architektur‑ und Betriebsbrille zu betrachten. Welche Komponenten im Datenpfad sind stateful, welche beeinflussen Source‑IP oder Next‑Hop und welche Mess‑/Rollout‑Mechanismen haben Sie für schnelle Reaktionen? Die folgenden Punkte geben praktische Hinweise für Entscheidungen, Risiken und integrierte Betriebsabläufe.

Risiken durch versteckte State‑Brüche

Typische Betriebsrisiken entstehen, wenn ein Flow an einem Punkt state erzeugt (z. B. Firewall/NAT) und die Rückantwort über einen anderen Pfad mit fehlender State‑Info zurückkommt. Betrieblich führt das zu intermittierenden Fehlern, die schwer reproduzierbar sind. Risiken im Überblick:

• Unvorhersehbare Ausfälle bei Version‑ oder Policy‑Änderungen an Firewalls/Load Balancern.
• Conntrack‑Überlauf bei Lastspitzen, der neue Verbindungen ablehnt.
• Service‑Mesh/Sidecar‑Interception, die Pakete umlenkt oder SNAT durchführt.

Conntrack und Kernel‑Tuning als Betriebswerkzeug

Conntrack‑Limits und Timeouts sind häufig übersehene Ursachen. Wenn Tabellen volllaufen, werden neue Verbindungen nicht mehr getrackt, was sich wie asymmetrische Drops äußern kann. Prüfen und setzen Sie leicht erhöhte Limits und passen Sie Timeouts an Ihr Traffic‑Profil an.

# 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

Kontrollieren Sie nach Änderungen die Werte und die Auslastung:

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

Observability: Metriken, Synthetische Tests, eBPF

Ohne kontinuierliche Telemetrie bleiben asymmetrische Pfade Geisterprobleme. Bauen Sie drei Ebenen auf:

1. Basis: Firewall/Router Session‑Logs und Conntrack‑Zähler (exportierbar an Prometheus).
2. Synthetik: periodische, gezielte TCP‑SYN‑Probes entlang kritischer Pfade, um Rückwegverhalten zu prüfen.
3. Deep‑Tracing: eBPF‑Tracing (z. B. Cilium, bpftrace) für persistente Flow‑Korrelation über Hosts hinweg.

# 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

Für Prometheus können Sie Conntrack‑Werte via node_exporter oder Textfile‑Collector erfassen. Beispiel Textfile‑Format:

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

Kubernetes & Service‑Mesh: Integrationstipps

Service‑Meshe und CNI‑Overlays verändern häufig den Flow (Sidecar‑SNAT, Traffic‑Redirect). Praktische Maßnahmen:

• Für Gateway‑kritische Pfade Sidecar‑Bypass prüfen (z. B. Gateway/ingress ohne Sidecar oder mit hostNetwork).
• Nutzen Sie eBPF/CNI‑Observability (z. B. Cilium Hubble) zur Korrelierung Node↔Pod↔Service.
• Bei externem LB: ExternalTrafficPolicy=Local + LB‑Stickiness als Kompromiss ermöglichen deterministische Rückpfade.

Change‑Management, Canary‑Rollouts und Eskalation

Änderungen an Routing/Firewalls sollten in Canary‑Schritten erfolgen: kleines Subnetz, limitierte Clients, automatisches Monitoring mit Alert‑Triggern. Definieren Sie klare Eskalationsschwellen (Conntrack‑Auslastung, Retransmit‑Rate, Firewall‑Drop‑Raten). Automatisieren Sie Rollbacks per Ansible/Playbook, damit ein Fehlschritt innerhalb definierter Zeit revertierbar ist.

Kurz: Betrachten Sie asymmetrisches Routing nicht nur als Debugfall, sondern als Architekturthema. Mit Conntrack‑Tuning, gezielter Observability, eBPF‑Tracing und einem disziplinierten Canary‑Change‑Verfahren reduzieren Sie Betriebsrisiko und erhöhen die Reaktionsgeschwindigkeit bei echten Vorfällen.

Architektur- und Betriebsregeln zur Vorbeugung

Betrachten Sie asymmetrische Pfade als Architekturthema, nicht nur als Debugfall. Trennen Sie transitive Netzfunktionen (Routing/ECMP) von stateful Diensten (NAT, Firewalls, Load‑Balancer) und legen Sie klare Pfade fest: stateful Komponenten sollten deterministisch erreichbar sein oder State‑Sync verwenden. Nutzen Sie BGP‑Communities oder Source‑Based‑Routing, um Return‑Pfad‑Determinismus in Multi‑Homing‑Szenarien zu erzwingen.

Betrieblich: setzen Sie Schwellen für Conntrack‑Auslastung, Retransmits und Firewall‑Drops als Alerts, automatisieren Sie synthetische SYN‑Probes in Ihr Monitoring und binden Sie Routing‑Policy‑Änderungen in ein GitOps‑Workflow mit getesteten Canary‑Schritten. Dokumentieren Sie explizit Abhängigkeiten zu individuellen Unternehmenssoftware‑Komponenten, die auf klientenseitige IPs oder Session‑Stickiness angewiesen sind, und bewahren Sie Session‑Logs für forensische Analysen auf.

Für dieses Thema sind auch Asymmetric Routing und Routing-Loop wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.