Boxr metió un TCP/IP stack en su motor de contenedores

En pocas palabras: El creador de Boxr, un motor de contenedores OCI rootless en Rust, integró UserNet, un stack propio de capas 2 a 4 (Ethernet, ARP, IPv4, ICMP, UDP, TCP) dentro del mismo binario, para dar salida a internet a los contenedores sin privilegios de root cuando pasta no está instalado.

Boxr, un motor de contenedores OCI escrito en Rust, metió un stack TCP/IP completo dentro de su propio binario para resolver el problema de red de los contenedores rootless. Se llama UserNet, corre en espacio de usuario sobre una interfaz TAP y funciona como respaldo cuando pasta no está instalado, según el artículo técnico de su creador.

Redes en contenedores rootless es el conjunto de técnicas que permiten a un contenedor sin privilegios de root salir a internet, resolver DNS y aceptar conexiones entrantes sin que el proceso host necesite sudo. UserNet es la implementación nativa en Rust que Boxr usa para eso: un stack que va de Ethernet hasta TCP, corriendo dentro del mismo binario del motor de contenedores.

¿Qué problema de red tienen los contenedores rootless?

Un contenedor rootless queda aislado en su propio namespace de red, con interfaces y rutas propias, pero sin salida al mundo exterior por diseño. El proceso que lo maneja no tiene privilegios de root sobre el host, así que no puede crear bridges, pares veth ni reglas de NAT de la forma tradicional.

Ponele que corrés nginx dentro de un contenedor rootless y el proceso pide resolver un dominio o abrir una conexión saliente. Un motor rootful resuelve esto con capacidades de host: bridges, iptables, lo de siempre. Pero un motor rootless tiene que traducir ese tráfico sin tocar la configuración del host, y ahí es donde entra un helper de red en espacio de usuario.

Ryo Tanaka, el desarrollador detrás de Boxr, lo plantea así en su publicación técnica: la respuesta habitual es un helper separado (pasta es el ejemplo maduro), pero él quiso probar si el propio runtime podía implementar un camino de red pequeño y entendible dentro de su binario. De ahí salió UserNet.

¿Cómo funciona UserNet, el stack TCP/IP que Boxr metió en su propio binario?

UserNet arranca con una interfaz TAP dentro del namespace de red del contenedor: la aplicación usa sockets POSIX normales y el stack Linux del contenedor emite frames Ethernet por esa interfaz, que Boxr lee en espacio de usuario. De ahí sale por un socket UDP o TCP ordinario del host hacia el destino real.

El camino completo, tal como lo describe la fuente, es este: aplicación del contenedor, socket POSIX, stack Linux del namespace, interfaz TAP (eth0), UserNet, socket UDP o TCP del host, destino. El camino de vuelta hace lo inverso: Boxr recibe bytes de un socket host, arma los headers de protocolo que el contenedor espera, calcula checksums, envuelve todo en un frame Ethernet y lo escribe de nuevo en TAP. Cubrimos ese tema en detalle en nuestra nota sobre diseñar redes multi-región en la nube.

Lo que llama la atención acá es la decisión de dejar las capas visibles en vez de esconderlas atrás de una abstracción grande. El parseo de Ethernet decide entre ARP e IPv4; el de IPv4 despacha ICMP, UDP o TCP. Cualquiera que haya debuggeado un stack de red sabe lo que cuesta cuando todo está mezclado en una sola función gigante, así que esta separación explícita facilita la revisión (y también hace más fácil encontrar el bug cuando algo falla).

¿Qué hacen ARP, ICMP y DNS dentro de UserNet?

ARP, ICMP y DNS son los protocolos chicos que le hacen creer al contenedor que hay una red real del otro lado de su interfaz. UserNet le arma al contenedor una red virtual con direcciones fijas: 10.0.2.15 para el propio contenedor, 10.0.2.2 como gateway y 10.0.2.3 como servidor DNS, según el detalle técnico publicado en dev.to.

Cuando el contenedor pregunta quién tiene el gateway o el DNS, el handler de ARP responde con una MAC virtual. IPv4 valida la forma del header y calcula el checksum de complemento a uno estándar para los paquetes que genera. Los pings ICMP al gateway virtual reciben su echo reply correspondiente, como si hablaran con un router real.

El caso más interesante es DNS. UserNet intercepta las consultas UDP dirigidas a la IP virtual de DNS, las reenvía por un socket UDP real del host hacia un resolver, y arma la respuesta como UDP sobre IPv4 sobre Ethernet para devolvérsela al contenedor. La aplicación ve un servidor DNS. El host ve un cliente UDP común. Boxr es el que traduce entre ambos mundos.

