Documentación
Inicio rápido + descripción de cada función y de cada dispositivo (en constante actualización)
Penetración de puertos
Este artículo presenta la función «Penetración de puertos» del panel: mapear el puerto de una aplicación en un servidor en túnel sin IP pública al puerto público del servidor del panel, para que los usuarios externos puedan acceder.
En una frase
Tu servidor está escondido en la red interna (sin IP pública) y en él corre un sitio web o una aplicación a la que nadie de fuera puede acceder. La penetración de puertos consiste en «abrir un puerto público en el servidor del panel y transportar el acceso externo, mediante un túnel cifrado, hasta el puerto de la aplicación de tu servidor interno». Resultado: quien accede desde fuera a IP del servidor del panel:puerto accede a la aplicación de tu servidor interno.
Descripción de la función
En los servidores sin IP pública conectados mediante «Operación mediante túnel», las aplicaciones que corren en ellos (como Navidrome de música, Nextcloud de almacenamiento en nube, Memos de notas) no son accesibles desde el exterior. La penetración de puertos mapea esos puertos de aplicación a puertos del servidor del panel (que tiene IP pública), para que los usuarios externos accedan mediante «IP del servidor del panel:puerto».
Casos de uso
- En el servidor en túnel corre una aplicación web y quieres que sea accesible desde fuera
- Exponer a la red pública los servicios de un dispositivo de red interna
- Dar una entrada pública al sitio web, la API o el panel de un dispositivo sin IP pública
Principio (cómo fluyen los datos)
Usuario externo → Puerto público del servidor del panel (p. ej. :9117) → Túnel cifrado → Puerto de la aplicación del servidor en túnel (p. ej. :9117)
El tráfico externo llega primero al servidor del panel (el único con IP pública), y desde allí, mediante un túnel inverso cifrado, se envía al dispositivo interno y acaba en el puerto de la aplicación que realmente corre en el dispositivo.
Canal unificado (todos los dispositivos, sin selección manual):
| Tipo de dispositivo | Canal de reenvío | Descripción |
|---|---|---|
| Servidor Linux (sin IP pública) | Túnel inverso 4433 (cifrado AES-256-GCM) | Flujo de bytes TCP nativo, rápido y estable, admite mucha concurrencia |
| Dispositivo Android/Termux | Túnel inverso 4433 (cifrado AES-256-GCM) | Usa el mismo túnel cifrado que los dispositivos Linux, estable y sin sobrecarga adicional |
El panel usa de forma unificada el túnel inverso 4433; al crear una penetración no hay que preocuparse por el canal subyacente ni elegirlo manualmente.
> Nota adicional: la Gestión del sistema (ejecución de comandos, terminal, archivos) de los dispositivos Android/Termux va por el canal estable de SocketIO; sin embargo, la Penetración de puertos usa de forma unificada el túnel inverso 4433. Cada uno cumple su función sin interferirse.
Cómo se usa
1. Asegúrate de que el dispositivo de destino ya está conectado mediante «Operación mediante túnel» (Agent en línea)
2. Abre «Penetración de puertos» y pulsa «Añadir penetración»
3. Elige el servidor en túnel (Agent) y rellena:
- Puerto de escucha: el puerto público del servidor del panel (para el acceso externo), por ejemplo
9117 - Puerto de destino: el puerto de la aplicación en el servidor en túnel, por ejemplo
8080
4. Una vez creado, el exterior ya puede acceder a http://IP del servidor del panel:puerto de escucha
Ejemplo
Supongamos que la IP pública del servidor del panel es 203.0.113.10 y tienes una Raspberry Pi interna con Navidrome (escuchando en 4533):
- Puerto de escucha:
4533 - Puerto de destino:
4533 - Una vez creado, los usuarios externos pueden abrir Navidrome en la Raspberry Pi accediendo a
http://203.0.113.10:4533
Límites de recursos
| Límite | Valor |
|---|---|
| Canales de reenvío máximos por Agent | 32 |
| Agents máximos en todo el panel | 64 |
Al superarse se rechazan automáticamente las conexiones nuevas, sin afectar a las penetraciones en funcionamiento.
Advertencias
1. Cortafuegos de la nube: el cortafuegos de la nube / grupo de seguridad del servidor del panel debe permitir el puerto de escucha correspondiente; de lo contrario, el exterior no podrá acceder.
2. Versión del Agent: reenviar puertos que no son SSH (distintos de 22) requiere que el servidor en túnel tenga instalada una versión nueva del Agent (las versiones antiguas solo permiten reenviar el puerto 22). Si necesitas reenviar otros puertos, reinstala el Agent.
3. Agent en línea: la penetración depende de que el Agent esté en línea. Si el Agent se desconecta, la penetración se interrumpe y se restaura automáticamente al reconectarse.
4. Restauración automática al reiniciar el panel: tras reiniciar el servicio del panel, las penetraciones se restauran automáticamente (se activan cuando el Agent se reconecta).
5. El servicio de destino en Android debe admitir concurrencia: si el servicio de destino penetrado en Android (como python3 -m http.server) es de un solo hilo y tiene keep-alive activado, una conexión sin cerrar bloqueará las peticiones posteriores. Se recomienda que el servicio de destino use varios hilos o que garantice el cierre puntual de las conexiones.
Documentación relacionada
- Operación mediante túnel — conecta primero el dispositivo sin IP pública al panel
- Reenvío de puertos — reenvío de puertos tradicional en servidores con IP pública (la diferencia entre ambos se explica más abajo)
Penetración de puertos vs Reenvío de puertos (cómo elegir)
| Penetración de puertos (este artículo) | Reenvío de puertos | |
|---|---|---|
| Servidores aplicables | Sin IP pública (servidores en túnel) | Con IP pública propia |
| Implementación | Túnel inverso | DNAT del cortafuegos del sistema |
| Ubicación del reenvío | Servidor del panel | La propia máquina de destino |
| Requiere Agent | Sí | No |
En una frase: sin IP pública usa penetración, con IP pública usa reenvío.