El borde minimalista: micro-proxies en Rust y Go

Hay una tendencia nicho pero profundamente apasionada en la comunidad de infraestructura: los desarrolladores están reemplazando sistemáticamente servicios de proxy comerciales pesados por herramientas open-source ultra-minimalistas escritas en Rust y Go. Durante años, la respuesta predeterminada para exponer un servidor de desarrollo local o evitar NAT de grado carrier (CGNAT) era usar un nombre conocido. Pero a medida que esas plataformas se orientan a funciones empresariales, sus agentes se vuelven más pesados y sus niveles gratuitos más restrictivos.

Entra el micro-proxy.

Escribir sobre herramientas open-source como bore, rathole y chisel atrae muchísimo a laboratorios caseros, aficionados a IoT y desarrolladores de edge computing — los ingenieros que ejecutan túneles en dispositivos con poca memoria como Raspberry Pi, donde cada megabyte de RAM cuenta. Al apoyarse en la seguridad de memoria de Rust o en la compilación estática de Go, estos micro-proxies ofrecen alternativas rápidas y auto-hospedadas que devuelven el control al desarrollador.

La búsqueda de una alternativa ligera a ngrok

Si alguna vez has necesitado mostrar a un cliente una app web local, probar un webhook o acceder a tu servidor doméstico desde una cafetería, has usado un servicio de tunneling. Estos funcionan ejecutando un agente en tu máquina local que llama a un servidor en la nube pública, atravesando tu firewall local. El servidor en la nube te proporciona una URL pública y reenvía el tráfico entrante por ese túnel.

Las soluciones comerciales son pulidas, pero tienen sus compromisos:

• Límites de conexión y ancho de banda. Las capas gratuitas frecuentemente limitan el ancho, las conexiones concurrentes o timeout en sesiones inactivas.
• Muros de pago por funciones. Túneles TCP en bruto para SSH o bases de datos, o un dominio personalizado persistente, suelen estar tras una suscripción.
• Bloat del agente. Los agentes comerciales incluyen funciones de cumplimiento, autoactualización y componentes UI que consumen recursos en dispositivos edge pequeños.
• Privacidad y control. Encaminamiento de tráfico local sin cifrar a través de un servidor de terceros introduce un punto de intercepción.

Esto ha generado demanda por algo que pueda hospedarse en un VPS barato, desplegarse como un solo binario y dejarse corriendo indefinidamente. Veamos tres herramientas que llenan ese nicho — y, lo que es importante, qué garantizan realmente sobre tu tráfico una vez sale de tu máquina, ya que ahí es donde la copia de marketing de estos proyectos suele adelantarse a los defaults.

1. Bore: El túnel TCP en Rust ridículamente simple

Si tu objetivo es la simplicidad absoluta, bore está hecho para ello. Creado por Eric Zhang, es un túnel TCP moderno y simple en Rust que expone puertos locales a un servidor remoto, evitando firewalls NAT estándar — e1e9 intended to be a highly efficient, unopinionated tool for forwarding TCP traffic that is simple to install and easy to self-host, with no frills attachedc3b3. Hasta ahora, tiene 11.4k estrellas en GitHub, 514 forks y está licenciado bajo MIT, en la versión 0.6.0 en crates.io.

Cómo funciona Bore

Bore es agresivamente poco opinado. e1e9 The whole project totals about 400 lines of safe, async Rust code and is trivial to set up — just run a single binary for the client and server.c3b3 No gestiona certificados TLS, no ofrece un panel de control, ni inspecciona tu tráfico HTTP. Solo reenvía bytes de A a B, usando un puerto de control implícito en 7835 para negociar nuevas conexiones entre cliente y servidor.

La corrección importante: bore no encripta tu tráfico por defecto, y el borrador inicial implicaba lo contrario por omisión. Bore soporta un flag opcional --secret, pero según la documentación oficial, ese secreto solo autentica el apretón de manos — no encripta la capa de datos. Literalmente, en la sección de autenticación del proyecto: el protocolo requiere que los clientes verifiquen la posesión del secreto mediante desafíos HMAC en cada conexión, pero “no se encripta más tráfico por defecto.” Si envías información sensible por bore, debes agregar TLS tú mismo (ver la sección de seguridad abajo).

Configuración rápida

cargo install bore-cli

Para exponer un servidor web local en el puerto 8000:

bore local 8000 --to bore.pub

El terminal devuelve un puerto remoto asignado aleatoriamente en bore.pub. Puedes fijar un puerto específico con --port, y exponer un host LAN distinto a localhost con --local-host.

