Virtualización, contenedores y redes de computadoras en entornos de servidores

Redes virtuales en hipervisores: cómo “cablear” máquinas virtuales

En virtualización, la red no es un cable físico: es un conjunto de componentes lógicos (vSwitch, puertos virtuales, bridges, interfaces virtuales y reglas de NAT) que determinan cómo una VM se conecta con otras VMs, con el host y con redes externas. Para administración de servidores, lo importante es entender dónde ocurre cada traducción, qué interfaz ve cada IP, y qué camino sigue el tráfico.

vSwitch, bridge e interfaces virtuales (vNIC)

• vNIC (interfaz virtual de la VM): es la “tarjeta de red” que ve el sistema operativo dentro de la VM (por ejemplo, eth0). Se conecta a un puerto del switch virtual.
• vSwitch (switch virtual): conmutador software dentro del hipervisor. Conecta vNICs entre sí y/o hacia un uplink (una interfaz del host) o hacia un componente de NAT.
• Bridge (puente): en muchos hipervisores basados en Linux, un bridge del host (por ejemplo br0) actúa como switch L2: las VMs “cuelgan” del bridge y el bridge se asocia a una NIC física para salir a la red.

Idea mental útil: vNIC → puerto del vSwitch/bridge → uplink (NIC del host) → red física.

Modos típicos de red en hipervisores (funcionalmente)

NAT en hipervisores y el problema del doble NAT

Cuando usas NAT del hipervisor, el host suele actuar como “router/NAT” para una subred privada de VMs. Si además el host ya está detrás de un NAT aguas arriba (por ejemplo, router doméstico o firewall perimetral), se produce doble NAT:

• NAT 1: dentro del host/hipervisor (VM → IP del host).
• NAT 2: en el borde de la red (host → IP pública o IP de otra red).

Impacto típico: publicar un servicio desde la VM hacia Internet requiere encadenar redirecciones de puertos (port-forward) en ambos niveles, y el troubleshooting se vuelve más lento porque el cliente no “ve” la IP real de la VM.

MTU en redes virtuales: por qué un ping funciona y una app no

La MTU (tamaño máximo de trama) puede desalinearse entre: vNIC de la VM, vSwitch/bridge, NIC física del host, y enlaces intermedios (por ejemplo, túneles, VPNs, overlays). Síntomas comunes:

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

• Conectividad intermitente o solo para paquetes pequeños.
• HTTPS/TLS que “se cuelga” en el handshake o transferencias grandes que fallan.

En entornos con encapsulación (túneles/overlay), suele requerirse bajar MTU en interfaces virtuales o ajustar MSS clamping en el borde. Operativamente, cuando veas fallos “raros”, valida MTU de extremo a extremo en el camino virtual y físico.

Rutas internas: cuando el host es un router “invisible”

En redes NAT o host-only, el host suele tener una interfaz en la red interna (por ejemplo, virbr0 o similar) y actúa como gateway para las VMs. Esto crea rutas internas que no existen en la red física. Consecuencia: desde otro equipo del LAN no podrás llegar a la IP privada de la VM a menos que configures rutas estáticas o uses port-forwarding.

Redes en contenedores: bridge, host y overlay (visión funcional)

Los contenedores no “virtualizan” hardware como una VM, pero sí crean espacios de red aislados (network namespaces) y conectan interfaces virtuales a redes lógicas. En la práctica, administras: redes tipo bridge, modo host y redes overlay (multi-host).

Bridge en contenedores (lo más común)

En modo bridge, el motor de contenedores crea una red virtual (por ejemplo, docker0) y conecta cada contenedor con un par de interfaces virtuales (veth):

• Un extremo del veth queda dentro del contenedor (por ejemplo, eth0).
• El otro extremo queda en el host y se conecta al bridge.

El contenedor recibe una IP privada de esa red. Para que un cliente externo llegue al servicio del contenedor, normalmente se usa mapeo de puertos (port publishing): el host escucha en un puerto y reenvía al puerto del contenedor.

Host network: sin NAT ni aislamiento de puertos

En modo host, el contenedor comparte la pila de red del host: no hay IP propia (a efectos prácticos) y el servicio escucha directamente en la IP del host. Ventajas: menos complejidad y menos overhead. Riesgo: colisión de puertos (dos servicios no pueden usar el mismo puerto en el mismo host) y menor aislamiento.

Overlay: red entre hosts (multi-nodo)

En overlay, los contenedores en distintos hosts se ven como si estuvieran en la misma red lógica. Se logra mediante encapsulación/túneles entre hosts. Operativamente, esto introduce:

• Más puntos donde revisar MTU (por el overhead de encapsulación).
• Necesidad de observar tráfico tanto en la interfaz “física” como en la interfaz del túnel/overlay.
• Dependencia de un plano de control (según la plataforma) para distribuir rutas/identidades.

Cómo se mapean puertos y cómo “ver” el tráfico

Mapeo de puertos: qué significa realmente

Cuando publicas un puerto de un contenedor en modo bridge, creas una relación del tipo:

IP_del_host:PUERTO_HOST  →  IP_del_contenedor:PUERTO_CONTENEDOR

