The IP that changed: compare numbers, not network names

Hay un tipo de falla que parece de SSH y no lo es: ssh mac se queda esperando y termina en Connection timed out. La llave está bien, el servicio está activo, y aun así no entra. En esta serie me pasó dos veces, con causas distintas, y las dos se resolvieron mirando la misma cosa: la dirección IP. Los pasos exactos están en el paso red y DHCP de la guía.

Primera vez: la red que parecía la misma

Al armar el puesto, la Mac no respondía desde Windows. Las dos máquinas estaban “en el WiFi de casa”, o eso creía. Al comparar las direcciones, la Mac tenía una IP del rango que usa el hotspot del iPhone, mientras que Windows, conectado por cable, estaba en el rango de mi módem. Eran subredes distintas. El nombre de la red en pantalla parecía el mismo, pero la dirección decía otra cosa.

La solución fueron dos acciones: conectar la Mac al WiFi del módem y quitarle la autoconexión al hotspot, para que no vuelva a saltar a él sin avisarme.

La lección que anoté: compara las IP (los tres primeros números), no los nombres de red. Dos máquinas se ven si están en la misma subred, y eso se lee en los números.

Segunda vez: después de actualizar macOS

Más tarde, ya con SSH funcionando, actualicé macOS (lo cuento en el post 05). Al terminar, ssh mac respondió con un timeout. Lo documenté con una captura, y la causa fue la misma: la Mac había recibido una IP nueva. Mi alias en ~/.ssh/config seguía apuntando a la anterior.

Aquí hay un detalle que no puedo afirmar con certeza. Revisé la configuración de la red WiFi de la Mac y dejé la opción Dirección Wi-Fi privada en Fijo (hay una captura de ese ajuste). La idea es que una dirección de hardware estable le permite al módem reconocer a la Mac y darle siempre la misma IP. Pero no verifiqué que ese cambio por sí solo evite que la IP vuelva a moverse. Es una hipótesis razonable, no un resultado comprobado.

Lo que sí hace que la IP no cambie

La solución de fondo es una reserva DHCP en el módem: le dices al router “a esta dirección de hardware dale siempre esta IP”. Mi plan de trabajo la marca como recomendada, y en mi lista de pendientes manuales figura la reserva para la IP de la Mac. No tengo verificado que ya esté hecha, así que no la voy a contar como lograda.

Mientras no esté, la Mac sigue siendo un nodo cuya dirección puede moverse.

Cómo lo trato ahora

Dejé escrito, para las sesiones desatendidas, un procedimiento de recuperación con límites claros:

1. Si ssh mac falla, intentar una sola vez encontrar la Mac por su nombre .local.
2. No escanear la red. Un escaneo de puertos no es un procedimiento de recuperación; es otra cosa.
3. Si la encuentra, actualizar el HostName del alias y anotarlo. Si no, anotarlo y seguir con lo que no necesita la Mac.

Que el procedimiento diga explícitamente qué no hacer es tan importante como lo que sí hace. Un agente que no puede entrar a una máquina tiene la tentación de “probar cosas” hasta que algo responda, y yo prefiero que anote el problema y siga.

Lo que me llevo

• Ante un timeout, compara direcciones antes de tocar claves o servicios.
• Una IP “fija” que no está reservada en el router es una IP prestada.
• El procedimiento de recuperación debe fijar un límite, no solo una acción.

Siguiente: la actualización de macOS que provocó el segundo timeout, y por qué el número de versión que anoté a mano quedó viejo.