Router ou computador separado como servidor VPN: como escolher

Tanto um router como um computador pequeno podem terminar uma VPN, e a decisão raramente depende do débito. Depende de quem aplica a atualização às duas da manhã, do que mais para quando essa caixa reinicia e de se ainda consegue chegar a uma consola quando é o túnel que se avariou. Responda a estas três perguntas para cada candidato e a escolha costuma fazer-se sozinha. O procedimento abaixo transforma a comparação numa lista curta de coisas que pode verificar antes de se comprometer.

Comece pelo que tem de continuar em funcionamento quando o túnel falha

A falha para a qual é preciso projetar é aquela em que o processo da VPN morre e ainda assim precisa de chegar ao anfitrião. Num router, o túnel e a gateway de internet partilham o destino: uma má alteração de configuração pode derrubar ambos, e o caminho de recuperação é muitas vezes um reset físico. Num computador separado, a gateway continua a funcionar e o anfitrião continua acessível pela LAN. Qual destes resultados consegue tolerar decide mais do que qualquer lista de funcionalidades.

Escreva a resposta numa frase: se o anfitrião da VPN reiniciar, o que perde a casa ou o escritório? Se a resposta incluir todo o acesso à internet, aceitou um domínio de falha partilhado e deveria dizê-lo deliberadamente em vez de o descobrir mais tarde.

Um segundo serviço no mesmo aparelho não é uma consola de reserva. Partilha a fonte de alimentação, o firmware e a conta de administrador.

Conte as superfícies de manutenção que cada anfitrião acrescenta

Um router traz firmware do fabricante com o seu próprio ritmo de lançamentos, e a funcionalidade VPN é normalmente um módulo dentro de uma imagem muito maior. Um computador traz um sistema operativo, um gestor de pacotes, um kernel e um conjunto de serviços que agora lhe pertencem. Ambos precisam de patches, e a verdadeira questão é que ritmo vai manter quando a novidade passar.

Num anfitrião Linux, torne esse ritmo visível em vez de contar com ele. systemctl list-timers mostra as tarefas agendadas e apt list --upgradable mostra o que está à espera. Registe que atualizações exigem reinício, porque um anfitrião VPN que reinicia é uma interrupção, a menos que a tenha planeado. Um router sem caminho de atualização automática precisa, em vez disso, de uma entrada na agenda, o que é um controlo mais fraco mas honesto.

Conte também as contas. Cada início de sessão adicional de administrador no anfitrião VPN é mais uma credencial a rodar e mais um caminho a revogar.

Siga o caminho da rede privada, não o rótulo da caixa

Aos clientes não importa onde o servidor corre; importa-lhes se os prefixos protegidos são alcançáveis e se existe um caminho de regresso. Coloque o servidor onde o encaminhamento é mais simples, o que normalmente significa diretamente no segmento que guarda os recursos. Um computador atrás do router continua a precisar de reencaminhamento de porta, e os recursos dessa LAN continuam a precisar de uma rota de regresso à sub-rede do túnel.

Verifique o reencaminhamento no anfitrião antes de culpar o cliente. sysctl net.ipv4.ip_forward deve reportar 1, e nft list ruleset ou iptables -S mostra se a interface do túnel pode sequer reencaminhar. Uma regra masquerade em falta parece, do lado do cliente, exatamente um túnel avariado.

Decida também o que o túnel não deve alcançar. Um servidor colocado no router vê todas as sub-redes que esse router encaminha, e isso é muitas vezes mais do que a política de acesso pretende. Num anfitrião separado, o mesmo isolamento está a uma regra de firewall de distância, e o raio de danos de um cliente comprometido é menor. A descrição da gateway IPsec no RFC 7296 trata isto como uma questão de encaminhamento e política, não de hardware, e nenhuma das formas é mais segura por omissão até a política estar escrita.

Mantenha uma consola de recuperação que não dependa do túnel

A consola que usa para reparar a VPN não pode ser a própria VPN. Mantenha um endereço LAN, uma consola série ou uma consola do fornecedor que funcione enquanto o túnel está em baixo, e use-a pelo menos uma vez antes de precisar dela. Um caminho fora de banda que nunca foi exercitado é um plano e não uma capacidade.

Faça uma cópia de segurança da configuração num local que o próprio anfitrião não possa apagar. tar -czf vpn-config-2026-11-03.tar.gz /etc/wireguard /etc/openvpn captura as chaves e as definições dos serviços, e a cópia tem de sair da máquina. Inclua as regras da firewall e o inventário de clientes, porque restaurar chaves sem a lista de pares produz um servidor a que ninguém se pode juntar. Guarde o arquivo onde a consola de recuperação o consiga alcançar.

Escreva o passo de reversão na mesma nota. Uma alteração de configuração sem reversão documentada é uma alteração permanente, qualquer que fosse a intenção.

Verifique a escolha com um reinício e uma atualização

Teste a disposição tal como vai falhar, não tal como funciona num bom dia. Reinicie o anfitrião, aplique uma atualização pendente e confirme que o túnel regressa sem passos manuais.

Depois do reinício, verifique as três coisas que mais vezes se avariam. systemctl is-active wg-quick@wg0 indica se a interface voltou, ss -lunp mostra se algo está à escuta na porta, e wg show lista um par com um aperto de mão concluído. Um serviço ativo sem aperto de mão significa que a firewall ou a rota estão erradas, não o daemon.

Repita a verificação a partir de um cliente numa rede diferente daquela a partir da qual configurou. Se o túnel sobreviver a um reinício, a uma atualização e a uma mudança de rede do cliente, a escolha do anfitrião está resolvida por agora. Se não, a peça em falta é normalmente um passo documentado e não outra caixa.