Servidor VPN doméstico frente a servidor en la nube: ¿cuál llega a tu NAS?
El túnel se levanta, pero el NAS de casa sigue inaccesible. Elige la ubicación del extremo por el recurso que debes tocar y luego comprueba la ruta.
El túnel se levanta, el cliente muestra un punto verde y ssh 192.168.1.20 sigue colgado hasta agotar el tiempo. Me pasó exactamente eso tras alquilar una instancia pequeña en la nube y poner WireGuard en ella: handshake correcto, DNS correcto y el NAS de mi escritorio tan inaccesible como si estuviera en la luna. El túnel no tenía nada malo. El extremo estaba aparcado en una red sin ruta hacia mi casa. La ubicación del extremo decide qué redes son adyacentes, así que elígela por el recurso que debes tocar primero y compara el alojamiento después.
Un túnel solo llega a las redes que el extremo puede enrutar
Una VPN da a tu cliente una dirección dentro del dominio de enrutamiento del propio extremo. Cuando el cliente envía un paquete a 192.168.1.20, el extremo tiene que saber adónde va. La tabla de una VM en la nube conoce las subredes VPC del proveedor; nunca ha oído hablar de tu LAN. Conectado y accesible son dos hechos distintos, y casi toda la confusión entre casa y nube viene de tomar el primero como prueba del segundo.
Un comando lo resuelve. En el extremo, ip route get 192.168.1.20 o bien nombra una interfaz LAN o bien apunta a la ruta por defecto. En un equipo de casa la respuesta es el lado LAN. En una instancia en la nube el paquete sale hacia internet y muere. Activar net.ipv4.ip_forward=1 y añadir una regla MASQUERADE no lo cambia, porque no hay nada a donde reenviar hasta que algo del lado de casa termine un enlace hacia la nube.
El caso doméstico tiene una segunda mitad: el camino de vuelta. Los paquetes que salen de la LAN por el equipo del túnel pasan por NAT, o la LAN necesita una ruta estática de vuelta a la subred del túnel. Cuando solo funciona una dirección, comprueba sysctl net.ipv4.conf.all.rp_filter. El filtrado estricto de ruta inversa descarta las respuestas que llegan por una interfaz distinta de la que predice la ruta, y el síntoma parece exactamente una regla de cortafuegos.
Lee el síntoma antes de tocar la configuración
El túnel no se establece: claves, dirección del extremo o un puerto UDP bloqueado. Túnel arriba pero equipos de la LAN muertos: ubicación y enrutamiento. Túnel arriba pero navegación muerta: reenvío, NAT o DNS. Son tres capas y tres comprobaciones distintas, y reescribir una configuración que ya era correcta desperdicia una noche.
| Symptom | First suspect | Check |
|---|---|---|
| Handshake fails, no transfer | Keys, endpoint port, UDP blocked | wg show, then the port from outside |
| Peer pings, LAN host times out | No route to the LAN | ip route get on the endpoint |
| Tunnel up, name resolution fails | DNS options in the peer config | Resolve a name from the client |
| Large transfers reset the connection | MTU | Lower the tunnel MTU and retry |
La accesibilidad entrante de casa merece su propia comprobación, porque decide si el alojamiento en casa es posible. Compara la dirección WAN que informa tu router con la que ve un equipo externo. Si cae en 100.64.0.0/10, o las dos no coinciden, estás detrás de NAT de operador y ninguna redirección de puerto funcionará jamás. Las opciones reales son un relé, un enlace en la nube que marca hacia fuera desde casa, o mover el extremo.
Qué te compra el alojamiento en casa y qué cuesta
Casa es la única ubicación que está dentro de la LAN por defecto, y esa es toda la razón para poner allí un servidor. Los dispositivos que solo responden en el segmento local, como impresoras y páginas de administración del NAS que rechazan subredes no locales, funcionan sin enrutamiento extra. También operas tú mismo la máquina, el router y el enlace.
Los costes son físicos. La subida de casa es el techo para todos los clientes a la vez, así que una videollamada y una copia de seguridad compiten por la misma tubería. Electricidad, desgaste del disco, parches, una dirección dinámica que necesita DDNS, un router que debe reenviar UDP hacia dentro y posiblemente NAT doble: todo cae sobre ti. Lo que la gente omite es la recuperación: si el equipo muere mientras estás fuera, tu única vía a casa muere con él. Ten un segundo dispositivo con las mismas claves, o al menos un plan de acceso físico.
Si quieres acceso a la LAN sin el equipo en casa, construye un enlace en lugar de fingir. El extremo en la nube se convierte en router: un túnel desde el lado de casa con AllowedIPs = 192.168.1.0/24 en el peer de la nube, más reenvío y NAT en el equipo de la nube. La guía de reenvío de strongSwan recorre la mitad de vuelta de esa configuración, y ahí fallan la mayoría de estos intentos. Ahora el peer de casa tiene que estar arriba para que algo funcione, así que cambiaste una dependencia por otra y deberías anotarlo.
Para qué sirve realmente un extremo en la nube
Un extremo en la nube cambia tu salida pública. El tráfico sale del rango de direcciones del proveedor, y los sitios ven esa dirección en lugar de la de casa. Ese es el valor, y también por eso una VPN en la nube no te da el NAS: moviste la salida, no la LAN.
Sigues ejecutando el sistema invitado, el servicio VPN y sus credenciales mientras el proveedor ejecuta el hipervisor y la red física, y esa división importa cuando algo falla a las 2 de la madrugada. Un extremo público se escanea de forma continua, así que mantén cerrado el puerto de gestión, permite solo el puerto VPN y parchea según un calendario. Los grupos de seguridad y los cortafuegos del proveedor deben permitir ese puerto, y algunas nubes descartan el tráfico reenviado salvo que ajustes la comprobación de origen y destino en la instancia.
Una instancia pequeña cubre un puñado de clientes, pero el cifrado es trabajo de CPU, y una instancia burstable que agota sus créditos se comporta de forma irregular bajo carga sostenida. Mira el camino que usas de verdad, no la hoja de especificaciones.
Una decisión que puedes escribir
La tarea decide la ubicación, no la etiqueta del equipo. Si necesitas un dispositivo en tu LAN de casa, la respuesta correcta más barata es un extremo en casa; un equipo en la nube solo funciona después de construir el enlace de vuelta. Si necesitas otra salida pública, la respuesta es la nube y la cuestión de la LAN nunca aparece. Querer ambas es legítimo, pero significa dos extremos, dos juegos de claves y dos rutas documentadas.
| What you need | Endpoint location | What else must exist |
|---|---|---|
| Reach a NAS or printer on the home LAN | A box on that LAN | Port forward or relay, DDNS, recovery plan |
| Browse from an exit unrelated to home | Cloud instance | Firewall and egress rules, patching |
| Both, reliably | Two endpoints, or cloud plus a link home | Separate keys, routes, documented failure modes |
Verifica desde el cliente en orden: handshake, dirección del peer, un equipo de la LAN y luego la IP de salida. curl -s https://ifconfig.me muestra lo que ve internet, y ip route get 192.168.1.20 muestra lo que cree el extremo. Cuando la comprobación de salida pasa y la del NAS se cuelga, ya tienes tu respuesta sobre la ubicación; ajustar AllowedIPs en el cliente no hará aparecer una ruta. Una línea dividida como 10.8.0.0/24, 192.168.1.0/24 solo mantiene el tráfico de la LAN dentro del túnel cuando esa ruta existe de verdad.