NetBird 0.74 en cooperativas: accesos, rutas y permisos
Mini-caso de acceso remoto para cooperativas rurales: NetBird une WireGuard, grupos, políticas y rutas con prueba de corte y salida documentada.
Un técnico de guardia entró a un router rural con una VPN compartida que nadie podía revocar. La cooperativa resolvía cortes, altas y cámaras con una mezcla de usuarios viejos, puertos abiertos y favores de madrugada. NetBird 0.74 permite ordenar ese acceso con WireGuard, grupos, políticas y rutas. Este caso anonimizado muestra qué se configura primero y cómo probar que un permiso cae a tiempo.
Dónde aparece el acceso que sobrevivió al turno
El caso es una cooperativa eléctrica con internet rural, cuadrillas propias y nodos repartidos entre fincas. El detalle concreto es un cuaderno de tapa azul en la camioneta de guardia: tiene IP, usuario, contraseña y una marca al lado de cada radio. La marca no dice quién entró ni quién debía perder acceso. La cifra que corrige la práctica viene del proyecto. La API de GitHub marcó NetBird v0.74.7 como última versión publicada el 17 de julio de 2026; el repositorio netbirdio/netbird tenía 27.410 estrellas y 1.513 forks al 19 de julio. El interés público por redes privadas administrables también llega a cooperativas y proveedores medianos. El dato global empuja la misma lectura. GitHub informó en Octoverse que más de 180 millones de desarrolladores trabajan y construyen en la plataforma. Las herramientas de red abiertas maduran porque muchas organizaciones chicas las prueban, fallan, reportan y corrigen. La contraseña compartida deja de ser un atajo cuando alguien se va. El aprendizaje de industria es simple: el acceso remoto tiene que nombrar usuario, equipo, recurso, puerto y vencimiento. Sin esos datos, soporte depende de memoria y la auditoría llega tarde.
Cómo funciona por dentro NetBird crea una red privada sobre WireGuard y permite administrarla desde un plano de control.
La documentación introductoria de NetBird describe el esquema self-hosted o cloud; en una cooperativa con datos sensibles conviene decidir temprano dónde vivirán cuentas, pares, grupos, políticas, rutas, DNS y logs de actividad. El flujo mínimo tiene seis pasos. Primero, IT registra usuarios o grupos desde el proveedor de identidad o desde gestión local. Segundo, cada notebook, servidor o gateway instala el cliente NetBird y queda como peer. Tercero, se arman grupos por rol: guardia, administración, proveedores y sistemas. Cuarto, una política define qué grupo llega a qué recurso, protocolo y puerto. Quinto, una red agrega recursos detrás de un routing peer. Sexto, los logs muestran cambios, conexiones y denegaciones. La guía de acceso con grupos y políticas explica que las políticas permiten decidir qué peers o grupos se conectan y con qué protocolos. La sección Networks agrega recursos, routing peers y políticas para llegar a subredes o servicios internos. La configuración self-hosted guarda datos de cuentas, peers, grupos, políticas, rutas, DNS, setup keys y logs, según la referencia de configuration files.
Qué se instala o configura primero
La pila inicial puede usar NetBird self-hosted, PostgreSQL como almacén si se quiere separar estado, un proveedor OIDC o Dex embebido, relay si hace falta, DNS interno, backup diario y monitoreo de peers. La guía Self-Hosted Quickstart permite levantar el plano de control, aunque producción pide dominio, TLS, backup y prueba de actualización. El inventario previo lista notebooks, servidores, routers y proveedores con acceso vigente. El costo mensual puede ubicarse entre USD 30 y USD 90, entre ARS 45.000 y ARS 135.000 al dólar oficial de venta de ARS 1.500. Ese rango incluye VPS, relay si hace falta, almacenamiento, monitoreo y backup. No incluye horas de inventario ni limpieza de usuarios viejos. El primer entregable verificable es una guardia piloto: dos notebooks, un servidor de monitoreo, un router de prueba, una política para SSH, otra para panel web y una revocación medida. UMSA puede participar cuando la cooperativa necesita reemplazar accesos compartidos por grupos, vencimientos y evidencia de corte sin frenar soporte.
Dónde se rompe y cómo probarlo
El primer riesgo aparece en políticas amplias. La señal es un grupo de guardia que llega a toda la subred cuando solo debía entrar a un equipo. La prueba es crear recursos /32, intentar acceder a otro host y registrar la denegación. El segundo riesgo aparece en el routing peer. La señal es una conexión permitida en NetBird que no llega al recurso interno. La prueba es revisar IP forwarding, ruta de retorno, masquerade y puerto destino desde una notebook de ensayo. El tercer riesgo aparece en salida de personal o proveedor. La señal es una cuenta desactivada que conserva un peer activo. La prueba es revocar usuario, setup key y peer, esperar sincronización y comprobar que no abre SSH ni panel web. La cooperativa puede seguir atendiendo de madrugada. La diferencia la marca un registro que diga quién entró, a qué entró y cuándo perdió permiso.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.