Uma VPN entre matriz, filiais, depósitos e equipes remotas não pode depender de uma configuração improvisada. Ao entender como configurar WireGuard entre filiais, sua empresa cria uma rede privada com criptografia moderna, menor sobrecarga que alternativas tradicionais e controle direto sobre quais sub-redes podem se comunicar. O resultado é acesso protegido a ERPs, arquivos, câmeras, serviços internos e aplicações hospedadas em nuvem, sem expor recursos corporativos à internet pública.
O WireGuard é especialmente adequado para operações que precisam de desempenho previsível e administração objetiva. Porém, o túnel por si só não resolve toda a conectividade: roteamento, regras de firewall, disponibilidade do link e tratamento correto de chaves definem se a VPN será uma ferramenta operacional confiável ou uma nova fonte de incidentes.
Quando usar WireGuard entre filiais
O cenário mais comum é uma matriz com IP público fixo e uma ou mais filiais conectadas à internet. Cada unidade possui uma rede local própria, como 10.10.0.0/24 na matriz e 10.20.0.0/24 na filial. Os gateways das duas pontas formam um túnel WireGuard e anunciam essas redes entre si.
Esse modelo atende empresas que precisam conectar sistemas locais, controlar o tráfego entre unidades ou dar acesso a recursos centralizados em um servidor. Também funciona bem quando aplicações corporativas estão em uma VPS ou servidor dedicado: a nuvem passa a operar como hub da rede, recebendo conexões seguras das filiais e distribuindo o acesso aos serviços necessários.
Há um ponto de decisão importante. Para duas ou três unidades, uma topologia ponto a ponto costuma ser simples e eficiente. Com muitas filiais, uma arquitetura hub-and-spoke reduz a quantidade de túneis e facilita a gestão. Nesse caso, cada filial se conecta a um gateway central, mas as políticas de acesso devem impedir que todas as redes se enxerguem automaticamente.
Planeje endereços, rotas e responsabilidades
Antes de instalar qualquer pacote, documente as redes que já existem. Sub-redes sobrepostas são um problema frequente: se matriz e filial usam 192.168.1.0/24, o roteamento não saberá para qual lado enviar o tráfego. Renumere uma das redes ou crie um plano de endereçamento corporativo antes de ativar a VPN.
Para este exemplo, considere a seguinte estrutura:
- Matriz: LAN 10.10.0.0/24 e túnel 10.254.0.1/30.
- Filial: LAN 10.20.0.0/24 e túnel 10.254.0.2/30.
- Gateway da matriz: IP público fixo e porta UDP 51820 liberada.
- Gateway da filial: pode estar atrás de NAT, desde que consiga iniciar a conexão de saída.
O gateway pode ser um firewall corporativo, um roteador compatível ou um servidor Linux com duas interfaces de rede. Para ambientes críticos, prefira uma infraestrutura com IP público estável, armazenamento SSD NVMe e monitoramento contínuo. Uma instância de nuvem posicionada no Brasil também ajuda a reduzir a latência de aplicações usadas por equipes locais.
Defina ainda quais serviços precisam trafegar pelo túnel. Uma VPN site-to-site não deve virar uma rede sem segmentação. Talvez a filial precise acessar somente o banco de dados, o ERP e um compartilhamento específico na matriz. Essa decisão orienta as regras de firewall e reduz a superfície de ataque.
Como configurar WireGuard entre filiais no Linux
A seguir, o exemplo usa Debian ou Ubuntu como gateways. Em outras distribuições, a lógica é a mesma, embora os comandos de instalação e persistência possam variar.
Em ambos os servidores, instale o WireGuard e gere o par de chaves. As chaves privadas nunca devem sair do respectivo gateway.
“`bash apt update apt install wireguard -y umask 077 wg genkey | tee privatekey | wg pubkey > publickey “`
Copie apenas o conteúdo de cada arquivo `publickey` para a outra ponta. Em produção, armazene a chave privada em local protegido e restrinja permissões do arquivo de configuração.
No gateway da matriz, crie o arquivo `/etc/wireguard/wg0.conf` com uma estrutura semelhante a esta:
“`ini [Interface] Address = 10.254.0.1/30 ListenPort = 51820 PrivateKey = CHAVE_PRIVADA_DA_MATRIZ
[Peer] PublicKey = CHAVE_PUBLICA_DA_FILIAL AllowedIPs = 10.254.0.2/32, 10.20.0.0/24 “`
Na filial, use a configuração abaixo. O endereço 203.0.113.10 é apenas um IP reservado para documentação: substitua pelo IP público real ou nome DNS do gateway da matriz.
“`ini [Interface] Address = 10.254.0.2/30 PrivateKey = CHAVE_PRIVADA_DA_FILIAL
[Peer] PublicKey = CHAVE_PUBLICA_DA_MATRIZ Endpoint = 203.0.113.10:51820 AllowedIPs = 10.254.0.1/32, 10.10.0.0/24 PersistentKeepalive = 25 “`
O parâmetro `AllowedIPs` merece atenção. No WireGuard, ele funciona como rota e como critério para aceitar tráfego de cada peer. Não use 0.0.0.0/0 sem necessidade em uma VPN entre filiais, pois isso pode desviar todo o tráfego de internet da unidade pelo túnel. Para acesso corporativo, anuncie somente as sub-redes que realmente precisam se comunicar.
O `PersistentKeepalive = 25` é recomendado na filial quando ela está atrás de NAT. Ele envia pequenos pacotes periódicos para manter o mapeamento ativo no roteador de borda. Se ambas as pontas têm IP público e regras estáveis, esse ajuste pode não ser necessário.
Libere o encaminhamento e proteja o tráfego
O WireGuard estabelece a interface, mas o Linux precisa estar autorizado a encaminhar pacotes entre a LAN e o túnel. Em cada gateway, habilite o encaminhamento IPv4 no arquivo `/etc/sysctl.conf`:
“`bash net.ipv4.ip_forward=1 “`
Aplique a alteração com o comando abaixo:
“`bash sysctl -p “`
Depois, permita no firewall somente o tráfego necessário. Na matriz, a porta UDP 51820 deve aceitar conexões de entrada. Nas duas pontas, as regras de encaminhamento precisam permitir tráfego entre `wg0` e a interface da rede local. Com nftables, iptables, UFW ou um firewall virtual, a sintaxe muda, mas a política permanece: liberar o túnel, permitir as redes corporativas autorizadas e negar o restante.
Evite mascaramento NAT entre as redes internas, salvo quando houver uma razão técnica clara. Sem NAT, os registros de firewall e de aplicação preservam o IP de origem real do usuário, facilitando auditoria e diagnóstico. Para isso funcionar, os dispositivos das LANs precisam conhecer a rota de retorno. A solução mais limpa é configurar o gateway WireGuard como rota padrão das estações ou adicionar rotas estáticas no roteador principal de cada filial.
Na matriz, a rota para 10.20.0.0/24 deve apontar para o gateway local que mantém o túnel. Na filial, a rota para 10.10.0.0/24 deve apontar para seu gateway WireGuard. Sem essas rotas, o handshake pode aparecer como ativo, mas os computadores não conseguirão trocar dados entre as sub-redes.
Ative, valide e monitore a VPN
Suba a interface em ambos os lados:
“`bash systemctl enable wg-quick@wg0 systemctl start wg-quick@wg0 wg show “`
O comando `wg show` exibe o último handshake, volume transferido, chave pública do peer e endpoint. Primeiro, teste a comunicação entre os IPs do túnel, como 10.254.0.1 e 10.254.0.2. Depois, teste um host real da rede remota. Se o túnel responde, mas a LAN não, o problema quase sempre está em encaminhamento, firewall ou rota de retorno.
Acompanhe também perda de pacotes e MTU. Em links com PPPoE, múltiplas camadas de encapsulamento ou provedores móveis, pacotes grandes podem falhar de forma intermitente. O WireGuard costuma calcular uma MTU adequada, mas, se houver sintomas como páginas parciais ou transferências travadas, teste valores menores, como 1380 ou 1360, na seção `Interface`.
Em uma operação empresarial, monitore a idade do último handshake, a disponibilidade da porta UDP, o uso de banda e a latência entre unidades. Alertas são mais úteis quando consideram o horário comercial e a criticidade do serviço. Uma falha no túnel que interrompe emissão de notas, consulta de estoque ou atendimento exige resposta rápida, não uma verificação manual no dia seguinte.
Segurança e continuidade para ambientes corporativos
Chaves WireGuard devem ser individuais por equipamento e revogadas quando um gateway é substituído. Não reutilize a mesma chave em filiais diferentes. Isso simplifica a remoção de acessos, evita ambiguidades nos logs e limita o impacto de uma exposição.
Também vale separar acesso administrativo do tráfego de produção. SSH, painéis de gerenciamento e interfaces de firewall devem aceitar conexões apenas de redes administrativas ou de uma VPN dedicada. Atualizações do sistema, cópias seguras da configuração e documentação de IPs, chaves públicas e rotas reduzem o tempo de recuperação durante uma troca de equipamento.
Para empresas com filiais distribuídas e serviços centralizados, hospedar o gateway em uma infraestrutura de nuvem com suporte 24/7, conectividade redundante e IP público no Brasil pode simplificar a operação. A Locacloud atende esse tipo de arquitetura com recursos para ambientes híbridos, firewall virtual e expansão de capacidade conforme a rede cresce.
Uma VPN bem configurada não é apenas um túnel ativo no painel. Ela precisa continuar funcionando quando o link muda de IP, quando uma nova filial entra na rede e quando a operação depende dela em um horário crítico. Trate WireGuard como parte da infraestrutura de produção, com regras explícitas, monitoramento e capacidade planejada para o próximo estágio do negócio.