Diagnosticare il routing asimmetrico: strumenti, sequenza di verifica e contromisure

Routing asimmetrico non è un’eccezione nelle reti moderne con Multi‑Homing, load balancer e orchestrazione di container, ma un quadro operativo plausibile. Diventa problematico quando sul percorso sono presenti dispositivi con stato (stateful Firewalls, NAT/Conntrack, Load Balancer con logica di sessione) che si aspettano il ritorno. Questo contributo fornisce una sequenza di verifica collaudata e minimamente invasiva, spiega gli strumenti principali e mostra contromisure pratiche — in particolare anche per ambienti Kubernetes.

Perché il routing asimmetrico crea problemi in esercizio

L’IP‑routing consente percorsi diversi di andata e ritorno. Spesso questo è desiderabile (bilanciamento del carico, ridondanza). Se però una componente stateful interviene su uno dei percorsi, ciò può causare perdita di pacchetti o connessioni interrotte. Breve spiegazione dei termini rilevanti: Stateful Firewall verifica lo stato della sessione, NAT (Network Address Translation) modifica sorgente/destinazione e richiede tabelle consistenti, Conntrack è il meccanismo kernel Linux per il connection‑tracking, rp_filter (Reverse Path Filter) scarta pacchetti la cui rotta di ritorno non è plausibile.

Indicatori precoci: quando verificare immediatamente l’asimmetria

Prima di apportare modifiche, verifichi i sintomi che sono particolarmente tipici:

• Il SYN dal client verso il server arriva, il SYN/ACK esce dal server ma non raggiunge il client.
• Interruzioni di connessione solo da specifiche reti di origine o tramite determinati operatori.
• Comportamento differente tra UDP e TCP (UDP appare più robusto, poiché i dispositivi stateful non intervengono).
• Problemi solo con specifici valori MTU / con trasferimenti di grandi dimensioni (PMTUD/ICMP coinvolti).

Sequenza di verifica: strutturata, sincronizzata, minimamente invasiva

Operi secondo il principio: prima osservare, poi modificare. Sequenza tipica:

Ambito e piano di riproduzione

Definisca sorgente, destinazione, protocollo, porta, orario e nodi coinvolti (per Kubernetes: Namespace, Service, Pod, Node). Stabilisce una finestra temporale per eseguire le catture in modo sincronizzato.

Traceroute e mtr in modalità protocollo

Le rotte ICMP possono differire dal percorso TCP/UDP. Utilizzi traceroute/mtr con TCP per mappare il percorso del suo servizio.

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

Controllare host‑routing e policy

Su Linux i comandi ip route get e ip rule indicano quale tabella e quale interfaccia vengono utilizzate per le risposte. PBR (Policy‑Based Routing) usa regole (ip rule) e tabelle di routing aggiuntive; le VRF isolano completamente le tabelle.

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

Verificare rp_filter in modo consapevole

Il Reverse Path Filtering può scartare traffico Multi‑Homing legittimo. Controlli le impostazioni globali e quelle per interfaccia.

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

Per modifiche persistenti crei un file in /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

Catture tcpdump bilaterali: il gold standard

Catture sincronizzate su client, router/firewall coinvolti, server o Kubernetes‑Node generano le prove. Filtri sui 5‑tuple (Src IP, Dst IP, Src Port, Dst Port, Proto) per ottenere corrispondenze univoche.

# 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

È importante il timing: se il SYN arriva al server e il SYN/ACK esce dal server ma non risulta nel capture sul client, indica un problema di percorso di ritorno.

Conntrack e diagnostica degli stati

Conntrack gestisce gli stati di connessione nel kernel. Voci invalide o mancanti indicano la mancanza di gestione NAT/degli stati.

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

Interpretazione: una voce con stato UNREPLIED o voci che scompaiono rapidamente indicano pacchetti di ritorno mancanti o timeout aggressivi.

Kubernetes: insidie aggiuntive e controlli concreti

Kubernetes aumenta la complessità: Load Balancer, kube‑proxy (iptables/ipvs/eBPF), CNI‑Overlay e SNAT influenzano l’IP sorgente e i percorsi di ritorno. Controlli le configurazioni dei Service e i capture a livello di Node e Pod.

ExternalTrafficPolicy e SNAT

Per i Service esistono due modalità operative per ExternalTrafficPolicy: Cluster (default, permette il forwarding a qualsiasi Node, può causare SNAT) e Local (mantiene l’IP del client, richiede che il LB indirizzi solo i Node con endpoint locali). Scegliete consapevolmente in base alla topologia del firewall.

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