Acá el parseo defensivo no es un detalle menor: cada header necesita chequeo de longitud antes de leer campos, los tamaños declarados de payload tienen que estar acotados por los bytes recibidos de verdad, y los checksums hay que calcularlos sobre el pseudo-header y el payload exactos. Rust saca de encima errores de memoria, pero no garantiza que la lógica del protocolo esté bien (eso lo tenés que revisar vos). Complementá con cómo kubernetes gestiona la red entre nodos.

¿Qué tan lista está la implementación de TCP en UserNet?

Hasta el 26/09/2026, la implementación de TCP en UserNet reconoce las banderas de apertura y cierre de conexión, sigue números de secuencia y ACK, abre sockets TCP reales del host sin privilegios para los destinos salientes, y traduce la respuesta de vuelta a paquetes para el contenedor. Alcanza para demostrar la arquitectura y probar tráfico real, no para llamarla un stack TCP de producción.

ARP, ICMP y un proxy DNS son piezas finitas, fáciles de explicar en un par de párrafos. TCP es otra historia: el espacio de estados se dispara. Retransmisión, ACKs duplicados, segmentos fuera de orden, window scaling, backpressure, conexiones semi-cerradas, resets, comportamiento de timing, streams de larga duración y limpieza de recursos bajo fallas: nada de eso está resuelto todavía según reconoce el propio autor.

¿Y por qué Boxr sigue etiquetado como beta entonces? Justamente por eso. Tanaka lo dice sin vueltas en su publicación: prefiere dejar el límite explícito antes que esconderlo detrás de la frase “stack TCP/IP”. La revisión más valiosa, según sus propias palabras, no es un comentario de “buen proyecto” sino un trace de paquetes que muestre que la máquina de estados tomó la decisión equivocada, o una falla de teardown reproducible.

¿En qué se diferencia UserNet de pasta y de los otros modos de red de Boxr?

Boxr ofrece seis modos de red porque no hay una respuesta única que sirva para toda máquina: auto, usernet, pasta, bridge, host y none. El modo auto usa pasta cuando está instalado y cae a UserNet si no, sin necesitar ningún binario adicional en el sistema.

Modo	Qué hace	Cuándo conviene
auto	Usa pasta si está disponible, si no cae a UserNet	Uso general, sin pensar en la instalación
usernet	Fuerza el stack embebido en Rust	Instalaciones mínimas, sin dependencias externas
pasta	Usa el driver externo de red rootless	Cuando ya tenés pasta instalado y confiás en su madurez
bridge	Red con bridge tradicional	Escenarios que necesitan aislamiento de bridge clásico
host	Comparte la red del host directo	Cuando el aislamiento de red no es prioridad
none	Sin red configurada	Contenedores que no necesitan conectividad

La lógica detrás de este orden es clara: dar un fallback embebido hace que una instalación mínima ya sea útil, sin dejar de reconocer el valor de una implementación madura como pasta. Como dice la fuente, la ingeniería suele ser mejor cuando “hecho acá” no se convierte en “hay que usarlo en todos lados”. Relacionado: un dashboard liviano para administrar contenedores.

Eso sí: meter el stack de red adentro del mismo proceso que el motor de contenedores cambia el dominio de fallas. Un panic, un bug de lógica o un agotamiento de recursos en el parseo de paquetes puede afectar más superficie del runtime que si estuviera en un proceso separado. La pregunta que plantea el propio Tanaka no es “¿Rust o C?” sino qué inputs cruzan el límite, qué privilegios tiene cada componente y qué pasa cuando algo falla.

¿Cómo se prueba UserNet en Boxr hoy?

Para probar UserNet hoy hay que clonar el repositorio de Boxr en GitHub, compilarlo con cargo y correrlo con la bandera de red explícita. Los comandos documentados son estos:

• Clonar el repo: git clone https://github.com/kchaitanya863/boxr
• Compilar en modo release: cargo build –release
• Correr un contenedor con UserNet: ./target/release/boxr run –network usernet -p 8080:80 nginx:latest

Según la fuente, el proyecto lanzó recientemente la versión v0.1.44, que incluyó fixes de build y de user-namespace para exec en Linux, junto con assets de lanzamiento actualizados. El repositorio de GitHub confirma que Boxr sigue en beta activa, con hardening de features y pruebas de paridad en curso.

La red rootless depende del entorno del host (soporte de user-namespace en el kernel y acceso a /dev/net/tun), así que los reportes útiles necesitan detalle: kernel, distribución, arquitectura, comando exacto, logs y un reproductor mínimo. Un capture de paquetes corto ayuda más todavía cuando la falla está en el data path.

Qué está confirmado y qué no

Está confirmado por el propio autor y por el repositorio: UserNet existe, es pura Rust, cubre Ethernet/ARP/IPv4/ICMP/UDP/DNS/TCP básico, y Boxr etiqueta todo el proyecto como beta con un solo mantenedor activo. También está confirmado el número de versión v0.1.44 con fixes de user-namespace.

