Configurar a VPN WireGuard de forma segura para administradores de servidores

Rede de manutenção em vez de portas de administração abertas ao público

As portas de administração acessíveis ao público aumentam a superfície de ataque de um servidor: tentativas de início de sessão via SSH, configurações incorretas de interfaces de administração e serviços de monitorização expostos acidentalmente ficam diretamente acessíveis a partir de redes externas. Um acesso via WireGuard reduz essa visibilidade, uma vez que, inicialmente, apenas uma porta UDP definida para o túnel encriptado precisa de permanecer acessível. No entanto, o WireGuard não disfarça o tráfego como HTTPS e não oferece um modo de transporte TCP.

A configuração ideal para a administração de uma VPN é, na maioria das vezes, uma rede do tipo «hub-and-spoke»: o servidor gere a interface wg0 e recebe, por exemplo, o endereço interno 10.77.0.1. O portátil de uma pessoa autorizada liga-se como um par independente e utiliza, por exemplo, o endereço 10.77.0.10. O SSH, uma consola Web interna ou pontos finais de monitorização aceitam então os acessos através da rede em túnel, em vez de o fazerem através do endereço público do servidor.

Esta não é uma VPN para utilizadores finais destinada a redirecionar todo o tráfego web de um dispositivo. Para fins de manutenção, faz mais sentido um modelo de acesso restrito: o túnel serve apenas como via de acesso a destinos de gestão claramente definidos. Embora um túnel completo possa ser utilizado de forma deliberada, altera adicionalmente o encaminhamento, a utilização do DNS e a acessibilidade a serviços externos. Estes efeitos secundários não são, na maioria das vezes, necessários para um acesso destinado exclusivamente à manutenção.

O Rede de manutenção é apenas uma restrição de rede. Não determina qual a conta Linux que pode iniciar sessão, quais os comandos que essa conta pode executar ou se o sistema operativo está atualizado. Além disso, são necessárias chaves SSH e contas pessoais, direitos «sudo» devidamente limitados, regras de firewall, atualizações de segurança, registo de atividades e um acesso de emergência devidamente mantido. Desta forma, uma falha numa única camada de proteção não será o único fator determinante no acesso.

Classificar corretamente as chaves, os pares e os endereços IP permitidos

Cada par do WireGuard possui o seu próprio par de chaves. A chave privada permanece exclusivamente no servidor, computador portátil ou dispositivo de gestão correspondente; no lado do destinatário, apenas é armazenada a chave pública derivada dessa chave privada. Uma chave pré-partilhada opcional complementa a criptografia de chave pública com material de chave simétrico adicional. Trata-se de uma camada adicional, mas não substitui nem as chaves privadas nem uma gestão de chaves transparente.

Coloca um Peer por dispositivo e não um peer comum para uma equipa. Desta forma, é possível remover de forma seletiva uma estação de trabalho perdida ou um dispositivo de um prestador de serviços que já não seja necessário. As chaves do WireGuard permitem o acesso à rede de manutenção. Separadamente, as chaves SSH autenticam uma pessoa ou um dispositivo perante o serviço SSH; por isso, a revogação deve ser planeada em ambos os níveis.

São particularmente importantes os AllowedIPs no servidor. No WireGuard, estas formam uma tabela de encaminhamento de chaves criptográficas: para os pacotes de saída, determinam o par adequado com base na morada de destino. Para os pacotes de entrada já autenticados, limitam simultaneamente as endereços de origem internos que esse par pode utilizar. Por conseguinte, esta configuração é mais do que uma simples especificação de rota.

Se o portátil de administração receber o endereço 10.77.0.10, no servidor deve constar, precisamente para esse par, AllowedIPs = 10.77.0.10/32. A atribuição /32 associa uma única morada de túnel a este par. Se atribuísses de forma genérica 10.77.0.0/24 a cada par de administração, essa atribuição ficaria confusa e a configuração tornar-se-ia desnecessariamente abrangente. Verifica também se a rede VPN selecionada não entra em conflito com redes de localização, de contentores ou domésticas.

