Acesso remoto privado

Operar WireGuard com routing e recuperação claros

Um VPS WireGuard oferece acesso cifrado a sistemas autorizados. Uma implementação fiável exige endereços explícitos, firewall e encaminhamento, chaves protegidas, rotas IPv4 e IPv6 testadas e recuperação fora do túnel. Não promete anonimato nem permite contornar regras.

Factos principais

Exemplo de escuta
`51820/udp`, configurável e não obrigatório
Identidade
Chaves públicas identificam peers; privadas ficam secretas
Routing
`AllowedIPs` afeta peer e rotas de origem aceites
Recuperação
Mantenha console ou SSH fora do túnel até validar

Desenhar túnel e confiança

Identifique utilizadores, dispositivos, sub-redes, DNS e destinos. Decida endpoint, router privado ou gateway; exigem encaminhamento, filtros e logs diferentes. Evite sobreposição.

WireGuard cifra entre peers; não protege endpoint comprometido, autentica aplicações ou oculta tráfego após a saída. IP e horários continuam visíveis. Use legalmente.

  • Atribua endereço e chaves únicos.
  • Documente IPv4, IPv6, DNS e saída.
  • Não transporte tráfego não autorizado.

Verificar antes do firewall

Confirme endereços, rotas, interfaces, firewalls e encaminhamento. Normalmente permite-se UDP como 51820/udp, preserva-se administração e filtra-se por destino.

Use ip route, ss -lunp e console. Para IPv6 verifique routing e regras. Guarde firewall e prepare rollback.

  • Abra apenas UDP e administração necessários.
  • Use NAT só quando exigido.
  • Teste de rede externa.

Tratar chaves e `AllowedIPs` como controlos

Gere chaves privadas no dispositivo. Em /etc/wireguard/wg0.conf, reveja cada peer: AllowedIPs controla tráfego e origens. Valores amplos podem desviar tráfego.

Atrás de NAT pode ser necessário PersistentKeepalive, sem substituir monitorização. Revogue dispositivos perdidos, rode após suspeitas e mantenha inventário sem segredos.

  • Nunca envie chaves privadas.
  • Use rotas mínimas.
  • Registe emissão, dono e revogação.

Validar handshake, routing, DNS, MTU e fugas

Use wg show para peer, handshake, endpoint e contadores. Teste túnel, destinos, DNS e saída em ambas famílias. Confirme prefixos com ip route.

Se pacotes pequenos passam e grandes bloqueiam, investigue MTU. Teste redes reais. A falha não deve expor tráfego e a recuperação deve continuar.

  • Teste destinos permitidos e negados.
  • Separe IPv4, IPv6 e DNS.
  • Registe configuração e rollback.

Operar como serviço privilegiado

Atualize, monitorize interface, disco, tráfego e acessos, e copie configuração sem chaves. Limite alterações e defina dispositivos e perdas.

Reveja peers, chaves, rotas e necessidade. Remova acessos, teste após mudanças e, ao retirar, revogue, apague e remova DNS e automação.

  • Alerte sem recolher navegação.
  • Cifre cópias.
  • Reteste após mudanças.

Fontes

  1. WireGuard — Início rápido
  2. Documentação do kernel Linux — WireGuard Netlink
  3. NIST SP 800-123 — Segurança geral de servidores
Perguntas frequentes

Perguntas frequentes

WireGuard torna o tráfego anónimo?

Não. Cifra entre peers; IP, horário, conta, saída e aplicações criam ligações.

Tem de usar a porta 51820?

Não. 51820/udp é exemplo; outro UDP deve corresponder aos firewalls.

Sem handshake, o que verificar?

Endpoint, porta, UDP, chaves, hora, escuta com ss -lunp e peer com wg show. Mantenha console.

Todo o tráfego em `AllowedIPs`?

Só num túnel total intencional e testado. Prefixos estreitos reduzem surpresas.