[🛠] IT Operations #1: Como resolvi o erro “Sem conexão com a Internet” do roteador da empresa (com Codex)

✨ Resumo do GPT-5.6 Sol

Um registro de como conectei o celular ao roteador do segundo andar e o navegador do Mac ao roteador da empresa para que o Codex diagnosticasse diretamente os equipamentos reais, aprendendo redes em tempo real enquanto recuperava o serviço.

Hoje o Wi-Fi do segundo andar da empresa estava estranho. O sinal aparecia muito forte, mas não havia Internet. O roteador estava ligado e o celular também se conectava, mas a tela continuava mostrando Sem conexão com a Internet.

O roteador diante de mim estava ligado, e o indicador de LAN também piscava. Só olhando por fora, não havia como saber onde a conexão estava bloqueada.

Antes, eu teria desligado e ligado o roteador algumas vezes, verificado se o cabo de rede estava conectado no lugar errado e, se ainda assim não funcionasse, começado a pesquisar. Mas dois dias antes, enquanto escrevia Saber usar a IA ativamente faz as possibilidades parecerem infinitas, aprendi uma nova forma de trabalhar.

Bastava conectar a IA aos equipamentos e às telas reais.

Desta vez, usei essa forma imediatamente. Conectei o celular ao Mac por USB e abri o ADB. O celular ficou conectado ao Wi-Fi problemático do segundo andar. No Chrome do celular, abri a tela administrativa do roteador do segundo andar e fiz login. No Chrome do Mac, abri a tela administrativa do roteador da empresa e fiz login. Então falei com o Codex.

O ponto principal não foi eu descobrir sozinho todas as configurações dos roteadores, mas primeiro preparar os equipamentos físicos, o ambiente de execução de comandos e as telas administrativas já autenticadas para que o Codex pudesse trabalhar de verdade.

Comece entendendo a situação atual. Mudar as coisas sem cuidado pode causar problemas, então tente resolver primeiro por comandos sempre que possível.

O Codex já não era um chatbot que apenas explicava. Ele podia ler por comandos o estado da rede do celular e alternar, pelo Computer Use, entre as duas telas administrativas nas quais eu havia feito login para verificar e alterar configurações reais.

Conectei o celular e os navegadores para mostrar as duas redes ao mesmo tempo

No começo, eu nem sabia por que 192.168.0.1 não abria. Ao verificar, descobri que os dois roteadores exerciam papéis diferentes.

Roteador da empresa 192.168.0.1
  └─ WAN do ipTIME do segundo andar 192.168.0.86
       └─ Wi-Fi / LAN do segundo andar 192.168.1.x
            └─ Tela administrativa do roteador do segundo andar 192.168.1.1

Como o Mac estava conectado à rede da empresa, ele conseguia abrir o roteador da empresa em 192.168.0.1. Já o celular conectado ao Wi-Fi do segundo andar recebia um endereço 192.168.1.x e usava 192.168.1.1 como gateway. Por isso deixei o roteador da empresa aberto no navegador do Mac e o roteador do segundo andar aberto no navegador do celular.

Eu não apenas mostrei as telas. Como o ADB estava conectado, o Codex podia ler o IP e a route recebidos pelo celular, especificar a interface Wi-Fi do segundo andar e testar diretamente a comunicação. Mesmo que o Wi-Fi caia, um celular pode concluir uma solicitação de Internet pelos dados móveis, então um simples ping poderia produzir um resultado enganoso.

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"

Os resultados foram estes.

• O roteador do segundo andar em 192.168.1.1 respondia a partir do celular.
• O roteador da empresa em 192.168.0.1 não respondia.
• O IP externo 1.1.1.1 também não respondia.
• A verificação HTTPS terminava em 000.

Eu acompanhei todo o processo ao lado. O fato de haver sinal Wi-Fi significava apenas que o celular estava conectado ao roteador do segundo andar. O problema estava depois, no trecho em que a WAN do roteador do segundo andar deveria sair para a rede da empresa.

Eu não abri primeiro um livro de redes para estudar LAN, WAN, gateway e NAT duplo em ordem. Vendo o Codex isolar e testar cada trecho da falha real, entendi imediatamente por que 192.168.0.1 e 192.168.1.1 existiam ao mesmo tempo.

A comunicação podia estar bloqueada mesmo com a concessão DHCP correta

No mesmo dia, os IP do NAS de desenvolvimento e do NAS de dados também haviam mudado. Encontrei os endereços atuais e os endereços MAC na lista de clientes DHCP do roteador da empresa e reservei os endereços para que os dois NAS recebessem os mesmos na próxima vez. Também atualizei o port forwarding de HTTP e HTTPS usado pela automação de férias que eu havia migrado antes para o NAS para apontar aos novos endereços.

Nesse processo, aprendi o que era DHCP exatamente quando precisei.

• Uma atribuição DHCP normal empresta um IP disponível a um dispositivo.
• Uma reserva DHCP faz um endereço MAC específico receber sempre o mesmo IP quando se conecta.
• Configurar um IP fixo no próprio equipamento e criar uma reserva DHCP no roteador são coisas diferentes.

