Descoperirea MTU-ului căii prin VPN: dimensionare și golul ICMP

Un tunel își finalizează handshake-ul, cererile mici revin, iar primul transfer mare se blochează. Acest tipar indică MTU-ul căii cu mult înainte de a indica debitul. Fiecare legătură de pe rută limitează dimensiunea pachetului, iar încapsularea consumă o parte din acea alocație pentru antete exterioare, așa că pachetul interior trebuie să fie mai mic decât ar sugera calea brută. Defecțiunea este silențioasă, și exact de aceea este scump de diagnosticat.

Ce măsoară de fapt MTU-ul căii

MTU-ul căii este cel mai mic MTU de legătură de pe ruta dintre două gazde, nu MTU-ul imprimat pe interfața locală. Valoarea locală este punctul de unde începe estimarea, iar calea decide unde trebuie să se termine. De aceea un tunel identic poate funcționa într-o rețea de acces și se poate bloca în alta: ruta s-a schimbat, nu configurația. A măsura o dată și a presupune peste tot este greșeala care ține această problemă în viață.

Pentru un tunel, numărul care contează este MTU-ul interior, adică alocația căii exterioare minus ce consumă încapsularea. WireGuard adaugă un antet IP exterior și un antet UDP; alte transporturi le adaugă pe ale lor. Setează dimensiunea interioară prea mare și fiecare pachet de dimensiune completă va avea nevoie de fragmentare care poate nu se va întâmpla niciodată.

De ce un tunel micșorează pachetul utilizabil

Dacă interfața tunelului păstrează MTU-ul legăturii fizice, fiecare pachet mare depinde de cineva din aval dispus să îl fragmenteze. IPv4 permite asta în principiu, dar un router căruia i s-a spus să nu fragmenteze returnează o eroare. Routerele IPv6 nu fragmentează niciodată în tranzit, așa că aceeași setare se comportă diferit în funcție de familia de adrese. În orice caz, expeditorul nu află nimic până când ceva nu raportează înapoi.

Consecința practică este o dimensiune care încape în handshake și nu în payload. Un TLS ClientHello sau o interogare DNS sunt suficient de mici pentru a traversa neatins o cale micșorată, în timp ce un transfer masiv nu este. De aceea simptomele se grupează în jurul unor operațiuni specifice, nu al unor gazde specifice.

Descoperirea funcționează doar când sosește feedback-ul

Descoperirea IPv4 se bazează pe bitul don't-fragment: un router care nu poate înainta pachetul returnează ICMP fragmentation-needed cu MTU-ul următorului salt, iar expeditorul își reduce estimarea. IPv6 folosește în schimb mesaje Packet Too Big, pentru că routerele nu fragmentează în tranzit. Ambele mecanisme presupun că mesajul găsește drumul înapoi la expeditor, prin tunel și pe lângă orice firewall de pe calea de întoarcere. Când această presupunere eșuează, expeditorul continuă să reîncerce o dimensiune pe care calea nu o poate transporta.

Un firewall care permite echo request și echo reply nu a permis neapărat acele tipuri de erori. ICMP este o familie, iar membrii care contează aici sunt erorile, nu perechea de echo. Verifică politica de trafic de control la ambele capete ale tunelului și pe calea dintre ele, și urmează îndrumările acceptate ale platformei în loc să permiți orice tip ICMP pretutindeni.

Aceeași filtrare poate sta în interiorul tunelului. Dacă calea interioară aruncă eroarea dar cea exterioară o transportă, expeditorul se poate adapta la o limită pe care traficul încapsulat nu o vede niciodată cu adevărat.

Testează calea în loc să ghicești un număr

Ține destinația, rețeaua de acces și tunelul fixe, apoi variază doar dimensiunea pachetului. Un test don't-fragment care eșuează cu un indiciu de MTU îți dă limita următorului salt; repetă până când o dimensiune trece, și notează atât dimensiunea, cât și familia de adrese.

ping -M do -s 1400 10.60.20.10
ping -M do -s 1300 10.60.20.10
ping -6 -M do -s 1300 2001:db8::10

Un ping care încape nu dovedește că segmentele de dimensiune completă ale unei aplicații reale încap, așa că repetă testul cu transferul care a eșuat de fapt. Compară cel mai mare test care a funcționat cu MTU-ul tunelului pe care l-ai configurat, și ține cele două numere separate în notițele tale. Dacă diferă cu aproximativ un antet, ai găsit suprasarcina încapsulării, nu un defect.

PLPMTUD, descris în RFC 4821, testează în sus și folosește confirmări de transport în loc să se bazeze pe erorile livrate. Ajută pe căile care filtrează ICMP, dar suportul variază în funcție de stivă și de aplicație. Un flux TCP se poate recupera singur, în timp ce o aplicație UDP cu dimensiune fixă a datagramei continuă să eșueze.

Alege o valoare și notează raționamentul

Scăderea MTU-ului tunelului este atât un diagnostic, cât și o corecție legitimă odată ce cunoști calea. Nu înlocuiește cunoașterea căii și a mecanismului de feedback implicate, pentru că o valoare reglată pentru o legătură mobilă va fi inutil de mică pe o conexiune de fibră. Notează dimensiunea aleasă, testul care a justificat-o și pasul de revenire.

Mecanismul IPv4 este descris în RFC 1191, iar îndrumările de împachetare IPv6 în RFC 8201; menționarea ambelor îl împiedică pe următorul inginer să rederive presupunerea. Dacă transferul încă se blochează la dimensiunea aleasă, oprește scăderea numărului și uită-te la următorul strat. O cale care eșuează la orice dimensiune nu este o problemă de MTU.