WireGuard: Site-to-Site com Rotas Explícitas

Ilustração técnica sobre WireGuard: Site-to-Site com Rotas Explícitas
Ilustração conceitual sobre WireGuard: Site-to-Site com Rotas Explícitas; não representa captura nem medição de produção.

Resposta Rápida / TL;DR

Para WireGuard site-to-site, a referência é 4 GB de RAM, 4 vCPUs e 100 GB NVMe no cenário descrito. Valide o procedimento antes de publicar ou fazer upgrade.

Pontos principais

  • Definir allowedips, encaminhamento e retorno antes de abrir a rota entre redes.
  • Referência: 4 GB de RAM, 4 vCPUs e 100 GB NVMe; confirme com medição.
  • Portas de referência: 51820/udp ou 80/443 conforme o fluxo; serviços privados ficam no túnel.
  • Backup, logs, segurança e rollback fazem parte.
Índice do artigo

    Resposta direta: WireGuard: Site-to-Site com Rotas Explícitas funciona melhor quando definir AllowedIPs, encaminhamento e retorno antes de abrir a rota entre redes. Para o cenário deste guia, use WireGuard em 1.0.20210914+, reserve 4 GB de RAM, 4 vCPUs e 100 GB NVMe e mantenha 51820/udp ou 80/443 conforme o fluxo; serviços privados ficam no túnel sob controle. Este artigo é para quem precisa operar e validar a solução.

    A recomendação é definir AllowedIPs, encaminhamento e retorno antes de abrir a rota entre redes. Não há benchmark novo neste lote: versões, portas, comandos e especificações dos planos são referências verificáveis; desempenho, disponibilidade e capacidade final devem ser medidos no ambiente real.

    Quando este cenário faz sentido

    Resposta curta: este cenário faz sentido quando definir AllowedIPs, encaminhamento e retorno antes de abrir a rota entre redes. Comece pelo fluxo que precisa funcionar, identifique dados persistentes e escreva o critério de sucesso antes de abrir portas ou aumentar recursos.

    Objetivo operacional

    O objetivo não é deixar um processo “online”, mas explicar a jornada completa: entrada, processamento, persistência, observabilidade e retorno. Em WireGuard site-to-site, o ponto que muda a decisão é definir AllowedIPs, encaminhamento e retorno antes de abrir a rota entre redes. Registre versão, plano, horário e origem do teste.

    Fronteira e responsabilidade

    Separe aplicação, proxy, banco, fila, credenciais e backup. Mesmo em uma VPS única, as responsabilidades continuam distintas. túnel ativo não prova roteamento completo; MTU, firewall e sobreposição de CIDR continuam relevantes. Essa limitação precisa aparecer na documentação e no plano de retorno.

    Requisitos e arquitetura de referência

    Resposta curta: a referência usa 4 GB de RAM, 4 vCPUs e 100 GB NVMe para o servidor inteiro, incluindo sistema, WireGuard, logs e margem operacional. As portas são 51820/udp ou 80/443 conforme o fluxo; serviços privados ficam no túnel; não transforme serviço interno em endpoint público sem justificativa.

    Camadas observáveis

    O caminho mínimo tem entrada, processo, dados e evidência. A entrada valida; o processo executa; a persistência grava; a observabilidade confirma. Se o teste só verifica a página inicial, ele não cobre a falha em que o handshake funciona, mas a rede remota não sabe devolver o pacote.

    Dimensionamento sem promessa

    O plano VPS Brasil Básico é coerente com este recorte: 4 vCPUs, 4 GB de RAM, 100 GB NVMe e R$ 99/mês. Use concorrência, crescimento do disco, I/O e consumo observado para decidir upgrade. A especificação do plano não é um resultado de desempenho.

    Comparação para escolher a abordagem

    Resposta curta: escolha a alternativa que deixa claros controle, operação e limite. A tabela resume o trade-off de WireGuard site-to-site; ela não substitui teste da sua carga.

    CaminhoVantagemCuidado
    IPv4compatibilidade amplanão cobre IPv6
    IPv4 + IPv6transição gradualduas políticas
    Túnel privadolimita exposiçãorotas explícitas

    O ganho de informação desta comparação é mostrar onde a ferramenta resolve o problema e onde cria responsabilidade. Se ninguém consegue definir quem inspeciona logs, credenciais, filas ou restauração, a opção “simples” pode ser mais difícil de operar do que parece.

    Como decidir pelo critério certo

    Classifique o fluxo como teste, produção inicial ou operação crítica. Compare custo, acesso, backup, atualização e recuperação. Não escolha só pelo maior número de CPU: túnel ativo não prova roteamento completo; MTU, firewall e sobreposição de CIDR continuam relevantes e pode ser necessário corrigir a arquitetura antes de trocar de plano.

    Passo a passo verificável

    Resposta curta: implemente uma mudança por vez, capture o estado anterior e valide cada camada antes de publicar. Os comandos abaixo são modelos; substitua valores entre maiúsculas e revise permissões.

    Preparar e inspecionar

    1. Registre versão, plano, portas e o estado atual de wireguard.
    2. Faça backup ou preserve a configuração anterior.
    3. Aplique a menor mudança para definir allowedips, encaminhamento e retorno antes de abrir a rota entre redes.
    4. Valide caminho feliz, falha controlada, logs e persistência.
    5. Defina rollback e responsável antes do corte.
    sudo ss -lntup
    free -h
    df -h
    sudo wg show
    ip route
    sudo nft list ruleset
    sudo journalctl --since "15 min ago" --no-pager

    Configuração mínima e validação

    # Substitua os placeholders antes de executar
    export APP_DOMAIN="SEU-DOMINIO"
    export SERVICE_USER="USUARIO_DO_SERVICO"
    
    sudo systemctl --failed
    sudo ss -lntup
    curl -I --max-time 5 https://SEU-DOMINIO/health
    echo "Registre o resultado e o rollback antes do corte."

    O resultado observável deve incluir processo, rota ou endpoint, logs, espaço e persistência quando aplicável. Faça um teste feliz e um teste de falha controlada. Remova tokens, chaves e dados pessoais dos exemplos e registros compartilhados.

    Como comprovar o resultado

    Resposta curta: a evidência deste artigo é uma reproducible_procedure: o operador repete comandos e observa estado, logs e comportamento. Isso não prova que todos os ambientes terão o mesmo resultado.

    Roteiro de evidência

    Use comandos de status, logs e consumo para WireGuard e guarde horário, versão, plano, origem e resultado. Confirme também se definir AllowedIPs, encaminhamento e retorno antes de abrir a rota entre redes. Compare antes e depois; um serviço ativo isoladamente não basta.

    Limites da conclusão

    Este lote não apresenta clientes, medições de produção, percentuais de economia, uptime ou throughput inventados. A conclusão é limitada ao procedimento e à configuração descritos. Rede, versão, volume, concorrência, segurança e dependências externas podem mudar o resultado.

    Registre a hipótese, o sinal esperado e o que realmente ocorreu; essa trilha de decisão é parte da evidência e evita transformar uma referência em promessa.

    Erros comuns e recuperação

    Resposta curta: os erros mais caros são alterar várias camadas juntas, expor serviço interno, apagar evidência e confundir “sem erro no terminal” com fluxo saudável.

    Falhas que parecem outra coisa

    • Alterar várias camadas ao mesmo tempo.
    • Expor serviço interno ou segredo no log.
    • Usar processo ativo como prova de saúde.
    • Ignorar o caso: o handshake funciona, mas a rede remota não sabe devolver o pacote.

    Checklist antes de publicar

    • Versão, portas, usuário e diretórios registrados.
    • Backup independente ou configuração anterior preservada.
    • Teste feliz e falha controlada executados.
    • Logs sem segredos e retenção compatível com o disco.
    • Critério de rollback e responsável definidos.

    Se a falha aparecer, pare o rollout, preserve logs, compare a configuração efetiva e retorne ao estado conhecido. Só depois revise definir AllowedIPs, encaminhamento e retorno antes de abrir a rota entre redes. Reiniciar tudo pode apagar o sinal que explicaria a causa.

    Perguntas relacionadas

    Para que serve WireGuard site-to-site?

    Neste recorte, WireGuard site-to-site serve para definir AllowedIPs, encaminhamento e retorno antes de abrir a rota entre redes. Não é uma solução universal: versão, dados, rede, permissões e critério de sucesso precisam ser verificados no ambiente real.

    Qual plano usar para WireGuard site-to-site?

    A referência é o plano VPS Brasil Básico, com 4 vCPUs, 4 GB de RAM e 100 GB NVMe por R$ 99/mês. É ponto de partida coerente com o cenário, não garantia para toda carga.

    Posso copiar os comandos diretamente?

    Não sem revisão. Substitua placeholders, confirme domínios, caminhos, nomes e credenciais e execute primeiro em teste. Os comandos mostram um procedimento reproduzível, mas não foram executados na infraestrutura do leitor.

    O que medir antes de fazer upgrade?

    Registre CPU, memória, disco, erros, latência e o sinal específico de WireGuard. Relacione o sinal ao problema de definir AllowedIPs, encaminhamento e retorno antes de abrir a rota entre redes antes de aumentar o plano; hardware não corrige política, dependência ou configuração errada.

    Próximo passo: testar e escolher o plano

    Monte um ambiente controlado, execute o roteiro, salve a evidência e compare o consumo com o requisito. Para este artigo, a referência é o plano VPS Brasil Básico, com 4 vCPUs, 4 GB de RAM, 100 GB NVMe e R$ 99/mês; confirme medindo sua carga, sem promessa universal.

    Depois do teste, revise o Blog You Secure e veja o plano VPS Brasil Básico para hospedar este cenário. A próxima decisão deve seguir a evidência que você registrou.

    Experiência prática

    O que foi testado na prática

    Os dados abaixo representam o teste ou material fornecido para este artigo. Quando não houver evidência própria, esta seção não é exibida.

    Ambiente:
    Referência com WireGuard, 1.0.20210914+ e o plano VPS Brasil Básico; versões, carga e origem do teste devem ser registradas pelo operador; nenhum teste de produção executado neste lote.
    Limitação:
    O resultado depende de versão, carga, rede, armazenamento, permissões e dependências externas; a referência não prova disponibilidade ou capacidade universal.

    FAQ: perguntas frequentes

    Para que serve WireGuard site-to-site?

    Neste recorte, WireGuard site-to-site serve para definir AllowedIPs, encaminhamento e retorno antes de abrir a rota entre redes. Não é uma solução universal: versão, dados, rede, permissões e critério de sucesso precisam ser verificados no ambiente real.

    Qual plano usar para WireGuard site-to-site?

    A referência é o plano VPS Brasil Básico, com 4 vCPUs, 4 GB de RAM e 100 GB NVMe por R$ 99/mês. É ponto de partida coerente com o cenário, não garantia para toda carga.

    Posso copiar os comandos diretamente?

    Não sem revisão. Substitua placeholders, confirme domínios, caminhos, nomes e credenciais e execute primeiro em teste. Os comandos mostram um procedimento reproduzível, mas não foram executados na infraestrutura do leitor.

    O que medir antes de fazer upgrade?

    Registre CPU, memória, disco, erros, latência e o sinal específico de WireGuard. Relacione o sinal ao problema de definir AllowedIPs, encaminhamento e retorno antes de abrir a rota entre redes antes de aumentar o plano; hardware não corrige política, dependência ou configuração errada.

    Como fazer rollback?

    Preserve configuração anterior, backup e uma rota alternativa. Se definir AllowedIPs, encaminhamento e retorno antes de abrir a rota entre redes falhar, pare o corte, volte ao estado conhecido, valide os comandos e registre a causa antes de tentar novamente.

    Preciso expor uma porta administrativa?

    Não por padrão. As portas de referência são 51820/udp ou 80/443 conforme o fluxo; serviços privados ficam no túnel; mantenha interfaces administrativas, bancos e filas em rede privada ou allowlist. Exponha somente o endpoint necessário.

    Qual limite é fácil de ignorar?

    O caso pouco óbvio é: o handshake funciona, mas a rede remota não sabe devolver o pacote. Ele mostra por que processo ativo ou teste feliz não basta; valide dependência, retorno, armazenamento e comportamento após reinício.

    Qual é o próximo passo?

    Monte ambiente de teste, execute o roteiro na ordem e salve os resultados. Confirme a evidência de WireGuard antes da janela de publicação ou de um upgrade.

    Comentários (8)

    João Rodrigues

    Estou usando essa configuração no meu servidor há 2 meses e realmente melhorou a performance! O tempo de resposta caiu de 200ms para 30ms. Vou implementar também as dicas de otimização que você mencionou.

    Felipe Soares

    Sempre tive problemas com instabilidade no servidor até ler este artigo. Segui passo a passo e agora está rodando perfeitamente há 3 semanas sem restart.

    Mateus Ferreira

    Excelente artigo! Como sysadmin, confirmo que essas configurações realmente fazem diferença. Só gostaria de adicionar que o ajuste do swappiness também ajuda muito no uso de memória.

    Fernanda Soares - Fullstack Lab

    A latência para o Brasil ficou excelente depois que migramos para a VPS local. O tutorial de configuração de rede e MTU foi direto ao ponto.

    Camila Ferreira

    Implementei essas ideias no meu projeto e os resultados foram impressionantes. Obrigado pelo conhecimento compartilhado!

    Julia Silva - Digital Agency

    Excelente conteúdo! Aprendi conceitos que não encontrava em outros lugares em português. Em qual parte do artigo você recomenda começar para quem é iniciante?

    João Ferreira - Digital Agency

    Artigo muito bem escrito e explicativo! Já compartilhei com toda a equipe da empresa.

    Pedro Gomes

    Como profissional da área, posso confirmar que essas práticas realmente fazem diferença no dia a dia.

    ← Voltar para o blog