Como ligar a rede do escritório às VMs do servidor dedicado com VPN site-to-site WireGuard (MikroTik, pfSense, OPNsense) ou IPsec com strongSwan.

Para que serve

Na VPN site-to-site, o roteador do escritório e a VM de VPN do seu servidor dedicado mantêm um túnel permanente. Qualquer computador da rede do escritório acessa o ERP, o banco ou o RDP das VMs como se estivessem na mesma rede, sem instalar cliente VPN em cada máquina. Este artigo usa WireGuard (MikroTik, pfSense e OPNsense) e mostra o IPsec com strongSwan para firewalls que não suportam WireGuard.

Pré-requisitos

  • VM de VPN já funcionando no Proxmox (veja "Como instalar um servidor VPN WireGuard em uma VM no Proxmox"), com wg0 em 10.8.0.1/24, placa interna ens19 em 10.10.10.2 e a porta 51820/udp liberada no firewall da VM. A VPN fica nessa VM, não no host.
  • Redes de exemplo, que não podem se sobrepor:
    • Rede das VMs no servidor: 10.10.10.0/24 (gateway das VMs = host Proxmox, 10.10.10.1).
    • Rede do escritório: 192.168.10.0/24.
    • IP do roteador do escritório dentro do túnel: 10.8.0.100.
    • IP público da VM de VPN: 203.0.113.5 (fictício).
  • Roteador do escritório com MikroTik RouterOS 7, pfSense (pacote WireGuard) ou OPNsense atual.
  • Acesso ao console IPMI/iLO do servidor e acesso local ao roteador do escritório.

O escritório inicia o túnel e envia keepalive. Assim funciona mesmo com IP dinâmico ou CGNAT da operadora: o servidor só precisa estar acessível na 51820/udp.

Passo a passo da VPN site-to-site

1. Lado do servidor dedicado (VM de VPN)

  1. Na VM de VPN, acrescente o escritório como peer em /etc/wireguard/wg0.conf. A chave pública vem do roteador (passo 2):

    [Peer]
    # Escritório
    PublicKey = CHAVE_PUBLICA_DO_ROTEADOR
    AllowedIPs = 10.8.0.100/32, 192.168.10.0/24

    Não coloque Endpoint: o servidor aprende o endereço do escritório quando ele conecta. O wg-quick cria sozinho a rota para 192.168.10.0/24 via wg0.

  2. Aplique sem derrubar os outros peers:

    wg syncconf wg0 <(wg-quick strip wg0)
    ip route | grep 192.168.10

    Se a rota não aparecer, reinicie a interface com systemctl restart wg-quick@wg0 (derruba os túneis por alguns segundos).

  3. Rotas de volta. Com o NAT do guia de instalação (oifname "ens19" masquerade), o tráfego do escritório chega às VMs com origem 10.10.10.2 e a resposta volta sozinha pela VM de VPN. Libere essa origem no firewall das VMs acessadas (ex.: na VM do ERP, IN ACCEPT, origem 10.10.10.2, porta do serviço).

    Se você precisa do IP real dos computadores do escritório nos logs, ou se as VMs também precisam iniciar conexões para o escritório (impressora, servidor de arquivos local), troque o NAT por rota estática: no host, na seção vmbr1 de /etc/network/interfaces, acrescente up ip route add 192.168.10.0/24 via 10.10.10.2, e adicione a mesma rota em cada VM envolvida (no Windows: route -p add 192.168.10.0 mask 255.255.255.0 10.10.10.2). Aí a origem liberada no firewall passa a ser 192.168.10.0/24.

2a. Escritório com MikroTik (RouterOS 7)

No terminal do MikroTik (Winbox > New Terminal):

/interface wireguard
add name=wg-datacenter listen-port=51820 mtu=1420
print   # copie o public-key e cole no peer do servidor

/interface wireguard peers
add interface=wg-datacenter public-key="CONTEUDO_DE_servidor.pub" \
    endpoint-address=203.0.113.5 endpoint-port=51820 \
    allowed-address=10.8.0.0/24,10.10.10.0/24 persistent-keepalive=25s

/ip address
add address=10.8.0.100/24 interface=wg-datacenter

/ip route
add dst-address=10.10.10.0/24 gateway=wg-datacenter

/ip firewall filter
add chain=forward action=accept src-address=192.168.10.0/24 dst-address=10.10.10.0/24 place-before=0
add chain=forward action=accept src-address=10.10.10.0/24 dst-address=192.168.10.0/24 place-before=0

/ip firewall mangle
add chain=forward action=change-mss new-mss=clamp-to-pmtu protocol=tcp tcp-flags=syn out-interface=wg-datacenter
NAT do MikroTik: se existe uma regra masquerade genérica (sem out-interface), o tráfego para o túnel será mascarado e o servidor verá tudo vindo de 10.8.0.100. Funciona, mas perde o IP real. Para evitar, adicione antes dela: /ip firewall nat add chain=srcnat action=accept dst-address=10.10.10.0/24 place-before=0.

2b. Escritório com pfSense

  1. Instale o pacote em System > Package Manager > Available Packages > WireGuard.
  2. VPN > WireGuard > Tunnels > Add Tunnel: gere as chaves, porta 51820, e anote a chave pública para o servidor.
  3. VPN > WireGuard > Peers > Add Peer: tunnel criado, Endpoint 203.0.113.5 porta 51820, Keep Alive 25, chave pública do servidor, Allowed IPs 10.8.0.0/24 e 10.10.10.0/24.
  4. VPN > WireGuard > Settings: marque Enable WireGuard.
  5. Interfaces > Assignments: atribua o tun_wg0, habilite, IPv4 estático 10.8.0.100/24.
  6. System > Routing > Gateways: crie um gateway nessa interface com IP 10.8.0.1. Em Static Routes, crie a rota 10.10.10.0/24 por esse gateway.
  7. Firewall > Rules: na aba da nova interface, libere o tráfego vindo de 10.10.10.0/24 conforme a necessidade; na LAN, a regra padrão já permite a saída.