Planear os limites da rede e o modelo de acesso

Planeie a rede de endereços VPN antes da instalação. Escolha um intervalo privado que não se sobreponha a LANs existentes, redes na nuvem, redes Docker ou Kubernetes, nem a redes domésticas frequentemente utilizadas. Defina quais os sistemas que devem ser acessíveis através do túnel: apenas o servidor gateway, uma rede de gestão delimitada ou serviços específicos. Deste modo, serão posteriormente definidas as rotas dos clientes, as regras do firewall e, se necessário, as rotas de retorno.

Documenta, para cada dispositivo, o utilizador responsável, a chave pública do WireGuard, o endereço IP fixo do túnel, a finalidade da autorização e o procedimento de revogação. Os grupos devem orientar-se por tarefas específicas, como operações, gestão de bases de dados ou apoio externo, e não por uma regra genérica do tipo „a VPN permite tudo“. Além disso, mantenha um acesso de emergência independente, por exemplo, uma consola do fornecedor de serviços. Verifique-o antes de efetuar alterações na firewall, no SSH ou no encaminhamento, para que uma regra incorreta não resulte no bloqueio do acesso.

O Firewall é a regra de rede principal: permite a porta UDP do WireGuard na interface pública, mas aceita ligações SSH exclusivamente através da interface de entrada wg0 ou a interface WireGuard efetivamente utilizada. Uma verificação adicional da rede de origem da VPN pode restringir ainda mais a regra, mas não pode substituir a vinculação à interface. Assim, a firewall não aceita pacotes que cheguem à interface pública apenas com base numa alegada morada de origem da VPN. O WireGuard associa endereços internos autenticados a pares; esta garantia aplica-se aos pacotes aceites através da interface do túnel.

Ao nível do SSH, são adicionadas chaves em vez do início de sessão com palavra-passe, contas pessoais e regras de «sudo» tão restritas quanto possível. O OpenSSH pode ser utilizado com AllowUsers Associar contas adicionalmente a endereços de origem ou redes CIDR. Esta segunda barreira complementa a que se encontra em wg0 Regra de firewall associada, mas não a substitui.

As aplicações web públicas continuam a necessitar de uma proteção de transporte própria através de HTTPS e dos certificados adequados. O guia para a proteção de um site através do TLS trata deste nível no que diz respeito ao acesso através do navegador. O WireGuard, por outro lado, protege o acesso à rede privada de administração; não substitui o TLS para serviços públicos, nem o seu processo de início de sessão, verificação de direitos e manutenção.

Estrutura básica com o wg-quick sem armadilhas de encaminhamento

Para um único servidor de manutenção, basta um cenário ponto a ponto restrito: o servidor executa wg0 com o endereço do túnel 10.77.0.1/24, o portátil de administração recebe de forma permanente 10.77.0.10/32. O servidor público só aceita UDP para o WireGuard. Os ficheiros seguintes constituem uma sugestão de configuração para wg-quick; não contêm, deliberadamente, chaves reais.

No servidor, um peer associa a chave pública do portátil à sua endereço de túnel específico. A chave privada do servidor permanece exclusivamente no ficheiro local. Guarda a configuração, por exemplo, em /etc/wireguard/wg0.conf e limite o acesso de leitura ao contexto de administração, uma vez que este contém uma chave secreta. As chaves públicas, por outro lado, destinam-se ao respectivo destinatário.

[Interface]
Address = 10.77.0.1/24
ListenPort = <UDP_PORT>
PrivateKey = <SERVER_PRIVATE_KEY>

[Peer]
# Administrations-Laptop Person A
PublicKey = <ADMIN_A_PUBLIC_KEY>
AllowedIPs = 10.77.0.10/32

