O WireGuard funciona nos dados móveis mas não na mesma wifi

O túnel sobe nos dados móveis e depois fica em a ligar em casa, com o mesmo perfil, a mesma chave de par e nenhuma alteração de configuração pelo meio. A diferença está na viagem: um pedido de dentro da LAN para o endereço público do router não é a mesma viagem que um pedido que chega da internet. A maioria das passarelas domésticas ou não implementa o caminho de retorno ou implementa-o apenas para certos protocolos. Isso faz o sintoma parecer uma chave avariada quando nada na chave mudou. Determine que caminho falhou antes de tocar numa chave, num encaminhamento de porta ou num perfil de cliente.

Um endereço, dois caminhos diferentes

De fora, um pacote chega ao endereço público do router e uma regra de encaminhamento de porta entrega-o ao ouvinte WireGuard no host interno. De dentro, o cliente marca o mesmo endereço público, pelo que o pacote sai do cliente, chega ao router e tem de ser virado de volta para a LAN. É nessa viragem que os dois caminhos se separam, porque o router tem de traduzir um fluxo que sai e volta a entrar pela mesma interface. Muitas implementações descartam-no em vez de o traduzir, e o cliente fica então à espera de um aperto de mão que nunca foi enviado.

O comportamento costuma chamar-se NAT loopback ou hairpinning, e pertence ao router e não ao WireGuard; RFC 4787 expõe os casos de tradução em que uma passarela pode ou não suportá-lo. O WireGuard em si não tem opinião sobre o caminho, porque só vê pacotes que chegam à sua interface. Quando o router descarta o fluxo, o daemon nunca recebe nada, o cliente comunica um tempo limite de aperto de mão e o registo do servidor fica vazio. Um registo vazio é, portanto, uma pista sobre onde o pacote parou, não uma prova de que o servidor esteja em baixo. É também a razão pela qual reinstalar não muda nada.

O contrário também conta: um registo do servidor que mostra uma tentativa de aperto de mão a partir do endereço da LAN prova que o pacote chegou e que o caminho está bem, o que desloca a investigação para chaves e endereços permitidos. Leia o registo pelo que ele prova e não pelo que esperava ver.

Reproduza-o antes de mudar o que quer que seja

Teste a partir de uma rede externa autorizada com o mesmo dispositivo e o mesmo perfil, e repita depois o teste dentro da LAN sem editar nada. Um aperto de mão concluído fora e um cliente que dentro nunca sai do dispositivo reproduzem a condição em vez de a adivinhar. As duas tentativas têm de usar o mesmo perfil, ou a comparação não prova nada.

Veja depois para onde resolve o nome do ponto final neste dispositivo. Os três comandos seguintes também mostram que endereço o cliente marcou de facto:

wg show wg0 endpoints
dig +short vpn.example.net A
resolvectl query vpn.example.net

O primeiro comando indica o ponto final que a interface está a usar neste momento, e os outros dois mostram para onde o nome resolve nesta máquina. Um cliente que marca um endereço público enquanto está na mesma rede que o servidor está a exercer o caminho de hairpin. Um cliente que marca o endereço da LAN não o faz, e uma falha aí pertence a outra investigação. Essa distinção decide se a secção seguinte se aplica sequer.

Formas suportadas de chegar a um servidor próximo

A disposição mais limpa é uma resposta de horizonte dividido: o nome público resolve para o endereço público na internet e para o endereço de LAN do servidor nos clientes de dentro. O perfil mantém um único nome de ponto final e o resolvedor escolhe o caminho. Isso exige controlo da resposta DNS interna, que um router doméstico costuma oferecer e uma organização pode organizar de propósito. Sem esse controlo, as opções que restam são uma função do router ou um segundo perfil.

A função do router é a reflexão: a passarela traduz o fluxo de dentro para fora e devolve-o para dentro. Onde funciona não precisa de qualquer alteração no cliente, e onde não funciona nenhuma definição do cliente o salva. Teste-a observando o registo do servidor durante uma tentativa interna em vez de ler a lista de funções do router.

Editar o perfil para um endereço privado é um diagnóstico, não um desenho. Prova que o servidor responde na LAN, e quebra o mesmo perfil no momento em que o portátil sai de casa.

Mantenha o perfil utilizável fora de casa

Escolha o caminho que escolher, deixe a verificação de identidade em paz. O endereço do ponto final não é a identidade do par, e uma mudança de endereço nunca justifica aceitar uma chave pública alheia que por acaso responda. O WireGuard autentica por chave, pelo que um anfitrião errado falha o aperto de mão em vez de conceder acesso a algo inesperado.

Se o endereço público se mover, o DNS dinâmico é o que mantém o nome útil, e o comportamento de atualização do cliente decide com que rapidez a mudança chega. Teste-o de fora após uma mudança de endereço, porque o caso da LAN não o pode validar. Esteja atento a um resolvedor que guarde em cache a resposta antiga para além da vida do registo. Um nome que ainda aponta para o endereço anterior parece exatamente um servidor que caiu.

Anote que nome o perfil usa e para onde resolve em cada lado da fronteira. Um perfil que depende de uma função do router que ninguém registou é uma chamada de suporte à espera da próxima atualização de firmware. A nota é também o que diz à pessoa seguinte se uma falha interna é o caso conhecido de hairpin ou algo novo.