WireGuard se blochează: o limită MTU sau o regulă de redirecționare lipsă?

Obiceiul este să scazi MTU-ul imediat ce WireGuard se comportă prost, iar acest obicei ascunde o altă defecțiune. Un gateway care nu redirecționează și o cale care nu transportă pachete mari produc tipare distincte: unul eșuează în ambele direcții și la orice dimensiune, celălalt supraviețuiește cererilor mici și moare la cele mari. Stabiliți ce formă aveți înainte de a schimba orice număr. Testul este ieftin și elimină jumătate din cauzele posibile.

Două defecțiuni, două forme diferite

O problemă de redirecționare apare imediat după server. Strângerea de mână reușește, adresa tunelului răspunde, și nimic din spatele gateway-ului nu este accesibil nici măcar cu o cerere minusculă. Pachetul a ajuns la server și nu a fost transmis mai departe, sau răspunsul nu avea rută de întoarcere.

O problemă de dimensiune apare doar peste un prag. DNS, o strângere de mână TCP și un apel API mic funcționează, în timp ce descărcarea unui fișier sau un răspuns mare se blochează. Pachetele care au încăput au mers de la un capăt la altul, iar cele care nu au încăput au fost aruncate undeva fără un raport util.

Acele descrieri indică oameni diferiți și fișiere de configurare diferite, de aceea măsurarea formei valorează mai mult decât o presupunere. Un singur ping către gateway nu le poate separa.

Excludeți redirecționarea înainte de a micșora ceva

Testați o destinație dincolo de gateway, nu gateway-ul în sine. Un ping către adresa tunelului serverului dovedește doar că interfața este activă și că ajungeți la mașina care termină tunelul. Traficul pentru rețeaua mai largă depinde de redirecționarea IP activată pe acea mașină și de un firewall care permite fluxul redirecționat. Ambele trebuie să fie adevărate, iar dacă unul este fals apare aceeași tăcere.

Rutarea de întoarcere contează la fel de mult. Dacă rețeaua de destinație nu știe cum să ajungă la adresa tunelului clientului, cererea ajunge și răspunsul dispare, iar clientul raportează un timeout care arată identic cu o redirecționare aruncată.

Acolo unde proiectarea folosește traducerea adreselor, regula de traducere face parte din acea cale de întoarcere. Eliminarea ei în timp ce urmăriți o problemă de MTU transformă o proiectare funcțională într-una stricată, așa că citiți regulile existente înainte de a le edita.

Măsurați unde începe ruptura

Citiți mai întâi starea redirecționării și regulile de filtrare. Sunt verificări doar de citire și răspund la întrebarea ieftină:

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

Apoi testați dimensiuni cu bitul don’t-fragment, din client, spre o gazdă dincolo de gateway:

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

Dacă primul test funcționează și al doilea eșuează cu o eroare de fragmentare, calea vă spune dimensiunea sa utilizabilă. Dacă niciunul nu funcționează, vă uitați la redirecționare sau la rutare, iar MTU nu este variabila care trebuie schimbată.

Reparați stratul pe care l-ați dovedit

Când redirecționarea este defecțiunea, corecția este o regulă de redirecționare sau o rută, exprimată cât mai îngust permite proiectarea. Când dimensiunea este defecțiunea, corecția este un MTU care ține cont de încapsulare pe această cale anume, aplicat interfeței care are nevoie de el și nu fiecărui adaptor din flotă.

În orice caz, repetați apoi aceeași sarcină către aceeași destinație. Dacă transferul mare original se finalizează acum, schimbarea a abordat stratul care eșua. Dacă doar testul mic s-a îmbunătățit, ați tratat un simptom, iar limita reală este încă la locul ei.

Notați ce formă ați observat înainte de schimbare. Acea singură linie, înregistrată lângă corecție, este ce îl împiedică pe următorul să scadă un MTU care nu a fost niciodată problema.