Cadrele jumbo nu fac o cale VPN să transporte pachete de 9000 de octeți

Ați activat cadre de 9000 de octeți în LAN și vă așteptați ca VPN-ul să devină mai rapid. A devenit mai lent sau a încetat complet să mai treacă transferuri mari. Cadrele jumbo sunt un acord de legătură local; ele nu lărgesc calea pe care o traversează tunelul.

Bugetul utilizabil este stabilit de cea mai mică limită de pe rută, inclusiv de încapsularea pe care o adaugă tunelul.

Ce schimbă de fapt cadrele jumbo

Un MTU este o proprietate a unei singure interfețe. Ridicarea lui pe un server și pe switch-ul acestuia înseamnă că acelea două pot schimba cadre mai mari fără fragmentare. Nu spune nimic despre routerul de dincolo de switch, despre furnizor sau despre cealaltă parte a unui tunel. Acele dispozitive au propriile limite, iar un pachet care depășește una dintre ele este aruncat sau fragmentat după reguli pe care nu le-ați stabilit.

Acord local, consecințe globale. Asta este toată confuzia.

Taxa de încapsulare

Un tunel înfășoară pachetul tău în altul. WireGuard peste IPv4 UDP adaugă aproximativ 60 de octeți de suprasarcină; modul UDP al OpenVPN este în același interval, iar IPsec variază în funcție de mod și algoritmi. Acești octeți provin din bugetul căii exterioare, nu din nimic.

Așadar, o legătură exterioară de 1500 de octeți nu poate transporta un pachet interior de 1500 de octeți odată ce se adaugă antetul tunelului.

Merită făcută aritmetica o dată. Pe o cale de 1500 de octeți, o interfață WireGuard vrea un MTU în jur de 1420 ca să încapă pachetul încapsulat. Setează interfața interioară la 9000 și fiecare pachet mare va avea nevoie de o fragmentare pe care tunelul nu o poate face, sau va fi aruncat.

Găsiți cea mai mică legătură de pe cale

Parcurgeți ruta și găsiți cel mai mic MTU. LAN-ul este de obicei 1500 sau 9000, WAN-ul de obicei 1500, iar o legătură mobilă sau PPP poate fi și mai mică. Apoi scădeți suprasarcina tunelului. Dacă rezultatul este mai mic decât MTU-ul interfeței interioare, aveți răspunsul. Descoperirea MTU a căii poate găsi acest lucru automat, dar numai când mesajele ICMP de care depinde sunt lăsate să treacă.

ICMP filtrat este motivul clasic pentru care un transfer mare se blochează în timp ce cererile mici funcționează bine.

Testați dependența de dimensiune fără a lărgi schimbarea

Folosiți un transfer reprezentativ și păstrați valorile originale ca să le puteți pune la loc. ping -M do -s 1472 testează un pachet de 1500 de octeți cu bitul DF setat; reduceți dimensiunea până trece. Dacă eșuează doar pachetele mari, aveți o problemă de dimensiune, nu de rutare.

Fiți atenți la offload-ul din partea gazdă când citiți capturi. Offload-ul de segmentare poate arăta cadre mult mai mari decât ce a trecut efectiv prin cablu, ceea ce face o cale funcțională să pară stricată și una stricată să pară în regulă.

Când un MTU mare este proiectul potrivit

O rețea privată controlată poate rula legitim cadre mai mari de la un capăt la altul, cu condiția ca fiecare dispozitiv de pe cale să fie de acord și suprasarcina tunelului să fie luată în calcul. Acesta este un proiect coordonat cu o valoare documentată pe legătură, nu un singur număr mare tastat într-un client.

Pentru o ieșire publică obișnuită, presupuneți 1500 sau mai puțin și lăsați tunelul să aleagă un MTU interior sigur. RFC 8201 acoperă descoperirea MTU a căii pentru cazul IPv6 și este o referință utilă despre cum ar trebui să funcționeze feedback-ul.