Perfil WireGuard copiado: por que os dois dispositivos falham

O túnel funcionava no portátil, então o arquivo de configuração passou para o telefone e o tablet, e agora os handshakes vão e vêm nos três. Nada foi digitado errado e a configuração do servidor não foi editada. Um perfil WireGuard não é uma conta com senha que vários dispositivos podem usar; é um par de chaves, e só a metade pública identifica um par. Copiar o arquivo copia a identidade, por isso o servidor tenta agora manter uma única relação de ponto final para vários dispositivos que todos afirmam ser o mesmo. Do lado do servidor não há um segundo dispositivo a notar, apenas um par cujo endereço não para de mudar.

Comece pelo registro de handshakes de cada dispositivo

Abra o cliente em cada dispositivo e anote a hora do último handshake e o ponto final atual antes de alterar qualquer coisa. Numa configuração saudável esses valores permanecem estáveis enquanto o dispositivo está em uso; com uma identidade duplicada as marcas de tempo alternam, e o ponto final registrado no servidor pode descrever um dispositivo diferente daquele que tem o perfil. Essa alternância é a assinatura, e explica por que o sintoma parece uma conectividade instável e não um erro de configuração. Os dispositivos não estão quebrados; estão interrompendo uns aos outros.

Faça a leitura nos próprios dispositivos, para que cada observação fique ligada a uma máquina específica. Um carimbo de data e hora copiado de um chat de suporte perde essa ligação e depois vale muito pouco.

Confirme se dois dispositivos compartilham uma identidade

Compare as chaves públicas, nunca as privadas. A chave pública é derivada da privada, então dois perfis com a mesma chave privada produzem a mesma chave pública e são indistinguíveis para o servidor. Se dois dispositivos informarem a mesma chave pública, a questão está resolvida e nenhum ajuste de keepalive ajudará. Duas chaves diferentes com handshakes instáveis apontam para outro lugar completamente, e por isso a comparação precisa vir antes de qualquer mudança.

wg show wg0 public-key
wg show wg0 latest-handshakes
wg show wg0 endpoints
wg show wg0 transfer

Esses comandos imprimem apenas material público e contadores, e é disso que uma conversa de suporte precisa. Uma entrada de par no servidor com uma chave pública e um ponto final que não para de se mover entre duas redes é o resultado esperado da duplicação, porque um pacote autenticado de uma nova origem atualiza para onde o tráfego é enviado. Esse comportamento é o protocolo funcionando como projetado, e por isso é tão fácil confundi-lo com uma falha de rede.

Provisone uma segunda identidade corretamente

Gere um novo par de chaves no dispositivo que precisa dele e depois adicione a chave pública resultante ao servidor como um par separado com seus próprios endereços permitidos. A chave privada deve ser criada no dispositivo e ficar lá; uma chave gerada em outro lugar e colada passou por pelo menos um local adicional, e essa viagem agora faz parte da história de confiança.

umask 077
wg genkey > newdevice.key
wg pubkey < newdevice.key

O lado do servidor precisa da chave pública mais uma atribuição de endereço permitido que não colida com o dispositivo original. Um perfil que mantém o endereço antigo do túnel enquanto apresenta uma chave nova produz um par que o servidor pode aceitar e depois encaminhar errado, o que é uma falha mais sutil do que um handshake recusado. Verifique a atribuição de endereço antes de conectar, não depois da primeira perda de pacotes desconcertante.

Aposente o duplicado sem quebrar o original

Quando a nova identidade funcionar, remova o perfil copiado do entorno do dispositivo original em vez de apagar a entrada do servidor que o original ainda usa. Se a cópia puder ter sido exposta, revogue-a imediatamente e emita outra; conveniência não é motivo para deixar um segredo compartilhado em circulação.

Um serviço gerenciado que realmente suporte vários dispositivos por assinatura dirá isso e emitirá credenciais separadas na própria interface. A duplicação manual de um perfil nunca é esse modelo, mesmo quando a marca do serviço sugere dispositivos ilimitados.

Teste os dois dispositivos separadamente e juntos

Verifique cada dispositivo sozinho primeiro: handshake, contadores de transferência em movimento e um destino que só o túnel alcança. Depois execute os dois ao mesmo tempo e observe como o servidor vê os pontos finais; duas chaves distintas devem produzir duas entradas de par estáveis em vez de uma que salta.

Guarde as novas chaves públicas com as notas de implantação e registre qual dispositivo tem qual. Sem essa lista, a próxima pessoa que copiar um perfil repetirá a mesma falha, e os handshakes alternados serão novamente culpados pela rede.