El borde minimalista: micro-proxies en Rust y Go

En el panorama en rápida evolución del edge computing, los laboratorios caseros y el desarrollo de Internet de las Cosas (IoT), exponer servicios locales a Internet de forma segura ha sido siempre un desafío central. Durante años, los desarrolladores han confiado en servicios comerciales y centralizados para abrir agujeros en firewalls NAT. Sin embargo, a medida que el ecosistema madura en 2026, surge una tendencia de nicho pero increíblemente apasionada: los desarrolladores están reemplazando servicios proxy comerciales pesados por herramientas ultra-minimalistas escritas en Rust y Go.

Estos micro-proxies no pretenden ser plataformas empresariales. Son intencionadamente pequeños, increíblemente rápidos y completamente de código abierto. Para los aficionados a IoT y arquitectos de redes en el borde que ejecutan aplicaciones en dispositivos con poca memoria, encontrar una alternativa ligera a ngrok se ha convertido en una necesidad más que un lujo.

Este artículo explora el auge de estas herramientas de red especializadas, profundizando en sus arquitecturas y aplicaciones prácticas como Bore, Rathole y Chisel. Analizaremos por qué los desarrolladores están haciendo el cambio, cómo configurar un túnel localhost en Raspberry Pi robusto y, finalmente, resolveremos la comparación de bore vs rathole para tu próximo proyecto embebido.

---

La sobrecarga de los túneles modernos

Antes de sumergirnos en las alternativas minimalistas, es importante entender qué impulsó este cambio. Exponer un servidor de desarrollo local, un panel de control de asistente doméstico o un sensor IoT remoto requiere sortear NAT y firewalls estrictos.

Históricamente, esto se lograba mediante reenvío de puertos SSH inverso complejo (ssh -R). Aunque efectivo, era propenso a caídas de conexión y requería un VPS dedicado con modificaciones específicas en sshd_config. Luego llegó la era de los proveedores de túneles SaaS. Estos servicios ofrecían una experiencia mágica para desarrolladores: un solo comando que proporcionaba instantáneamente una URL pública y segura HTTPS apuntando a una máquina local.

Sin embargo, a medida que estas plataformas crecieron, se transformaron de simples herramientas para desarrolladores en redes masivas de entrega en el borde. Esta evolución trajo funciones empresariales—capas de autenticación, inspección de tráfico, balanceo de carga y WAFs—pero también introdujo fricciones:

1. Sobrecarga de recursos: Los daemons cliente para plataformas de borde completas pueden ser intensivos en recursos. Aunque insignificante en un MacBook M3, esta sobrecarga se nota en un Raspberry Pi Zero o en un dispositivo Linux embebido con recursos limitados.
2. Límites de ancho de banda y conexión: Las capas gratuitas en plataformas comerciales se han vuelto cada vez más restrictivas, limitando ancho de banda, número de túneles activos o rotando dominios aleatoriamente, lo que rompe flujos de trabajo automatizados.
3. Ecosistemas cerrados: Muchos clientes de túneles modernos son de código cerrado. Para quienes gestionan infraestructura personal en laboratorios caseros (como cámaras de seguridad o datos NAS privados), ejecutar daemons de red cerrados es un impedimento.

La respuesta a estas limitaciones ha sido un renacimiento de micro-proxies de código abierto. Construidos con lenguajes modernos a nivel de sistemas como Rust y Go, estas herramientas ofrecen implementaciones en binario único, ejecución segura en memoria y prácticamente sin dependencias en tiempo de ejecución.

---

Chisel: La navaja suiza de los proxies en Go

Al hablar de herramientas modernas de red, Go (Golang) suele ser el primer lenguaje que viene a la mente, debido a su excepcional modelo de concurrencia y su robusta biblioteca estándar. En el ámbito de túneles minimalistas, el proxy inverso chisel es la navaja suiza definitiva.

¿Qué es Chisel?

Chisel es un túnel TCP/UDP rápido transportado sobre HTTP y asegurado mediante SSH. Creado por Jaime Pillora y lanzado bajo la licencia MIT, está escrito completamente en Go y combina cliente y servidor en un solo ejecutable. A mediados de 2026, el proyecto cuenta con aproximadamente 16,500 estrellas en GitHub y 1,600 forks, con la última versión (v1.11.8) compilada con Go 1.27.0 — evidencia de que sigue siendo un proyecto activamente mantenido y no un hackeo de fin de semana estancado.

