Router u ordenador aparte como servidor VPN: cómo elegir

Tanto un router como un ordenador pequeño pueden terminar una VPN, y la decisión rara vez depende del rendimiento. Depende de quién aplica la actualización a las dos de la madrugada, de qué más se detiene cuando esa caja se reinicia y de si aún puede llegar a una consola cuando lo que se ha roto es el túnel. Responda esas tres preguntas para cada candidato y la elección suele tomarse sola. El procedimiento siguiente convierte la comparación en una lista corta de cosas que puede comprobar antes de comprometerse.

Empiece por lo que debe seguir en pie cuando falla el túnel

El fallo para el que hay que diseñar es aquel en el que el proceso de la VPN muere y aun así necesita llegar al equipo anfitrión. En un router, el túnel y la puerta de enlace de internet comparten el destino: un mal cambio de configuración puede tumbar los dos, y el camino de recuperación suele ser un reinicio físico. En un ordenador aparte, la puerta de enlace sigue funcionando y el equipo sigue siendo accesible por la LAN. Cuál de esos resultados puede tolerar decide más que cualquier lista de funciones.

Escriba la respuesta como una frase: si el equipo de la VPN se reinicia, ¿qué pierde el hogar o la oficina? Si la respuesta incluye todo el acceso a internet, ha aceptado un dominio de fallo compartido y debería decirlo a propósito en lugar de descubrirlo más adelante.

Un segundo servicio en el mismo aparato no es una consola de repuesto. Comparte la fuente de alimentación, el firmware y la cuenta de administrador.

Cuente las superficies de mantenimiento que añade cada equipo

Un router trae firmware del fabricante con su propio ritmo de versiones, y la función de VPN suele ser un módulo dentro de una imagen mucho mayor. Un ordenador trae un sistema operativo, un gestor de paquetes, un núcleo y un conjunto de servicios que ahora posee. Ambos necesitan parches, y la pregunta real es qué ritmo mantendrá cuando la novedad se desvanezca.

En un equipo Linux, haga visible ese ritmo en lugar de confiar en él. systemctl list-timers muestra las tareas programadas y apt list --upgradable muestra qué está esperando. Anote qué actualizaciones necesitan un reinicio, porque un equipo de VPN que se reinicia es una interrupción a menos que la haya planificado. Un router sin ruta de actualización automática necesita en cambio una entrada de calendario, que es un control más débil pero honesto.

Cuente también las cuentas. Cada inicio de sesión adicional de administrador en el equipo de la VPN es otra credencial que rotar y otra ruta que revocar.

Siga la ruta de la red privada, no la etiqueta de la caja

A los clientes no les importa dónde se ejecuta el servidor; les importa si los prefijos protegidos son accesibles y si existe una ruta de vuelta. Coloque el servidor donde el enrutamiento sea más simple, lo que normalmente significa directamente en el segmento que contiene los recursos. Un ordenador detrás del router todavía necesita una redirección de puerto, y los recursos de esa LAN todavía necesitan una ruta de vuelta a la subred del túnel.

Compruebe el reenvío en el equipo antes de culpar al cliente. sysctl net.ipv4.ip_forward debería informar de 1, y nft list ruleset o iptables -S muestra si la interfaz del túnel tiene permiso para reenviar. Una regla masquerade ausente se parece desde el lado del cliente exactamente a un túnel roto.

Decida también qué no debe alcanzar el túnel. Un servidor colocado en el router ve todas las subredes que ese router enruta, lo que a menudo es más de lo que pretende la política de acceso. En un equipo aparte, el mismo aislamiento está a una regla de cortafuegos de distancia, y el radio de daño de un cliente comprometido es menor. La descripción de la puerta de enlace IPsec del RFC 7296 trata esto como una cuestión de enrutamiento y política, no de hardware, y ninguna de las dos formas es más segura por defecto hasta que la política esté escrita.

Mantenga una consola de recuperación que no dependa del túnel

La consola que usa para reparar la VPN no puede ser la VPN. Mantenga una dirección LAN, una consola serie o una consola del proveedor que funcione mientras el túnel está caído, y úsela al menos una vez antes de necesitarla. Una ruta fuera de banda que nunca se ha ejercitado es un plan y no una capacidad.

Haga una copia de seguridad de la configuración en un lugar que el propio equipo no pueda borrar. tar -czf vpn-config-2026-11-03.tar.gz /etc/wireguard /etc/openvpn captura las claves y las definiciones de servicio, y la copia tiene que salir de la máquina. Incluya las reglas del cortafuegos y el inventario de clientes, porque restaurar claves sin la lista de pares produce un servidor al que nadie puede unirse. Guarde el archivo donde la consola de recuperación pueda alcanzarlo.

Escriba el paso de reversión en la misma nota. Un cambio de configuración sin reversión documentada es un cambio permanente, fuera cual fuera la intención.

Verifique la elección con un reinicio y una actualización

Pruebe la disposición tal como fallará, no tal como funciona en un buen día. Reinicie el equipo, aplique una actualización pendiente y confirme que el túnel vuelve sin pasos manuales.

Después del reinicio, compruebe las tres cosas que más se rompen. systemctl is-active wg-quick@wg0 informa de si la interfaz ha vuelto, ss -lunp muestra si algo escucha en el puerto y wg show lista un par con un handshake completado. Un servicio activo sin handshake significa que el cortafuegos o la ruta están mal, no el demonio.

Repita la comprobación desde un cliente en una red distinta de la que usó para configurar. Si el túnel sobrevive a un reinicio, una actualización y un cambio de red del cliente, la elección de equipo queda resuelta por ahora. Si no, la pieza que falta suele ser un paso documentado y no otra caja.