WireGuard bloquéase: un límite de MTU ou unha regra de reenvío ausente?

O costume é baixar o MTU en canto WireGuard empeza a comportarse mal, e ese costume agocha outra avaría. Unha pasarela que non reenvía e un camiño que non transporta paquetes grandes producen patróns distinguibles: un falla en ambas as direccións e en todos os tamaños, o outro sobrevive ás peticións pequenas e morre coas grandes. Identifique que forma ten antes de cambiar calquera número. A proba é barata e elimina a metade das causas posibles.

Dous fallos, dúas formas distintas

Un problema de reenvío aparece xusto despois do servidor. O aperto de mans funciona, a dirección do túnel responde, e nada detrás da pasarela é accesible nin cunha petición minúscula. O paquete chegou ao servidor e non se pasou, ou a resposta non tiña ruta de volta.

Un problema de tamaño só aparece por riba dun limiar. O DNS, un aperto TCP e unha chamada pequena á API funcionan, mentres que a descarga dun ficheiro ou unha resposta grande se colgan. Os paquetes que cabían viaxaron de extremo a extremo, e os que non cabían descartáronse nalgún punto sen un informe útil.

Esas descricións apuntan a persoas distintas e a ficheiros de configuración distintos, por iso medir a forma vale máis ca unha conxectura. Un só ping á pasarela non pode separalas.

Descarte o reenvío antes de encoller nada

Probe un destino máis alá da pasarela, non a pasarela mesma. Un ping á dirección do túnel do servidor só demostra que a interface está activa e que pode chegar á máquina que remata o túnel. O tráfico para a rede máis ampla depende de que o reenvío IP estea activado nesa máquina e dun cortalumes que permita o fluxo reenviado. As dúas cousas deben ser certas, e se unha é falsa prodúcese o mesmo silencio.

O encamiñamento de volta importa o mesmo. Se a rede de destino non sabe como chegar á dirección do túnel do cliente, a petición chega e a resposta desaparece, e o cliente informa dun tempo de espera que parece idéntico a un reenvío descartado.

Onde o deseño usa tradución de direccións, a regra de tradución forma parte dese camiño de volta. Quitala mentres se persegue un problema de MTU converte un deseño que funciona nun roto, así que lea as regras existentes antes de editalas.

Mida onde comeza a rotura

Primeiro lea o estado do reenvío e as regras de filtrado. Son comprobacións de só lectura e responden á pregunta barata:

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

Despois probe tamaños co bit de non fragmentar, desde o cliente, cara a un equipo máis alá da pasarela:

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

Se a primeira proba funciona e a segunda falla cun erro de fragmentación, o camiño está a dicirlle o seu tamaño utilizable. Se non funciona ningunha, está a mirar un reenvío ou un encamiñamento, e o MTU non é a variable que hai que cambiar.

Repare a capa que demostrou

Cando o reenvío é a avaría, a corrección é unha regra de reenvío ou unha ruta, expresada coa estreiteza que o deseño permita. Cando o tamaño é a avaría, a corrección é un MTU que ten en conta a encapsulación neste camiño concreto, aplicado á interface que o necesita e non a cada adaptador da frota.

De calquera xeito, despois repita a mesma tarefa contra o mesmo destino. Se a transferencia grande orixinal agora se completa, o cambio abordou a capa que fallaba. Se só mellorou a proba pequena, tratou un síntoma e o límite real segue no seu sitio.

Anote que forma observou antes do cambio. Esa única liña, rexistrada xunto á corrección, é o que impide que a seguinte persoa baixe un MTU que nunca foi o problema.