Malkovro de voja MTU tra VPN: grandeco kaj la ICMP-manko

Tunelo finas sian manpremon, malgrandaj petoj revenas, kaj la unua granda transigo haltas. Tiu ŝablono montras al la voja MTU longe antaŭ ol ĝi montras al trairo. Ĉiu ligilo laŭ la itinero limigas la paketan grandecon, kaj enkapsuligo elspezas parton de tiu permeso por eksteraj kaplinioj, do la interna paketo devas esti pli malgranda ol la kruda vojo sugestus. La fiasko estas silenta, kaj tio ĝin faras multekosta diagnozi.

Kion la voja MTU efektive mezuras

La voja MTU estas la plej malgranda ligila MTU sur la itinero inter du gastigantoj, ne la MTU presita sur via loka interfaco. La loka valoro estas kie la takso komenciĝas, kaj la vojo decidas kie ĝi devas finiĝi. Tial identa tunelo povas funkcii en unu alira reto kaj halti en alia: la itinero ŝanĝiĝis, ne la agordo. Mezuri unufoje kaj supozi ĉie estas la eraro, kiu tenas ĉi tiun problemon viva.

Por tunelo, la grava nombro estas la interna MTU, tio estas la permeso de la ekstera vojo minus ĉio, kion la enkapsuligo konsumas. WireGuard aldonas eksteran IP-kaplinion kaj UDP-kaplinion; aliaj transportoj aldonas siajn proprajn. Se oni agordas la internan grandecon tro alte, ĉiu plengranda paketo bezonas fragmentadon, kiu eble neniam okazos.

Kial tunelo malgrandigas la uzeblan paketon

Se la tunela interfaco konservas la MTU de la fizika ligilo, ĉiu granda paketo dependas de tio, ĉu iu pli malsupre pretas fragmentigi ĝin. IPv4 principe permesas tion, sed direktilo, al kiu oni diris ne fragmentigi, anstataŭe redonas eraron. IPv6-direktiloj tute ne fragmentigas dum pasado, do la sama agordo kondutas malsame laŭ la adresa familio. Ĉiuokaze la sendinto lernas nenion ĝis io raportos reen.

La praktika sekvo estas grandeco, kiu taŭgas por la manpremo sed ne por la utila ŝarĝo. TLS ClientHello aŭ DNS-demando estas sufiĉe malgrandaj por trapasi malgrandigitan vojon netuŝite, dum amasa transigo ne estas. Tial la simptomoj grupiĝas ĉirkaŭ specifaj operacioj anstataŭ specifaj gastigantoj.

Malkovro funkcias nur kiam la retrosignalado alvenas

La malkovro de IPv4 baziĝas sur la malpermeso-fragmentigi bito: direktilo, kiu ne povas plusendi la paketon, redonas ICMP fragmentation-needed kun la MTU de la sekva salto, kaj la sendinto malaltigas sian takson. IPv6 anstataŭe uzas Packet Too Big-mesaĝojn, ĉar direktiloj ne fragmentigas dum pasado. Ambaŭ mekanismoj supozas, ke la mesaĝo trovas sian vojon reen al la sendinto, tra la tunelo kaj preter eventuala fajroŝirmilo sur la revena vojo. Kiam tiu supozo fiaskas, la sendinto daŭre reprovas grandecon, kiun la vojo ne povas porti.

Fajroŝirmilo, kiu permesas echo request kaj echo reply, ne nepre permesis tiujn erartipojn. ICMP estas familio, kaj la membroj, kiuj gravas ĉi tie, estas la eraroj, ne la echo-paro. Kontrolu la politikon pri kontroltrafiko ĉe ambaŭ tunelaj finoj kaj sur la vojo inter ili, kaj sekvu la subtenatan gvidadon de la platformo anstataŭ permesi ĉiun ICMP-tipon ĉie.

La sama filtrado povas sidi ene de la tunelo. Se la interna vojo faligas la eraron sed la ekstera portas ĝin, la sendinto povas adaptiĝi al limo, kiun la enkapsuligita trafiko efektive neniam vidas.

Testu la vojon anstataŭ diveni nombron

Tenu la celon, la aliran reton kaj la tunelon fiksaj, kaj variigu nur la paketan grandecon. Malpermeso-fragmentigi testo, kiu fiaskas kun MTU-sugesto, donas al vi la limon de la sekva salto; ripetu ĝis grandeco pasas, kaj notu kaj la grandecon kaj la adresan familion.

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

Ping, kiu taŭgas, ne pruvas, ke la plengrandaj segmentoj de reala aplikaĵo taŭgas, do ripetu la teston per la transigo, kiu efektive fiaskis. Komparu la plej grandan funkcian teston kun la tunela MTU, kiun vi agordis, kaj tenu la du nombrojn apartaj en viaj notoj. Se ili diferencas je proksimume unu kaplinio, vi trovis la enkapsuligan superŝarĝon, ne difekton.

PLPMTUD, priskribita en RFC 4821, testas supren kaj uzas transportajn konfirmojn anstataŭ fidi al liveritaj eraroj. Ĝi helpas sur vojoj, kiuj filtras ICMP, sed subteno varias laŭ stako kaj aplikaĵo. TCP-fluo povas mem resaniĝi, dum UDP-aplikaĵo kun fiksa datagrama grandeco daŭre fiaskas.

Elektu valoron kaj notu la rezonadon

Malaltigi la tunelan MTU estas samtempe diagnozo kaj legitima ripeto post kiam vi konas la vojon. Ĝi ne anstataŭas scii, kiun vojon kaj kiun retrosignalan mekanismon oni implikis, ĉar valoro agordita por mobila ligilo estos senbezone malgranda sur fibra konekto. Notu la elektitan grandecon, la teston, kiu pravigis ĝin, kaj la retroigan paŝon.

La IPv4-mekanismo estas priskribita en RFC 1191 kaj la IPv6-paketiga gvidado en RFC 8201; nomi ambaŭ malhelpas la sekvan inĝenieron rederivi la supozon. Se la transigo daŭre haltas je la grandeco, kiun vi elektis, ĉesu malaltigi la nombron kaj rigardu la sekvan tavolon. Vojo, kiu fiaskas je ĉiu grandeco, ne estas MTU-problemo.