Sobre un pequeño problema de conexión con un host de la intranet

Hace un tiempo, en el trabajo, me encontré con un problema un poco molesto. Desde mi portátil Mac, que estaba en la intranet de la empresa, usaba SSH para conectarme a otra máquina de esa misma intranet, un DGX Spark. Después de funcionar con normalidad durante un rato, por ejemplo una o dos horas, la conexión se cortaba de repente. Al principio pensé si quizá el host se había quedado en reposo, así que fui a operar el host localmente y probé la conexión otra vez. En cuanto hacía eso, la conexión entre mi portátil y el host se recuperaba.

Después de probarlo varias veces, llegué a una solución provisional: cada vez que mi portátil empezaba a recibir Request timeout con ping IP del host, iba a operar el host directamente y hacía ping a mi portátil desde allí. En cuanto lo hacía, la conexión de mi portátil con el host volvía inmediatamente a la normalidad. Funcionaba siempre, pero solo durante una o dos horas, hasta que tenía que repetirlo otra vez.

sequenceDiagram
    participant Mac as Portátil Mac
    participant Host as Host DGX Spark

    Mac--xHost: SSH se corta / ping da Request timeout
    Note over Host: Operar el host localmente
    Host->>Mac: Hacer ping a mi Mac desde el host
    Mac->>Host: La conexión se recupera

Mis compañeros usaban Windows, y yo era la única persona con Mac. Me dijeron que ellos no se habían encontrado con este problema. Además, no tenía acceso a la configuración del router de la empresa, así que no podía ver los detalles de enrutado de bajo nivel de la intranet. Después de darle muchas vueltas con GPT, la mejor hipótesis fue que Windows y macOS gestionan la caché ARP de forma distinta, y eso provocaba comportamientos de conexión diferentes.

Así que pasé un tiempo atrapada en este bucle infinito: “Ah, se ha desconectado otra vez ⭢ conectar teclado, ratón y monitor al host ⭢ hacer ping a mi portátil ⭢ la conexión funciona”. Pero este método era demasiado engorroso. Después de comentarlo con GPT, me sugirió otro enfoque: escribir directamente en mi portátil el mapeo entre la IP y la dirección MAC del host, para que macOS ya no tuviera que depender de una consulta ARP dinámica. Eso sí, había un detalle a tener en cuenta: en un momento dado cambié el host a red cableada para acelerar la descarga de modelos LLM. Entonces me di cuenta de que, cuando el host usaba Wi-Fi o red cableada, podía recibir una IP distinta, y la dirección MAC también era diferente. Ese mapeo también tenía que añadirlo antes de poder conectar.

flowchart LR
    host["<div class='dgx-gold-metallic'>Host DGX Spark</div>"]

    subgraph laptop["Portátil Mac"]
        arp["Añadir el mapeo del host al portátil<br/>IP del host + dirección MAC"]
    end

    laptop -->|Encontrar el host directamente y conectarse| host

    style laptop fill:#e8f2ff,stroke:#3b82f6,color:#1e3a8a
    classDef dgx fill:transparent,stroke:transparent,color:#3f2a00
    class host dgx

No mucho después encontré una solución aún más cómoda: conectarme usando el nombre mDNS del host. Es decir, el host anuncia su hostname .local mediante mDNS dentro de la red local. Mientras el dispositivo esté en la misma red local, puede conectarse directamente al host usando ese nombre. Esto me resolvió el problema por completo. Más tarde me di cuenta de que el nombre .local del DGX Spark estaba impreso en la propia portada del manual. La respuesta había estado delante de mí todo el tiempo, jaja.

flowchart LR
    subgraph lan["Misma red local"]
        host["<div class='dgx-gold-metallic'>Host DGX Spark</div>"]
        mdns(("Multidifusión mDNS<br/>Anuncia hostname .local e IP"))
        laptop["Portátil Mac"]
        other1["Otro dispositivo"]
        other2["Otro dispositivo"]
    end

    host -.->|Anuncia| mdns
    mdns -.->|Los dispositivos de la misma red pueden descubrirlo| laptop
    mdns -.-> other1
    mdns -.-> other2
    laptop -->|Conectarse con el hostname .local| host

    classDef mac fill:#e8f2ff,stroke:#3b82f6,color:#1e3a8a
    classDef dgx fill:transparent,stroke:transparent,color:#3f2a00
    class laptop mac
    class host dgx

Posdata: Al principio pensé que configurar mDNS sería el final de este asunto. Pero más adelante, después de actualizar la versión del driver del host, el problema de desconexión también desapareció. Podría haberme saltado todas las soluciones provisionales de arriba. Fue un arreglo totalmente inesperado y bastante bruto 🙃.