Dos sistemas que no se ven: el servicio no está caído
Un servicio sano que no responde desde otra máquina es un síntoma clásico de red mal entendida. La causa suele estar en cómo sale cada host, no en el servicio.
Lectura: 4 minutos
El síntoma
Es común que un servicio corra dentro de una máquina virtual y tenga que hablar con otro que vive en la máquina anfitriona —el equipo que contiene a las virtuales—. El resultado es siempre el mismo: no hay conexión. El reflejo natural es asumir que el servicio está caído, pero al revisarlo está arriba, sano, y responde bien cuando se lo llama desde el propio anfitrión. Las dos cosas son verdad al mismo tiempo: el servicio funciona y no se puede llegar a él.
El diagnóstico
Antes de tocar configuración conviene descartar en orden. Un síntoma clásico se resuelve con cuatro preguntas:
- ¿Está escuchando? Si el servicio acepta conexiones desde el anfitrión, está vivo.
- ¿El problema es del cliente? Si desde la máquina virtual tampoco responde a mano, no es el programa que llama.
- ¿Hay un bloqueo de por medio? Si no hay reglas que corten el tráfico, el firewall no es el culpable.
- ¿Qué dirección está usando la máquina virtual para salir? Esta es la pregunta correcta, y casi nunca se hace primero.
La pregunta no es si el servicio está caído, sino por dónde lo está buscando quien intenta conectarse.
La causa real
Cada máquina virtual se conecta a la red de una de dos maneras, y la diferencia define qué direcciones existen desde adentro:
| Modo | Qué significa | Cuándo conviene |
|---|---|---|
| Puente (bridge) | La máquina se conecta a la red real como un equipo más, con su propia dirección. | Cuando tiene que verse desde la red local o recibir visitas de afuera. |
| NAT (traducción de direcciones) | La máquina queda en una red privada interna y sale por una puerta que le presta el anfitrión. | Cuando tiene que estar aislada y ser reproducible: muchas máquinas iguales, sin depender del router del lugar. |
En modo NAT, la máquina virtual no comparte red con el anfitrión: no lo ve como vecino. Para alcanzarlo tiene que salir por la puerta del NAT, que tiene una dirección fija y conocida. Llamar a la dirección del anfitrión en la red real es llamar a una dirección que, desde adentro, simplemente no existe.
La decisión: un parque de máquinas que se replica muchas veces va en NAT, y los servicios del anfitrión se alcanzan por la dirección de la puerta del NAT, nunca por su dirección en la red local. El modo puente se reserva para lo que sí tiene que verse desde afuera.
El costo de esa decisión es exactamente el síntoma inicial: hay que saber que desde adentro la red es otra. Ese costo se paga una vez, dejando la regla escrita con la dirección correcta, en lugar de pagarlo cada vez que alguien busca un servicio que estaba sano.
Por qué NAT y no puente
El modo puente funciona hasta que cambia el lugar. Depende del router donde esté el anfitrión, de que la red no bloquee conexiones entrantes y de que nadie más esté usando la misma dirección. Un parque que se replica muchas veces necesita que cada copia nazca igual, sin negociar con la red del lugar: cada una recibe su propia red privada y sus puertos se traducen uno a uno desde el anfitrión. La reproducibilidad pesa más que la comodidad inicial del puente.
La lección
"No responde" no es lo mismo que "está caído". Cuando dos sistemas no se ven, antes de revisar el servicio hay que revisar por dónde se están buscando: la topología de red, las credenciales, el nombre que se usa. El servicio suele estar perfecto.
Una dirección que "no existe" tampoco es un misterio: casi siempre es una red distinta a la que se cree estar usando.
Bitácora de Thot-ecosystem · Infraestructura.