No portátil, indica Endpoint para o endereço público do servidor e a porta UDP selecionada. Para fins exclusivamente de manutenção do servidor, como opção do lado do cliente, deve-se utilizar AllowedIPs na maioria das vezes, apenas 10.77.0.1/32 necessário. Desta forma, apenas o tráfego destinado ao endereço VPN do servidor é encaminhado para o túnel; os acessos à Internet do portátil mantêm o seu percurso habitual.

[Interface]
Address = 10.77.0.10/32
PrivateKey = <ADMIN_A_PRIVATE_KEY>

[Peer]
PublicKey = <SERVER_PUBLIC_KEY>
Endpoint = <SERVER_PUBLIC_ADDRESS>:<UDP_PORT>
AllowedIPs = 10.77.0.1/32
PersistentKeepalive = <ONLY_IF_NEEDED>

A indicação 0.0.0.0/0 No cliente, por outro lado, uma rota predefinida IPv4 através do túnel significa: uma Túnel completo. wg-quick deriva as rotas a partir das AllowedIPs e trata as rotas por defeito com lógica adicional de encaminhamento baseada em políticas. Isto é possível num acesso planeado deliberadamente desta forma, mas, entre outras coisas, altera o tráfego externo e pode revelar problemas de DNS ou de acessibilidade.

Este exemplo abrange exclusivamente o IPv4. Se o servidor tiver conectividade IPv6 pública, a porta TCP 22 também terá de ser explicitamente bloqueada pelo firewall IPv6 ou o serviço SSH terá de ser vinculado de forma adequada. Uma autorização IPv4 bloqueada não protege contra um listener IPv6 que continue a ser acessível publicamente. Planeie separadamente os endereços de túnel IPv6 e os prefixos do lado do cliente; ::/0 seria, nesse caso, igualmente uma rota predefinida para o IPv6 e não um complemento neutro à configuração do IPv4.

Ativa primeiro o túnel, verifica a ligação ao endereço da VPN e inicia sessão através do SSH numa segunda sessão. Só quando este método funcionar de forma fiável e existir um acesso independente à consola ou um acesso de emergência é que deves remover a partilha pública do SSH. Verifica tanto o IPv4 como, se for o caso, o IPv6. As chaves privadas não devem constar em tickets, registos de chat nem sistemas de gestão de versões.

Comparar modelos de encaminhamento e regras de firewall

A firewall aplica o modelo de acesso pretendido. Na interface pública, pode aceitar a porta UDP do WireGuard definida; por outro lado, a porta TCP 22 não deve permanecer aberta nessa interface como acesso geral de administração. Em vez disso, o SSH só é autorizado para pacotes cuja interface de entrada wg0 ou seja, a interface WireGuard utilizada. Uma verificação adicional da rede de origem pode restringir ainda mais o âmbito permitido da VPN; no entanto, uma regra baseada exclusivamente no endereço de origem não é suficiente.

A ligação à interface de entrada impede que um pacote que chegue à interface pública cumpra os requisitos de autorização SSH apenas devido a um endereço de origem falsificado proveniente da área da VPN. A mapeamento criptográfico do WireGuard entre o par e a endereço interno aplica-se aos pacotes autenticados na interface do túnel. A sintaxe específica do firewall deve ser compatível com o software utilizado e ter em conta, de forma inequívoca, tanto a interface como a família de endereços.

Tenha especialmente em conta a conectividade IPv6 pública. Se apenas for removida a abertura do IPv4 para o TCP 22, o SSH poderá continuar acessível a partir da Internet através do IPv6. Por isso, bloqueie também a porta nas regras IPv6 ou configure o serviço SSH de forma a que não fique à escuta num endereço IPv6 público. As regras IPv4 e IPv6 devem ser verificadas separadamente.

No caso de uma firewall com gestão de estado, não basta considerar apenas o caminho de ida pretendido. Os pacotes de resposta de uma ligação autorizada também têm de chegar ao cliente; no caso de acessos atrás de um gateway, acrescenta-se ainda o caminho de volta a partir da rede de destino. Uma autorização genérica de toda a sub-rede VPN para todos os serviços transforma desnecessariamente a rede de manutenção numa rede de acesso interna excessivamente ampla.

