Enrutamiento y puertas de enlace en redes de computadoras

¿Cómo decide un host si el tráfico es local o va a la puerta de enlace?

Cuando un servidor (host) necesita enviar un paquete IP, primero decide a qué “siguiente salto” (next hop) entregarlo en la capa de red. Esa decisión se basa en su tabla de rutas. La lógica práctica es:

• Si el destino pertenece a una red que el host considera directamente conectada (por ejemplo, su misma subred en una interfaz), el host envía el tráfico directo al destino (resolviendo la MAC del destino con ARP/ND).
• Si el destino no está en una red directamente conectada, el host envía el tráfico a una puerta de enlace (gateway/router) definida para alcanzar otras redes. En ese caso, el host resuelve la MAC de la puerta de enlace y le entrega el paquete para que el router lo reenvíe.

En términos operativos: el host no “adivina” por IP; hace una búsqueda de coincidencia en su tabla de rutas y elige la mejor ruta disponible.

Coincidencia de prefijo más largo (Longest Prefix Match)

La tabla de rutas contiene entradas del tipo prefijo/máscara → siguiente salto o interfaz. Si varias rutas coinciden con el destino, el host elige la ruta con el prefijo más específico (más largo). Ejemplo:

• 10.10.0.0/16 coincide con 10.10.20.5
• 10.10.20.0/24 también coincide con 10.10.20.5
• Se elige /24 por ser más específico.

Métricas: cómo se desempata entre rutas “igual de específicas”

Si dos rutas tienen el mismo prefijo (misma especificidad), se usa la métrica (coste). En general, menor métrica = preferida. La métrica puede representar “preferencia administrativa” o coste calculado por el sistema (por ejemplo, priorizar una interfaz sobre otra).

En algunos sistemas también influyen otros criterios (por ejemplo, prioridad de ruta, tipo de ruta, o reglas de política), pero como base para diagnóstico en servidores, piensa en: prefijo más largo primero, luego métrica.

Continúa en nuestra aplicación.

• Escuche el audio con la pantalla apagada.
• Obtenga un certificado al finalizar.
• ¡Más de 5000 cursos para que explores!

O continúa leyendo más abajo...

Descargar la aplicación

Routers y el concepto de salto (hop)

Un router (enrutador) conecta redes IP distintas y reenvía paquetes entre ellas. Cada vez que un paquete pasa por un router, se cuenta un salto (hop). El número de saltos no siempre indica “mejor” o “peor”, pero es una pista útil para entender el camino y detectar desvíos.

Un router toma decisiones similares a un host, pero a escala de red: consulta su tabla de rutas para decidir a qué siguiente salto reenviar el paquete. En redes reales, los routers aprenden rutas mediante protocolos dinámicos; en servidores y laboratorios, es común usar rutas estáticas o una ruta por defecto.

Rutas estáticas simples: ejemplos prácticos

Ejemplo 1: ruta por defecto (default route)

La ruta por defecto se usa cuando no existe una ruta más específica para el destino. Se representa como 0.0.0.0/0 (IPv4) o ::/0 (IPv6). En servidores, es típica cuando hay un único camino “hacia afuera” (por ejemplo, hacia el router de la red).

Ejemplo conceptual (IPv4):

Destino: 0.0.0.0/0  → Gateway: 192.168.1.1  → Interfaz: eth0  → Métrica: 100

Interpretación: “Para cualquier red no conocida, envía al router 192.168.1.1 por eth0”.

Ejemplo 2: ruta estática a una subred remota

Supón un servidor en la red 192.168.10.0/24 que necesita llegar a 192.168.20.0/24 a través del router 192.168.10.1. Se agrega una ruta específica:

Destino: 192.168.20.0/24 → Gateway: 192.168.10.1 → Interfaz: eth0

Esto evita depender de la ruta por defecto (si existe) y fuerza un camino concreto para esa subred.

Ejemplo 3: dos rutas posibles al mismo destino (métrica)

Un servidor con dos caminos hacia 10.50.0.0/16 (por dos routers distintos). Ambas rutas tienen el mismo prefijo, así que gana la de menor métrica:

10.50.0.0/16 → 10.0.0.1  métrica 100 (eth0)  [preferida] 10.50.0.0/16 → 10.0.1.1  métrica 200 (eth1)  [respaldo]

Si el camino preferido falla y el sistema detecta la caída (según el entorno), podría usarse la alternativa; en otros casos, requerirá intervención o mecanismos adicionales.

Escenarios típicos en servidores: múltiples interfaces y segmentación

Administración vs. producción (dos redes separadas)

Es común que un servidor tenga:

• Interfaz de administración (por ejemplo, mgmt0) en una red restringida: acceso SSH, monitoreo, backups.
• Interfaz de producción (por ejemplo, eth0) para tráfico de aplicaciones.

Un error típico es colocar la ruta por defecto en la interfaz equivocada, provocando que el tráfico de salida (o el retorno) tome el camino incorrecto.

Ejemplo de diseño deseado:

• mgmt0: 172.16.0.10/24, gateway 172.16.0.1 (solo para administración interna)
• eth0: 10.0.0.10/24, gateway 10.0.0.1 (salida principal para producción)

