Mituri despre MTU la VPN: de ce pachetele tale se micșorează și unde se duce spațiul

Cineva îți spune că VPN-ul "pierde pachete din cauza MTU", tu setezi tunelul la 1400 și transferul funcționează din nou. Acel rezultat pare un diagnostic. De obicei este o coincidență aritmetică: ai ales un număr suficient de mic încât să încapă sub o limită pe care nu ai identificat-o niciodată, și vei întâlni aceeași limită din nou în următoarea rețea, cu un alt buget.

Două mituri cauzează cea mai mare parte a acestui lucru. Primul este că MTU-ul interfeței tunelului este MTU-ul căii. Al doilea este că încapsularea costă "un antet" și că PPPoE nu costă nimic care merită numărat. Ambele sunt greșite în feluri care fac numărul ales să pară arbitrar, deși este de fapt determinat.

Mitul unu: MTU-ul tunelului este MTU-ul căii

Valoarea pe care o setați pe o interfață de tunel este o promisiune locală despre cel mai mare pachet intern pe care implementarea îl va preda mai departe. Capacitatea reală a căii este o proprietate a fiecărei legături dintre dumneavoastră și capătul îndepărtat, și se poate schimba când se schimbă o rută, când o conexiune mobilă este predată sau când traficul ia alt peering. Un 1500 configurat vă spune ce va construi gazda dumneavoastră, nu ce va transporta rețeaua.

Descoperirea MTU-ului căii există pentru a reconcilia cele două și depinde de feedback. În IPv4, un router care nu poate transmite un pachet de dimensiune completă ar trebui să trimită un mesaj ICMP "fragmentation needed", iar expeditorul își reduce estimarea. În IPv6, echivalentul este un mesaj Packet Too Big, iar routerele nu fragmentează deloc în tranzit. Când acel feedback este filtrat, expeditorul continuă să producă pachete pe care calea nu le poate transporta, și nimic nu-i spune de ce.

Mitul doi: încapsularea costă un antet

Numărați straturile exterioare cu onestitate. Un antet IP exterior are 20 de octeți în IPv4 sau 40 în IPv6. Încapsularea UDP pentru traversarea NAT adaugă 8. Protocolul tunelului adaugă propriul antet, un vector de inițializare sau nonce, umplutură până la limita de bloc sau aliniere a cifrului, o coadă și o valoare de verificare a integrității. În funcție de protocol și cifru, totalul se situează confortabil în zeci de octeți înainte ca pachetul intern să înceapă.

Apoi scădeți din nou antetele pachetului intern însuși. Un segment TCP din interiorul tunelului poartă propriul antet IP de 20 de octeți și antet TCP de 20 de octeți, iar MSS-ul din TCP derivă din MTU, nu din încărcătura nominală a tunelului. De aceea ping cu o încărcătură mai mică poate reuși în timp ce un transfer de fișier se blochează: uneltele testează lucruri diferite, și doar unul dintre ele exercită un segment TCP de dimensiune completă.

ip link show tun0
ping -M do -s 1472 192.0.2.10
ping -M do -s 1400 192.0.2.10

Prima comandă raportează MTU-ul configurat al tunelului. Cele două sonde trimit o încărcătură de 1472 de octeți, care cu 28 de octeți de antete IPv4 și ICMP este un pachet de 1500 de octeți, apoi unul mai mic. Dacă sonda mare eșuează complet și cea mică reușește, aveți o defecțiune dependentă de dimensiune, nu o problemă generală de rutare.

Mitul trei: PPPoE vă mai dă 1500 curat

O legătură de acces PPPoE convențională nu transportă un pachet IP de 1500 de octeți. Antetul PPPoE plus câmpul de protocol PPP ocupă 8 octeți în cadrul Ethernet, lăsând 1492 pentru pachetul IP. Aceasta este limita tradițională descrisă în RFC 2516. Dacă rulați un VPN peste o astfel de legătură, suprasarcina tunelului vine din acei 1492, nu din 1500.

RFC 4638 definește o modalitate de a negocia o încărcătură PPP mai mare atunci când atât concentratorul de acces, cât și echipamentul clientului o susțin, motiv pentru care "această conexiune folosește PPPoE" singur nu dovedește un număr anume. O setare locală nu poate obliga un dispozitiv intermediar să accepte un pachet pentru care nu a fost niciodată configurat, așa că întrebarea utilă este ce a negociat de fapt legătura, nu ce spune eticheta.

De ce defecțiunea pare selectivă

Faptul că cererile mici reușesc și transferurile mari se blochează este semnătura clasică a unei găuri negre a MTU-ului căii. Strângerea de mână, interogarea DNS și apelul API încap toate; transferul în bloc produce segmente de dimensiune completă care mor pe o singură legătură, iar mesajul ICMP care ar fi trebuit să raporteze problema nu ajunge niciodată. Conexiunea pare în regulă și descărcarea se blochează, ceea ce îi face pe oameni să se uite la server în loc de cale.

O a doua greșeală înrudită este confuzia dintre trei numere: MTU-ul interfeței, MSS-ul din TCP și setarea proprie de fragmentare sau umplutură a protocolului. Strângerea MSS pe un router rescrie MSS-ul anunțat pentru ca expeditorul să construiască segmente mai mici; nu schimbă MTU-ul tunelului și nu ajută traficul UDP. A da același număr tuturor trei pentru că par înrudite este modul în care o modificare bine intenționată strică o configurație care funcționează.

Ce să schimbați și în ce ordine

Începeți cu dovezi. Confirmați cu sondele de mai sus că defecțiunea depinde de dimensiune, apoi găsiți cea mai mică dimensiune care trece și cea mai mare care eșuează. Verificați MTU-ul real al legăturii de acces înainte de a da vina pe tunel; o legătură PPPoE limitează bugetul înainte ca VPN-ul să o atingă. Notați valorile originale pentru ca modificarea să poată fi anulată.

Apoi aplicați cea mai mică ajustare documentată de client. Mulți clienți oferă un MTU al tunelului plus o opțiune de corectare MSS, iar opțiunea MSS este adesea pârghia mai bună pentru TCP pentru că ajunge la expeditor fără a micșora fiecare pachet. Retestați aceeași destinație și același transfer, și notați numerele la care v-ați oprit. O valoare de tunel care funcționează într-o rețea de acces nu este o constantă universală, iar următorul sit va avea propriul buget.