Para auto-hospedaje, ejecuta bore server en tu VPS (opcionalmente con --secret para autenticación del apretón de manos, y --min-port/--max-port para restringir el rango expuesto), luego apunta la bandera --to de tu cliente local a la dirección de tu VPS. Es una herramienta plug-and-play cuando necesitas un túnel inmediato y no quieres un archivo de configuración.

2. Rathole: Alta performance en NAT traversal en Rust

Mientras bore es genial para pruebas rápidas y efímeras, rathole apunta a algo más permanente: exponer un NAS doméstico o una red de sensores IoT de forma segura y continua. Nota importante: el repositorio ha cambiado de organización, de rapiz1/rathole a rathole-org/rathole (el antiguo URL aún redirecciona). Actualmente tiene aproximadamente 14k estrellas, 809 forks y está licenciado bajo Apache-2.0, describiéndose como e1e9 a lightweight and high-performance reverse proxy for NAT traversal, written in Rust, an alternative to frp and ngrokc3b3.

El modelo de seguridad — y una corrección

Este es el segundo lugar donde el borrador original exageraba las cosas. El README de Rathole anuncia soporte para Noise Protocol: e1e9 tokens of services are mandatory and service-wise, and with the optional Noise Protocol, encryption can be configured at ease, with no need to create a self-signed certificate — TLS is also supportedc3b3. Pero dos detalles importan y el borrador anterior los mezclaba:

1. El campo token es autenticación del servicio, no encriptación del transporte. Demuestra que un cliente puede enlazar un servicio; no encripta los bytes en la línea.
2. La encriptación es opcional, no automática. A menos que agregues explícitamente un bloque [client.transport] / [server.transport] con type = "noise" (o "tls"), Rathole por defecto usa type = "tcp" sin cifrado — igual que bore. El bloque Noise también requiere un par local_private_key/remote_public_key (o el patrón por defecto, Noise_NK_25519_ChaChaPoly_BLAKE2s) — no se activa solo por poner un token.

Por tanto, la afirmación anterior de que “el tráfico está cifrado de extremo a extremo automáticamente” tras configurar un token compartido es inexacta. Así sería una configuración que habilita el cifrado:

Configuración vía TOML

server.toml en tu VPS:

[server]
bind_addr = "0.0.0.0:2333"

[server.transport]
type = "noise"

[server.services.my_ssh]
token = "super_secret_string"
bind_addr = "0.0.0.0:5202"

client.toml en tu servidor doméstico:

[client]
remote_addr = "vps_ip_address:2333"

[client.transport]
type = "noise"

[client.services.my_ssh]
token = "super_secret_string"
local_addr = "127.0.0.1:22"

Sin un bloque [transport] en ambos lados, vuelve a TCP sin cifrado ni autenticación en la capa de transporte, solo para pruebas locales rápidas. Rathole también soporta servicios UDP (type = "udp" en un bloque de servicio) y recarga dinámica del archivo de configuración sin reiniciar el proceso. Según sus propias métricas, e1e9 rathole puede lograr mucho mayor rendimiento que frp y manejar volúmenes grandes de conexiones con mayor estabilidad y menos consumo de memoriac3b3, con binarios de unos 500KiB.

3. Chisel: El túnel SSH versátil en Go

Para entornos corporativos muy restrictivos o necesidades complejas de proxying, chisel es la opción en Go. Actualmente en v1.11.5 (marzo 2026), con 16.1k estrellas, 1.6k forks, licencia MIT y se describe como: e1e9 a fast TCP/UDP tunnel, transported over HTTP, secured via SSH, single executable including both client and server, written in Goc3b3.

A diferencia de bore y rathole, chisel tiene su historia de seguridad bien desde el inicio — esta es la única en la que la confianza del borrador original estaba justificada, y vale aclararlo: la encriptación siempre está activa. Cuando inicia un servidor chisel, genera un par de claves ECDSA en memoria (o carga una desde --keyfile) y asegura todo el tráfico con ellas usando crypto/ssh de Go. El servidor imprime su huella digital en el arranque; los clientes deben fijar esa huella con --fingerprint para evitar MITM.

Cómo sortear firewalls restrictivos

El truco está en la capa de transporte. Muchas redes corporativas bloquean TCP en bruto o descartan SSH, pero casi nunca bloquean HTTP/HTTPS estándar. Chisel envuelve su túnel TCP/UDP dentro de HTTP, actualizándose a WebSockets — así, a un firewall restrictivo, un túnel chisel parece tráfico web normal. Cuando llega al servidor chisel, la carga útil se asegura con el protocolo SSH debajo.