Lo que no está confirmado, porque la propia fuente lo deja abierto, es el comportamiento de TCP bajo condiciones adversas: no hay datos publicados de retransmisión, throughput bajo carga concurrente, ni benchmarks comparativos contra pasta o slirp4netns. Tampoco hay fecha anunciada para que UserNet salga de beta. Esto se conecta con lo que analizamos en otra alternativa para correr contenedores sin Docker.

Errores comunes al evaluar UserNet

Cualquiera que quiera meter UserNet en un pipeline de CI o en producción se topa con supuestos que no aplican todavía:

• Asumir que “TCP/IP stack” significa TCP completo: la implementación actual cubre el handshake y la traducción básica, pero le falta retransmisión, ventanas deslizantes y manejo de conexiones semi-cerradas. Tratarlo como un reemplazo de un stack de kernel es un error.
• Ignorar el modo auto y forzar usernet sin necesidad: si ya tenés pasta instalado, dejar que Boxr elija automáticamente te da la implementación más madura sin perder nada.
• No reportar bugs con contexto completo: el mantenedor pide kernel, distro, arquitectura y logs. Un reporte sin eso no sirve para reproducir el problema.
• Pensar que “está en Rust” implica seguridad de protocolo: Rust elimina errores de memoria, pero no valida que la lógica de parseo de headers sea correcta. Esa parte sigue dependiendo de revisión humana.

Un criterio práctico para evaluar este tipo de herramientas beta antes de meterlas en un entorno con tráfico real: correlas primero contra una carga sintética con conexiones largas y reinicios forzados de red, capturás el tráfico con una herramienta como tcpdump del lado del host, y comparás el comportamiento contra el mismo escenario corriendo con pasta. Si las diferencias de latencia o de errores de conexión son mínimas, tenés una base razonable para decidir. Esto es una propuesta editorial, no algo que hayamos ejecutado nosotros.

Preguntas Frecuentes

¿Qué es un contenedor rootless?

Un contenedor rootless es un contenedor que corre sin privilegios de root en el host, usando namespaces de usuario para mapear un usuario sin privilegios como si fuera root dentro del contenedor. Boxr, por ejemplo, es rootless por defecto y no necesita sudo ni daemon para funcionar.

¿Cómo se conecta a internet un contenedor sin privilegios de root?

Se conecta a través de un helper de red en espacio de usuario que traduce el tráfico del contenedor hacia sockets normales del host. En Boxr, eso lo hace pasta (herramienta externa madura) o UserNet (stack embebido propio), según el modo de red elegido.

¿Qué es UserNet en Boxr?

UserNet es el stack de red de capas 2 a 4 escrito en Rust que Boxr incluye dentro de su propio binario, sin depender de ningún binario externo. Cubre Ethernet, ARP, IPv4, ICMP, un proxy de DNS y una implementación básica de TCP.

¿Es seguro meter un stack de red dentro del motor de contenedores?

Depende del modelo de amenaza: un stack embebido comparte el mismo dominio de fallas que el resto del runtime, así que un bug en el parseo de paquetes puede afectar más que si estuviera en un proceso separado. El propio autor de Boxr reconoce que la pregunta de seguridad no es sobre el lenguaje sino sobre qué inputs cruzan el límite y qué pasa cuando fallan.

¿En qué se diferencia UserNet de pasta o slirp4netns?

UserNet es una implementación nativa en Rust integrada en el binario de Boxr, mientras que pasta es una herramienta externa madura que corre como proceso separado. Boxr usa pasta como opción prioritaria cuando está instalada y UserNet como fallback sin dependencias adicionales.

Conclusión

Boxr sumó un stack de red propio para que las redes en contenedores rootless funcionen incluso sin ninguna dependencia externa instalada, y eso es un aporte real a un problema que todo runtime rootless tiene que resolver de alguna forma. El diseño en capas visibles, con ARP, ICMP y DNS funcionando y un TCP básico operativo, deja una base entendible para auditar.

Lo que falta es justo lo más difícil: TCP bajo condiciones reales de red, con pérdidas, reordenamiento y conexiones que se cortan a la mitad. Si estás evaluando Boxr para algo que no sea un experimento local, tratá UserNet como lo que es hoy, un fallback en beta, y dejá pasta como opción principal si ya la tenés instalada. Para levantar tu propio entorno de pruebas con contenedores y necesitás infraestructura confiable donde correrlos, donweb.com tiene opciones de VPS y cloud pensadas para cargas de este tipo.

Fuentes

• Why I Put a TCP/IP Stack Inside a Rootless Container Engine – artículo técnico de Ryo Tanaka sobre UserNet
• Boxr en GitHub – repositorio oficial del motor de contenedores rootless