Como construir um teste WireGuard com dois pares que prova um único caminho

Um teste WireGuard que carrega uma rota padrão, um prefixo LAN, DNS e uma exceção de firewall não pode dizer qual deles quebrou. Reduza-o a dois pares, um par de endereços e um único serviço permitido, e a falha não tem onde se esconder. A base entediante é o diagnóstico. Construa-a primeiro; leva quinze minutos e poupa a tarde que de outro modo você passaria adivinhando.

O que a base prova é mais estreito do que a maioria espera. Ela prova que duas identidades concordam, que o UDP chega à porta de escuta e que um destino permitido carrega uma requisição. Encaminhamento, NAT, rotas LAN e DNS são funções separadas a acrescentar depois, uma de cada vez.

Chaves, endereços e o único endpoint

Gere um par de chaves em cada sistema e mova entre eles apenas as metades públicas. wg genkey | tee privatekey | wg pubkey > publickey é o comando documentado de uma linha, e deixa a chave privada num ficheiro que você pode depois proteger. Escolha endereços de túnel de uma faixa que não apareça em nenhuma outra configuração sua, como 10.99.0.1/24 e 10.99.0.2/24. Anote qual endereço pertence a qual máquina, porque cada verificação posterior depende desse mapeamento.

Chaves privadas nunca viajam. Se um teste precisa de uma copiada para o outro lado, o teste já deu errado. Quando os dois sistemas estão atrás de NAT, pelo menos um precisa de uma porta UDP alcançável enquanto o outro carrega um Endpoint que aponta para ela, e o endereço e a porta públicos pertencem às suas notas, não às suas suposições sobre a 51820.

Um encaminhamento de porta que mapeia uma porta externa diferente funciona bem desde que o Endpoint corresponda. Divergências aqui produzem silêncio em vez de erros, e por isso vale a pena verificá-las no papel antes de depurar no cabo.

Os campos que pertencem ao wg e os que não pertencem

O conjunto de campos essenciais é pequeno: PrivateKey e ListenPort em Interface, PublicKey, AllowedIPs e Endpoint em Peer. Address e DNS pertencem ao wg-quick e não ao próprio wg, e essa distinção morde no momento em que a mesma configuração passa para outra ferramenta.

[Interface]
PrivateKey = <peer-a-private>
Address = 10.99.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <peer-b-public>
AllowedIPs = 10.99.0.2/32
Endpoint = 203.0.113.10:51820

AllowedIPs carrega duas tarefas ao mesmo tempo. Ele seleciona quais destinos entram no túnel, e autoriza o par a usar esses endereços de origem na chegada. Por isso a entrada espelho do outro lado tem de nomear exatamente o endereço do seu túnel; um /32 para o par errado lê-se como um problema de roteamento e comporta-se como um de autorização. O início rápido do WireGuard mostra a mesma forma de dois pares com a redação canónica se quiser comparar nomes de campos.

Ler o handshake em vez do ícone

Levante a interface através do que a possui e depois leia o estado em vez de uma luz de estado. wg show imprime o último handshake por par junto com os contadores de bytes, e um handshake nos últimos minutos significa que chaves, endpoint e caminho UDP funcionam todos. Um contador que só sobe numa direção é a sua própria resposta, e não é a mesma falha que um handshake que nunca acontece.

As duas falhas implicam investigações diferentes. A ausência total de handshake aponta para uma divergência de chaves, um Endpoint errado, UDP bloqueado ou uma firewall que descarta o próprio handshake. Um handshake que tem sucesso enquanto os dados não vão a lado nenhum aponta para AllowedIPs, um serviço que não escuta no endereço do túnel ou uma firewall do anfitrião que aceita a porta para a LAN mas não para a interface do túnel. São metades diferentes do sistema, e a base separa-as antes de começar a mudar regras.

Provar um serviço permitido e depois o inverso

Faça uma requisição ao endereço de túnel do outro par num serviço que deve responder, e escolha algo melhor do que ping. Uma resposta ICMP ausente pode ser filtragem do anfitrião e não uma falha do túnel, por isso um ping silencioso não prova nenhuma direção. Uma conexão TCP a uma porta que sabe estar aberta, ou uma requisição que devolve dados, dá-lhe uma resposta que pode interpretar.

Execute a direção inversa como um teste separado com o seu próprio resultado, porque as duas direções têm entradas separadas de firewall e AllowedIPs e podem falhar de forma independente. Se o handshake funciona e a requisição não, o problema está no caminho dos dados e não no túnel: AllowedIPs, o serviço à escuta ou uma firewall do anfitrião. Corrija isso antes de acrescentar encaminhamento, NAT ou DNS, ou passará a tarde a depurar uma função que nunca teve culpa.

Manter a base como referência

Guarde a topologia que funciona e a fonte do perfil num local de onde possa restaurar, e mantenha-as fora de qualquer diretório que sincronize com um serviço público. Depois acrescente uma função de cada vez, repetindo a requisição original após cada uma: encaminhamento, NAT, uma rota LAN e só depois DNS. Cada adição que quebra o teste é agora identificável, porque nada mais se moveu.

Uma base que só torna um ícone verde não lhe disse nada sobre qual adição causou a falha seguinte. Mantenha o único caminho permitido a funcionar como referência, e cada alteração posterior é medida contra ele.