Cómo funciona realmente Chisel

El “encuadre sobre HTTP” es un poco más específico de lo que parece: Chisel abre una única conexión WebSocket sobre una solicitud HTTP(S) y luego multiplexa una sesión autenticada por SSH — con sus propios canales cifrados — a través de esa única conexión. Debido a que el apretón de manos inicial parece una solicitud HTTP ordinaria con una cabecera Upgrade, Chisel puede atravesar la mayoría de los proxies corporativos y CDNs. Se confirma que funciona detrás de Cloudflare (con WebSockets habilitados) y Heroku, por ejemplo. La limitación es que cualquier intermediario que elimine la cabecera Upgrade — algunos proxies corporativos estrictos lo hacen — bloqueará completamente a Chisel, por lo que no es una herramienta universal para evadir DPI en todos los entornos.

La encriptación es obligatoria, no opcional: al iniciarse, el servidor genera un par de claves ECDSA en memoria y muestra su huella digital. Los clientes pueden fijar esa huella con --fingerprint para detectar intentos de man-in-the-middle, que es la forma recomendada de ejecutarlo fuera de una red de confianza.

Características clave, verificadas contra el README actual:

• Ejecutable único: No es necesario instalar paquetes separados de servidor y cliente.
• Transporte sobre HTTP (mediante actualización WebSocket): Funciona a través de la mayoría de firewalls y CDNs que soportan WebSockets; bloqueado por aquellos que eliminan la cabecera Upgrade.
• Proxy SOCKS5 integrado: El servidor puede actuar como un proxy SOCKS5 completamente funcional, permitiendo que un cliente enrute sesiones completas del navegador o tráfico del sistema a través del túnel.
• Reenvío de puertos inverso: El servidor puede exponer un puerto que mapea de vuelta al servicio local del cliente, habilitado con --reverse en el lado del servidor.
• Reconexión automática: El cliente se reconecta automáticamente usando retroceso exponencial.

Seguridad en 2026: Incluso las herramientas minimalistas necesitan parches

Ser de código abierto no hace que una herramienta sea inmune a errores, y Chisel tuvo un año notable en ese frente. En 2026, se publicaron dos avisos de alta gravedad: una vulnerabilidad en ACL del authfile que permitía evadir la autenticación mediante inyección de ExtraData en un canal SSH posterior al apretón de manos (GHSA-24fp-5v3p-rvpw, mayo 2026), y una vulnerabilidad relacionada donde un cliente restringido y autenticado podía acceder a servicios TCP internos arbitrarios del servidor a través del canal SOCKS5 porque no se verificaba el acceso SOCKS5 contra el authfile (GHSA-397r-r4gr-x5pg, junio 2026).

La solución, aplicada desde la versión v1.11.7, implica un cambio que rompe compatibilidad y que conviene conocer antes de actualizar: ahora, el acceso SOCKS5 está controlado por un token socks en el archivo users.json. Si usas --socks5 junto con --authfile, cualquier usuario que deba mantener acceso SOCKS necesita una entrada explícita que coincida con socks (una entrada comodín "" aún funciona). La versión v1.11.8 (julio 2026) también actualizó la dependencia golang.org/x/crypto/ssh a v0.55.0, que la notas de la versión vinculan a la corrección de una vulnerabilidad en la librería SSH identificada como GO-2026-6303. Si aún usas una versión antigua de Chisel en producción, este es un buen momento para actualizar.

Caso de uso: El tester de penetración y el desarrollador en el borde

El proxy inverso chisel es muy popular en la comunidad de ciberseguridad — por la misma razón que es útil para laboratorios caseros: túneles silenciosos sobre puertos web comunes. Esa popularidad tiene sus ventajas y desventajas. Chisel aparece en catálogos de “vivir de los túneles” usados por atacantes para pivotar en redes, y sus binarios en Windows son periódicamente marcados por Microsoft Defender como un troyano genérico — no porque el código sea malicioso, sino porque la simplicidad de un solo binario lo hace atractivo como herramienta de pivoting para intrusos. Si eres defensor, vale la pena conocer la firma de tráfico de Chisel (apretón WebSocket a un host desconocido en ⁸⁰⁄₄₄₃, seguido de conexiones de larga duración) tanto como conocerlo como herramienta de construcción.

