SSH y RDP a servidores de clientes: paso a paso para MSP
Un proveedor de servicios gestionados puede administrar servidores por SSH y RDP sin abrir puertos entrantes en los cortafuegos de sus clientes. Mediante túneles WireGuard de prialo, un router Linux publica la red local del cliente como ruta de subred tras la aprobación manual del administrador y la autorización explícita de cada dispositivo del técnico.
El problema de exponer SSH y RDP en cortafuegos perimetrales
Abrir los puertos TCP 22 para SSH o TCP 3389 para RDP en el cortafuegos de un cliente expone los servicios a ataques de fuerza bruta continuos en Internet. El reenvío de puertos exige mantener direcciones IP públicas estáticas y reglas de NAT independientes por cada máquina gestionada, una carga operativa insostenible cuando un MSP atiende decenas de sedes remotas.
Las redes tradicionales suelen concentrar todo el tráfico en concentradores centrales, lo que introduce latencia e incrementa la superficie de ataque si las credenciales de un túnel se ven comprometidas. Entender las diferencias frente a una red en malla privada frente a VPN tradicional permite adoptar arquitecturas donde los paquetes viajan punto a punto directamente entre dispositivos.
Arquitectura de red de prialo para acceso remoto punto a punto
Cada nodo en prialo genera su propio par de claves WireGuard y recibe una dirección IP fija dentro del rango 100.64.0.0/10 definido por la norma RFC 6598. Este espacio reservado previene cualquier conflicto de enrutamiento con redes privadas que utilicen direccionamiento 192.168.x.x o 10.x.x.x, facilitando la convivencia con las subredes preexistentes de cada cliente corporativo.
La negociación directa de conexiones se realiza mediante STUN en el puerto UDP 3478 del plano de control con técnicas de perforación de NAT. Si la topología de red presenta CGNAT de operador o cortafuegos simétricos que impiden el enlace directo, el tráfico fluye cifrado por un servidor de retransmisión en TCP 4430 que reenvía tramas sin descifrar su contenido.
El plano de control de prialo funciona con gRPC sobre TCP 50051 y protege las comunicaciones mediante TLS fijado por huella SPKI con formato sha256:... El software cliente rechaza de forma estricta cualquier servidor que no presente la clave fijada, prescindiendo por completo de autoridades de certificación públicas en su modelo de seguridad.
4 pasos para configurar rutas de subred y aprobación de dispositivos
Para acceder a todos los equipos de la LAN de un cliente sin instalar software en cada uno de ellos, el MSP despliega un único nodo pasarela en Linux dentro de esa oficina:
- Instalación del nodo pasarela: el técnico ejecuta el comando de alta con una clave de enrolamiento y la huella criptográfica fijada para unir la máquina Linux a la malla del MSP.
- Anuncio de la subred local: la máquina Linux de la oficina publica el rango de red interna hacia el plano de control mediante el parámetro de rutas anunciado.
- Aprobación manual por el administrador: un responsable del MSP valida explícitamente en el plano de control que ese nodo tiene autorización para encaminar el tráfico de esa subred.
- Aceptación explícita en el cliente del técnico: el ordenador del técnico solicita incorporar las rutas aprobadas de la malla para enviar tráfico RDP o SSH hacia las direcciones IP privadas del cliente.
sudo PRIALO_AUTH_KEY='<enrolment key>' prialo install --server=control.example.com:50051 --relay=control.example.com:4430 --tls-pin=sha256:<fingerprint>
prialo up --advertise-routes=192.168.50.0/24
prialo node routes <router> --approve 192.168.50.0/24Tras completar estos comandos, el comando prialo status confirma el estado 'Control: tls, pinned' y la dirección IP asignada en 100.64.0.0/10. Ninguna subred se enruta por defecto. Únicamente los sistemas Linux pueden actuar como encaminadores de subred en prialo, y las aplicaciones para teléfonos o Windows aún no procesan rutas de subred recibidas.
Comparativa de alternativas de conectividad para proveedores de servicios
Los proveedores de soporte evalúan diferentes herramientas de red en malla según el nivel de control sobre los datos, la gestión de claves y la arquitectura de los servidores centrales:
| Herramienta | Protocolo de datos | Servidor de coordinación | Retransmisión de tráfico |
|---|---|---|---|
| prialo | WireGuard | Autohospedado o gestionado | Relay TCP 4430 cifrado |
| Tailscale | WireGuard | Operado por Tailscale Inc. | Servidores DERP propios |
| Headscale | WireGuard | Autohospedado de código abierto | Servidores DERP compatibles |
| NetBird | WireGuard | Hospedado o autohospedado | Servidores de retransmisión propios |
| ZeroTier | Protocolo propio (no WireGuard) | Controladores propios o alojados | Nodos raíz y lunas |
Gobierno de datos y despliegue autohospedado para MSP
El software prialo está desarrollado por Sinergia, una empresa radicada en Barcelona sujeta a la normativa mercantil y fiscal española. El paquete autohospedado, disponible en el servidor autohospedado para Linux, se compone de tres contenedores orquestados con Docker Compose: servidor de coordinación con gRPC y STUN, nodo de retransmisión y base de datos PostgreSQL.
Este despliegue precisa únicamente 2 vCPU y 2 GB de RAM en sistemas Linux x86_64 o arm64 con Docker Engine 24 o superior y Compose v2 para gestionar cientos de nodos. La API administrativa en el puerto 8080 nunca se expone a Internet público y se accede exclusivamente a través de un túnel SSH. Todo el registro de auditoría, las identidades de dispositivos y las políticas permanecen en los servidores del propio MSP.
En el marco regulatorio europeo, normativas como la Directiva NIS2 (Directiva UE 2022/2555), el RGPD (Reglamento UE 2016/679) y el Esquema Nacional de Seguridad español (Real Decreto 311/2022) exigen un control estricto sobre los accesos y registros técnicos. Aunque prialo no cuenta con certificaciones bajo estas normas, su arquitectura autohospedada garantiza que las claves y metadatos no salgan del control del cliente.
A fecha de 17 de octubre de 2026, el paquete autohospedado y el cliente de línea de comandos funcionan plenamente en Linux y macOS, existiendo una versión temprana de Windows sin instalador ni firma digital. Las aplicaciones para Mac y iPhone se encuentran en proceso de revisión en Apple, mientras que la versión para Android continúa en preparación técnica.
Preguntas frecuentes
¿Qué impacto tiene el tráfico de SSH y RDP sobre los servidores relay de prialo?
El reenvío de una trama en el relay de prialo requiere unos 23 ns sin importar el número de clientes. Una sesión SSH consume menos de 1 MB por hora, mientras que el escritorio remoto RDP consume entre 0,5 y 1 GB por hora de tráfico retransmitido.
¿Qué sucede si una malla supera la cuota de datos en el relay?
La variable PRIALO_MESH_QUOTA_BYTES limita los datos salientes mensuales del relay. Al sobrepasar el límite, el servidor de retransmisión de prialo descarta y contabiliza las tramas excedentes de esa malla sin desconectar los dispositivos que mantengan conexión directa punto a punto.
¿Cómo se gestiona el acceso a equipos de clientes desde un teléfono móvil?
Los teléfonos móviles aún no aceptan rutas de subred en la versión actual de prialo. Para conexiones SSH directas desde dispositivos iOS hacia nodos con cliente prialo instalado, puede emplearse Termi1, una aplicación cliente para iPhone y iPad.
¿Cuánto cuesta el servicio gestionado de prialo para un equipo de soporte técnico?
El plan Teams de prialo cuesta 5 EUR al mes por persona más IVA mediante facturación de Cifrago. Incluye miembros y dispositivos ilimitados, aprobación manual de equipos, reglas de acceso, 100 GB mensuales de tráfico relay por persona y soporte por correo en 2 días laborables.
¿Prefieres tu propio servidor? Guía del paquete autoalojado de prialo