[🛠] IT Operations #1: Cómo resolví el error «Sin conexión a Internet» del router de la empresa (con Codex)

✨ Resumen de GPT-5.6 Sol

Un registro de cómo conecté el teléfono al router de la segunda planta y el navegador del Mac al router de la empresa para que Codex diagnosticara directamente los equipos reales, y de cómo aprendí redes en tiempo real mientras recuperaba el servicio.

Hoy el Wi-Fi de la segunda planta de la empresa funcionaba de forma extraña. La señal era excelente, pero no había Internet. El router estaba encendido y el teléfono se conectaba, pero la pantalla seguía mostrando Sin conexión a Internet.

El router que tenía delante estaba encendido y el indicador LAN parpadeaba. Mirándolo por fuera, no había forma de saber dónde se cortaba la conexión.

Antes habría apagado y encendido el router varias veces, comprobado si el cable de red estaba conectado en el lugar equivocado y, si aun así no funcionaba, habría empezado a buscar en Internet. Pero dos días antes, mientras escribía Saber aprovechar activamente la IA hace que las posibilidades parezcan infinitas, aprendí una nueva forma de trabajar.

Solo tenía que conectar a la IA con los equipos y las pantallas reales.

Esta vez la puse en práctica de inmediato. Conecté el teléfono al Mac por USB y abrí ADB. El teléfono estaba conectado al Wi-Fi problemático de la segunda planta. En Chrome del teléfono abrí la pantalla de administración del router de la segunda planta e inicié sesión. En Chrome del Mac abrí la pantalla de administración del router de la empresa e inicié sesión. Y entonces se lo dije a Codex.

Lo esencial no fue que yo averiguara personalmente toda la configuración de los routers, sino que primero preparé los equipos físicos, el entorno de ejecución de comandos y las pantallas de administración con sesión iniciada para que Codex pudiera trabajar de verdad.

Empieza por entender la situación actual. Cambiar cosas a la ligera podría causar problemas, así que intenta resolverlo primero con comandos siempre que sea posible.

Codex ya no era un chatbot que solo explicaba cosas. Podía leer por comandos el estado de red del teléfono y desplazarse mediante Computer Use entre las dos pantallas de administración en las que yo había iniciado sesión para comprobar y cambiar ajustes reales.

Conecté el teléfono y los navegadores para mostrar las dos redes a la vez

Al principio ni siquiera sabía por qué no se abría 192.168.0.1. Al comprobarlo, vi que los dos routers desempeñaban funciones distintas.

Router de la empresa 192.168.0.1
  └─ WAN del ipTIME de la segunda planta 192.168.0.86
       └─ Wi-Fi / LAN de la segunda planta 192.168.1.x
            └─ Pantalla de administración del router de la segunda planta 192.168.1.1

Como el Mac estaba conectado a la red de la empresa, podía abrir el router de la empresa en 192.168.0.1. En cambio, el teléfono conectado al Wi-Fi de la segunda planta recibía una dirección 192.168.1.x y utilizaba 192.168.1.1 como gateway. Por eso dejé abierto el router de la empresa en el navegador del Mac y el de la segunda planta en el navegador del teléfono.

No me limité a mostrarle las pantallas. Como ADB estaba conectado, Codex podía leer la IP y la route que había recibido el teléfono, especificar la interfaz Wi-Fi de la segunda planta y probar directamente la comunicación. Aunque se corte el Wi-Fi, un teléfono puede completar una solicitud de Internet usando los datos móviles, de modo que un simple ping podía producir un resultado engañoso.

adb shell "ping -I wlan0 -c 3 -W 2 192.168.1.1"
adb shell "ping -I wlan0 -c 3 -W 2 192.168.0.1"
adb shell "ping -I wlan0 -c 3 -W 2 1.1.1.1"

adb shell "curl --interface wlan0 -k -sS -o /dev/null \
  -w '%{http_code}' --connect-timeout 5 --max-time 10 \
  https://www.google.com/generate_204"

Los resultados fueron los siguientes.

• El router de la segunda planta en 192.168.1.1 respondía desde el teléfono.
• El router de la empresa en 192.168.0.1 no respondía.
• La IP externa 1.1.1.1 tampoco respondía.
• La comprobación HTTPS terminaba en 000.

Observé todo el proceso desde el lado. Que hubiera señal Wi-Fi solo significaba que el teléfono estaba conectado al router de la segunda planta. El problema estaba después, en el tramo por el que la WAN del router de la segunda planta debía salir a la red de la empresa.

No abrí primero un libro de redes para estudiar por orden LAN, WAN, gateway y doble NAT. Al ver cómo Codex aislaba y probaba cada tramo de la avería real, entendí inmediatamente por qué existían a la vez 192.168.0.1 y 192.168.1.1.

La comunicación podía estar bloqueada aunque la concesión DHCP fuera correcta

Ese mismo día también habían cambiado las IP del NAS de desarrollo y del NAS de datos. Busqué sus direcciones actuales y sus direcciones MAC en la lista de clientes DHCP del router de la empresa, y reservé las direcciones para que ambos NAS recibieran las mismas la próxima vez. También actualicé el port forwarding HTTP y HTTPS utilizado por la automatización de vacaciones que había migrado antes al NAS para que apuntara a las nuevas direcciones.

Durante ese proceso aprendí qué era DHCP justo cuando lo necesité.