Para el desarrollador en el borde, Chisel es muy adecuado para gestión remota. Si despliegas una flota de máquinas expendedoras inteligentes, puedes correr un cliente Chisel en cada una. Ellas se comunican con tu servidor central vía HTTP, proporcionándote acceso remoto, encriptado y por SSH inverso, a cada unidad sin exponer puertos en las máquinas.

Iniciar un servidor Chisel en tu VPS:

chisel server -p 8080 --reverse

Conectando desde tu dispositivo en el borde local:

chisel client vps-ip:8080 R:80:localhost:3000

Este mapea el puerto 80 en tu VPS al puerto 3000 en tu dispositivo local en el borde (la sintaxis R: y remote-port:local-host:local-port son la sintaxis real de Chisel para reversa-remota).

---

Los pesos pesados en Rust: Bore vs. Rathole

Mientras Go maneja la concurrencia de manera excelente, Rust ofrece un control sin igual sobre el uso de memoria y CPU. Para el menor uso de recursos posible, los desarrolladores recurren a túneles basados en Rust. En el ecosistema Rust, dos herramientas dominan la conversación: Bore y Rathole.

Elegir entre ambas suele reducirse a un debate de simplicidad versus potencia. Desglosemos la comparación bore vs rathole.

Bore: La máxima expresión de simplicidad

Bore, creado por Eric Zhang y lanzado bajo la licencia MIT, está diseñado para hacer una cosa y hacerlo perfectamente: exponer un puerto TCP local a Internet. Actualmente en la versión 0.6.0, y fiel a su filosofía, toda la herramienta tiene unas 400 líneas de Rust asíncrono construidas sobre Tokio.

La filosofía: Bore opera con una filosofía de cero fricciones. No te pide escribir archivos de configuración, configurar reglas de enrutamiento complejas ni gestionar certificados. Está pensado para ser un reemplazo instantáneo para la funcionalidad básica de servicios de túneles comerciales.

Características clave de Bore: * CLI sin configuración: Puedes comenzar a tunelizar inmediatamente con argumentos de línea de comandos intuitivos. * TCP en bruto: Maneja tráfico TCP en bruto, siendo protocol-agnóstico. Ya sea túnel HTTP, SSH, MySQL o tráfico de servidores Minecraft, Bore lo maneja de forma transparente. * Servidor comunitario público: Por defecto, si solo quieres probar un webhook, puedes apuntar al servidor comunitario del mantenedor en bore.pub sin necesidad de tu propio VPS. (Las versiones antiguas a veces mencionan bore.digital, que ya no es el servidor comunitario actual; bore.pub es el oficial según la documentación.)

Una advertencia de seguridad importante: La opción --secret de Bore solo autentica el apretón de manos inicial mediante desafío-respuesta HMAC — no cifra el tráfico tunelizado en sí. A menos que el servicio que expones ya soporte TLS (HTTPS, por ejemplo), los bytes que fluyen a través de un servidor Bore autoalojado están en texto plano en la red. Para datos sensibles, coloca Bore detrás de un proxy inverso que termine TLS, o ejecútalo sobre un transporte ya cifrado como un enlace WireGuard. Esto es un compromiso genuino por su simplicidad, no un descuido — pero implica una postura de seguridad diferente a Chisel o Rathole, que cifran el túnel por defecto.

Al igual que Chisel, el minimalismo de Bore tiene un lado negativo: se ha catalogado como herramienta abusada para pivotes de evasión de firewalls en la seguridad ofensiva, precisamente porque un binario pequeño y legítimo es fácil de desplegar en un host comprometido.

Cuándo usar Bore: Si estás desarrollando una aplicación web local y necesitas una URL de webhook para Stripe o GitHub, Bore será tu mejor amigo. Requiere cero carga mental.

Iniciar un servidor Bore autoalojado:

bore server

Exponer un puerto local usando tu servidor autoalojado:

bore local 8000 --to myserver.com

Rathole: El caballo de batalla seguro y de alto rendimiento

Si Bore es un scooter, Rathole es un coche deportivo de alta gama. Rathole es un proxy inverso ligero y de alto rendimiento para la traversía NAT, posicionado explícitamente como alternativa a herramientas como frp y ngrok. Fue originalmente creado por Yujia Qiao (rapiz1); el proyecto se ha trasladado a la organización comunitaria rathole-org en GitHub, donde sigue activamente mantenido — con alrededor de 14,000 estrellas y commits recientes — y con licencia Apache-2.0.

