Cómo registrar cambios de routers con OpenWISP y OpenWrt
Guía técnica para ordenar routers OpenWrt con OpenWISP: plantillas, agentes, monitoreo, firmware, costos y prueba de reversión.
Un cambio de SSID aplicado a mano en 42 routers deja 42 puntos de falla antes del primer reclamo. OpenWISP centraliza configuración, monitoreo y actualización de firmware sobre equipos OpenWrt, con plantillas, agente y métricas. Para una cooperativa de internet rural, la nota muestra qué dato vive en el controlador, quién puede empujar cambios y cómo probar una reversión cuando un sitio queda sin enlace.
Dónde aparece el costo de cada cambio manual
El costo aparece cuando soporte entra por SSH a cada router y copia una regla de memoria. Un AP queda con contraseña vieja, otro pierde VLAN y un tercero queda sin monitoreo. OpenWISP ordena esa rutina con organizaciones, dispositivos, plantillas y módulos que registran configuración, estado y alertas desde un servidor central.
La cifra que corrige la discusión viene de OpenWrt: la primera versión estable 24.10 incorporó más de 5.400 commits desde la rama anterior, y la serie 24.10.7 fue publicada el 21 de mayo de 2026 según su página de release. Para una red rural, ese movimiento pide más que una libreta de contraseñas: qué firmware corre cada equipo y qué cambio se aplicó.
Un router sin inventario ya es una deuda técnica.
En una cooperativa eléctrica con internet rural, el objeto visible era una etiqueta blanca bajo la puerta del rack con la frase clave vieja, no tocar. El antagonista tenía nombre simple: configuración por SSH sin registro. El puente global lo marca GitHub, que en Octoverse 2025 informó más de 180 millones de desarrolladores y cerca de 230 repositorios nuevos por minuto. El software abierto escala, aunque el cambio en campo sigue fallando cuando nadie guarda evidencia local.
Cómo funciona por dentro
El flujo empieza en el controlador. OpenWISP guarda organización, ubicación, dispositivo, credenciales de enrolamiento, plantilla y último estado. El agente openwisp-config corre en OpenWrt, se conecta al servidor, recibe configuración y aplica cambios. El módulo de monitoreo registra métricas, estado de salud y alertas, según la documentación de Monitoring.
La base guarda datos estructurados: equipo, MAC, sitio, versión, plantilla, usuario y auditoría. Los archivos de firmware quedan separados con checksum y fecha. El módulo de Firmware Upgrader registra cada actualización y busca evitar dobles cargas accidentales con la misma imagen. El tablero muestra equipos offline, errores de configuración, latencia y sitio afectado.
Los permisos separan diseño, ejecución y lectura. Ingeniería define plantillas. Soporte aplica cambios autorizados a grupos de dispositivos. Guardia ve estado y alerta, aunque no edita. Dirección consulta cortes por zona. El backup copia base, configuración, secretos de enrolamiento y archivos de firmware. La restauración crea un controlador limpio, enrola un router de prueba y confirma que recibe plantilla, monitoreo y alerta.
Qué se instala o configura primero
La pila mínima usa OpenWISP 25.10, PostgreSQL, Redis, un proxy HTTPS, backups con Restic y un canal de gestión WireGuard u OpenVPN para alcanzar routers detrás de NAT. En equipos OpenWrt se instala openwisp-config y openwisp-monitoring. Un servidor chico cuesta entre USD 18 y USD 50 mensuales, entre ARS 25.776 y ARS 71.600 al dólar vendedor oficial de ARS 1432. El monto cubre cómputo, almacenamiento y monitoreo del controlador. Routers, visitas a sitio y enlaces de gestión se calculan aparte.
El primer entregable verificable es un inventario con diez routers: sitio, MAC, versión, plantilla, último contacto y responsable. El segundo es una plantilla aplicada a un grupo chico y una reversión documentada. En despliegues UMSA, esa prueba se hace con un router de laboratorio y otro de campo, porque una plantilla validada en banco puede cortar un enlace si cambia una interfaz con nombre distinto.
La implementación toma de dos a cinco semanas. La primera define sitios, grupos y red de gestión. La segunda enrola equipos piloto. La tercera arma plantillas y alertas. Las siguientes ajustan firmware, backups y procedimiento de reversión. El entregable que decide la continuidad es una bitácora de cambios: usuario, plantilla, grupo, hora, resultado y ticket. Cuando aparece un corte, soporte revisa la bitácora antes de mandar una camioneta.
Dónde se rompe y cómo probarlo
El primer riesgo es perder alcance hacia equipos detrás de NAT. La señal aparece cuando el controlador muestra offline masivo en una zona. La prueba corta el túnel de gestión y verifica alerta, reintento y procedimiento manual.
El segundo riesgo es aplicar una plantilla a hardware distinto. La señal aparece cuando un grupo queda con interfaces faltantes o sin VLAN. La prueba usa dos modelos de router y exige validación de configuración antes del despliegue.
El tercer riesgo es actualizar firmware sin plan de regreso. La señal aparece cuando un equipo vuelve con versión nueva y servicio incompleto. La prueba ejecuta actualización en un piloto, confirma checksum, espera reconexión y documenta cómo restaurar la imagen anterior.
El valor aparece cuando cada router puede contestar tres preguntas: qué configuración recibió, quién la aplicó y cómo vuelve atrás.