Gaura neagră MTU: de ce cererile mici funcționează, dar încărcările se blochează

O pagină se încarcă, un apel API mic revine, apoi o încărcare de fișier atârnă până când clientul renunță. Nimic din jurnalul serverului nu explică asta, pentru că pachetele au fost aruncate la mijlocul traseului fără ca un răspuns util să fie trimis înapoi. Acest tipar este o gaură neagră MTU: o legătură mai îngustă decât presupune expeditorul, plus o refuzare tăcută de a spune asta. Dimensiunea care eșuează este repetabilă, și exact asta o face diagnosticabilă.

Ce face gaura neagră

Fiecare legătură are o unitate maximă de transmisie, iar un pachet mai mare decât limita saltului următor trebuie fie fragmentat, fie respins cu un mesaj ICMP care spune asta. Descoperirea MTU a traseului depinde de sosirea acelui mesaj și de respectarea lui. Filtrărea sau ignorarea lui îl lasă pe expeditor să repete un pachet care nu va încăpea niciodată.

Încapsularea face asta obișnuită în jurul VPN-urilor, pentru că un tunel adaugă un antet exterior unui pachet dimensionat deja pentru legătura fizică. Pachetul interior este legal la 1500 de bați, iar cel încapsulat nu este, așa că moare la frontieră în timp ce pachetele mici trec. O strângere de mână finalizată și o pagină de autentificare care funcționează dovedesc doar că pachetele mici funcționează. Cel mai mare pachet pe care aplicația încearcă să îl trimită este cel care contează.

Găsiți dimensiunea la care se rupe

Căutați binar dimensiunea sarcinii utile cu un test fără fragmentare, de la un gazdă de o parte a tunelului la o gazdă de cealaltă parte. Cea mai mare sarcină utilă care trece este MTU-ul de traseu utilizabil minus suprasarcina antetului.

ping -M do -s 1400 -c 2 192.0.2.20
ping -M do -s 1200 -c 2 192.0.2.20
ping -f -l 1372 192.0.2.20

O sarcină utilă de 1472 de bați trece pe un traseu Ethernet curat de 1500 de bați după ce se adaugă cei 28 de bați ai antetelor IPv4 și ICMP. Când același test reușește doar la o sarcină mai mică după ridicarea tunelului, diferența este suprasarcina de încapsulare, iar frontiera tunelului este locul unde mesajul de respingere ar fi trebuit generat. Notați ambele numere, înainte și după conectare, pentru că acea pereche este dovada. Repetați testul pentru IPv6 când aplicația îl folosește, deoarece antetul este mai mare și pragul de eșec se mișcă.

Citiți dovezile înainte de a da vina pe tunel

Erorile aplicațiilor la distanță, congestia și pierderea obișnuită blochează și ele încărcările, așa că un singur transfer eșuat nu identifică o gaură neagră. Ceea ce le separă este relația de dimensiuni: un succes repetabil la 1200 de bați și o blocare repetabilă la 1400 de bați, în aceeași direcție, prin același punct final.

O captură la ambele capete arată pachetele mari plecând și nu ajung niciodată, fără respingere între ele. Acesta este momentul să priviți dispozitivul de frontieră în locul serverului, care răspunde la fiecare cerere pe care o primește efectiv. Congestia blochează și ea, dar blochează dimensiuni diferite la momente diferite, iar aceasta este o altă semnătură.

Verificați reparația pe ambele transporturi

Reparația acceptată este să lăsați frontiera să raporteze limita reală, sau să strângeți acolo dimensiunea maximă a segmentului TCP, ca să nu fie încercat niciun segment prea mare. Scăderea fiecărui MTU din rețea, sau dezactivarea firewall-ului, ascunde simptomul și lasă o configurație despre care nimeni nu va mai putea raționa.

ip link show dev tun0
sudo nft list ruleset | grep -i -E 'mtu|mss'
sysctl net.ipv4.tcp_mtu_probing
ping -M do -s 1400 -c 2 192.0.2.20

Verificați cu același test de dimensiune, apoi cu aplicația care a eșuat, și verificați un al doilea protocol, pentru că aplicațiile UDP nu primesc niciodată corecția de dimensiune a segmentului TCP. Păstrați valorile originale în tichet, pentru că o reparație care nu poate fi anulată este o a doua problemă care așteaptă să se întâmple. Dacă testul de dimensiune trece și încărcarea tot se blochează, gaura neagră nu a fost cauza, iar investigația trebuie să meargă mai departe în loc să extindă schimbarea.