Ejemplo conceptual: un servicio web escucha en el contenedor en 0.0.0.0:8080. Lo publicas como 80 en el host. El cliente se conecta a IP_host:80, y el host redirige hacia IP_contenedor:8080.

Observación del tráfico: desde host vs desde contenedor

• Desde el host: puedes observar en la interfaz física (tráfico entrante del cliente), en el bridge (tráfico hacia el contenedor) y en reglas de firewall/NAT que implementan el port-forward. Esto es clave para detectar si el paquete “entra” pero no “llega”.
• Desde el contenedor: observas lo que llega a su eth0 (o interfaz equivalente) dentro del namespace. Es útil para confirmar si el servicio recibe la conexión y en qué IP/puerto está escuchando.

Regla práctica: si el host ve SYNs entrantes pero el contenedor no ve nada, el problema está en el camino virtual (NAT/forward/bridge/políticas). Si el contenedor ve el tráfico pero no responde, el problema suele ser del servicio (bind, firewall interno, app) o de rutas de retorno.

Laboratorio conceptual guiado: rastrear IP/puerto del servicio y el camino del cliente

Objetivo: identificar qué IP/puerto escucha el servicio dentro del contenedor, qué IP/puerto expone el host, y por dónde viaja el tráfico cuando un cliente se conecta.

Escenario

• Un host Linux ejecuta un contenedor con un servicio HTTP.
• El contenedor está en red bridge.
• Se publica el servicio hacia el exterior con un puerto del host.

Paso 1: confirmar qué escucha el servicio dentro del contenedor

Entra al contenedor y verifica el bind del proceso:

# Dentro del contenedor (conceptual; el comando exacto depende de la imagen/base OS)  ss -lntp  # o netstat -lntp

Qué buscar:

• Si el servicio escucha en 127.0.0.1:PORT, solo acepta conexiones locales del contenedor; desde fuera no funcionará aunque publiques el puerto.
• Para aceptar conexiones entrantes, normalmente debe escuchar en 0.0.0.0:PORT (todas las interfaces) o en la IP del contenedor.

Luego identifica la IP del contenedor:

# Dentro del contenedor  ip addr show  # o similar

Paso 2: confirmar el mapeo de puertos en el host

En el host, lista los contenedores y sus puertos publicados:

# En el host  docker ps  # o comando equivalente de tu runtime

Debes ver una relación tipo 0.0.0.0:80->8080/tcp (ejemplo). Eso significa: el host escucha en 80 en todas sus IPs y reenvía al 8080 del contenedor.

Valida que el host realmente está escuchando en el puerto publicado:

# En el host  ss -lntp | grep ':80'  # ajusta el puerto

Nota operativa: en muchos setups, no verás un proceso “app” escuchando en el host para ese puerto, porque el reenvío puede implementarse con reglas de NAT/forwarding. Lo importante es que el puerto esté publicado y que las reglas existan.

Paso 3: probar el flujo desde un cliente y observar dónde se corta

Desde un cliente (otra máquina) intenta acceder:

curl -v http://IP_DEL_HOST:PUERTO_HOST/

Ahora observa en paralelo:

• En el host: captura tráfico en la interfaz por donde llega el cliente (por ejemplo, eth0) y en el bridge del contenedor (por ejemplo, docker0).
• En el contenedor: captura en eth0 del contenedor.

Guía conceptual de interpretación:

• Si ves el tráfico en la interfaz física del host pero no en el bridge, revisa publicación de puertos, políticas de firewall/forward y si el puerto está correctamente mapeado.
• Si ves el tráfico en el bridge pero no dentro del contenedor, revisa que el contenedor esté conectado a la red esperada y que no haya políticas que bloqueen el forward hacia su veth.
• Si el contenedor recibe el tráfico pero el cliente no obtiene respuesta, revisa el bind del servicio (0.0.0.0 vs 127.0.0.1), el puerto correcto, y la respuesta/ruta de retorno.

Paso 4: repetir el mismo ejercicio en modo host (comparación rápida)

Ejecuta el servicio en modo host (conceptualmente) y repite:

• Dentro del contenedor, el servicio ahora “vive” sobre la red del host.
• Desde el cliente, te conectas a IP_DEL_HOST:PUERTO sin traducción hacia una IP privada de contenedor.

Qué deberías notar:

• Desaparece el salto “host → IP del contenedor” (no hay bridge/NAT para ese servicio).
• La observación del tráfico se simplifica (menos puntos intermedios), pero aumentan los riesgos de colisión de puertos y de exposición accidental.

Paso 5: checklist de administración cuando algo falla (VMs y contenedores)

• ¿Dónde escucha el servicio? (IP/puerto y si es 0.0.0.0 o loopback).
• ¿Qué IP tiene la carga? (IP de VM o IP de contenedor; y si es alcanzable desde el origen).
• ¿Hay traducciones intermedias? (NAT del hipervisor, port-forward del host, NAT perimetral: posible doble NAT).
• ¿La ruta de retorno es simétrica? (especialmente con redes internas/host-only/overlay).
• ¿MTU consistente? (si hay túneles/overlay, sospecha de MTU/MSS).