Enrutamiento asimétrico no es una excepción en redes modernas con Multi‑Homing, balanceadores de carga y orquestación de contenedores, sino un patrón operativo plausible. Se vuelve problemático cuando en la ruta existen dispositivos con estado (firewalls con estado, NAT/Conntrack, balanceadores de carga con lógica de sesión) que esperan el camino de retorno. Este artículo ofrece una secuencia de comprobación probada y mínimamente invasiva, explica las herramientas clave y muestra contramedidas prácticas —especialmente también para entornos Kubernetes.
Por qué el enrutamiento asimétrico causa problemas en operación
El enrutamiento IP permite caminos diferentes de ida y vuelta. Eso suele ser deseable (distribución de carga, redundancia). Sin embargo, si un componente con estado está en uno de los caminos, puede provocar pérdida de paquetes o conexiones abortadas. Términos importantes, explicados brevemente: firewall con estado verifica el estado de la sesión, NAT (traducción de direcciones de red) modifica origen/destino y requiere tablas consistentes, Conntrack es el Linux‑mecanismo del kernel para el seguimiento de conexiones, rp_filter (filtro de ruta inversa) descarta paquetes cuya ruta de retorno no es plausible.
Indicadores tempranos: cuándo comprobar inmediatamente la asimetría
Antes de realizar cambios, verifique síntomas que son especialmente típicos:
- El SYN del cliente llega al servidor, pero el SYN/ACK sale del servidor y no alcanza al cliente.
- Cortes de conexión solo desde determinadas redes de origen o a través de determinados operadores.
- Comportamiento distinto entre UDP y TCP (UDP suele comportarse con más resistencia, ya que los dispositivos con estado no lo verifican).
- Problemas solo con ciertos valores de MTU / en transferencias grandes (PMTUD/ICMP afectados).
Secuencia de comprobación: estructurada, sincronizada, mínimamente invasiva
Trabaje según el principio: primero observar, luego cambiar. Orden típica:
Alcance y plan de reproducción
Defina origen, destino, protocolo, puerto, hora y nodos afectados (en Kubernetes: Namespace, Service, Pod, Node). Establezca una ventana temporal para ejecutar capturas de forma sincronizada.
traceroute y mtr en modo de protocolo
Las rutas ICMP pueden diferir del camino TCP/UDP. Use traceroute/mtr con TCP para mapear la ruta de su servicio.
mtr -T -P 443 -r -c 20
traceroute -T -p 443 Comprobar enrutamiento del host y políticas
En Linux muestran ip route get e ip rule qué tabla e interfaz se usan para las respuestas. PBR (Policy‑Based Routing) emplea reglas (ip rule) y tablas de enrutamiento adicionales; las VRF aíslan tablas por completo.
ip route get
ip route get from
ip rule show
ip route show table allComprobar rp_filter de forma deliberada
El filtrado de ruta inversa puede descartar tráfico legítimo de Multi‑Homing. Verifique las configuraciones globales y por interfaz.
sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf..rp_filterPara cambios persistentes, cree un archivo en /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=2Capturas tcpdump en ambos lados: el estándar de oro
Capturas sincronizadas en el cliente, routers/firewalls afectados, servidor o nodos Kubernetes generan la evidencia. Filtre por 5‑Tuple (Src IP, Dst IP, Src Port, Dst Port, Proto) para obtener resultados de coincidencia inequívocos.
# 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.pcapLo importante es la sincronización: si el SYN llega al servidor y el SYN/ACK sale del servidor, pero no aparece en la captura del cliente, eso indica un problema en la ruta de retorno.
Conntrack y diagnóstico de estados
Conntrack gestiona los estados de conexión en el kernel. Entradas inválidas o ausentes indican falta de manejo de NAT/estado.
sudo conntrack -L -p tcp --dport 443 | tail -n 20
sudo conntrack -S # Statistik
cat /proc/net/stat/nf_conntrackInterpretación: una entrada con estado UNREPLIED o entradas que desaparecen rápidamente indican paquetes de retorno ausentes o tiempos de espera agresivos.
Kubernetes: puntos problemáticos adicionales y comprobaciones concretas
Kubernetes aumenta la complejidad: balanceadores de carga, kube‑proxy (iptables/ipvs/eBPF), overlays CNI y SNAT influyen en la IP de origen y en las rutas de retorno. Revise las configuraciones de Service y las capturas en los niveles de Node y Pod.
ExternalTrafficPolicy y SNAT
En los Service existen dos modos de funcionamiento para ExternalTrafficPolicy: Cluster (por defecto, permite reenvío a cualquier Node, puede provocar SNAT) y Local (preserva la IP del cliente, requiere que el LB dirija tráfico solo a nodos con endpoints locales). Selecciónelo de forma consciente según la topología de su firewall.
kubectl get svc -n -o yaml
# Umstellen (Beispiel)
kubectl patch svc -n -p '{"spec": {"externalTrafficPolicy": "Local"}}'Capturas en Pods y Nodes
Utilice un Debug‑Pod privilegiado o un DaemonSet para realizar capturas en las interfaces del host. Esto muestra si se está produciendo SNAT y qué Node envía la respuesta de retorno.
# 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.capKube‑Proxy, IPVS y eBPF
Kube‑proxy en modo iptables aplica reglas NAT; IPVS trabaja con servidores virtuales y puede tomar decisiones de hashing/ruta diferentes; los proxies eBPF (p. ej. Cilium) ofrecen mejor observabilidad y pueden evitar SNAT opcionalmente. Verifique qué modo está ejecutando y qué impacto tiene en la decisión de la ruta de retorno.
Contramedidas: cuándo es práctico cada enfoque
1) Forzar simetría mediante PBR
Si el multihoming es la causa, encamine las respuestas por la misma interfaz que el paquete entrante. Esto se hace con ip rule y tablas de enrutamiento separadas.
# 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 showLimitaciones: PBR solo ayuda si la dirección de origen es estable y conocida y no hay proxies NAT intermedios que cambien la fuente.
2) Colocar componentes stateful de forma consistente
Enfoque: o bien consolidar funciones stateful en un lugar determinista (p. ej., un clúster NAT/firewall central), o operar appliances stateful con sincronización de estado (operativamente costoso). En firewalls activo/activo la replicación de estado es posible, pero compleja y propensa a errores.
3) Ajustar Firewall/ACLs en lugar de desactivar rp_filter de manera general
Establecer rp_filter en „loose“ puede ayudar a corto plazo, pero reduce la protección contra spoofing. Mejor: ajustar las reglas del firewall para permitir las fuentes SNAT y las rutas de retorno esperadas.
4) Balanceo de carga y afinidad (stickiness)
Con balanceadores de carga externos, la persistencia de sesión (session‑stickiness) o un método de hashing pueden determinar qué backend acepta el flujo. Es una solución pragmática cuando no se puede restablecer completamente la simetría.
5) Ampliar la observabilidad
A largo plazo, los registros de flujo (NetFlow/IPFIX), los registros de sesión del firewall, el trazado con eBPF o métricas centralizadas (MRTG/Prometheus) son útiles para identificar rápidamente los nodos de retorno y detectar regresiones tras cambios.
Rollback, Change‑Management und Checklisten
Los cambios en enrutamiento y firewall son críticos. Teste en pasos pequeños y guarde las configuraciones anteriores.
# 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).yamlDocumente los puntos de rollback y manténgalos restaurables de forma automatizada (Ansible/Playbooks, Git‑ops). Supervise los contadores de conntrack, los retransmits y los contadores de drops del firewall tras cada cambio.
Si los cambios no resuelven: medidas de escalada
- Mirroring temporal de flujo (flow‑mirroring) o SPAN en el router para ver los paquetes de retorno.
- Reconfigurar el load balancer a nivel de pool (stickiness, Only‑Local‑Nodes).
- Desactivar temporalmente funciones stateful (solo con una clara evaluación de riesgos).
Lista de comprobación práctica (versión corta)
- Definir el alcance y planificar capturas.
- TCP‑traceroute y capturas tcpdump en ambos extremos.
- Comprobar ip route/ip rule/rp_filter.
- Analizar entradas de conntrack y registros de sesión del firewall.
- Kubernetes: comprobar ExternalTrafficPolicy, SNAT y capturas Node/Pod.
- Realizar el cambio más pequeño posible, activar el monitoring y tener un punto claro de rollback.
Conclusión
El enrutamiento asimétrico puede diagnosticarse de forma fiable si se actúa de manera sistemática: definir el alcance, realizar capturas en ambos extremos, comprobar el estado del host y del kernel (routing, rp_filter, conntrack) y tener en cuenta las especificidades de Kubernetes. Operativamente son útiles tres enfoques: simetría mediante enrutamiento/PBR, colocación consistente de funciones stateful o soluciones temporales como la persistencia (stickiness) en el load balancer. La documentación y los puntos de recuperación son obligatorios ante cualquier cambio. Con buena observabilidad, el tiempo de diagnóstico se reduce de horas a minutos.
Enrutamiento asimétrico: perspectivas de arquitectura, operaciones y observabilidad
Además del diagnóstico de fallos, vale la pena considerar el enrutamiento asimétrico desde una perspectiva de arquitectura y operaciones. ¿Qué componentes en el camino de datos son stateful, cuáles afectan la Source‑IP o el Next‑Hop y qué mecanismos de medición/rollout dispone para reacciones rápidas? Los puntos siguientes ofrecen indicaciones prácticas para decisiones, riesgos y procesos operativos integrados.
Riesgos por rupturas de estado ocultas
Los riesgos operativos típicos surgen cuando un flujo genera estado en un punto (p. ej., firewall/NAT) y la respuesta de retorno llega por otro camino sin la información de estado. Operativamente esto provoca fallos intermitentes difíciles de reproducir. Riesgos de un vistazo:
- Fallas imprevisibles por cambios de versión o de políticas en firewalls o load balancers.
- Desbordamiento de conntrack ante picos de carga que rechaza nuevas conexiones.
- Interceptación por service‑mesh/sidecar que redirige paquetes o realiza SNAT.
Conntrack y ajuste del kernel como herramienta operativa
Los límites de conntrack y los timeouts son causas frecuentemente pasadas por alto. Si las tablas se llenan, las nuevas conexiones dejan de ser rastreadas, lo que puede manifestarse como pérdidas asimétricas. Compruebe y establezca límites ligeramente superiores y ajuste los timeouts según el perfil de tráfico.
# 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 --systemCompruebe los valores y la utilización tras los cambios:
cat /proc/sys/net/netfilter/nf_conntrack_max
cat /proc/net/stat/nf_conntrackObservabilidad: métricas, pruebas sintéticas, eBPF
Sin telemetría continua, las rutas asimétricas siguen siendo problemas fantasma. Construya tres niveles:
- Base: registros de sesión de firewall/router y contadores de Conntrack (exportables a Prometheus).
- Sintético: sondas TCP‑SYN periódicas y dirigidas a lo largo de rutas críticas para comprobar el comportamiento del camino de retorno.
- Trazado profundo: eBPF‑tracing (p. ej. Cilium, bpftrace) para correlación persistente de flujos entre hosts.
# 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/healthzPara Prometheus puede recopilar los valores de Conntrack mediante node_exporter o Textfile‑Collector. Ejemplo del formato de Textfile:
# /var/lib/node_exporter/textfile_collector/conntrack.prom
# HELP node_conntrack_entries Anzahl der Conntrack‑Einträge
node_conntrack_entries 12345Kubernetes & Service‑Mesh: consejos de integración
Los service meshes y los overlays CNI a menudo alteran el flujo (Sidecar‑SNAT, Traffic‑Redirect). Medidas prácticas:
- Para rutas críticas de gateway, compruebe el bypass de sidecar (p. ej. Gateway/ingress sin sidecar o con hostNetwork).
- Utilice eBPF/CNI‑Observability (p. ej. Cilium Hubble) para correlacionar Node↔Pod↔Service.
- Para balanceadores de carga externos: ExternalTrafficPolicy=Local + LB‑Stickiness como compromiso para permitir caminos de retorno deterministas.
Gestión de cambios, despliegues canary y escalación
Los cambios en Routing/Firewalls deberían realizarse en pasos canary: subred pequeña, clientes limitados, monitorización automática con disparadores de alertas. Defina umbrales claros de escalación (utilización de Conntrack, tasa de retransmisiones, tasas de drops en firewall). Automatice rollbacks mediante Ansible/Playbook, de modo que un fallo pueda revertirse dentro de un plazo definido.
En resumen: no considere el enrutamiento asimétrico solo como un caso de depuración, sino como un tema de arquitectura. Con ajuste de Conntrack, observabilidad dirigida, eBPF‑tracing y un procedimiento disciplinado de cambios canary, reducirá el riesgo operativo y aumentará la velocidad de respuesta ante incidentes reales.
Reglas de arquitectura y operación para la prevención
Considere las rutas asimétricas como un tema de arquitectura, no solo un caso de depuración. Separe las funciones de red transitivas (Routing/ECMP) de los servicios stateful (NAT, Firewalls, Load‑Balancer) y defina rutas claras: los componentes stateful deben ser alcanzables de forma determinista o usar State‑Sync. Utilice BGP‑Communities o Source‑Based‑Routing para forzar el determinismo del camino de retorno en escenarios de Multi‑Homing.
Operativamente: establezca umbrales para la utilización de Conntrack, retransmisiones y drops del firewall como alertas, automatice sondas SYN sintéticas en su sistema de monitorización e integre los cambios de política de enrutamiento en un flujo de trabajo GitOps con pasos canary probados. Documente explícitamente las dependencias de componentes de software empresarial individuales que dependen de direcciones IP del cliente o de persistencia de sesión, y conserve los registros de sesión para análisis forenses.
Para este tema también son importantes el enrutamiento asimétrico y el bucle de enrutamiento. El artículo sitúa estos aspectos de forma comprensible y muestra en qué hay que fijarse en la práctica.