Captures in Pods und Nodes

Usi un debug‑Pod privilegiato o un DaemonSet per effettuare capture sulle interfacce host. Questo mostra se avviene SNAT e quale Node invia la risposta di ritorno.

# 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 modalità iptables applica regole NAT; IPVS lavora con virtual server e può adottare differenti criteri di hashing/percorso; i proxy basati su eBPF (es. Cilium) offrono migliore osservabilità e possono evitare SNAT opzionalmente. Verifichi quale modalità sta utilizzando e quali implicazioni ha sulla decisione del percorso di ritorno.

Contromisure: quali soluzioni sono praticabili e quando

1) Symmetrie per PBR erzwingen

Se il Multi‑Homing è la causa, instradi le risposte attraverso la stessa interfaccia che ha ricevuto il pacchetto. Questo si realizza con ip rule e tabelle di routing separate.

# 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

Limitazioni: il PBR è utile solo se l’indirizzo sorgente è stabile e noto e non ci sono NAT‑proxy a monte che ne alterino la sorgente.

2) Stateful Komponenten konsistent platzieren

Strategia: o raggruppare le funzioni stateful in una posizione deterministica (p. es. cluster NAT/Firewall centrale), oppure gestire appliance stateful con State‑Sync (operativamente oneroso). Con firewall attivo/attivo è possibile la State‑Replication, ma complessa e soggetta a errori.

3) Firewall/ACLs anpassen statt rp_filter pauschal zu deaktivieren

Impostare rp_filter su loose può aiutare a breve termine, ma riduce la protezione contro lo spoofing. Meglio: adattare le regole del firewall in modo che consentano le sorgenti SNAT e i percorsi di ritorno attesi.

4) Lastverteilung und Stickiness

Con load balancer esterni, la session‑stickiness o un metodo di hashing possono determinare quale backend accetta il flow. È una soluzione pragmatica quando la simmetria non può essere ripristinata completamente.

5) Ampliare l’osservabilità

A lungo termine, Flow‑Logs (NetFlow/IPFIX), Firewall Session Logs, eBPF‑Tracing o metriche centralizzate MRTG/Prometheus sono utili per identificare rapidamente i nodi del percorso di ritorno e rilevare regressioni dopo le modifiche.

Rollback, gestione dei cambiamenti e checklist

Le modifiche a routing e firewall sono critiche. Testate in piccoli passi e salvate le configurazioni precedenti.

# 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

Documentate i punti di rollback e manteneteli recuperabili in modo automatizzato (Ansible/Playbooks, Git‑ops). Monitorate i contatori conntrack, i retransmit e i contatori dei drop della firewall dopo ogni modifica.

Se le modifiche non risolvono: misure di escalation

• Flow‑mirroring temporaneo o SPAN sul router per osservare i pacchetti di ritorno.
• Riconfigurare il load balancer a livello di pool (stickiness, Only‑Local‑Nodes).
• Disattivazione temporanea delle funzionalità stateful (solo con valutazione chiara del rischio).

Checklist pratica (versione breve)

1. Definire lo scope e pianificare i capture.
2. TCP‑traceroute e capture tcpdump da entrambe le parti.
3. Verificare ip route/ip rule/rp_filter.
4. Analizzare le voci conntrack e i log delle sessioni firewall.
5. Kubernetes: verificare ExternalTrafficPolicy, SNAT, capture su node/pod.
6. Eseguire la minima modifica, attivare il monitoring, definire un chiaro punto di rollback.

Conclusione

L’asymmetria del routing può essere diagnosticata in modo affidabile seguendo un approccio sistematico: definire lo scope, effettuare capture da entrambe le parti, verificare lo stato di host e kernel (routing, rp_filter, conntrack) e considerare le specificità di Kubernetes. Operativamente sono sensati tre approcci: simmetria tramite routing/PBR, collocazione consistente delle funzioni stateful o workaround come lo stickiness sul load balancer. Documentazione e punti di fallback sono obbligatori per ogni modifica. Con buona osservabilità i tempi di diagnosi si riducono da ore a minuti.

Routing asimmetrico: prospettive di architettura, operatività e osservabilità

Oltre alla diagnosi degli errori, conviene considerare il routing asimmetrico da una prospettiva architetturale e operativa. Quali componenti nel percorso dei dati sono stateful, quali influenzano la Source‑IP o il Next‑Hop e quali meccanismi di misura/rollout avete per reazioni rapide? I punti seguenti forniscono indicazioni pratiche per decisioni, rischi e flussi operativi integrati.