2c. Escritório com OPNsense

  1. VPN > WireGuard > Instances: crie a instância (porta 51820, endereço do túnel 10.8.0.100/24) e copie a chave pública.
  2. VPN > WireGuard > Peers: chave pública do servidor, endpoint 203.0.113.5:51820, Allowed IPs 10.8.0.0/24, 10.10.10.0/24, keepalive 25. Vincule o peer à instância e marque Enable WireGuard.
  3. O OPNsense cria as rotas das Allowed IPs automaticamente (a menos que "Disable routes" esteja marcado).
  4. Firewall > Rules > WireGuard (Group): libere o tráfego entre 10.10.10.0/24 e 192.168.10.0/24.
  5. Firewall > Settings > Normalization: crie uma regra na interface WireGuard com Max MSS 1380 para evitar fragmentação.

3. Alternativa: IPsec com strongSwan (Fortigate, Sophos e outros)

Se o firewall do escritório não suporta WireGuard, use IPsec IKEv2 na mesma VM de VPN (não no host):

apt install charon-systemd strongswan-swanctl

Crie /etc/swanctl/conf.d/escritorio.conf:

connections {
  escritorio {
    version = 2
    local_addrs = 203.0.113.5
    remote_addrs = %any
    proposals = aes256-sha256-modp2048
    local {
      auth = psk
      id = 203.0.113.5
    }
    remote {
      auth = psk
      id = escritorio
    }
    children {
      lan {
        local_ts = 10.10.10.0/24
        remote_ts = 192.168.10.0/24
        esp_proposals = aes256-sha256-modp2048
        dpd_action = clear
      }
    }
    dpd_delay = 30s
  }
}
secrets {
  ike-escritorio {
    id = escritorio
    secret = "TROQUE_POR_UMA_CHAVE_LONGA_E_ALEATORIA"
  }
}

Carregue com systemctl enable --now strongswan e swanctl --load-all. Libere UDP 500 e 4500 no firewall da VM (em /etc/pve/firewall/110.fw: IN ACCEPT -i net0 -p udp -dport 500 e IN ACCEPT -i net0 -p udp -dport 4500) e ative o encaminhamento de pacotes na VM, se ainda não estiver ativo. No firewall do escritório, use os mesmos valores: IKEv2, PSK, ID local escritorio, ID remoto 203.0.113.5, AES-256, SHA-256, DH grupo 14, e as mesmas redes local/remota invertidas.

Como saber se funcionou

  1. Na VM de VPN, wg show wg0 mostra o peer do escritório com latest handshake recente e o endpoint com o IP público do escritório. No IPsec, swanctl --list-sas mostra a SA escritorio como ESTABLISHED e a child lan como INSTALLED.
  2. No MikroTik, /interface wireguard peers print detail mostra last-handshake recente.
  3. De um computador do escritório: ping 10.10.10.20 e Test-NetConnection 10.10.10.20 -Port 3389.
  4. Da VM: ping 192.168.10.1 (o roteador do escritório precisa permitir ICMP).

Problemas comuns

  • Handshake ok, mas o ping não passa: falta a rede do escritório no AllowedIPs do servidor ou a rede das VMs no allowed-address do roteador. No WireGuard, um pacote cuja origem não está nas Allowed IPs do peer é descartado em silêncio.
  • Ping funciona, mas RDP/ERP trava ou páginas carregam pela metade: é MTU. Aplique o MSS clamp mostrado acima; links PPPoE (muito comuns em fibra no Brasil) têm MTU 1492, então use MTU 1412 ou menor no túnel.
  • Túnel cai e não volta sozinho: confirme o keepalive de 25 segundos no lado do escritório. Sem ele, o NAT da operadora esquece a sessão.
  • IPsec com "NO_PROPOSAL_CHOSEN" ou "TS_UNACCEPTABLE": as propostas de criptografia ou as redes local/remota não batem entre os dois lados. Veja journalctl -u strongswan -f.
  • Redes sobrepostas: se o escritório também usa 10.10.10.0/24, troque uma das faixas. Não há configuração de túnel que resolva isso de forma simples.

Perguntas frequentes

O escritório precisa de IP fixo?

Não. Como o escritório inicia o túnel e mantém o keepalive, funciona com IP dinâmico e até atrás de CGNAT. Só a VM de VPN precisa de IP público fixo.

Posso ligar várias filiais na mesma VM de VPN?

Sim. Cada filial vira um peer com um IP de túnel próprio e a sua rede em AllowedIPs. As redes das filiais não podem se repetir.

WireGuard ou IPsec para site-to-site?

Prefira WireGuard quando o roteador do escritório suporta (MikroTik RouterOS 7, pfSense, OPNsense). Use IPsec quando o equipamento só fala IPsec.

Precisa de ajuda?

Se o túnel não fechar, abra um ticket com a saída de wg show (ou swanctl --list-sas), o modelo do roteador do escritório e as faixas de rede usadas dos dois lados.

Esta resposta lhe foi útil? 0 Usuários acharam útil (0 Votos)

Leia também