Para a manutenção de um único servidor, o primeiro modelo é o mais claro. O caminho do cliente para 10.77.0.1/32 basta isso, e a firewall pode aceitar o SSH exclusivamente para os pacotes que chegam através da interface WireGuard. Embora a porta UDP continue visível do exterior, sem a chave de par correspondente não é possível obter acesso administrativo.

O segundo modelo exige uma separação clara: o servidor VPN não é, neste caso, apenas um ponto final, mas sim um router. A firewall deve permitir, por exemplo, o acesso via SSH a servidores de gestão definidos e via HTTPS a uma consola interna, em ambos os casos limitados à interface de entrada do WireGuard, a redes de destino específicas e a portas concretas. Não deves abrir as portas da base de dados em toda a VPN apenas pelo facto de os utilizadores já estarem ligados.

Num «Full Tunnel», o servidor VPN funciona também como gateway para destinos na Internet. Para tal, tem de encaminhar pacotes IPv4 entre wg0 e encaminhá-las para a sua ligação ascendente; além disso, as respostas necessitam de um caminho de regresso à rede VPN. Em muitas configurações de servidor, é utilizada para o efeito uma regra específica de Source NAT na ligação ascendente, caso a rede a montante não conheça nenhuma rota para o prefixo VPN. Planeie estas regras de forma consciente e limite-as à rede de túnel prevista.

Um «Full Tunnel» não é uma especificação de segurança do WireGuard, mas sim uma decisão de encaminhamento tomada no cliente. Porque wg-quick Uma vez que as rotas predefinidas de AllowedIPs são tratadas de forma especial, esta configuração só deve ser utilizada com uma resolução de nomes planeada, capacidade de gateway suficiente e regras de saída adequadas. Para o uso habitual Administração de VPN na maioria das vezes, é mais abrangente do que o necessário. No caso do IPv6, esta questão de planeamento aplica-se separadamente: ::/0 encaminha todo o tráfego IPv6 através do túnel.

Tornar as redes internas acessíveis de forma seletiva

Se os administradores precisarem de aceder a outros sistemas privados para além do gateway VPN, a tarefa passa de um simples acesso ao servidor para uma rede de administração encaminhada. Comece por planear as redes e os serviços de destino: por exemplo, SSH para servidores no segmento de administração e HTTPS para uma consola interna. Cada caminho adicional alarga a zona de confiança e, por isso, deve ser justificado por uma tarefa operacional concreta.

Como primeiro requisito técnico, o gateway tem de poder reencaminhar pacotes IPv4. A configuração do kernel net.ipv4.ip_forward ativa este comportamento. Não deve ser tratada como uma linha de código sem consequências: de acordo com a documentação do kernel, uma alteração de ip_forward Os restantes parâmetros de configuração IPv4 voltam aos valores predefinidos do anfitrião ou do router. Por isso, verifique as diretrizes de rede e de segurança em vigor antes e depois da alteração.

Em segundo lugar, a firewall necessita de Regras de trânsito em ambos os sentidos. Uma regra não deve limitar-se a proibir todo o tráfego de wg0 aceitar na LAN. Em vez disso, limite-as à rede de origem da VPN, às endereços de destino previstos e aos protocolos necessários, por exemplo, TCP 22 para servidores de gestão e TCP 443 para uma consola. As bases de dados permanecem fora desta autorização, salvo exceção justificada.

Em terceiro lugar, a rede de destino necessita de um caminho de regresso à rede VPN, por exemplo, uma rota para 10.77.0.0/24 através do endereço interno do gateway. Sem esta rota de retorno, o trajeto de ida pode funcionar, mas as respostas não chegam ao administrador. Se o encaminhamento na rede de destino não for possível, o Source NAT no gateway pode ser uma alternativa técnica; no entanto, oculta o endereço original do cliente VPN, dificultando assim o registo de eventos no lado do destino e a definição de regras mais precisas.