• Una asignación DHCP normal presta una IP disponible a un dispositivo.
• Una reserva DHCP hace que una dirección MAC concreta reciba siempre la misma IP cuando se conecta.
• Configurar una IP fija en el propio equipo y establecer una reserva DHCP en el router son cosas distintas.

Pero el problema del router de la segunda planta no se explicaba solo por una reserva DHCP. La pantalla de administración de ipTIME mostraba la IP externa 192.168.0.86 y el estado Conectado a Internet. En el router de la empresa también figuraba que esa misma IP estaba concedida al ipTIME actual.

En medio de la investigación, Codex miró solo la página actual de la lista DHCP y concluyó erróneamente que no aparecía .86. Había más de 90 clientes y la lista estaba dividida en varias páginas, mientras que yo ya había visto la fila correspondiente en otra página.

Sí está.

Cuando le volví a mostrar la dirección MAC y la fila de concesión .86, la dirección de la investigación cambió. Ya no se trataba de que el equipo no hubiera recibido una IP, sino de encontrar el ajuste que bloqueaba la comunicación después de haberla recibido.

Desconectar y volver a conectar la WAN no cambió el resultado. La función de control de acceso estaba activada, pero la blacklist estaba vacía. Entonces apareció la causa en la pantalla Vinculación IP&MAC: .86 no estaba vinculada a la MAC WAN actual de ipTIME, sino a la MAC de un ordenador de escritorio utilizado tiempo atrás.

Servidor DHCP: concede 192.168.0.86 al ipTIME actual
Vinculación IP&MAC: registra 192.168.0.86 como la MAC del PC antiguo

DHCP había dado la dirección al dispositivo actual, pero la configuración de seguridad consideraba que el propietario de esa dirección era otro dispositivo. Por eso ipTIME parecía haber recibido una IP en su pantalla de administración, pero no podía comunicarse con el router de la empresa.

Recibir una IP y poder comunicarse con esa IP no significaban lo mismo. También lo entendí de forma natural al seguir la avería.

Eliminé una sola vinculación antigua y volví a verificar desde el Wi-Fi real

No desactivé todas las funciones de seguridad del router. Eliminé únicamente la vinculación IP–MAC antigua de .86 que causaba el problema y volví a negociar la conexión WAN de ipTIME.

Esta vez el resultado cambió de inmediato.

192.168.0.1  ping correcto
1.1.1.1      ping correcto
HTTPS        204
Android Wi-Fi VALIDATED

Después de recuperar la conexión, añadí una reserva DHCP para que la MAC WAN actual de ipTIME recibiera siempre .86. La reserva DHCP proporciona continuamente la misma dirección al dispositivo actual, mientras que la vinculación IP–MAC obliga a que solo un dispositivo concreto pueda utilizarla. La avería se produjo porque los dos registros apuntaban a dispositivos distintos.

Internet volvió, pero se mantuvo la estructura de doble NAT en la que el ipTIME de la segunda planta crea una red 192.168.1.x separada bajo la red de la empresa. Para cambiarlo al modo AP·hub habría que cambiar no solo DHCP y la IP de administración, sino también si el cable de red real está conectado a WAN o LAN. Si lo tocaba a distancia sin cuidado, podía perder a la vez la pantalla de administración y los equipos de la segunda planta, así que hoy corregí únicamente la causa confirmada de la avería de Internet.

No arreglé el problema después de aprenderlo todo sobre redes; aprendí mientras lo arreglaba

Lo esencial de lo que hice hoy no fue estudiar de antemano todos los conocimientos de redes para arreglar el router.

Cuando apareció el problema, apliqué de inmediato la forma de trabajar que había descubierto el 22 de julio. Primero hice las conexiones físicas e inicié las sesiones que solo yo podía realizar. Conecté el teléfono al Wi-Fi de la segunda planta y al Mac por USB. Abrí las pantallas de administración de ambos routers. Definí el alcance de los cambios y volví a señalar la fila DHCP cuando vi que Codex la había pasado por alto.

A partir de ahí, Codex pudo actuar. Comprobó por comandos hasta qué tramo había comunicación, leyó la configuración de las dos pantallas de administración mediante Computer Use, descartó una a una las posibles causas, modificó solo el registro necesario y volvió a verificar desde el mismo teléfono.

No estudié toda clase de conocimientos de redes por separado antes de entrar en la práctica. Los conceptos que necesitaba en ese momento llegaron unidos a pantallas reales y resultados de comandos. DHCP, dirección MAC, gateway, LAN y WAN, vinculación IP–MAC y doble NAT dejaron de ser términos que debía memorizar y se convirtieron en herramientas para explicar por qué había ocurrido la avería que tenía delante.

La IA tampoco acertó siempre desde el principio. Como ocurrió al pasar por alto .86, también emitió juicios erróneos. Pero cuando yo observaba la pantalla real y volvía a señalar algo extraño, Codex pasaba enseguida a la siguiente comprobación. No necesitaba conocer previamente todos los comandos y menús de configuración, pero sí tenía que seguir mirando si el resultado era extraño y redefinir el objetivo.

Dos días antes había comprendido por primera vez que conectar el navegador y el teléfono a la IA ampliaba el terreno que podía manejar directamente. Hoy aproveché activamente esa idea para una avería real de la empresa.

Estudiar durante semanas un campo desconocido y aplicarlo algún día no era la única manera. También podía resolver un problema real junto con la IA, aprender en ese mismo momento solo lo necesario y producir de inmediato un resultado.