MTU sau MSS? Ce repară de fapt o modificare VPN

Ping-urile reușesc, transferurile mari se blochează, iar tunelul se declară sănătos. Cineva scade MTU-ul interfeței, altcineva limitează MSS, și uneori problema dispare din motive pe care nimeni nu le notează. Cele două numere descriu obiecte diferite, așa că modificarea celui greșit produce o remediere care pare noroc. Iată procedura: identificați stratul, aplicați ajustarea potrivită și apoi testați pe o conexiune nouă.

Două numere, două obiecte

MTU aparține unei legături sau unei interfețe: este cel mai mare pachet care poate fi predat fără a fi împărțit. MSS aparține TCP: este cea mai mare cantitate de încărcătură TCP pe care o poate duce un segment și exclude atât antetul TCP, cât și pe cel IP. Pe o legătură Ethernet obișnuită cu IPv4, un MTU de 1500 de octeți dă bine-cunoscutul MSS de 1460 de octeți. Aceste numere descriu straturi diferite și sunt schimbate prin mecanisme diferite. Confundarea lor este ușoară pentru că ambele se măsoară în octeți și ambele sunt aproape de 1500.

Unul vine ca setare a interfeței. Celălalt vine ca opțiune într-un segment SYN, negociată între capete care nu vă văd niciodată interfața.

Unde ajunge supraîncărcarea exterioară

O VPN pune pachetul interior într-un altul, iar pachetul exterior trebuie să încapă pe calea fizică. Antetele de încapsulare, antetul IP exterior, antetul de transport și orice etichetă de autentificare consumă octeți pe care pachetul interior nu-i poate folosi. Lăsați interfața tunelului la 1500 și pachetul exterior depășește frecvent ce poate duce calea. Cu bitul 'nu fragmenta' setat, routerul îl aruncă și ar trebui să trimită înapoi o eroare ICMP; dacă acea eroare este filtrată, expeditorul nu află niciodată.

De aceea defecțiunea pare selectivă. Cererile mici se finalizează, iar tot ce umple un segment se blochează, pentru că doar pachetele mari sunt aruncate. Un tunel care lasă un ping să treacă nu este un tunel care transportă date.

Limitarea MSS, și unde se aplică

Limitarea MSS rescrie valoarea din segmentul SYN când acesta traversează un punct ales, făcând ambele capete să aleagă o încărcătură mai mică fără ca vreunul să știe de ce. În Linux este o țintă a tabelei mangle aplicată de o regulă explicită și trebuie să lovească pachetele SYN în direcția dorită. Limitați-o la interfața tunelului și la intervalul de adrese, pentru că o regulă largă schimbă comportamentul traficului care nu intră niciodată în tunel.

Efectul este doar asupra TCP. O aplicație UDP, o sesiune QUIC și orice protocol care își construiește propriile datagrame rămân neatinse.

Diagnosticați cu o cale fixă

Păstrați o singură variabilă odată. Testați cu un pachet a cărui dimensiune o alegeți dumneavoastră, și setați indicatorul 'nu fragmenta' ca nucleul să raporteze rezultatul în loc să-l ascundă.

Notați unde începe defecțiunea: în interiorul tunelului, la interfața tunelului sau pe calea fizică după încapsulare. Apoi schimbați un singur număr și repetați același test, nu altul. Conexiunile existente păstrează MSS-ul negociat, așa că o schimbare de politică este vizibilă doar pe o conexiune nouă, motiv pentru care o pagină din cache nu dovedește nimic în nicio direcție. Dacă o încărcare mare începe să funcționeze, ați învățat despre acea cale și nu despre fiecare protocol de pe ea.

Ce nu repară fiecare modificare

Scăderea MTU-ului interfeței nu modifică MSS-ul unei sesiuni deja stabilite. Limitarea MSS nu ajută un flux UDP și nu repară o cale pe care erorile ICMP sunt filtrate într-o singură direcție. Fiecare modificare repară o clasă de probleme și lasă restul exact cum era.

Notați ce ajustare ați aplicat, unde și care test a arătat diferența, altfel următorul inginer le aplică pe amândouă și pierde capacitatea de a spune care conta. Dacă restricția este reală și permanentă, preferați un MTU de tunel care o reflectă în locul unei limitări care o ascunde. Dacă trebuie să limitați, lăsați regula îngustă și comentată, fiindcă o regulă mangle neexplicată devine permanentă implicit.