Escolhe a rede de endereços VPN de forma a que não entre em conflito nem com as redes locais dos administradores, nem com as redes existentes de locais, na nuvem ou de contentores. As sobreposições tornam a seleção de rotas ambígua e geram erros que podem parecer um problema do WireGuard ou da firewall. Além disso, documenta os endereços fixos dos túneis e os dispositivos associados antes de ativares mais pares ou redes de destino.

Gerir com segurança o funcionamento e as alterações

Uma rede de manutenção só se mantém fácil de gerir se cada dispositivo receber um par de pares próprio, um par de chaves próprio e um endereço IP de túnel fixo. Por isso, um inventário deve incluir, no mínimo, o endereço do túnel, a designação do dispositivo, a pessoa responsável, a finalidade, a data de emissão e a data de verificação. A atribuição de 10.77.0.10/32 a um portátil de administração específico torna os acessos rastreáveis e impede que vários dispositivos utilizem a mesma identidade VPN.

Planeie a troca de chaves como um processo operacional regular, e não apenas como reação a um incidente. Para substituir um dispositivo, cria um novo par com um novo endereço ou um endereço sucessor claramente documentado, verifica o acesso e, em seguida, elimina o par antigo. As chaves privadas do WireGuard devem estar exclusivamente no respetivo dispositivo; nem os bilhetes nem as listas de inventário centrais devem conter essas chaves.

Em caso de perda de um computador portátil ou de saída de um colaborador externo, deve remover o par correspondente da configuração do servidor. Isto impede o acesso desse utilizador à rede de administração, sem ser necessário substituir as chaves de outros administradores. Retirada por pares mas não é o mesmo que revogar uma chave SSH: a chave do WireGuard controla o percurso da rede, enquanto a chave SSH controla o início de sessão na conta de destino.

Após a remoção de um peer, o WireGuard não consegue trocar mais pacotes de uma ligação SSH existente através desse peer; por isso, a ligação fica bloqueada ou termina após ser interrompida ou atingir o tempo limite. No entanto, a remoção não revoga automaticamente o início de sessão SSH já efetuado ao nível da aplicação, nem encerra os processos iniciados anteriormente. Por isso, em caso de incidente, verifica também as autorizações SSH, os processos em execução, as contas e, se for o caso, os direitos de «sudo».

Para efetuar alterações específicas, pode wg syncconf comparar uma configuração existente do WireGuard com as diferenças explícitas; de acordo com o manual, isto deverá perturbar menos as sessões entre pares do que setconf. No entanto, não substitui a aprovação, a verificação por duas pessoas nem as janelas de manutenção. Antes de qualquer alteração, guarda a configuração que está a funcionar e regista como a restaurar.

Diagnóstico, desde o handshake até ao acesso SSH

Em caso de falha, separa sistematicamente o transporte, o encaminhamento e a aplicação. Começa pela porta UDP acessível publicamente e pelo handshake, antes de alterares as definições do SSH. O comando wg show Apresenta, entre outros, os AllowedIPs, a hora do último handshake e o contador de transferências para os pares configurados. Valores em falta ou inalterados indicam a existência de um problema antes do acesso SSH propriamente dito.

Se houver um handshake, verifica-se, tanto no cliente como no servidor, a morada do túnel efetivamente definida e a rota até ao destino. Para a gestão pura do gateway, o cliente tem de aceder ao destino 10.77.0.1 através da interface WireGuard. No caso de destinos internos, acrescentam-se os contadores do firewall, o tráfego de retorno autorizado e a rota de retorno da rede de destino; um handshake bem-sucedido não comprova o cumprimento destes pré-requisitos.

Só quando a configuração de rede estiver correta é que se procede à verificação do serviço SSH. Verifica as entradas relevantes para o início de sessão e a restrição de origem no ficheiro sshd_config, nomeadamente partilhas de utilizadores como AllowUsers, e verifica o estado dos serviços e os registos com as ferramentas da tua distribuição. Em seguida, analisa a conta de utilizador e as entradas em authorized_keys e regras do sudo separadamente. A documentação de configuração, por si só, não comprova nem o sucesso do início de sessão nem a acessibilidade do serviço.