La filosofía: Rathole está construido para permanencia y seguridad. Está diseñado para configurarse una vez mediante un archivo y dejarse en ejecución indefinidamente en dispositivos en el borde, routers y sistemas NAS.

Características clave de Rathole: * Cifrado con Noise Protocol: Rathole integra el marco Noise Protocol como alternativa a TLS. Su patrón de apretón de manos por defecto es Noise_NK_25519_ChaChaPoly_BLAKE2s, que autentica el servidor al cliente usando un par de claves estáticas — conceptualmente similar a la fijación de claves de host SSH — sin la sobrecarga de emitir y gestionar certificados X.509. (Un borrador anterior de este texto citaba el patrón NN, que proporciona cifrado pero sin autenticación del servidor y vulnerable a MITM; NK es lo que Rathole realmente envía por defecto.) * Autenticación basada en tokens: Los servicios están estrictamente autenticados. El servidor dicta qué servicios están permitidos, y los clientes deben autenticarse con tokens por servicio. * Mayor rendimiento que frp: Los propios benchmarks del proyecto muestran un rendimiento significativamente mayor y mejor estabilidad bajo carga que frp, una alternativa popular basada en Go. * Huella pequeña: Una compilación mínima de Rathole sin funciones innecesarias puede reducirse a aproximadamente 500 KB; un binario de versión completa (con TLS, Noise y transporte WebSocket compilados) ocupa unos pocos megabytes. En cualquier caso, es una fracción de la huella de una alternativa basada en JVM, y cabe cómodamente en routers embebidos como dispositivos OpenWrt. * Transporte WebSocket: Una adición más reciente permite que Rathole túnel sobre WebSockets además de TCP/TLS/Noise en crudo, ayudándolo a atravesar los mismos proxies restrictivos que dan ventaja a Chisel.

El veredicto: bore vs rathole La decisión bore vs rathole es sencilla. Si necesitas un túnel temporal, sin fricciones y con cifrado opcional para desarrollo local o pruebas rápidas, usa Bore. Su CLI es intuitiva y no te molesta.

Si estás configurando infraestructura permanente — como exponer de forma segura una instancia de Nextcloud autoalojada, gestionar nodos IoT remotos o reemplazar una VPN a tiempo completo — opta por Rathole. El archivo de configuración requiere unos minutos de configuración inicial (incluyendo generar un par de claves Noise), pero el rendimiento, la estabilidad y la autenticación criptográfica que ofrece por defecto lo convierten en la opción más sólida para entornos de producción.

---

Implementando un túnel localhost en Raspberry Pi

Para contextualizar el poder de estos micro-proxies, veamos un escenario muy práctico: configurar un túnel localhost en Raspberry Pi.

Millones de desarrolladores usan Raspberry Pi como servidores domésticos. Ejecutan automatización del hogar (Home Assistant), bloqueadores de anuncios en toda la red (Pi-hole) y servidores multimedia privados. Sin embargo, acceder a estos servicios cuando estás fuera de tu Wi-Fi doméstico es notoriamente difícil porque los ISPs domésticos cambian tu IP (IP dinámica) y te colocan detrás de routers NAT estrictos.

En lugar de abrir puertos en tu router (lo que expone toda tu red a escáneres automáticos de Internet), puedes usar un micro-proxy para crear una conexión segura y saliente desde tu Pi a un VPS en la nube barato de $5/mes.

La configuración: usando Rathole para un túnel permanente en Pi

Para una configuración de laboratorio en casa, Rathole es la opción ideal. Así es como diseñas esta solución, usando la sintaxis real de configuración de transporte Noise de Rathole (que requiere un par de claves generadas, a diferencia de la configuración de marcador de posición en borradores anteriores).

1. Generar un par de claves en el VPS

./rathole --genkey
# Clave privada: cQ/vwIqNPJZmuM/OikglzBo/+jlYGrOt9i0k5h5vn1Q=
# Clave pública:  GQYTKSbWLBUSZiGfdWPSgek9yoOuaiwGD/GIX8Z1kkE=

Mantén la clave privada en el VPS; pegarás la clave pública en la configuración del Pi en el paso 3.

2. El VPS en la nube (la puerta de enlace pública)

Alquilas un servidor virtual privado pequeño y económico (por ejemplo, DigitalOcean, Linode o Hetzner) con una IP pública estática, e instalas el binario Rathole allí.

Crea server.toml:

[server]
bind_addr = "0.0.0.0:2333" # Puerto donde Rathole escucha para el Pi

