El camino que una tabla anuncia no es todavía el camino que un paquete recorrió
Un servicio puede funcionar durante una prueba pequeña y fallar cuando cambia el tamaño del paquete, expira una traducción o se retira uno de dos enlaces de igual coste. Una tabla de rutas puede mostrar una salida plausible mientras el plano de datos usa una FIB antigua; una captura en el borde puede mostrar una dirección traducida sin revelar qué host interno originó el flujo; y una ruta de ida visible no permite suponer que la respuesta regresará por el mismo recorrido. El diagnóstico se vuelve incorrecto cuando se trata toda esa evidencia como si describiera una única cosa llamada «la ruta».
Este capítulo separa cuatro decisiones relacionadas pero distintas: cómo el plano de control aprende y selecciona rutas; cómo el plano de datos convierte una decisión en forwarding; cómo NAT (Network Address Translation) y NAPT (Network Address and Port Translation) transforman direcciones, puertos y estado; y cómo el retorno, el MTU (Maximum Transmission Unit) y la observabilidad condicionan el resultado. La pregunta rectora es: ¿qué estado y qué decisión permiten sostener un claim sobre el camino de un flujo, y qué queda fuera de alcance?
El lector seguirá un caso sintético y reproducible. No es una receta de comandos ni un incidente real: es un modelo para comparar controles positivos y negativos, localizar una primera transición fallida y escribir una conclusión acotada.
Alcance, prerequisitos y resultados
Se presupone el modelo de capas, Ethernet/ARP y direccionamiento de los capítulos 25–27. Aquí no se desarrolla el algoritmo de un protocolo de routing dinámico concreto, ni se trata NAT como una política de seguridad por sí misma. Se usa IPv6 sólo para contrastar el tratamiento de PMTU y fragmentación donde la diferencia evita una inferencia errónea.
Al terminar, el lector debería poder:
- distinguir plano de control y plano de datos, y relacionar RIB, FIB, prefijo, next hop e interfaz;
- reconstruir una selección de ruta por longest-prefix match (LPM) y separar instalación de forwarding;
- comparar rutas estáticas, rutas aprendidas dinámicamente y ECMP (Equal-Cost Multi-Path) sin prometer simetría;
- describir una traducción NAT/NAPT como transformación con estado y distinguirla de un filtro;
- explicar por qué un retorno asimétrico, una pérdida de estado o un ICMP bloqueado producen síntomas parecidos;
- diseñar una observación positiva, una negativa y un retest que reduzcan incertidumbre sin convertir una tabla observada en una prueba del camino real.
El plano de control construye posibilidades; el plano de datos ejecuta una decisión
Alcance: una tabla no prueba transmisión de un paquete concreto.
El plano de control mantiene conocimiento sobre topología, prefijos alcanzables, preferencias y next hops. Puede recibir rutas estáticas de una configuración, rutas conectadas de interfaces o rutas aprendidas mediante un protocolo dinámico. Una RIB (Routing Information Base) es la colección conceptual de rutas disponibles para la decisión; no debe confundirse con una captura del hardware de forwarding. La selección puede tener en cuenta coincidencia de prefijo, preferencia administrativa, métrica, política y estado de la interfaz.
El plano de datos recibe un paquete, valida lo necesario, consulta una FIB (Forwarding Information Base) y ejecuta la acción instalada: seleccionar interfaz y siguiente salto, decrementar TTL (Time To Live) en IPv4, resolver la dirección de enlace, reencapsular y poner la unidad en cola. RFC 1812 describe ese recorrido para un router IPv4: recepción desde el enlace, validación, decisión de entrega local o forwarding, determinación del next hop, tratamiento del TTL y encapsulación en la interfaz de salida (§§5.2.1.1–5.2.1.2). RFC 1812, §§5.2.1.1–5.2.1.2
La separación es operacional, no una promesa de que existan dos procesadores físicos. Una plataforma puede compilar una ruta, programar ASIC y mantener una copia de software; otra puede hacer todo en el kernel. Lo que importa para el análisis es qué estado era fuente de decisión y qué estado se usó para el paquete concreto. Una RIB actualizada no prueba que una FIB haya convergido, que el vecino esté resoluble ni que la cola de salida entregue el paquete. Del mismo modo, una FIB instalada prueba una capacidad local de decisión, no que se haya usado durante una ventana que no observamos.
LPM, next hop y la diferencia entre destino final y vecino inmediato
El longest-prefix match elige, entre los prefijos candidatos que contienen una dirección destino, el de mayor longitud de prefijo antes de aplicar otras preferencias. RFC 1812 formaliza el conjunto de rutas candidatas y la poda por coincidencia de prefijo (§5.2.4.3–§5.2.4.4). RFC 1812, §5.2.4.3
El next hop es el vecino que recibe el paquete en el siguiente tramo; puede coincidir con el destino si éste es adyacente o ser otro router. El paquete conserva su destino IP final salvo que un mecanismo posterior lo transforme. La trama del enlace, en cambio, se dirige al vecino inmediato. La diferencia importa porque una captura que muestra la MAC del gateway no prueba que ese gateway sea el destino del servicio, y una tabla que nombra un next hop no demuestra que el enlace lo haya alcanzado.
Considérese este conjunto conceptual para un router R1:
Desliza horizontalmente para consultar todas las columnas.
Para 10.40.8.77, el /25 gana por LPM aunque la ruta /24 tenga otra fuente. Para 10.40.8.180, el /25 no coincide y compite el /24. La tabla no se interpreta como una lista de interfaces ordenada: es un conjunto que primero se filtra por destino y luego se desempata según la política declarada. Si quedan varias rutas equivalentes, la plataforma puede instalar ECMP; RFC 1812 admite conservar varias rutas y dividir tráfico, y RFC 2992 analiza algoritmos que eligen next hop usando campos del flujo y estudia la interrupción cuando cambia el conjunto de next hops (§§5.2.4.3–5.2.4.5 de RFC 1812; §§1–2.2 de RFC 2992). RFC 1812, §§5.2.4.3–5.2.4.5 RFC 2992, §§1–2.2
ECMP no significa necesariamente round-robin por paquete. Un hash sobre campos que identifican un flujo puede mantener los paquetes de una conversación en un next hop mientras la composición de los caminos no cambie; una implementación distinta puede usar otra política. Tampoco significa que los caminos sean idénticos en latencia, MTU, filtros o estado de seguridad: «equal cost» es una propiedad de la métrica usada para seleccionar, no una prueba de equivalencia operacional.
Rutas estáticas, rutas dinámicas y el momento de la decisión
Una ruta estática hace explícita una relación entre prefijo, next hop, interfaz y condición de instalación. Es útil cuando el diseño es pequeño, cuando una ruta por defecto debe ser deliberada o cuando la estabilidad del camino importa más que la convergencia automática. Su límite es la dependencia de que alguien retire o cambie la ruta cuando el enlace o el vecino dejan de ser válidos. Una ruta estática que sigue instalada puede producir un descarte o una cola sin vecino aunque la configuración parezca correcta.
Una ruta dinámica se obtiene de mensajes y estados de un protocolo de routing. El protocolo puede retirar un prefijo, cambiar su métrica o elegir otro next hop; el router aún debe validar, seleccionar e instalar el resultado en el estado que usa forwarding. La convergencia es una transición temporal, no una propiedad instantánea. Durante ella, RIB, FIB, contadores y caminos observados pueden no coincidir. Una tabla de control que ya cambió sólo permite afirmar que ese componente aprendió o seleccionó algo; para afirmar forwarding hay que correlacionar la FIB efectiva, el contador o la captura del siguiente tramo.
Esto evita una confusión común: routing es el proceso de decidir o aprender caminos; forwarding es la aplicación de una decisión a cada paquete. Un router puede tener una ruta adecuada y descartar por validación de cabecera, TTL, ACL, falta de vecino, congestión o política. RFC 1812 exige comprobaciones básicas del encabezado IPv4 y permite registrar descartes (§5.2.2); el mismo documento describe ICMP Destination Unreachable para distintos motivos, pero también admite que una política no genere ese mensaje. RFC 1812, §§5.2.2 y 5.2.7.1
Caso conductor: Northstar y una API publicada detrás de NAPT
Northstar Systems tiene un cliente C (10.40.8.21/24), un gateway de borde E (10.40.8.1 en la LAN y 198.51.100.7 hacia el proveedor), y una API pública S (203.0.113.80:443). El servicio reside detrás de un balanceador L (10.80.5.20) en otra zona. E usa NAPT para que varias estaciones compartan 198.51.100.7; el flujo de C se representa inicialmente como:
original: 10.40.8.21:51514 -> 203.0.113.80:443 TCP
translated:198.51.100.7:41022 -> 203.0.113.80:443 TCP
El caso tiene dos caminos de salida de igual coste desde E hacia el proveedor, P1 y P2. El retorno de S puede llegar por cualquiera de ellos. E debe conservar suficiente estado de traducción para mapear el paquete de respuesta a 10.40.8.21:51514; si la plataforma distribuye ambos sentidos a dispositivos distintos sin estado compartido, la asimetría puede parecer una pérdida de servicio aun cuando el destino externo vea la respuesta.
Reconstrucción paso a paso
- Clasificación del destino.
Cve que203.0.113.80no pertenece a10.40.8.0/24y selecciona10.40.8.1como next hop. ARP resuelve el vecino local; esta transición pertenece al capítulo 26 y no prueba aún queEtenga una ruta de salida. - Entrada al plano de datos.
Erecibe el paquete, valida IPv4 y consulta su FIB. Una ruta más específica para203.0.113.0/24prevalece sobre la ruta por defecto si está instalada. Si existen dos next hops ECMP, el hash de la implementación puede elegirP1para este 5‑tuple (protocolo, IP y puertos), pero la elección no se deduce sólo de la RIB. - Creación de estado NAT. Antes de emitir hacia el proveedor, NAPT asigna o reutiliza el mapeo
10.40.8.21:51514 ↔ 198.51.100.7:41022y ajusta los campos afectados y, cuando corresponde, sus checksums. RFC 3022 distingue Basic NAT de NAPT en §§2–2.2 y describe ajustes de cabeceras/checksum en §§4.1–4.2; el tratamiento depende de familia, protocolo, fragmentación y del checksum existente —por ejemplo, UDP/IPv4 puede transportar checksum cero—. RFC 3022, §§2–2.2 y 4.1–4.2 - Forwarding y reencapsulación.
Eselecciona el next hop deP1, resuelve la dirección de enlace y transmite una nueva trama. El destino IP visible en el proveedor es ahora198.51.100.7como origen; la cabecera de enlace y, potencialmente, la interfaz cambian. El router no está «repitiendo» la misma trama de la LAN. - Retorno.
Sresponde a198.51.100.7:41022. El retorno puede entrar porP2; si el estado de NAT es local aE, el flujo sigue siendo traducible aunque la ida y la vuelta no compartan enlace. Si la arquitectura ha separado un firewall con estado y un router ECMP sin sincronización, el paquete puede ser descartado por el dispositivo que no conoce la asociación. La hipótesis se prueba correlacionando el 5‑tuple traducido, el identificador de estado y el dispositivo que vio cada sentido. - Entrega interna. Una vez invertida la traducción,
Eusa la ruta conectada hacia10.40.8.21, resuelve su vecino LAN y entrega el segmento. La observación de una respuesta enEantes de esa inversión no prueba queChaya recibido la respuesta ni que TLS o la aplicación hayan completado.
Tabla mínima de evidencia
Desliza horizontalmente para consultar todas las columnas.
El control negativo debe cambiar sólo la propiedad examinada. Un prefijo de prueba retirado no debe interpretarse como evidencia de que un servicio real está indisponible; sirve para comprobar que el dispositivo diferencia «sin ruta» de «ruta instalada». Una prueba positiva de NAT debe incluir una nueva asociación y su retorno, no sólo una línea de configuración.
NAT y NAPT: transformación con estado, no cortafuegos implícito
Alcance: NAT no equivale a firewall ni a autorización.
NAT cambia la representación de una dirección entre ámbitos. NAPT añade el identificador de transporte para multiplexar varios hosts tras una dirección pública. La asignación puede ser estática, dinámica o dependiente del endpoint; su semántica debe nombrar el protocolo y la política. RFC 3022 describe sesiones tradicionales principalmente iniciadas desde el espacio privado y mapas estáticos como una excepción de entrada (§2); no convierte ese comportamiento histórico en una ley de todas las implementaciones actuales. RFC 3022, §2
En UDP, RFC 4787 separa mapping (cómo se reutiliza una asignación para destinos externos) de filtering (qué paquetes entrantes se aceptan). Define, entre otros, Endpoint-Independent Mapping (§4) y comportamientos de filtrado con distinta dependencia del endpoint (§5), y trata hairpinning como una capacidad separada (§6). La propia especificación advierte que el comportamiento de filtrado determina propiedades de seguridad diferentes de la elección de mapping (§4). RFC 4787, §§4–6
Por eso NAT no es un firewall. La traducción puede ocultar una dirección, crear una barrera accidental para conexiones no solicitadas o impedir una visibilidad directa, pero ninguna de esas consecuencias sustituye una política explícita de autorización, inspección o registro. Un NAT configurado para aceptar una asignación estática puede permitir tráfico entrante; un firewall stateful puede negar tráfico aunque no traduzca nada. El claim correcto es «este dispositivo traduce y aplica este comportamiento de filtrado bajo estas reglas», no «NAT protege la red».
Estado de traducción y conntrack como implementación concreta
En una implementación Linux con Netfilter, conntrack mantiene tuplas originales y de respuesta, estado de protocolo, timeout, contadores y atributos nat-src/nat-dst que pueden inspeccionarse mediante su interfaz netlink. La documentación del kernel enumera esos campos y estados; la documentación de variables nf_conntrack_* muestra, por ejemplo, expiración, máximo de entradas y estados TCP. Linux kernel, family conntrack netlink Linux kernel, conntrack sysctl
Esto es una implementación concreta, no la definición universal de NAT ni la prueba de que un router propietario use el mismo modelo. En una plataforma distinta, el estado puede estar en ASIC, en un procesador de servicios, en un balanceador o replicado entre nodos. Incluso en Linux, ver una entrada ESTABLISHED prueba que ese subsistema considera que existe una asociación; no prueba que el paquete haya salido por la interfaz correcta, que el peer haya recibido la respuesta o que una aplicación haya aceptado los datos.
Asimetría: retorno diferente no equivale a fallo
Un camino asimétrico es aquel en que ida y vuelta usan secuencias de enlaces o routers distintas. No es por sí mismo una vulnerabilidad ni una anomalía: ECMP, políticas de routing, enlaces de proveedores y fallos transitorios pueden producirlo. La asimetría se vuelve material cuando un control depende del orden o de un estado compartido: un firewall stateful sin sincronización, un NAT cuyo mapa vive en un solo nodo, un sensor colocado sólo en la ida o una ACL de retorno que valida el origen según una interfaz inesperada.
La validación de origen de RFC 1812 ilustra el punto: un router puede comparar el origen de un paquete con la interfaz que usaría para alcanzar esa dirección y descartar si no coincide (§5.3.8). Es un control contra direcciones de origen inverosímiles, pero también una condición que puede interactuar con routing asimétrico o multihoming. RFC 1812, §5.3.8
No debe afirmarse «la ruta es simétrica» porque dos traceroutes se parecen, porque el estado de una tabla muestra un único next hop o porque un firewall observó el SYN. Una captura en un punto puede pertenecer a un sentido; un traceroute usa probes con reglas distintas del flujo de la aplicación; una FIB puede cambiar entre probes; y un balanceador puede elegir otro backend. Para sostener un claim de simetría hay que fijar protocolo, 5‑tuple, tiempo, puntos y definición de «mismo camino», y observar ambos sentidos con correlación suficiente. En muchos entornos el claim responsable es más estrecho: «la ida fue observada por A–B–E y el retorno por E–C durante T».
Contraejemplo: tabla coherente, camino no probado
Supongamos que E muestra dos rutas ECMP y el firewall registra el SYN de C, pero no registra el SYN-ACK. Tres explicaciones siguen vivas: S no respondió; el retorno tomó un proveedor que no llegó a E; o E recibió la respuesta pero otro nodo sin estado la descartó. La RIB de E no discrimina esas ramas. Se necesita una captura o contador en ambos bordes, la tabla de asociación NAPT en el dispositivo que recibe el retorno y el log de S. El resultado negativo útil es un SYN-ACK sintético enviado a una dirección de prueba cuyo retorno se observa en P2; si falla sólo con el flujo traducido, la hipótesis de estado o filtrado gana apoyo, pero no prueba por sí sola la causa raíz.
PMTU e ICMP: una parte pequeña del camino puede romper el servicio
Alcance: IPv6 y contraste acotado con reglas IPv4.
El path MTU es el menor MTU de los enlaces de un camino. Para IPv4, un router puede necesitar fragmentar o devolver ICMP «Fragmentation Needed and DF Set» bajo las condiciones descritas por RFC 1812 (§§4.2.3.3 y 5.2.6–5.2.7.1) y RFC 1191. Para IPv6, un nodo intermedio que no puede reenviar por el MTU del siguiente enlace descarta el paquete y normalmente origina ICMPv6 Packet Too Big cuando aplican las reglas de generación; RFC 4443 contempla excepciones para mensajes de error, orígenes no unívocos y limitación por congestión/tasa. La fragmentación de IPv6 la realiza el origen, no los routers. RFC 8200, §§4.5 y 5; RFC 8201, §5; RFC 4443, §2.4
El alcance aquí es diagnóstico: si un dispositivo filtra esos ICMP, si el PMTU cambia entre caminos ECMP o si un túnel reduce el MTU, los paquetes pequeños pueden funcionar y una respuesta grande puede quedar en timeout. No se sigue que todo timeout sea PMTU ni que ICMP deba aceptarse sin una política. La prueba positiva es una notificación coherente con el flujo y una reducción posterior del tamaño transmitido; la negativa es comparar tamaños y caminos manteniendo identidad, destino y ventana. La captura en el borde sólo muestra el mensaje que pudo llegar a ese punto; no prueba que el origen lo procesara.
Seguridad y observabilidad: conservar el estado que transforma la evidencia
Routing y NAT crean fronteras de identidad observada. Después de NAPT, el servidor ve una dirección y puerto públicos que pueden representar muchos clientes; RFC 6888 señala que un operador de CGN necesita asociar dirección externa, puerto, protocolo, suscriptor y timestamp para reconstruir qué abonado correspondía a una conexión (§4). La recomendación no implica que todo entorno deba registrar todos los destinos; sí muestra por qué un log de aplicación sin zona horaria, puerto y ventana no basta para atribuir un flujo. RFC 6888, §4
Un programa de observabilidad debe conservar, al menos, dirección y sentido, 5‑tuple antes y después de la traducción cuando proceda, identificador de estado, interfaz o next hop seleccionado, contador de forwarding, motivo de descarte, MTU efectivo, reloj y versión/configuración. Cada dato debe declarar si es estado de control, estado de datos, observación directa o inferencia. Los contadores pueden ser acumulativos y no localizan un paquete individual; la RIB puede ser una instantánea; una tabla conntrack puede expirar antes de la consulta; y una captura puede perder tráfico o mostrarlo después de offload.
Un control de seguridad bien formulado es verificable: «en la ventana T, los paquetes con origen de la red autorizada que entran por la interfaz I coinciden con la ruta inversa esperada y se registra cualquier descarte por validación de origen». No es equivalente a «el router bloquea spoofing». Un control positivo debe activar una ruta de origen válida; un control negativo debe usar un origen no válido dentro de un entorno autorizado y comprobar el descarte, el contador y la ausencia de entrega superior. El retest debe probar también recuperación después de una reconvergencia, una expiración de estado y un cambio de next hop.
Límites y errores de explicación
«La RIB es la ruta que tomó el paquete». Es una fotografía del conocimiento o selección del plano de control. La FIB, la interfaz, el vecino, la cola y el momento de observación pueden diferir.
«El prefijo más específico siempre gana sin más». LPM filtra candidatos por coincidencia; preferencias, métricas, políticas, VRF, ECMP y estado pueden determinar qué se instala o qué next hop queda disponible. Hay que declarar el dominio de la tabla.
«NAT es un firewall». NAT transforma; el filtrado y la autorización son propiedades separadas y dependientes de la implementación.
«Un estado conntrack existe en todo router». conntrack identifica una implementación Linux/Netfilter. Otros dispositivos pueden no exponer ese estado, usar otra estructura o distribuirla.
«La ruta de vuelta es la misma porque la ida funciona». La ida prueba, como máximo, el sentido y la ventana observados. La asimetría puede ser legítima o puede romper estado y controles.
«Un traceroute demuestra el camino de la aplicación». Sus probes, respuestas, políticas y hashes pueden ser distintos. Es evidencia útil de un experimento específico, no una vista universal del forwarding.
«Si no hay ICMP, no hay PMTU». Un camino puede operar con otra estrategia o fallar silenciosamente; tampoco una notificación ICMP prueba que la aplicación haya ajustado su emisión.
Transferencia profesional
Ante un incidente «la API responde a veces», redacte primero un claim acotado: «Para el 5‑tuple X, entre T1 y T2, C entregó el SYN a E; E instaló estado NAPT N y envió por P1; S observó la dirección traducida y emitió SYN‑ACK; el retorno fue observado en P2 pero no en C». Luego enumere las inferencias y los límites: no se ha demostrado todavía que el firewall P2 consultara el mismo estado, que el paquete no se perdiera en una cola o que TLS validara al servidor.
El diseño de la prueba debe tener controles. Una prueba positiva conserva prefijo, tamaño, 5‑tuple y ventana esperados y verifica observaciones en C, E, proveedor y S. Una negativa retira una sola condición —por ejemplo, un prefijo de prueba o el estado NAPT— y espera el descarte o ICMP documentado. Un control de regresión repite la prueba tras reconvergencia, expiración del estado y cambio de MTU, sin asumir que la ruta vuelva a ser la misma.
La transferencia no consiste en memorizar nombres de tablas. Consiste en responder tres preguntas: qué componente decidió, qué componente ejecutó y qué evidencia correlaciona ambos sentidos. Cuando la respuesta no puede sostenerse, la incertidumbre es un resultado profesional, no un hueco que deba llenarse con una narrativa de simetría o con la etiqueta «NAT bloqueó».
Síntesis
El plano de control mantiene rutas y políticas; el plano de datos valida, consulta la FIB, elige next hop, reencapsula y transmite. LPM ordena candidatos por especificidad, pero la ruta instalada y la interfaz efectiva siguen dependiendo de preferencia, política, estado y tiempo. ECMP puede elegir varios next hops sin prometer igual latencia, igual MTU o igual retorno.
NAT y NAPT transforman direcciones y, cuando procede, puertos mediante asignaciones cuyo estado y filtrado deben describirse por separado. conntrack es una forma concreta de implementar y observar parte de esa función en Linux/Netfilter, no un vocabulario universal. Un camino asimétrico puede ser válido; se convierte en un problema cuando el control o el estado que necesita el flujo no está disponible en el punto que recibe el retorno.
La conclusión más fuerte que permite una tabla es sobre esa tabla. Para hablar del camino de un paquete hay que unir estado de control, FIB, interfaces, vecinos, observaciones de ambos sentidos, traducción, MTU y tiempo. Si falta uno de esos enlaces, el claim debe reducirse y la siguiente prueba debe elegirse por su capacidad de discriminar hipótesis.
Problema de transferencia
Después de una migración de borde, clientes internos completan el handshake TCP con una API sólo en aproximadamente la mitad de los intentos. La RIB muestra dos rutas ECMP; la FIB de un nodo tiene ambos next hops; un balanceador ve SYN en la dirección pública traducida, pero el firewall stateful sólo registra respuestas cuando entran por P1. En paralelo, solicitudes grandes sobre IPv6 fallan mientras mensajes pequeños funcionan.
Redacta una adjudicación que separe observación, inferencia, impacto posible y límites. Reconstruye el flujo original y traducido, identifica qué estado debe existir en cada sentido, diseña un control positivo y uno negativo para la asimetría, y añade una prueba de PMTU que no confunda «no llegó ICMP» con «la ruta está rota». Explica qué evidencia adicional necesitarías antes de afirmar que la migración introdujo una vulnerabilidad o que la API estuvo indisponible globalmente.