AllowedIPs idênticos ou sobrepostos não são um mero erro de documentação. Ao enviar dados, o WireGuard atribui endereços de destino a um par com base nestes prefixos; ao receber dados, estes limitam os endereços de origem internos do par autenticado. Por conseguinte, prefixos de host duplicados ou contraditórios não constituem uma identificação única e fiável Atribuição de pares. Não se deve dar por certo qual o resultado concreto que uma ferramenta de gestão produzirá ao aplicar uma configuração deste tipo. Em vez disso, evita a colisão já na fase de inventário e na verificação da configuração.

Aplica as correções de forma controlada e realiza os diagnósticos apenas com acesso de emergência disponível. Desta forma, uma alteração incorreta num peer, no encaminhamento ou na firewall não bloqueia simultaneamente o caminho de regresso para a reparação. Após cada implementação, verifique novamente o handshake, o contador de transferências, a rota e o acesso ao serviço de gestão especificamente autorizado.

wg show
ip route

A escolha das ferramentas e os limites de segurança são determinantes

A escolha do método de gestão depende da gestão do servidor existente, e não de um método WireGuard supostamente universal. wg-quick É adequado para configurações simples: o script auxiliar configura a interface, os endereços e as rotas derivadas das AllowedIPs. No entanto, para redes complexas, a documentação remete para ferramentas mais específicas ou para a configuração direta com wg e ferramentas de IP.

Se um anfitrião já gerir a sua rede de forma declarativa através do systemd-networkd, os ficheiros .netdev e .network constituem uma alternativa adequada. O systemd-networkd suporta configurações específicas do WireGuard e pode obter chaves privadas a partir de credenciais; no que diz respeito a conteúdos confidenciais, a documentação recomenda credenciais encriptadas ou, no mínimo, direitos de acesso restritivos aos ficheiros como medida de proteção. Isto é particularmente adequado para servidores implementados de forma automatizada.

Acessos diretos a wg e ip oferecem o maior controlo em termos de automatização, encaminhamento baseado em políticas e procedimentos específicos de firewall, mas exigem um modelo operacional bem definido. Nunca geres a mesma interface simultaneamente através do wg-quick, do systemd-networkd e de scripts próprios. Várias entidades responsáveis podem sobrepor-se mutuamente em termos de rotas, endereços ou configurações de pares, dificultando uma reversão fiável.

O PersistentKeepalive só faz sentido para pares que, estando atrás de um NAT ou de uma firewall com gestão de estado, raramente enviam dados por si próprios, mas que, mesmo assim, têm de permanecer acessíveis para tráfego de entrada. Se não for especificado, fica desativado; a documentação refere 25 segundos apenas como um intervalo possível, não como uma predefinição geral. Os clientes móveis beneficiam frequentemente do roaming, porque o WireGuard consegue atualizar o ponto final com base em pacotes autenticados corretamente.

O roaming e a restrição fixa de pontos finais são uma questão de equilíbrio: uma firewall que apenas aceita UDP proveniente de redes de origem conhecidas pode limitar a superfície de ataque, mas impede uma utilização flexível em viagem. O WireGuard salienta ainda que um atacante ativo pode redirecionar o endereço de origem externo e, assim, facilitar um ataque de negação de serviço, sem ler nem alterar o conteúdo encriptado.

Um túnel WireGuard não substitui a gestão de identidades, a verificação de direitos, as atualizações, as cópias de segurança nem o registo de atividades. Não disfarça o seu tráfego como HTTPS e não oferece o modo TCP. Por conseguinte, as aplicações web públicas continuam a necessitar de uma proteção TLS independente; o artigo explica os requisitos e a implementação Configurar o HTTPS de forma segura. Separa claramente esta camada de proteção do acesso VPN para a administração.