Quem escolhe a MTU do WireGuard: o wg-quick, o kernel ou você

O WireGuard não tem negociação de MTU. Ele criptografa o que a interface lhe entrega e envia o resultado, e se o pacote encapsulado exceder o caminho, ele é descartado ou fragmentado em algum lugar que você não vê. Alguém precisa escolher a MTU da interface, e esse alguém é a ferramenta que subiu a interface.

Existem três candidatos, e é fácil confundi-los.

Três lugares de onde o valor pode vir

O valor pode ser definido explicitamente na configuração da interface, calculado pela ferramenta de configuração a partir das informações de rota, ou definido por qualquer gerenciador de rede que seja dono da interface. Uma chamada comum de wg não faz nada disso, porque o wg só gerencia chaves e pares. A MTU vive na interface de rede, e por isso ip link show wg0 é onde você a lê.

Se você não tem certeza de qual caso se aplica, leia primeiro a MTU e depois descubra quem iniciou a interface.

Decida por quem executa a interface

Se o wg-quick a inicia, uma linha MTU explícita vence; caso contrário, ele calcula um valor. Se um gerenciador de rede a inicia, o perfil desse gerenciador decide. Se um runtime de contêiner ou um cliente de provedor a inicia, leia a documentação deles em vez de presumir o comportamento do wg-quick.

A decisão não é qual número é melhor em abstrato. É qual componente você consegue realmente configurar.

O que o cálculo padrão faz

O wg-quick procura a rota até o endpoint do par, pega a MTU dessa interface de saída e subtrai a sobrecarga de encapsulamento. Com um cabeçalho externo IPv4 são cerca de 60 bytes; com IPv6 são cerca de 80. O resultado é limitado para que um caminho de 1500 bytes dê 1420 em vez de um valor que só funciona em uma família de endereços. Esse é um padrão razoável, não uma medição do seu caminho.

Ele não pode saber de um túnel posterior, de um link móvel ou de um caminho ICMP filtrado.

O limite esconde uma pergunta real. Se o seu caminho é de fato 9000 bytes de ponta a ponta, 1420 deixa desempenho na mesa, e se o caminho é 1400, 1420 já é grande demais. O padrão é um compromisso, e deve ser tratado como tal.

Quando o caminho muda sob os seus pés

Um notebook que passa de Ethernet para Wi-Fi e depois para o hotspot de um celular mantém a MTU da interface com que começou. O caminho externo pode agora ser menor, e nada renegocia. Túneis aninhados pioram a situação, porque cada camada subtrai a sua própria sobrecarga do mesmo orçamento. O valor que funcionava no escritório não é o valor que funciona no aeroporto.

Um handshake recente prova que as chaves funcionam. Não prova nada sobre se pacotes grandes cabem.

Teste um número por vez

Mantenha a mesma aplicação e o mesmo destino, mude um valor e meça. O ping -M do -s 1372 testa um pacote de 1400 bytes com o bit DF ligado, e esse é o tipo de teste que você quer. Se as requisições pequenas funcionam e as grandes travam, você tem um problema de tamanho e não de roteamento.

Mude apenas a MTU. Ajustar várias opções de pacote ao mesmo tempo não diz qual delas importava.

E não espere que uma mudança de MTU conserte uma rota de retorno ausente, uma regra de encaminhamento ou uma falha de DNS. Esses também produzem sintomas de ausência de tráfego, e têm os seus próprios testes. O manual do wg-quick documenta a seleção automática.