Chave privada aqui, chave pública ali: as chaves do WireGuard
A sua chave privada fica no seu dispositivo; a entrada de par contém a chave pública do outro lado. Partilhe apenas a metade pública e dê a cada dispositivo a sua própria identidade.
A maioria das falhas de WireGuard montadas à mão resume-se a qual chave foi parar onde. A secção de interface leva a chave privada do dispositivo que está a configurar, enquanto uma secção de par leva a chave pública da máquina do outro extremo. Trocar essas metades, ou colar a errada, produz um handshake que nunca se completa e um registo que nunca nomeia uma chave. Faça as quatro verificações abaixo por ordem antes de tocar em AllowedIPs ou DNS.
Duas chaves, duas direções
Uma chave privada pertence exatamente a um dispositivo e fica na secção de interface desse dispositivo. A sua metade pública é o que qualquer outro par precisa para reconhecer o dispositivo, e as ferramentas derivam-na em vez de a inventarem. No servidor, a chave pública do seu dispositivo aparece como uma entrada de par; no seu dispositivo, a chave pública do servidor ocupa esse papel. Ler uma configuração em voz alta com esses termos apanha a maioria das confusões antes de chegarem a um handshake.
O comando wg imprime o que a interface local está realmente a usar, incluindo as duas chaves públicas. Isso torna-o na forma mais rápida de separar um erro de configuração de um problema de conetividade:
wg show
wg show interfacesA primeira saída lista cada par com a sua chave pública, o endpoint que usou por último e a idade do seu último handshake. Uma idade de handshake «nunca» de um lado e recente do outro aponta para uma chave que só um extremo aceitou. O segundo comando nomeia as interfaces que pode inspecionar mais a fundo.
O que partilhar e o que nunca partilhar
Uma chave pública destina-se a ser entregue, embora ainda identifique uma relação de dispositivos, por isso enviá-la ao administrador que a pediu é diferente de a publicar. Uma chave privada nunca sai do dispositivo que a gerou. Um perfil exportado ou um código QR contém toda a configuração, incluindo essa chave privada, pelo que nenhum dos dois é seguro para fazer circular, e esconder o texto dentro de uma imagem não muda nada. As chaves pré-partilhadas são opcionais e igualmente secretas, e ambos os extremos têm de ter o mesmo valor, senão o handshake para nessa etapa.
Outra distinção merece ser dita sem rodeios: um endpoint é um endereço e uma porta, nunca uma chave. Colar uma chave pública no campo do endpoint, ou um endereço num campo de chave, produz um perfil que é analisado e depois não faz nada. As ferramentas não o apanham, porque ambos os campos são apenas cadeias. O início rápido do WireGuard mostra a cadeia de geração e derivação numa linha.
Um dispositivo, uma entrada de par
Onde o serviço o permite, cada dispositivo deve levar a sua própria identidade de par. Colar o perfil completo de um portátil num telefone torna difuso qual dispositivo detém essa identidade no servidor e torna mais difícil revogar um único telefone perdido. Se uma chave privada escapar, remova a autorização antiga do par no servidor e arranje um substituto. Apagar o ficheiro local não remove a entrada do servidor, e uma nova chave de cliente não ajuda ninguém até o servidor conhecer a sua metade pública.
Mantenha a correspondência entre dispositivo e chave pública junto à lista de endereços. É essa lista que transforma uma revogação numa tarefa de dois minutos em vez de uma tarde inteira.
O que continua a falhar depois do handshake
Os pares de chaves identificam pares; não decidem o comportamento da rede. O AllowedIPs associa intervalos de endereços a um par, e as rotas em volta são geridas pelo cliente ou pela ferramenta de configuração. O sintoma costuma dizer que camada abrir a seguir:
| What you see | Which key problem it usually means | Where to look first |
|---|---|---|
| Handshake age stays at never on both ends | Peer public key missing, or an endpoint pointing at nothing | wg show, then the endpoint value |
| Handshake completes on one side only | The two ends hold different public keys for each other | wg show on both hosts |
| Handshake works, then no traffic | AllowedIPs or routes rather than keys | wg show and the route table |
| Worked until a key was regenerated | The peer entry still holds the old public key | Compare both public keys, then update the peer |
O DNS pode falhar depois de ambos os pares se autenticarem corretamente, e uma aplicação pode falhar enquanto o túnel está saudável, por isso um handshake a funcionar não é o fim do diagnóstico. As chaves também não dizem nada sobre a prática de registo de um operador nem sobre se um site reconhece a sua conta, e essas perguntas pertencem a outro lugar. Passe às camadas de rede quando as quatro verificações passarem, porque uma chave em falta não é um problema de encaminhamento disfarçado.