[server.transport]
type = "noise"

[server.transport.noise]
local_private_key = "cQ/vwIqNPJZmuM/OikglzBo/+jlYGrOt9i0k5h5vn1Q=" # del --genkey anterior

[server.services.home_assistant]
token = "super_secure_random_string"
bind_addr = "0.0.0.0:8123" # El puerto público al que accederás vía web

Ejecuta el servidor: ./rathole --server server.toml

3. La Raspberry Pi (el dispositivo en el borde)

En tu laboratorio en casa, descargas el binario Rathole en tu Raspberry Pi. La Pi se conectará al VPS y establecerá una conexión cifrada y autenticada.

Crea client.toml:

[client]
remote_addr = "TU_IP_VPS:2333"

[client.transport]
type = "noise"

[client.transport.noise]
remote_public_key = "GQYTKSbWLBUSZiGfdWPSgek9yoOuaiwGD/GIX8Z1kkE=" # la clave pública impresa en el paso 1

[client.services.home_assistant]
token = "super_secure_random_string" # Debe coincidir con el token del servidor
local_addr = "127.0.0.1:8123" # El puerto en el que corre Home Assistant localmente

Ejecuta el cliente: ./rathole --client client.toml

El resultado: Tu Raspberry Pi ha creado con éxito un túnel cifrado, autenticado y seguro desde tu sala de estar hasta la nube. Ahora puedes acceder a tu panel de Home Assistant desde cualquier parte del mundo navegando a http://TU_IP_VPS:8123.

Lo más importante, porque esto es una alternativa ligera a ngrok, el daemon Rathole en tu Pi consume solo unos pocos megabytes de RAM y casi 0% de CPU en reposo. Los recursos de tu Pi se reservan para ejecutar aplicaciones reales, no para sobrecarga de red. Además, dado que esta conexión se origina desde la Pi hacia el VPS, el firewall de tu router doméstico nunca tiene una regla entrante que preocuparse, manteniendo tu red segura contra ataques no solicitados.

---

Implicaciones más amplias para IoT y redes en el borde

El cambio hacia estos micro-proxies representa una tendencia más amplia en ingeniería de software: un regreso a la filosofía Unix. En lugar de herramientas monolíticas que intentan gestionar todo, desde túneles hasta verificación de identidad, los desarrolladores prefieren utilidades modulares y de alto rendimiento que hacen exactamente una cosa.

En los sectores de IoT y borde industrial, esto tiene un impacto especialmente importante. Imagina una red de miles de sensores ambientales alimentados por energía solar desplegados en un bosque. Estos dispositivos funcionan con microcontroladores diminutos o placas Linux reducidas. Tienen conectividad 4G/LTE intermitente, restricciones estrictas de energía y cero capacidad de enrutamiento de red entrante.

Desplegar un agente de túnel comercial en estos dispositivos suele ser poco práctico, dada la limitación en tamaño binario y la sobrecarga de memoria. Un binario Rust compilado de forma estática, como Rathole — mucho menor a unos pocos megabytes, y más cercano a 500 KB en una compilación mínima — puede integrarse directamente en el firmware del dispositivo. Cuando un ingeniero necesita extraer datos de diagnóstico, el dispositivo puede crear temporalmente un túnel cifrado Noise, transmitir los datos y cerrar el túnel para conservar batería.

Postura de seguridad en el borde

Uno de los aspectos más críticos al usar estas herramientas de código abierto es el control que se le da al usuario respecto a la seguridad. Con proxies de código cerrado, debes confiar implícitamente en que el proveedor no registra tu tráfico en texto plano (especialmente si la terminación SSL sucede en sus servidores).

Al alojar tú mismo un alternativa ligera a ngrok usando herramientas como Chisel o Rathole, controlas ambos extremos del canal. Pero “código abierto” y “autoalojado” no son sinónimos de “seguro automáticamente” — los avisos de vulnerabilidades en los archivos authfile y las configuraciones de SOCKS5 en 2026 son un recordatorio útil de que estas herramientas llevan las mismas responsabilidades de parcheo que cualquier otro servicio expuesto en red. La ventaja del software de código abierto y minimalista no es que sea invulnerable; es que las vulnerabilidades se divulgan, arreglan y actualizan en un código pequeño y auditable, en lugar de quedar en la opacidad de notas de versión de un proveedor.

En un mundo donde la privacidad de datos es primordial, eliminar al intermediario — incluso si es un SaaS benevolente — es una mejora real en seguridad, siempre que también mantengas el binario actualizado.