Configuración

chisel server -p 8080 --reverse

En la máquina local restringida:

chisel client https://tu-vps-dominio.com R:80:localhost:3000

Este comando abre una conexión HTTP, negocia una sesión segura SSH y reenvía reversamente el puerto local 3000 al puerto 80 del servidor. Chisel también soporta modo proxy SOCKS5 (--socks5 en el servidor, un socks remoto en el cliente), autenticación por usuario con --authfile, y terminación TLS nativa con certificados automáticos de Let’s Encrypt vía --tls-domain — una función que el borrador anterior no mencionó y que es importante si quieres que chisel termine HTTPS en lugar de estar detrás de Nginx o Caddy. El soporte UDP llegó en la v1.7 del proyecto.

Comparativa: bore vs. rathole vs. chisel

El debate “bore vs rathole” es común entre entusiastas de Rust; chisel suele estar en su propia categoría para evasión de firewalls. La tabla a continuación es lo que faltaba en el borrador original — una comparación lado a lado de lo que por defecto obtienes, antes de configurar nada adicional:

	Bore	Rathole	Chisel
Lenguaje	Rust	Rust	Go
Encriptado por defecto	No	No (opcional vía Noise/TLS)	Sí (siempre en ECDSA/SSH)
Formato de configuración	Flags CLI	Archivo TOML	Flags CLI
Soporte UDP	No	Sí	Sí
Mejor para	Túneles instantáneos y desechables	Servicios persistentes y de alto rendimiento en laboratorios caseros	Cruza firewalls HTTP-only corporativos
Licencia	MIT	Apache-2.0	MIT

El veredicto: usa bore para un túnel desechable sin configuración, donde puedas agregar TLS propio si el tráfico lo requiere. Usa rathole para infraestructura persistente en laboratorios caseros con bajo recurso — pero activa explícitamente el transporte Noise. Usa chisel cuando estés tras un firewall HTTP-only y quieras cifrado sin configuración adicional.

Tutorial: Configurar un túnel localhost en Raspberry Pi

Millones de aficionados corren servicios personales en Raspberry Pi. El problema: muchas conexiones residenciales están detrás de CGNAT, sin IP pública para hacer port forwarding. Aquí, rathole, usado correctamente — con el transporte Noise activado esta vez.

Paso 1 — Preparar el servidor (VPS)

Descarga el binario de rathole desde la página oficial de lanzamientos. Crea server.toml:

[server]
bind_addr = "0.0.0.0:2333"

[server.transport]
type = "noise"

[server.services.pi_web]
token = "MySecureToken123!"
bind_addr = "0.0.0.0:8080"

Ejecuta: ./rathole server.toml

Paso 2 — Preparar el cliente (Raspberry Pi)

Descarga el binario ARM (Rust compila limpio para ARM). Crea client.toml:

[client]
remote_addr = "TU_IP_VPS:2333"

[client.transport]
type = "noise"

[client.services.pi_web]
token = "MySecureToken123!"
local_addr = "127.0.0.1:80"

Ejecuta: ./rathole client.toml

Como solo uno de [client] o [server] aparece en cada archivo, rathole detecta automáticamente qué modo usar — no necesitas la bandera --client/--server a menos que ambos bloques compartan un solo archivo.

Paso 3 — Persistencia con systemd

Crea /etc/systemd/system/rathole.service:

[Unit]
Description=Rathole Client Tunnel
After=network.target

[Service]
Type=simple
User=pi
ExecStart=/home/pi/rathole /home/pi/client.toml
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

Habilita y arranca:

sudo systemctl enable rathole
sudo systemctl start rathole

(El proyecto también incluye ejemplos de unidades systemd en examples/systemd en el repositorio, útiles para comparar si quieres opciones adicionales como LimitNOFILE.)

Acceder a http://TU_IP_VPS:8080 ahora enruta a través del túnel cifrado Noise hasta la Pi.

Consideraciones de seguridad para proxies edge

Al reemplazar herramientas comerciales por binarios auto-hospedados, asumes la responsabilidad que antes gestionaban ellos. Con las correcciones anteriores, esta lista debe ser más específica que “mantente actualizado”:

