Router ou ordenador aparte como servidor VPN: como escoller

Tanto un router como un ordenador pequeno poden rematar unha VPN, e a decisión raramente depende do rendemento. Depende de quen aplica a actualización ás dúas da mañá, de que máis se detén cando esa caixa se reinicia e de se aínda pode chegar a unha consola cando o que se rompeu é o túnel. Responda esas tres preguntas para cada candidato e a elección adoita facerse soa. O procedemento seguinte converte a comparación nunha lista curta de cousas que pode comprobar antes de comprometerse.

Comece polo que debe seguir en pé cando falla o túnel

O fallo para o que hai que deseñar é aquel no que o proceso da VPN morre e aínda así necesita chegar ao equipo. Nun router, o túnel e a porta de enlace de internet comparten o destino: un mal cambio de configuración pode botar abaixo os dous, e o camiño de recuperación adoita ser un reinicio físico. Nun ordenador aparte, a porta de enlace segue funcionando e o equipo segue sendo accesible pola LAN. Cal deses resultados pode tolerar decide máis que calquera lista de funcións.

Escriba a resposta como unha frase: se o equipo da VPN se reinicia, que perde a casa ou a oficina? Se a resposta inclúe todo o acceso a internet, aceptou un dominio de fallo compartido e debería dicilo a propósito en lugar de descubrilo máis adiante.

Un segundo servizo no mesmo aparello non é unha consola de reserva. Comparte a fonte de alimentación, o firmware e a conta de administrador.

Conte as superficies de mantemento que engade cada equipo

Un router trae firmware do fabricante co seu propio ritmo de versións, e a función de VPN adoita ser un módulo dentro dunha imaxe moito maior. Un ordenador trae un sistema operativo, un xestor de paquetes, un núcleo e un conxunto de servizos que agora posúe. Ambos precisan parches, e a verdadeira pregunta é que ritmo manterá cando a novidade se esvaeza.

Nun equipo Linux, faga visible ese ritmo en lugar de confiar nel. systemctl list-timers mostra as tarefas programadas e apt list --upgradable mostra que está agardando. Anote que actualizacións precisan un reinicio, porque un equipo de VPN que se reinicia é unha interrupción a menos que a planificase. Un router sen ruta de actualización automática necesita no seu lugar unha entrada de calendario, que é un control máis débil pero honesto.

Conte tamén as contas. Cada inicio de sesión adicional de administrador no equipo da VPN é outra credencial que rotar e outra ruta que revogar.

Siga a ruta da rede privada, non a etiqueta da caixa

Aos clientes non lles importa onde se executa o servidor; impórtalles se os prefixos protexidos son accesibles e se existe unha ruta de volta. Poña o servidor onde o encamiñamento é máis simple, o que normalmente significa directamente no segmento que contén os recursos. Un ordenador detrás do router aínda necesita unha redirección de porto, e os recursos desa LAN aínda necesitan unha ruta de volta á subrede do túnel.

Comprobe o reenvío no equipo antes de culpar o cliente. sysctl net.ipv4.ip_forward debería informar de 1, e nft list ruleset ou iptables -S mostra se a interface do túnel ten permiso para reenviar. Unha regra masquerade ausente parécese desde o lado do cliente exactamente a un túnel roto.

Decida tamén que non debe alcanzar o túnel. Un servidor colocado no router ve todas as subredes que ese router encamiña, o que a miúdo é máis do que pretende a política de acceso. Nun equipo aparte, o mesmo illamento está a unha regra de devasa de distancia, e o radio de dano dun cliente comprometido é menor. A descrición da porta de enlace IPsec do RFC 7296 trata isto como unha cuestión de encamiñamento e política, non de hardware, e ningunha das dúas formas é máis segura por defecto ata que a política estea escrita.

Manteña unha consola de recuperación que non dependa do túnel

A consola que usa para reparar a VPN non pode ser a VPN. Manteña un enderezo LAN, unha consola serie ou unha consola do provedor que funcione mentres o túnel está caído, e úsea polo menos unha vez antes de necesitala. Unha ruta fóra de banda que nunca se exercitou é un plan e non unha capacidade.

Faga unha copia de seguridade da configuración nun lugar que o propio equipo non poida borrar. tar -czf vpn-config-2026-11-03.tar.gz /etc/wireguard /etc/openvpn captura as chaves e as definicións de servizo, e a copia ten que saír da máquina. Inclúa as regras da devasa e o inventario de clientes, porque restaurar chaves sen a lista de pares produce un servidor ao que ninguén pode unirse. Garde o arquivo onde a consola de recuperación poida alcanzalo.

Escriba o paso de reversión na mesma nota. Un cambio de configuración sen reversión documentada é un cambio permanente, calquera que fose a intención.

Verifique a elección cun reinicio e unha actualización

Probe a disposición tal como fallará, non tal como funciona nun bo día. Reinicie o equipo, aplique unha actualización pendente e confirme que o túnel volve sen pasos manuais.

Despois do reinicio, comprobe as tres cousas que máis se rompen. systemctl is-active wg-quick@wg0 informa de se a interface volveu, ss -lunp mostra se algo escoita no porto e wg show lista un par cun aperto de man completado. Un servizo activo sen aperto de man significa que a devasa ou a ruta están mal, non o daemon.

Repita a comprobación desde un cliente nunha rede distinta da que usou para configurar. Se o túnel sobrevive a un reinicio, unha actualización e un cambio de rede do cliente, a elección de equipo queda resolta por agora. Se non, a peza que falta adoita ser un paso documentado e non outra caixa.