WireGuard trava: um limite de MTU ou uma regra de encaminhamento ausente?

O hábito é baixar o MTU assim que o WireGuard se comporta mal, e esse hábito esconde outra falha. Um gateway que não encaminha e um caminho que não transporta pacotes grandes produzem padrões distinguíveis: um falha nos dois sentidos e em todos os tamanhos, o outro sobrevive a pedidos pequenos e morre nos grandes. Identifique que forma tem antes de mudar qualquer número. O teste é barato e elimina metade das causas possíveis.

Duas falhas, duas formas diferentes

Um problema de encaminhamento aparece logo depois do servidor. O aperto de mão funciona, o endereço do túnel responde, e nada atrás do gateway é alcançável nem com um pedido minúsculo. O pacote chegou ao servidor e não foi passado, ou a resposta não tinha rota de volta.

Um problema de tamanho só aparece acima de um limite. O DNS, um aperto de mão TCP e uma chamada pequena à API funcionam, enquanto o download de um ficheiro ou uma resposta grande ficam pendurados. Os pacotes que cabiam viajaram de ponta a ponta, e os que não cabiam foram descartados algures sem um relatório útil.

Essas descrições apontam para pessoas diferentes e ficheiros de configuração diferentes, por isso medir a forma vale mais do que um palpite. Um único ping ao gateway não os consegue separar.

Exclua o encaminhamento antes de encolher qualquer coisa

Teste um destino para além do gateway, não o gateway em si. Um ping ao endereço do túnel do servidor só prova que a interface está ativa e que chega à máquina que termina o túnel. O tráfego para a rede mais ampla depende de o encaminhamento IP estar ativo nessa máquina e de uma firewall que permita o fluxo encaminhado. As duas coisas têm de ser verdadeiras, e se uma for falsa produz-se o mesmo silêncio.

O encaminhamento de retorno importa tanto como isso. Se a rede de destino não souber como chegar ao endereço do túnel do cliente, o pedido chega e a resposta desaparece, e o cliente comunica um tempo esgotado que parece idêntico a um encaminhamento descartado.

Onde o desenho usa tradução de endereços, a regra de tradução faz parte desse caminho de retorno. Removê-la enquanto se persegue um problema de MTU transforma um desenho que funciona num quebrado, por isso leia as regras existentes antes de as editar.

Meça onde começa a quebra

Leia primeiro o estado do encaminhamento e as regras de filtragem. São verificações só de leitura e respondem à pergunta barata:

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
ip route get 10.30.0.9

Depois teste tamanhos com o bit de não fragmentar, a partir do cliente, em direção a um anfitrião para além do gateway:

ping -M do -s 1200 10.30.0.9
ping -M do -s 1400 10.30.0.9

Se o primeiro teste funcionar e o segundo falhar com um erro de fragmentação, o caminho está a dizer-lhe o seu tamanho utilizável. Se nenhum funcionar, está a olhar para encaminhamento ou para encaminhamento de rotas, e o MTU não é a variável a mudar.

Repare a camada que provou

Quando o encaminhamento é a falha, a correção é uma regra de encaminhamento ou uma rota, expressa tão estreitamente quanto o desenho permite. Quando o tamanho é a falha, a correção é um MTU que tem em conta a encapsulação neste caminho concreto, aplicado à interface que precisa dele e não a cada adaptador da frota.

De qualquer forma, repita depois a mesma tarefa contra o mesmo destino. Se a transferência grande original agora se conclui, a alteração tratou da camada que falhava. Se só o teste pequeno melhorou, tratou um sintoma e o limite real continua no lugar.

Anote que forma observou antes da alteração. Essa única linha, registada ao lado da correção, é o que impede a pessoa seguinte de baixar um MTU que nunca foi o problema.