INFRAESTRUTURA PRIVADA / SEM IDENTIFICAÇÃO NECESSÁRIALer a doutrina de privacidade
As notas de campo do KoalaVPS

Um túnel privado com um propósito claro.

O WireGuard pode ligar os seus dispositivos a um servidor ou a uma rede privada. Os seus benefícios dependem de um encaminhamento correto, de DNS e da segurança dos endpoints.

Defina a rota

Decida se o túnel transporta apenas tráfego de serviços privados ou todo o tráfego de internet. Configure as rotas permitidas intencionalmente e considere tanto IPv4 quanto IPv6. Uma configuração de túnel dividido e uma de túnel completo têm considerações diferentes de vazamento e acessibilidade.

Mantenha uma chave por dispositivo

Gere chaves privadas no dispositivo sempre que possível e nunca as publique. Use identidades de pares separadas para que um dispositivo perdido possa ser revogado sem substituir todos os clientes. Armazene a configuração do servidor com permissões protegidas.

Configure o encaminhamento e DNS

Defina regras de encaminhamento e de firewall de forma deliberada. Verifique a resolução de nomes, a MTU e o caminho de retorno. Teste o endereço público efetivo e o comportamento de DNS a partir do cliente, em vez de assumir que um handshake bem-sucedido significa que todo o tráfego usa a rota pretendida.

Compreenda a mudança de confiança

Uma VPN auto-hospedada pode proteger o tráfego na rede local, mas o VPS e o upstream ainda veem metadados e qualquer tráfego não criptografado. Ela não torna uma sessão de navegador anônima nem substitui as políticas dos serviços que você acessa.

Use um listener explícito e inspecione o handshake

A UDP 51820 é uma escolha comum de configuração do WireGuard, não uma política de host obrigatória ou garantida. Abra apenas a porta UDP escolhida e mantenha a administração restrita separadamente. O comando wg show pode reportar informações de handshake e transferência dos pares sem exigir que você publique chaves privadas.

  • Verifique um handshake recente
  • Teste o serviço privado pretendido
  • Teste rotas de internet e DNS apenas se pretender um túnel completo
wg show

Use keepalives apenas quando a rede precisar deles

Um par atrás de NAT pode precisar de tráfego keepalive periódico para preservar um mapeamento para pacotes de entrada. A definição adequada depende da rede. Mantenha a configuração intencional; não copie uma receita de túnel completo se o objetivo for apenas o acesso a uma aplicação privada.

Escolha entre túnel dividido ou um design de túnel completo

Comece pelo objetivo real. Um túnel dividido pode transportar apenas uma sub-rede privada ou um serviço administrativo; um túnel completo também necessita de encaminhamento de internet, regras de saída e um plano DNS. Escolha endereços de túnel não sobrepostos e decida como IPv6 é tratado. UDP51820 é uma porta comum, não obrigatória. Confirme a política do anfitrião selecionado e mantenha o acesso à consola/administrador disponível enquanto altera rotas ou regras de firewall.

  • Dê a cada dispositivo um par de chaves único e uma identidade de par restrita.
  • Mantenha as chaves privadas nos dispositivos a que se destinam e fora de ficheiros públicos ou de partilha por QR.
  • Trate os endpoints públicos e o roaming de clientes como parte do design da rede.

Estabeleça um pequeno túnel antes de adicionar o encaminhamento de internet

Siga a instalação do SO suportado e gere chaves com permissões de ficheiro restritivas. Configure a interface do servidor, um par e o listener UDP escolhido. Um par do lado do servidor deve normalmente ter o seu próprio endereço de túnel em AllowedIPs, em vez de um catch-all sobreposto atribuído a vários clientes. Comece com acesso ao endereço do túnel e depois adicione o encaminhamento aprovado e as rotas de destino. Um handshake bem-sucedido prova o contacto com o par, não que o DNS ou a saída para a internet estejam corretos.

# Inspection examples; these do not reveal a private key:
wg show
ip address show dev wg0
ip route get 10.44.0.1

Teste o caminho esperado e um caminho proibido

A partir do cliente, verifique um handshake recente e um serviço privado permitido. Tente um destino que deva ser negado. Se utilizar um túnel completo, verifique a rota pública efetiva, o resolver DNS e o comportamento IPv6 a partir desse cliente; o tráfego de túnel dividido deve manter o caminho local pretendido. Repita após uma mudança de rede do cliente. Utilize um keepalive NAT apenas quando a rede do par o exigir, e mantenha o intervalo consistente com o design documentado.

  • Sem handshake: inspecione o endpoint DNS, a acessibilidade UDP, as chaves e o mapeamento de peers.
  • Handshake mas sem serviço: inspecione AllowedIPs, firewall, encaminhamento e a rota de retorno.
  • Alguns sites travam: investigue o MTU do caminho antes de aplicar um valor permanente aleatório.

Torne a revogação e o comportamento de reinicialização repetíveis

Remova a chave de par de um dispositivo perdido e confirme que já não consegue estabelecer o acesso pretendido. Mantenha cópias de segurança encriptadas da configuração e um inventário de qual chave pública pertence a qual dispositivo. Teste se a interface e as regras de encaminhamento necessárias regressam após um reinício normal. Uma VPN transfere a confiança para o VPS e para o seu upstream; não remove identificadores de aplicações, cookies de conta nem a necessidade de HTTPS até ao destino final.

CONFIGURE SUA INFRAESTRUTURA

Assuma o controle.
Implemente nos seus termos.

Sem documentação de identidade. Acesso total de administrador. Faturação nativa em cripto.