• No asumas cifrado si no lo has configurado. Bore y rathole, por defecto, envían tráfico en texto plano. Si reenvías SSH, ese protocolo interno sigue cifrado — pero si envías un panel de administración HTTP sin cifrar o un puerto de base de datos sin cifrado, cualquiera en el camino puede leerlo. Chisel es el único de los tres que encripta por defecto.
• Nunca expongas servicios sin autenticación. Si tu app local no tiene login, no pongas en un puerto público sin protección. Los bots detectan puertos abiertos en minutos.
• Pon un reverse proxy real delante del puerto expuesto. Ejecuta Nginx o Caddy en tu VPS, termina TLS con Let’s Encrypt en 443, y proxya internamente a bore/rathole/chisel en lugar de exponer sus puertos directamente (el --tls-domain de chisel puede sustituir esto si no quieres una capa proxy adicional).
• Fija huellas digitales donde la herramienta lo soporte. La bandera --fingerprint de chisel marca la diferencia entre “encriptado” y “encriptado y verificado” — saltársela te deja vulnerable a MITM en la primera conexión.
• Mantente actualizado. Rust y Go eliminan clases enteras de bugs de memoria, pero bugs lógicos en el código de túneles (bypass de autenticación, confusión en rangos de puertos) aún ocurren. Revisa las páginas de lanzamientos — chisel, por ejemplo, tiene su 35a0a versión etiquetada en v1.11.5.

Conclusión

El panorama de infraestructura atraviesa un renacimiento minimalista, y las tres herramientas anteriores son opciones realmente buenas — bore para túneles desechables, rathole para infraestructura persistente en laboratorios caseros, chisel para entornos con firewalls hostiles. Pero “auto-hospedado” y “seguro por defecto” no son la misma afirmación, y dos de estas tres herramientas vienen con cifrado desactivado a menos que lo actives. No es una crítica — es el compromiso de un binario de 400 líneas sin adornos — pero es un detalle importante que saber antes de apuntar una a algo que realmente importe.

---

Registro de cambios

Correcciones y adiciones al borrador original, verificadas contra fuentes oficiales (repositorios GitHub, READMEs y páginas de lanzamientos) hasta agosto de 2026:

1. Corregido el reclamo de cifrado de bore por omisión. El borrador original no mencionaba que bore no cifra por defecto; se añadió una corrección explícita citando la sección de Autenticación de bore, que indica que --secret solo cubre el apretón de manos (“no se encripta más tráfico por defecto”). Fuente: github.com/ekzhang/bore.
2. Corregido el reclamo de seguridad en rathole. El borrador decía que el tráfico está “cifrado de extremo a extremo automáticamente” tras configurar un token compartido. Esto confunde el token (autenticación del servicio) con el transporte Noise (encriptación), que debe configurarse explícitamente en [transport] y está apagado por defecto. Se actualizaron ejemplos y tutoriales para activar Noise correctamente. Fuente: rathole-org/rathole README y docs/transport.md.
3. Actualizado el repositorio principal de rathole. El proyecto se movió de rapiz1/rathole a rathole-org/rathole; se actualizó el enlace y se mencionó el redireccionamiento.
4. Se añadieron estadísticas verificadas actuales. Estrellas/forks y licencia de los tres proyectos: bore (11.4k estrellas, 514 forks, MIT), rathole (~14k estrellas, 809 forks, Apache-2.0), chisel (16.1k estrellas, 1.6k forks, MIT, v1.11.5). Fuentes: páginas oficiales en GitHub.
5. Se añadió el modelo de seguridad real de chisel. Se aclaró que chisel es la única herramienta de las tres que cifra por defecto (con clave ECDSA en memoria o en archivo vía crypto/ssh), y se añadió el uso de --fingerprint para evitar MITM y --tls-domain para certificados automáticos. Fuentes: jpillora/chisel README, secciones Seguridad y Uso.
6. Se añadieron soporte UDP y recarga dinámica en rathole, y soporte UDP en chisel (desde v1.7). Ninguno mencionado en el borrador original.
7. Corrección en la línea ExecStart en el tutorial Raspberry Pi. La versión original usaba --client /home/pi/client.toml; dado que el archivo solo tiene un bloque [client], rathole detecta automáticamente el modo y la bandera no es necesaria (solo si ambos bloques están en un solo archivo).
8. Se añadió detalles de control y flags en bore: puerto control 7835, flags --local-host, --min-port/--max-port.
9. Se reescribió la sección de Consideraciones de Seguridad para reflejar los hallazgos corregidos, incluyendo una tabla comparativa del estado de cifrado por defecto en las tres herramientas.
10. Se eliminó frontmatter/metadata, entregando solo contenido limpio en Markdown.