Jumbo-kadroj ne igas VPN-vojon porti pakaĵojn de 9000 bajtoj
Granda MTU estas loka liga interkonsento. Subtrahu la tunelan superkoston de la plej malgranda ligo sur la vojo antaŭ ol altigi la internan interfacon.
Vi ebligis 9000-bajtajn kadrojn sur la LAN kaj atendis, ke la VPN rapidiĝos. Ĝi malrapidiĝis, aŭ tute ĉesis pasigi grandajn transigojn. Jumbo-kadroj estas loka liga interkonsento; ili ne pligrandigas la vojon, kiun la tunelo trapasas.
La uzebla buĝeto estas fiksita de la plej malgranda limo sur la vojo, inkluzive de la enkapsuligo, kiun la tunelo aldonas.
Kion jumbo-kadroj vere ŝanĝas
MTU estas eco de unu interfaco. Altigi ĝin sur servilo kaj ĝia ŝaltilo signifas, ke tiuj du povas interŝanĝi pli grandajn kadrojn sen fragmentado. Ĝi diras nenion pri la enkursigilo post la ŝaltilo, pri la provizanto aŭ pri la alia flanko de tunelo. Tiuj aparatoj havas proprajn limojn, kaj pakaĵo, kiu superas unu el ili, estas forĵetita aŭ fragmentita laŭ reguloj, kiujn vi ne starigis.
Loka interkonsento, tutmondaj sekvoj. Tio estas la tuta konfuzo.
La enkapsuliga imposto
Tunelo volvas vian pakaĵon ene de alia. WireGuard super IPv4 UDP aldonas proksimume 60 bajtojn da superkosto; la UDP-reĝimo de OpenVPN estas en la sama gamo, kaj IPsec varias laŭ reĝimo kaj algoritmoj. Tiuj bajtoj venas el la buĝeto de la ekstera vojo, ne el nenie.
Do ekstera ligo de 1500 bajtoj ne povas porti internan pakaĵon de 1500 bajtoj post kiam tunela kapo estas aldonita.
La aritmetiko indas fari unufoje. Sur vojo de 1500 bajtoj, WireGuard-interfaco volas MTU ĉirkaŭ 1420, por ke la enkapsuligita pakaĵo taŭgu. Starigu la internan interfacon al 9000 kaj ĉiu granda pakaĵo bezonos fragmentadon, kiun la tunelo ne povas fari, aŭ estos forĵetita.
Trovu la plej malgrandan ligon sur la vojo
Iru la vojon kaj trovu la plej malaltan MTU. La LAN kutime estas 1500 aŭ 9000, la WAN kutime 1500, kaj poŝa aŭ PPP-ligo povas esti eĉ pli malalta. Poste subtrahu la tunelan superkoston. Se la rezulto estas pli malgranda ol la MTU de la interna interfaco, vi havas vian respondon. Malkovro de voja MTU povas trovi tion aŭtomate, sed nur kiam la ICMP-mesaĝoj, de kiuj ĝi dependas, estas permesataj.
Filtrita ICMP estas la klasika kialo, kial granda transigo pendas dum malgrandaj petoj funkcias bone.
Testu grandec-dependecon sen larĝigi la ŝanĝon
Uzu reprezentan transigon kaj konservu la originajn valorojn, por ke vi povu restarigi ilin. ping -M do -s 1472 testas pakaĵon de 1500 bajtoj kun la DF-bito starigita; malgrandigu la grandecon ĝis ĝi trapasos. Se nur grandaj pakaĵoj malsukcesas, vi havas grandecan problemon, ne vojan.
Gardu vin kontraŭ malkargaĵo ĉe la gastiganto legante kaptaĵojn. Segmenta malkargaĵo povas montri kadrojn multe pli grandajn ol tio, kio efektive trapasis la draton, kio igas funkcian vojon aspekti rompita kaj rompitan aspekti en ordo.
Kiam granda MTU estas la ĝusta dezajno
Kontrolita privata reto povas laŭleĝe funkciigi pli grandajn kadrojn de fino al fino, kondiĉe ke ĉiu aparato sur la vojo konsentas kaj la tunela superkosto estas kalkulita. Tio estas kunordigita dezajno kun dokumentita valoro por ligo, ne unu granda nombro tajpita en klienton.
Por ordinara publika eliro, supozu 1500 aŭ malpli kaj lasu la tunelon elekti sekuran internan MTU. RFC 8201 kovras malkovron de voja MTU por la IPv6-kazo kaj estas utila referenco pri tio, kiel la retronutrado devus funkcii.