// INFORME: Lecciones al montar un laboratorio en Raspberry Pi 5
// CONTEXTO: Hardware enablement / Contenedores / Aislamiento de red / Drivers
// ENTORNO: Raspberry Pi 5 / ARM64 / WiFi integrado + adaptadores USB
// ESTADO: Base estable validada y flujo de trabajo definido
NOTA DE ALCANCE
Las observaciones de esta entrada corresponden a un laboratorio personal y al estado del soporte disponible en el momento de la prueba.
No deben leerse como una sentencia universal contra una distribución concreta, sino como una lección práctica sobre estabilidad de plataforma, compatibilidad de drivers y diseño de un laboratorio reproducible.
0x01: El primer error
La idea inicial era sencilla: desplegar una Raspberry Pi 5 con una distribución orientada a seguridad y empezar a trabajar.
En la práctica, lo primero que apareció no fue productividad, sino un problema mucho más básico, y es que la conectividad inalámbrica no era estable ni predecible, ni con el chip interno ni con determinados adaptadores USB antiguos que en otros entornos habían funcionado razonablemente bien.
Ese punto fue importante porque obligó a replantear el problema correctamente.
No se trataba de “hacer funcionar una herramienta”, sino de entender si la base del sistema operativo era la adecuada para una plataforma tan reciente como la Raspberry Pi 5.
CAUSA TÉCNICA RESUMIDA
La Raspberry Pi 5 introduce cambios relevantes en el plano de entrada/salida, especialmente por el papel del chip RP1, que actúa como concentrador de I/O y modifica la relación entre kernel, buses y periféricos.
Cuando a eso se le suma una distribución rolling release, firmware parcheado muy sensible a versión y drivers externos fuera del árbol principal del kernel, la compatibilidad deja de ser un detalle y pasa a ser el problema central.
En mi escenario, el punto más frágil fue la combinación entre kernel reciente, soporte aún inmaduro para ciertos componentes y dependencias especialmente sensibles como Nexmon, cuyo funcionamiento depende de una compatibilidad muy concreta con versiones de kernel, disposición de memoria y firmware.
Por eso, más que decir que una distro “está rota”, la conclusión correcta es otra: no siempre es la mejor base para una plataforma nueva cuando el laboratorio depende de drivers y parches delicados.
La sorpresa fue que una distribución generalista y bien soportada como Ubuntu Desktop ofrecía una base mucho más estable.
No porque traiga más herramientas, sino porque resuelve primero lo importante: hardware, kernel, firmware y comportamiento predecible.
LECCIÓN
En un laboratorio serio, la prioridad no es la distro con más herramientas preinstaladas, sino la plataforma más estable sobre la que esas herramientas puedan ejecutarse sin pelearte antes con el hardware.
0x02: Contenedores
Una vez resuelto el problema de la base, el siguiente paso lógico fue dejar de pensar en una única “distro mágica” y pasar a un modelo más limpio:
Sistema anfitrión estable + Herramientas aisladas en contenedores.
En este esquema, Ubuntu se encarga del hardware, del kernel y de la estabilidad general del equipo, mientras que Kali queda encapsulada como entorno de trabajo desechable y controlado.
docker run -ti --privileged --net=host kalilinux/kali-rolling /bin/bash
Los parámetros --privileged y --net=host permiten al contenedor interactuar con las interfaces de red del anfitrión y trabajar con un grado de acceso suficiente para determinados casos de laboratorio, incluyendo operaciones que requieren visibilidad directa de dispositivos o manipulación de interfaces.
IMPORTANTE
Este enfoque es útil en laboratorio, pero conviene decirlo con precisión: --privileged y --net=host reducen aislamiento y deben entenderse como una concesión controlada para pruebas, no como configuración por defecto para cualquier entorno.
Aun así, el modelo es claramente superior al enfoque monolítico porque separa responsabilidades:
- El host gestiona estabilidad y compatibilidad de hardware
- El contenedor agrupa herramientas, dependencias y cambios de entorno
- El laboratorio gana reproducibilidad y reduce contaminación del sistema base
LECCIÓN
Un laboratorio maduro no consiste en meterlo todo en una única instalación, sino en desacoplar base, tooling y red para que cada capa falle lo menos posible y sea más fácil de sustituir.
0x03: Split tunneling y network namespaces
El siguiente nivel de madurez en el laboratorio no estaba ya en la distro, sino en la red.
La idea es sencilla, no todo proceso que corre en una máquina debería compartir el mismo camino de salida, la misma resolución DNS o el mismo contexto de conectividad.
Para resolver eso, una estrategia limpia es usar network namespaces.
El host mantiene su conectividad normal para administración, navegación o acceso remoto, mientras que un espacio de red separado agrupa procesos concretos y los fuerza a salir por una ruta específica, por ejemplo una VPN.
ELEMENTOS
- veth pairs para enlazar host y namespace
- Reglas de enrutado y NAT mediante
iptablesonftables - Uso de
MASQUERADEpara traducir tráfico saliente - Resolución DNS específica dentro del namespace
Lo importante aquí no es solo sacar tráfico por una interfaz distinta, sino evitar inconsistencias.
Si el namespace usa una salida tunelizada pero resuelve dominios con el DNS del host o del ISP, el aislamiento deja de ser limpio y aparecen fugas funcionales o de telemetría.
Segmentar procesos sin segmentar también DNS, routing y política de salida es quedarse a medias.
LECCIÓN
Un laboratorio bien diseñado no aísla solo herramientas; aísla también su red, sus rutas y su resolución de nombres.
0x04: Los drivers
El siguiente aprendizaje llegó con los adaptadores WiFi USB.
Algunos chipsets muy comunes, especialmente en Realtek, siguen dependiendo de drivers out-of-tree, es decir, módulos que no forman parte del kernel principal o cuyo mantenimiento no siempre va acompasado al ritmo de las actualizaciones.
Cuando se combinan hardware reciente, kernel cambiante y módulos externos, la pregunta deja de ser “qué distro uso” y pasa a ser “quién mantiene realmente este driver y cómo lo integra mi sistema”.
En ese punto, proyectos mantenidos por la comunidad resultan mucho más útiles que perseguir una imagen que traiga todo preconfigurado.
Repositorios bien mantenidos y mecanismos como DKMS son mucho más valiosos a largo plazo que una falsa sensación de “listo para usar”.
DKMS
- DKMS recompila automáticamente el módulo cuando el kernel cambia.
- Eso convierte un parche puntual en una solución mantenible.
- En distribuciones con ecosistemas comunitarios especialmente rápidos, como Arch/Manjaro a través de AUR, esa capacidad de adaptación puede llegar incluso antes que en repositorios oficiales.
La capacidad técnica no está en pulsar un botón ni en confiar ciegamente en una distribución, sino en entender la cadena completa, es decir:
- Chipset.
- Driver.
- Kernel.
- Firmware.
- Empaquetado y mantenimiento.
LECCIÓN
En Linux, muchas veces la diferencia entre frustración y estabilidad no está en cambiar de herramienta, sino en entender quién mantiene realmente la capa que falla.
0x05: Conclusión
Lo que empezó como un problema aparentemente simple con el WiFi terminó siendo una lección mucho más útil sobre arquitectura de laboratorio.
La enseñanza importante no es qué distribución “gana”, sino qué enfoque resulta más sólido:
- Elegir una base estable y bien soportada
- Aislar herramientas en contenedores
- Segmentar red y DNS con namespaces
- Resolver drivers desde mantenimiento real, no desde marketing de distro
En pruebas posteriores, otras distribuciones orientadas a seguridad también ofrecieron buenos resultados, pero a esas alturas lo relevante ya no era la marca de la distro, sino el modelo mental aprendido durante el proceso.
RESUMEN
- La Raspberry Pi 5 exige una base de sistema con buen soporte real de hardware.
- Una distro especializada no siempre es la mejor opción si la compatibilidad base falla.
- Contenedores permiten desacoplar estabilidad del host y tooling especializado.
- Network namespaces añaden segmentación y control real sobre la salida de procesos.
- Drivers mantenidos por comunidad y DKMS suelen ser más útiles que perseguir soluciones “mágicas”.
[ EOF ]
"A laboratory depends on stability and the criteria you use to separate the system, the network, and the tools."