NetBird Lanza su Proxy Inverso Capa 4 en Código Abierto
NetBird v0.67 llegó con soporte Layer 4 completo, extendiendo su proxy inverso open source más allá de HTTP. Ahora podés exponer TCP, UDP y TLS directamente a través de tu red NetBird con el mismo modelo zero-trust que usas para aplicaciones web. El anuncio fue oficial el 31 de marzo de 2026, según el hub de conocimiento de NetBird.
En 30 segundos
- NetBird v0.67 agregó soporte nativo para TCP, UDP y TLS en su reverse proxy (antes solo tenía HTTP)
- Cada protocolo tiene su propio modo: TCP con connection limiting, UDP con session-based relay, TLS con SNI-aware routing sin terminar encriptación
- Mismo modelo zero-trust de NetBird aplica a L4: autenticación de cliente, restricciones de acceso, geo-restricciones
- Casos de uso: bases de datos, tuneles SSH, servidores de juegos, backends IoT, protocolos personalizados
- Exponen servicios directamente desde CLI con comandos simples, sin necesidad de configuración JSON compleja
Qué es un proxy inverso de capa 4
Un proxy inverso de capa 4 es un intermediario de red que redirige tráfico en nivel de transporte, trabajando directamente con TCP, UDP o TLS sin necesidad de interpretar la aplicación que corre arriba. A diferencia de un reverse proxy HTTP (capa 7), que entiende rutas, headers y contenido, un L4 proxy solo ve puertos, direcciones IP y flujos de bytes.
Pensalo así: si necesitás proxear una aplicación web, un proxy HTTP te deja balancear por URL path o dominio (donweb.com/api vs donweb.com/blog). Pero si lo que tenés es una base de datos PostgreSQL, un juego multiplayer, o un protocolo IoT personalizado, ahí no hay cabeceras HTTP que interpretar. Entrás en puro L4: aceptás conexión en puerto 5432, la relayeás al backend, y que fluya lo que fluya.
El beneficio de un L4 proxy es velocidad y flexibilidad. No necesita desencriptar, no necesita parsear headers, no consume tanto CPU. La contrapartida es que perdés la inteligencia de capa 7: no podés routear por URL, no podés cachear, no podés inspeccionar payloads.
NetBird v0.67 y el soporte Layer 4
Hasta la versión 0.66, el reverse proxy de NetBird era HTTP-only. Cumplía bien para aplicaciones web, dashboards y APIs. Pero el equipo de NetBird se topó con un problema: ¿qué hacés si querés proteger con zero-trust un servicio que no es HTTP? Exacto, te quedabas afuera.
En marzo de 2026 liberaron v0.67 agregando soporte nativo a TCP, UDP y TLS en el proxy inverso. El changelog oficial detalla que ahora podés exponer cuatro tipos de servicios:
- HTTP/HTTPS (L7): lo que ya tenías, apps web y APIs
- TCP (L4): bases de datos, SSH, custom protocols
- UDP (L4): DNS, gaming, VoIP, telemetría IoT
- TLS passthrough (L4): servicios con encriptación end-to-end donde el backend termina TLS, no el proxy
La clave es que cada modo fue diseñado específicamente. TCP maneja connection limiting para no saturar. UDP usa session-based relay con idle timeouts configurables. TLS es SNI-aware: routea por Server Name Indication sin terminar la encriptación, así el proxy nunca ve el plaintext.
Modos de operación: TCP, UDP y TLS
TCP con connection limiting
TCP es bidireccional y stateful. Cuando exponés un servicio TCP, NetBird mantiene conexiones vivas, maneja handshakes, retransmisiones, todo. El connection limiting es importante porque un TCP proxy puede quedarse sin file descriptors si le mandás 10 mil conexiones concurrentes (spoiler: no es recomendado). Relacionado: ejecutar servicios sin dependencias externas.
La v0.67 te deja setear límites por servicio. Si tenés una base de datos que soporta máximo 500 conexiones, configurás connection limit en 500 y NetBird rechaza las que vienen después hasta que se libere una.
UDP con session-based relay
UDP es sin conexión, así que el proxy no puede “mantener” una conexión. En su lugar, NetBird mantiene sesiones por tupla de (source IP, source port, destination IP, destination port). Cualquier datagrama que llegue dentro de la ventana temporal se relayea; después idle timeout, cierra la sesión.
Perfecto para DNS, que es stateless y rapidísimo. También para gaming: manténé la sesión abierta mientras haya paquetes cada pocos segundos; si el cliente se va, timeout y listo.
TLS passthrough con SNI-aware routing
Acá viene lo interesante. Si el backend tiene su propio certificado TLS y no querés que el proxy lo maneje (porque mantenés seguridad end-to-end), usás TLS passthrough. El proxy ve el ClientHello, extrae el Server Name Indication (SNI), routea la conexión al backend correcto basado en el SNI, y después todo es transparente: los datos encriptados fluyen directo, el proxy no toca nada.
Caso de uso real: tenés múltiples backends con certificados diferentes, querés que todo llegue por el mismo puerto del proxy, pero no querés terminar/reterminar TLS en el proxy. SNI routing lo maneja automáticamente.
Casos de uso reales para L4
Bases de datos internas
PostgreSQL, MySQL, MongoDB: todos hablan TCP nativo. Hoy si querés acceso remoto seguro, o tenés una contraseña débil, o usás VPN clásica con todos sus problemas. Con NetBird L4 proxy, los clientes se conectan al proxy, NetBird valida identidad (certificate, token, lo que uses), y relayea al backend. Mismo zero-trust que para apps web, pero en la base de datos. Para más detalles técnicos, mirá mecanismos de seguridad en infraestructura.
Tuneles SSH
SSH es TCP puro. Si exponés el proxy en puerto 2222 y lo apuntás a tu servidor SSH interno, cualquiera con acceso NetBird puede connectarse vía SSH a través del proxy. El proxy no ve las claves ni los comandos (está en TLS), solo relayea bytes TCP.
Servidores de juegos y protocolos customizados
Un servidor de Minecraft, un servidor de un MMO, un backend IoT que habla protocolo propietario: cualquier cosa TCP o UDP entra. Porque NetBird no necesita entender la aplicación, solo relayea.
DNS y servicios UDP
DNS over UDP (puerto 53), NTP, SNMP, cualquier servicio ligero que no quiera overhead de TCP. UDP session relay de NetBird maneja eso.
Seguridad zero trust en proxies L4
Acá es donde NetBird juega fuerte, porque la mayoría de otros proxies L4 open source (HAProxy, Traefik en L4) no tienen zero-trust integrado. Tratás de restringir acceso con firewall, ACLs, o lo que sea, externo. NetBird no: el zero-trust entra en el proxy directamente.
Lo que NetBird trae a L4 es exactamente lo mismo que trae a HTTP: autenticación por cliente (certificate pinning, token), restricciones por usuario/grupo, geo-restricciones, logging de quién conectó cuándo desde dónde. El backend nunca ve al cliente real, ve al proxy. El proxy sabe quién es el cliente porque NetBird lo validó.
Diferencia con L7: en HTTP, podés routear por header (`Authorization: Bearer token`). En L4 no hay headers. Los docs de NetBird dicen que en L4 la autenticación es pre-proxy: NetBird valida la identidad del cliente en la capa de red, antes de que haya datos de aplicación. Después la conexión se relayea sin más validaciones.
Configuración y características técnicas
Exponér un servicio es simple. Desde CLI:
netbird reverse-proxy expose tcp --port 5432 --backend postgres-interno:5432 En optimización de recursos en sistemas profundizamos sobre esto.
Eso expone PostgreSQL en el puerto 5432 local, relayeando a postgres-interno:5432 en tu red interna. El proxy entiende qué es postgres-interno porque está en tu red NetBird.
Para UDP:
netbird reverse-proxy expose udp --port 53 --backend dns-server:53
Parámetros relevantes según la documentación oficial:
- Port: puerto en el que el proxy escucha (local o asignado automáticamente)
- Backend: dirección destino en formato host:port
- Protocol: tcp, udp, tls-passthrough
- Connection limit (TCP): máximo de conexiones concurrentes
- Idle timeout (UDP): cuántos segundos de inactividad antes de cerrar sesión
- Auth mode: none, cert, token (según tu modelo de identidad)
NetBird soporta PROXY protocol v2, así el backend recibe la IP real del cliente si la necesita.
Comparativa con otras soluciones open source
| Solución | L4 soporte | Zero-trust integrado | Ease of use | Caso mejor |
|---|---|---|---|---|
| NetBird v0.67 | TCP, UDP, TLS | Sí, nativo | CLI simple | Equipos con múltiples ubicaciones, zero-trust end-to-end |
| HAProxy | TCP, UDP | No (usar firewall externo) | Config verbose | Load balancing de alto rendimiento, máximo control |
| Traefik | TCP (limitado) | No | YAML moderado | Microservicios Docker, acoplado con orquestación |
| NGINX | TCP, UDP (stream module) | No | Nginx.conf | Rendimiento extremo, uso empresarial establecido |
| Envoy | TCP, UDP | Parcial (mTLS) | YAML complejo | Service mesh, ecosistema Istio/xDS |
NetBird gana por simplicidad + zero-trust. HAProxy gana por rendimiento bruto. NGINX gana por madurez y documentación. Elegir depende de qué necesitás: ¿querés plugar y andar sin configuración? NetBird. ¿Necesitás estrujar 100k pps? HAProxy. ¿Ya tenés NGINX en todos lados? Extendé en NGINX.
Errores comunes
Confundir L4 con L7 y esperar cosas que no existen
Un error clásico: “Voy a usar NetBird L4 para routear bases de datos por hostname.” Error. L4 no ve hostnames ni URLs, ve puertos. Si querés múltiples bases de datos proxeadas, asignás puertos diferentes (5432, 5433, 5434) o usa TLS passthrough + SNI. Pero L4 puro no routea por contenido.
No setear connection limits y quedarse sin descriptores
Si no limitás conexiones TCP y la aplicación cliente se vuelve loca mandando requests, el proxy agota file descriptors a nivel OS. Resultado: el proxy empieza a rechazar conexiones nuevas, parece que se rompió. Siempre setea límites razonables basados en lo que tu backend aguanta.
Asumir que UDP es confiable porque pasá por proxy
UDP sigue siendo UDP: puede perder paquetes, puede llegar out-of-order. El proxy no lo arregla. Si necesitás garantías de entrega, la aplicación tiene que manejarlo (como DNS con retransmisiones). El proxy solo relayea. Complementá con soluciones empresariales de infraestructura.
Preguntas Frecuentes
¿Necesito actualizar NetBird para obtener L4?
Sí, debe ser v0.67 en adelante (liberada el 31 de marzo de 2026). Si tenés una versión anterior, actualizás con tu gestor de paquetes o descargás desde el release de GitHub.
¿El proxy L4 de NetBird es tan rápido como NGINX?
Probablemente no. NGINX está optimizado para el máximo rendimiento bruto, soporta decenas de miles de pps. NetBird prioriza simpledad + zero-trust, así que hay overhead. Para casos de uso típicos (bases de datos internas, SSH, VoIP) está bien. Si necesitás balancear 100 mil requests por segundo, mejor NGINX.
¿Puedo usarlo para proxear traffic no NetBird?
El proxy de NetBird es para traffic dentro de la red NetBird. Si querés proxear servicios externos (internet público), podés hacer port-forwarding pero sin seguridad zero-trust. Mejor caso: usá NetBird internamente, expone lo que necesitás, y deja que otros accedan a través de NetBird.
¿TLS passthrough mantiene la validación de certificados?
No la hace el proxy. El cliente y el backend validan sus certificados directamente (mTLS). El proxy ve el SNI, routea, y transparenta el resto. Es exactamente lo que querés para máxima seguridad: ni el proxy ni intermediarios ven el contenido.
¿Qué pasa si el backend cae mientras un cliente está conectado?
La conexión se rompe. El cliente recibe un reset TCP (o timeout en UDP). No hay reconnection automática ni circuit breaking. Si necesitás eso, agregá un load balancer o health checker adelante del proxy, o implementá retry en la aplicación cliente.
Conclusión
NetBird v0.67 cierra un hueco real: los proxies L4 open source existentes dejaban de lado la seguridad zero-trust. NGINX y HAProxy son poderosos pero requieren gestión de firewall, ACLs y autenticación por separado. Con NetBird, ahora tenés un reverse proxy que trata TCP, UDP y TLS con el mismo modelo de seguridad que ya usás en HTTP.
No es un reemplazo universal. HAProxy seguirá siendo mejor para load balancing extremo, NGINX para uso empresarial establecido. Pero si tenés múltiples equipos, ubicaciones dispersas, y querés zero-trust desde el día uno sin configuración arcana, NetBird L4 es ahora una opción creíble. La CLI simple y la integración directa con tu red NetBird lo hacen atractivo comparado con alternativas más complejas.
Si trabajás con infraestructura interna — bases de datos, túneles SSH, servidores de juegos en red privada — vale la pena probar. Si necesitás exponer servicios TCP a tu equipo remoto, NetBird v0.67 te ahorra configurar VPN tradicional o firewall rules frágiles.
Fuentes
- NetBird v0.67 – Layer 4 Proxy Support for TCP, UDP, and TLS — hub oficial con detalles técnicos del release
- NetBird Reverse Proxy Documentation — guía de configuración y uso
- NetBird v0.67.0 Release Notes — changelog oficial en GitHub
- NetBird Reverse Proxy Authentication — detalles de modelos de autenticación en L4
- Cloudflare Spectrum — referencia comparativa de L4 proxy en contexto enterprise