---

Conclusión: crea tu cinturón de herramientas minimalista

La era de depender de plataformas de túneles empresariales pesadas para simples reenvíos de puertos está llegando a su fin. La comunidad de desarrolladores ha impulsado una infraestructura eficiente, segura y completamente de código abierto, dando lugar a una edad dorada de herramientas de red.

Ya seas un desarrollador web que busca la simplicidad instantánea de Bore, un entusiasta de laboratorios caseros configurando un túnel localhost en Raspberry Pi con Rathole, o un investigador (o defensor) rastreando un proxy inverso chisel en una red, hay una herramienta diseñada específicamente para tus necesidades.

Rust y Go han demostrado ser los lenguajes perfectos para esta revolución en redes. Han permitido a los desarrolladores construir software que no solo es excepcionalmente rápido, sino también sorprendentemente ligero. A medida que el edge computing continúa desplazando el procesamiento desde centros de datos centralizados hacia nuestros hogares, vehículos y dispositivos embebidos, estos micro-proxies serán los hilos invisibles que conectan la web descentralizada.

Deja atrás la sobrecarga. Recobra tu RAM. Mantén los binarios actualizados. Abraza el borde minimalista.

---

Registro de cambios editorial

Este borrador fue verificado con el repositorio oficial de GitHub de cada proyecto, su README y (para Chisel) sus avisos de seguridad, y luego extendido con desarrollos verificados en 2026. Cambios respecto al borrador original:

Correcciones - El servidor comunitario de Bore es bore.pub, no bore.digital — corregido en todas las referencias. - El patrón Noise por defecto en Rathole es Noise_NK_25519_ChaChaPoly_BLAKE2s (autenticado por servidor), no Noise_NN_25519_ChaChaPoly_BLAKE2s (sin autenticación, vulnerable a MITM), como usaba el ejemplo de configuración anterior. - La configuración de Rathole en Raspberry Pi era incompleta: el transporte Noise requiere un par de claves generadas (local_private_key en el servidor, remote_public_key en el cliente, generado con rathole --genkey). Los ejemplos originales de client.toml/server.toml omitían esto y no funcionarían tal cual. Se reemplazaron por ejemplos funcionales y correctamente claveados. - El mecanismo de transporte de Chisel fue descrito como envolver tráfico SSH “dentro de solicitudes HTTP(S) estándar”; se corrigió para especificar que es una actualización WebSocket sobre HTTP(S), y se añadió la advertencia de que proxies que eliminen la cabecera Upgrade bloquean completamente a Chisel (no es una herramienta universal para evadir DPI). - Se suavizó la afirmación en la sección IoT/firmware, ajustando la capacidad de Rathole compilado en Rust para reflejar el tamaño real (~500 KB en mínimo, hasta unos pocos MB en versión completa), según la documentación del proyecto.

Adiciones (contenido nuevo, basado en fuentes) - Datos actuales del proyecto Chisel (autor Jaime Pillora, licencia MIT, ~16.5k estrellas, versión v1.11.8 en Go 1.27.0). - Avisos de seguridad de 2026 en Chisel (GHSA-24fp-5v3p-rvpw, mayo; GHSA-397r-r4gr-x5pg, junio), cubriendo vulnerabilidades en authfile y SOCKS5, cambio en la configuración de authfile, y actualización de x/crypto/ssh. - Clarificación en Bore: advertir que la opción --secret solo autentica el apretón inicial y no cifra el tráfico, diferencia importante respecto a Chisel y Rathole. - Ambos Bore y Chisel: mencionados como herramientas que aparecen en catálogos “living-off-the-land” y que pueden ser marcadas por software de seguridad. - Rathole: mención de su movimiento de rapiz1/rathole a la organización rathole-org, estrellas (~14k), licencia Apache-2.0, y soporte para transporte WebSocket. - Nueva sección en “Seguridad en el borde” aclarando que ser de código abierto no garantiza seguridad automática, sino que permite detectar y arreglar vulnerabilidades.

Verificado sin cambios necesarios - Ejemplos de CLI de Chisel (chisel server -p 8080 --reverse / chisel client vps-ip:8080 R:80:localhost:3000) y su efecto. - CLI de Bore y su implementación en Rust (~400 líneas, Tokio). - Valor principal de Rathole (mayor rendimiento que frp, bajo consumo, autenticación por token).