Mas o problema do roteador do segundo andar não podia ser explicado apenas pela reserva DHCP. A tela administrativa do ipTIME mostrava o IP externo 192.168.0.86 e o estado Conectado à Internet. No roteador da empresa também havia um registro de que o mesmo IP estava concedido ao ipTIME atual.

No meio da investigação, o Codex olhou apenas a página atual da lista DHCP e concluiu incorretamente que .86 não estava ali. Havia mais de 90 clientes e a lista estava dividida em várias páginas, enquanto eu já tinha visto a linha correspondente em outra página.

Está aí.

Quando mostrei novamente o endereço MAC e a linha da concessão .86, a direção da investigação mudou. O problema não era a falta de um IP, mas encontrar a configuração que bloqueava a comunicação depois de ele ter sido recebido.

Desconectar e reconectar a WAN não mudou o resultado. A função de controle de acesso estava ativada, mas a blacklist estava vazia. Então a causa apareceu na tela Vinculação IP&MAC: .86 não estava vinculada à MAC WAN atual do ipTIME, mas à MAC de um computador de mesa usado anteriormente.

Servidor DHCP: concede 192.168.0.86 ao ipTIME atual
Vinculação IP&MAC: registra 192.168.0.86 como a MAC do PC antigo

O DHCP havia dado o endereço ao dispositivo atual, mas a configuração de segurança considerava que o dono daquele endereço era outro dispositivo. Por isso, o ipTIME parecia ter recebido um IP na tela administrativa, mas não conseguia se comunicar com o roteador da empresa.

Receber um IP e conseguir se comunicar com esse IP não eram a mesma coisa. Também entendi isso naturalmente ao acompanhar a falha.

Apaguei uma única vinculação antiga e verifiquei novamente no Wi-Fi real

Não desativei todas as funções de segurança do roteador. Apaguei apenas a vinculação IP–MAC antiga de .86 que causava o problema e renegociei a conexão WAN do ipTIME.

Desta vez, o resultado mudou imediatamente.

192.168.0.1  ping bem-sucedido
1.1.1.1      ping bem-sucedido
HTTPS        204
Android Wi-Fi VALIDATED

Depois de recuperar a conexão, adicionei uma reserva DHCP para que a MAC WAN atual do ipTIME recebesse sempre .86. A reserva DHCP continua fornecendo o mesmo endereço ao dispositivo atual, enquanto a vinculação IP–MAC obriga que apenas um dispositivo específico possa usá-lo. A falha ocorreu porque os dois registros apontavam para dispositivos diferentes.

A Internet voltou, mas permaneceu a estrutura de NAT duplo em que o ipTIME do segundo andar cria uma rede 192.168.1.x separada sob a rede da empresa. Para mudar para o modo AP·hub, seria preciso alterar não apenas o DHCP e o IP administrativo, mas também se o cabo de rede real está conectado à WAN ou à LAN. Se eu mexesse nisso remotamente sem cuidado, poderia perder ao mesmo tempo a tela administrativa e os equipamentos do segundo andar; por isso, hoje corrigi apenas a causa confirmada da falha de Internet.

Não consertei o problema depois de aprender tudo sobre redes; aprendi enquanto consertava

O ponto principal do que fiz hoje não foi estudar previamente todo o conhecimento de redes para consertar o roteador.

Quando o problema apareceu, usei imediatamente a forma de trabalhar que havia descoberto em 22 de julho. Primeiro, fiz as conexões físicas e os logins que só eu podia realizar. Conectei o celular ao Wi-Fi do segundo andar e ao Mac por USB. Abri as telas administrativas dos dois roteadores. Defini o escopo das mudanças e, quando vi que o Codex havia deixado passar a linha do DHCP, apontei-a novamente.

A partir daí, o Codex pôde agir. Ele verificou por comandos até qual trecho havia comunicação, leu as configurações das duas telas administrativas com o Computer Use, eliminou uma a uma as causas possíveis, alterou apenas o registro necessário e verificou novamente no mesmo celular.

Eu não estudei todo tipo de conhecimento de redes separadamente antes de entrar na prática. Os conceitos de que precisava naquele momento vieram ligados a telas reais e resultados de comandos. DHCP, endereço MAC, gateway, LAN e WAN, vinculação IP–MAC e NAT duplo deixaram de ser termos que eu precisava memorizar e se tornaram ferramentas para explicar por que a falha diante de mim havia ocorrido.

A IA também não acertou sempre desde o começo. Como quando deixou passar .86, ela também fez julgamentos errados. Mas, quando eu olhava a tela real e voltava a apontar algo estranho, o Codex passava imediatamente para a próxima verificação. Eu não precisava conhecer de antemão todos os comandos e menus de configuração, mas precisava continuar julgando se o resultado parecia estranho e redefinindo o objetivo.

Dois dias antes, eu havia percebido pela primeira vez que conectar o navegador e o celular à IA ampliava a área que eu conseguia manejar diretamente. Hoje aproveitei ativamente essa descoberta para resolver uma falha real da empresa.

Estudar por semanas uma área desconhecida e aplicá-la algum dia não era a única forma. Também dava para resolver um problema real junto com a IA, aprender naquele momento apenas o necessário e produzir um resultado imediatamente.