Rischi dovuti a rotture di state nascoste

I rischi operativi tipici emergono quando un flow crea state in un punto (es. firewall/NAT) e la risposta di ritorno torna tramite un altro percorso privo delle informazioni di state. Operativamente ciò causa errori intermittenti difficili da riprodurre. Rischi in sintesi:

• Interruzioni imprevedibili in seguito ad aggiornamenti di versione o modifiche di policy su firewall/load balancer.
• Overflow di conntrack durante picchi di traffico che rifiuta nuove connessioni.
• Intercettazione da parte di service‑mesh/sidecar che devia pacchetti o esegue SNAT.

Conntrack e tuning del kernel come strumenti operativi

I limiti e i timeout di Conntrack sono spesso cause trascurate. Quando le tabelle si riempiono, le nuove connessioni non vengono più tracciate, il che può manifestarsi come drop asimmetrici. Verificate e impostate limiti leggermente superiori e adattate i timeout al vostro profilo di traffico.

# 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

Dopo le modifiche controllate i valori e l’utilizzo:

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

Osservabilità: metriche, test sintetici, eBPF

Senza telemetria continua i percorsi asimmetrici restano problemi fantasma. Costruite tre livelli:

1. Base: log di sessione di Firewall/Router e contatori di Conntrack (esportabili a Prometheus).
2. Sintetico: probe TCP‑SYN periodiche e mirate lungo i percorsi critici per verificare il comportamento del percorso di ritorno.
3. Deep‑Tracing: eBPF‑tracing (z. B. Cilium, bpftrace) per la correlazione persistente dei flow tra host.

# 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

Per Prometheus potete raccogliere i valori di Conntrack tramite node_exporter o Textfile‑Collector. Esempio di formato 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: consigli per l’integrazione

I service mesh e gli overlay CNI spesso modificano il flusso (Sidecar‑SNAT, Traffic‑Redirect). Misure pratiche:

• Per i percorsi critici di gateway verificate il bypass dei sidecar (z. B. Gateway/ingress senza Sidecar o con hostNetwork).
• Usate l’osservabilità eBPF/CNI (z. B. Cilium Hubble) per correlare Node↔Pod↔Service.
• Per LB esterni: abilitare ExternalTrafficPolicy=Local + LB‑stickiness come compromesso per permettere percorsi di ritorno deterministici.

Change‑Management, Canary‑Rollouts ed escalation

Le modifiche a Routing/Firewalls dovrebbero essere eseguite in step Canary: subnet ridotte, client limitati, monitoraggio automatico con trigger di alert. Definite soglie di escalation chiare (Conntrack‑Auslastung, Retransmit‑Rate, Firewall‑Drop‑Raten). Automatizzate i rollback tramite Ansible/Playbook, in modo che un errore sia revertibile entro tempi definiti.

In breve: non considerate il routing asimmetrico solo un caso di debug, ma un tema architetturale. Con il tuning di Conntrack, osservabilità mirata, eBPF‑tracing e una procedura di change Canary disciplinata riducete il rischio operativo e aumentate la velocità di reazione agli incidenti reali.

Regole di architettura e operative per la prevenzione

Considerate i percorsi asimmetrici come tema architetturale, non solo come caso di debug. Separate le funzioni di rete transitive (Routing/ECMP) dai servizi stateful (NAT, Firewalls, Load‑Balancer) e definite percorsi chiari: i componenti stateful devono essere raggiungibili in modo deterministico o usare State‑Sync. Usate BGP‑Communities o Source‑Based‑Routing per imporre il determinismo del percorso di ritorno negli scenari di Multi‑Homing.

Operativamente: imposti soglie per la saturazione di Conntrack, le ritrasmissioni e i drop del firewall come alert, automatizzi sonde SYN sintetiche nel sistema di monitoraggio e integri le modifiche delle policy di routing in un workflow GitOps con passi Canary testati. Documenti esplicitamente le dipendenze verso componenti software aziendali personalizzati che si basano su indirizzi IP lato client o sull’affinità di sessione, e conservi i log di sessione per analisi forensi.

Per questo tema sono inoltre rilevanti il routing asimmetrico e il routing loop. Il contributo inquadra questi aspetti in modo comprensibile e mostra cosa è rilevante nella pratica quotidiana.