En muchos casos, conviene que la ruta por defecto apunte al gateway de producción y que las redes de administración se alcancen con rutas específicas (o mediante reglas de política), para evitar que el tráfico de producción “escape” por la red de administración.

Servidor con múltiples interfaces en subredes distintas

Cuando un servidor tiene dos interfaces en dos subredes, su tabla de rutas incluirá automáticamente rutas “directamente conectadas” para ambas redes. Ejemplo conceptual:

Si falta la ruta por defecto o apunta al gateway incorrecto, el servidor podrá hablar con sus redes conectadas, pero fallará al llegar a redes remotas.

Diagnóstico: leer tablas de rutas y usar traceroute/tracert

Cuando hay pérdida de conectividad entre subredes, tu objetivo es responder dos preguntas:

• ¿Qué ruta está eligiendo el host para llegar al destino?
• ¿En qué salto se rompe el camino?

Paso a paso: verificar la ruta elegida en el host

1) Identifica el destino y la IP

• Trabaja con una IP concreta (por ejemplo, el servidor remoto o su IP de subred).

2) Consulta la tabla de rutas

• Linux: ip route
• Windows: route print
• macOS/BSD: netstat -rn o route -n get <destino>

Busca:

• Una ruta específica al prefijo del destino (ideal).
• Si no existe, qué ruta por defecto se usará.
• La interfaz de salida y la métrica.

3) Pregunta al sistema “qué ruta usarías para esta IP”

• Linux: ip route get 192.168.20.50

Salida típica (simplificada):

192.168.20.50 via 192.168.10.1 dev eth0 src 192.168.10.10

Interpretación: se enviará al gateway 192.168.10.1 por eth0, usando como IP origen 192.168.10.10. Si el src no es el esperado (por ejemplo, sale con IP de administración), es una pista de asimetría o selección de interfaz incorrecta.

Paso a paso: localizar el salto donde falla con traceroute/tracert

1) Ejecuta traceroute/tracert hacia el destino

• Linux/macOS: traceroute 192.168.20.50
• Windows: tracert 192.168.20.50

2) Interpreta los saltos

• El primer salto suele ser tu puerta de enlace (si el destino no es local).
• Si se queda en el primer salto, puede ser: gateway incorrecto, gateway caído, o filtrado.
• Si avanza y luego aparecen * * *, puede ser: un router intermedio no responde a ICMP/TTL expirado, o hay un corte real más adelante.

3) Contrasta con la tabla de rutas

• Si traceroute muestra un primer salto distinto al gateway esperado, revisa la ruta por defecto o rutas más específicas.
• Si el primer salto es correcto pero el segundo no existe, el problema puede estar en el router (falta ruta de retorno, ACL, o ruta hacia la subred destino).

Escenario de fallo típico: falta ruta de retorno (asimetría)

Un caso muy común entre subredes: desde A puedes “llegar” a B, pero B no sabe volver a A. Síntomas:

• ping falla o es intermitente.
• traceroute desde A se queda en algún router cercano a B.

Checklist rápido:

• En A: ¿hay ruta hacia la subred de B (o default correcta)?
• En B: ¿hay ruta hacia la subred de A (o default correcta)?
• En routers intermedios: ¿existen rutas en ambos sentidos?

Escenario de fallo típico: ruta por defecto en la interfaz equivocada

En servidores con red de administración y producción, si la ruta por defecto apunta a la red de administración, el tráfico de producción puede salir por el camino equivocado. Señales:

• ip route get <destino> muestra dev mgmt0 cuando esperabas dev eth0.
• Traceroute muestra como primer salto el gateway de administración.

Acción de diagnóstico:

• Revisar cuál es la ruta por defecto activa y su métrica.
• Verificar si existen rutas más específicas que deberían “ganar” por prefijo más largo.

Práctica guiada: laboratorio mental con dos subredes y un router

Objetivo: entender la decisión local vs. gateway y practicar lectura de rutas y traceroute.

Topología

• Servidor A: 192.168.10.10/24, gateway 192.168.10.1
• Router R: interfaz en 192.168.10.1/24 y otra en 192.168.20.1/24
• Servidor B: 192.168.20.20/24, gateway 192.168.20.1

Verificaciones en A (pasos)

1) Confirma que B no es local

• B está en 192.168.20.0/24, distinto de 192.168.10.0/24, así que A debe usar gateway.

2) Revisa la tabla de rutas

ip route

Debes ver:

• 192.168.10.0/24 dev ... (conectada)
• default via 192.168.10.1

3) Comprueba la ruta exacta al destino

ip route get 192.168.20.20

Esperado: via 192.168.10.1.

4) Ejecuta traceroute

traceroute 192.168.20.20

Esperado (aproximado):

• Hop 1: 192.168.10.1 (router)
• Hop 2: 192.168.20.20 (destino)

Si falla: qué revisar en orden

• En A: ¿default gateway correcto? ¿interfaz correcta? ¿métrica inesperada?
• En R: ¿tiene interfaces activas en ambas subredes? ¿está reenviando tráfico entre interfaces?
• En B: ¿tiene gateway 192.168.20.1 o ruta de retorno hacia 192.168.10.0/24?