Handshake sim, internet não: o que corrigir primeiro no Windows 11

No Windows 11, handshakes recentes costumam conviver com navegadores que não abrem nada. O handshake só prova que a troca UDP com o par foi concluída. Ele não diz nada sobre a rota que o Windows instalou, o resolver que ele usa, nem sobre se a saída encaminha alguma coisa.

Quatro condições decidem qual dessas camadas falhou. Percorrê-las em ordem leva minutos, enquanto reescrever as chaves leva mais tempo e não muda nada.

Decida a camada antes de tocar nas chaves

Percorra três destinos, nesta ordem. Comece por um endereço do lado do túnel, depois um IP público como número e termine com um nome de host. Onde a sequência quebra, ali se nomeia a camada. Uma falha no primeiro passo é roteamento, no segundo é encaminhamento ou NAT, e no terceiro é resolução de nomes.

Essa ordem é o método inteiro. Ela impede que uma falha de DNS seja diagnosticada como túnel quebrado, que é o desvio errado mais comum aqui.

wg show
Find-NetRoute -RemoteIPAddress 1.1.1.1
Resolve-DnsName example.com -Server 1.1.1.1

Se o tempo do handshake estiver vazio

Quando o tempo do handshake está vazio, a troca cifrada nunca foi concluída. Portanto, a falha está antes do roteamento. Olhe primeiro o endereço do endpoint e a porta, depois se a rede filtra UDP. Um provedor que descarta o tráfego do WireGuard produz exatamente isso, e também um cliente que copiou um endpoint de um perfil antigo.

Bytes que saem sem que nenhum entre são outro caso. Isso aponta para NAT ou para um firewall que devolve o tráfego ao lugar errado.

Se a rota perder para o adaptador físico

Para um túnel completo, a seção do par precisa cobrir os destinos que você espera usar. O Windows às vezes mantém a rota padrão do adaptador físico mesmo com uma regra geral configurada. Dividir a regra geral em 0.0.0.0/1 mais 128.0.0.0/1 cria dois prefixos mais específicos que ganham a busca. A divisão é um contorno documentado, não uma preferência.

Confirme com route print ou com uma consulta de endereço público. A interface escolhida deve ser o adaptador do túnel. Se o físico ainda ganhar, corrija as faixas do par antes de tocar no servidor.

Se os endereços funcionam e os nomes falham

O WireGuard transporta pacotes IP e não tem opinião sobre DNS. Coloque uma linha DNS = na seção de interface, ou configure o adaptador pelo Windows. Sem ela, um ping por endereço funciona enquanto todo nome de host falha, e os usuários relatam isso como falta de internet.

Verifique quais servidores o Windows realmente usa após conectar. Um resolver remanescente no adaptador físico explica uma falha parcial, em que alguns nomes resolvem e outros não. Limpe-o em vez de acrescentar um segundo em cima.

Se a máquina Windows for a saída

O Internet Connection Sharing reescreve o endereçamento quando está ativo, o que pode mover o adaptador compartilhado para outra faixa. Um cliente que ainda aponta para o endereço original então para de funcionar. Os valores de registro ScopeAddress e StandaloneDHCPAddress controlam essa faixa, e a configuração pode voltar após uma reinicialização.

Vale a pena olhar outros dois conflitos específicos do Windows. O serviço Routing and Remote Access pode interferir no túnel. Um instalador criado para a arquitetura errada falha com uma mensagem que nunca menciona arquitetura.

Corrija a camada que o teste nomeou e depois repita os mesmos três destinos. Uma mudança que conserta o teste do nome de host mas quebra o endereço do túnel foi aplicada à camada errada.