PC de casa sin abrir puertos: paso a paso con WireGuard
Para acceder a tu PC de casa sin abrir puertos hacen falta dos equipos que salgan a Internet y se encuentren a través de un punto de coordinación, y no uno que espere conexiones entrantes. Eso hace una red privada en malla con WireGuard: cada equipo recibe una dirección fija 100.64.x.x y se ven entre ellos estén donde estén.
Por qué abrir el puerto 22 o el 3389 en el router es un riesgo
Un puerto abierto en el router es un servicio a la escucha para cualquiera que escanee tu IP pública, y las IP residenciales se escanean de forma continua. SSH en el 22 recibe intentos de contraseña desde el primer minuto; el escritorio remoto de Windows en el 3389 ha sido durante años una de las puertas de entrada habituales del ransomware. Cambiar el número de puerto solo retrasa el escaneo. Además hace falta una IP pública fija o un DNS dinámico, y mantener al día el servicio expuesto, porque cualquier fallo en él es explotable desde fuera.
CGNAT: por qué redirigir puertos ni siquiera funciona en muchas fibras
Con CGNAT, tu operador comparte una sola IPv4 pública entre varios abonados y la dirección que ves en tu router está dentro de 100.64.0.0/10, el espacio compartido RFC 6598. Un paquete entrante dirigido a esa IP pública no sabe a qué abonado ir, así que la redirección de puertos que configures en tu router nunca recibe nada. La salida es invertir el sentido: que el PC de casa inicie él la conexión hacia fuera y la mantenga abierta. Es exactamente lo que hace un nodo de red en malla, y por eso funciona igual con IP fija, dinámica o CGNAT.
Abrir puertos, VPN en el router o red en malla: qué expone cada opción
| Opción | Qué queda expuesto a Internet | ¿Funciona tras CGNAT? | Qué mantienes tú |
|---|---|---|---|
| Redirigir el puerto 22 o 3389 | El propio servicio (SSH o RDP), a cualquier escáner | No | IP fija o DNS dinámico y los parches del servicio expuesto |
| Servidor WireGuard en el router | Un puerto UDP, sin credenciales que adivinar | No, sin IP pública propia | Las claves de cada cliente, el router y el DNS dinámico |
| Red en malla (prialo) | Ningún puerto entrante en casa | Sí, por STUN y relay | Nada en casa; el plano de control, si lo autoalojas |
Paso a paso: unir el PC de casa y el portátil a una red privada prialo
El recorrido completo son cinco pasos y ninguno toca el router. Hoy se hace con el paquete autoalojado y el cliente de línea de comandos en Linux o macOS; las apps de Mac e iPhone están en revisión de Apple y el cliente de Windows es una versión temprana, sin instalador ni firma. Si prefieres no montar servidor, el servicio alojado dará el mismo resultado en cuanto las apps estén disponibles.
- Plano de control: en un VPS Linux con Docker, descarga el paquete autoalojado de prialo, copia .env.example a .env con los tres secretos y arranca con docker compose up -d. Abre en el cortafuegos 50051/tcp, 4430/tcp y 3478/udp; nunca el 8080.
- Pin TLS: lee la huella del servidor con docker compose logs prialo-server | grep -oE 'sha256:[0-9a-f]{64}' | sort -u. Debe salir una sola; cópiala por un canal que ya sea tuyo, nunca por el enlace que quieres proteger.
- Clave de alta: crea una clave de un solo uso desde dentro del contenedor contra la API de administración (POST /api/v1/auth/preauth-keys con reusable:false). Una clave por equipo; las claves caducan y se pueden revocar.
- PC de casa: instala el nodo como servicio con el comando de abajo. prialo status debe decir «Control: tls, pinned» y mostrar una IP dentro de 100.64.0.0/10; prialo ip la imprime sola.
- Portátil o móvil: repite la instalación con otra clave de alta. Desde entonces ssh [email protected] (la IP que te dio prialo ip en el PC) funciona desde cualquier red, y un cliente SSH en el móvil llega por la misma dirección.
sudo PRIALO_AUTH_KEY='<clave de alta>' prialo install \
--server=control.ejemplo.es:50051 \
--relay=control.ejemplo.es:4430 \
--tls-pin=sha256:<huella>RDP, SSH y archivos por la red privada: qué cambia y qué no
Dentro de la malla, el PC de casa se usa igual que en la red local: ssh a su 100.64.x.x, escritorio remoto a 100.64.x.x:3389 o archivos por SMB, sin tocar la configuración de cada programa. Lo que cambia es que ninguno de esos servicios escucha ya en Internet: solo los equipos de tu red llegan a ellos, y cada uno se identifica con su clave WireGuard, no con una contraseña. Cuando los dos equipos consiguen hablarse en directo, la latencia es la del camino más corto; si el operador lo impide, el relay de tu servidor reenvía los paquetes cifrados, y entonces una sesión SSH gasta bastante menos de 1 MB por hora y una de escritorio remoto entre 0,5 y 1 GB por hora.
Preguntas frecuentes
¿Puedo acceder a mi PC de casa sin abrir puertos si tengo CGNAT?
Sí. Con CGNAT la redirección de puertos no funciona porque la IP pública se comparte con otros abonados, pero una red en malla no necesita conexiones entrantes: el PC de casa sale él hacia el plano de control y, si no hay camino directo, el relay reenvía el tráfico cifrado.
¿Necesito IP fija o DNS dinámico para la red privada?
No. La red privada no depende de tu IP pública: cada equipo recibe una dirección fija 100.64.x.x dentro de la malla y la conserva aunque cambie de wifi, de operador o de país. El único nombre DNS necesario es el del plano de control, que vive en el VPS.
¿El escritorio remoto va más lento por la red en malla?
El escritorio remoto por la red en malla va a la velocidad del camino directo entre los dos equipos cuando WireGuard logra abrirlo, que es lo habitual. Si pasa por el relay, el límite es el ancho de banda de tu servidor; una sesión consume entre 0,5 y 1 GB por hora.
¿Qué pasa si pierdo el pin TLS del servidor?
El pin TLS es la identidad de tu plano de control: cada nodo rechaza un servidor que no presente esa clave. Por eso el fichero control-tls.key se copia fuera del host, cifrado, en cuanto el servidor arranca por primera vez; sin esa copia, perder el servidor obliga a dar de alta todos los equipos.
¿Prefieres tu propio servidor? Guía del paquete autoalojado de prialo