Mitoj pri VPN-MTU: kial viaj paketoj malgrandiĝas kaj kien iras la spaco

Iu diras al vi, ke la VPN «perdas paketojn pro MTU», vi agordas la tunelon al 1400, kaj la transdono denove funkcias. Tia rezulto ŝajnas diagnozo. Plej ofte ĝi estas hazardo de aritmetiko: vi elektis nombron sufiĉe malgrandan por eniri sub limon, kiun vi neniam identigis, kaj vi denove renkontos la saman limon en la sekva reto kun alia buĝeto.

Du mitoj kaŭzas la plejparton de tio. La unua estas, ke la MTU de la tunela interfaco estas la MTU de la vojo. La dua estas, ke enkapsuligo kostas «unu kaplinion» kaj PPPoE kostas nenion indan je kalkulo. Ambaŭ malĝustas tiel, ke la nombro, kiun vi elektas, ŝajnas arbitra, kvankam ĝi fakte estas difinita.

Mito unu: la MTU de la tunelo estas la MTU de la vojo

La valoro, kiun vi agordas ĉe tunela interfaco, estas loka promeso pri la plej granda interna paketo, kiun la efektivigo transdonos malsupren. La reala kapacito de la vojo estas eco de ĉiu ligo inter vi kaj la malproksima fino, kaj ĝi povas ŝanĝiĝi, kiam ŝanĝiĝas itinero, kiam poŝa konekto transdonas, aŭ kiam trafiko prenas alian peeradon. Agordita 1500 diras al vi, kion konstruos via gastiganto, ne kion portos la reto.

Malkovro de voja MTU ekzistas por akordigi la du kaj dependas de retrosciigo. Ĉe IPv4, enkursigilo, kiu ne povas plusendi plengrandan paketon, devus sendi ICMP-mesaĝon «fragmentation needed», kaj la sendanto malaltigas sian takson. Ĉe IPv6, la ekvivalento estas mesaĝo Packet Too Big, kaj enkursigiloj tute ne fragmentas dum transiro. Kiam tiu retrosciigo estas filtrita, la sendanto daŭre produktas paketojn, kiujn la vojo ne povas porti, kaj nenio diras al ĝi kial.

Mito du: enkapsuligo kostas unu kaplinion

Kalkulu la eksterajn tavolojn honeste. Ekstera IP-kaplinio estas 20 bajtoj ĉe IPv4 aŭ 40 ĉe IPv6. UDP-enkapsuligo por NAT-trapaso aldonas 8. La tunela protokolo aldonas sian propran kaplinion, inicialigan vektoron aŭ noncon, plenigaĵon ĝis la bloka aŭ vicigada limo de la ĉifro, finan parton kaj kontrolvaloron de integreco. Depende de la protokolo kaj ĉifro, la sumo komforte atingas dekojn da bajtoj antaŭ ol la interna paketo eĉ komenciĝas.

Poste denove subtrahu la proprajn kapliniojn de la interna paketo. TCP-segmento ene de la tunelo portas sian propran 20-bajtan IP-kaplinion kaj 20-bajtan TCP-kaplinion, kaj la MSS de TCP deriviĝas de la MTU, ne de la nominala utila ŝarĝo de la tunelo. Tial ping kun pli malgranda utila ŝarĝo povas sukcesi, dum dosiera transdono haltas: la iloj testas malsamajn aferojn, kaj nur unu el ili ekzercas plengrandan TCP-segmenton.

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

La unua komando raportas la agorditan MTU de la tunelo. La du sondoj sendas utilan ŝarĝon de 1472 bajtoj, kio kun 28 bajtoj da IPv4 kaj ICMP-kaplinioj estas paketo de 1500 bajtoj, poste pli malgrandan. Se la granda sondo tute malsukcesas kaj la malgranda sukcesas, vi havas grandodependan difekton, ne ĝeneralan itineran problemon.

Mito tri: PPPoE ankoraŭ donas al vi puran 1500

Konvencia PPPoE-aliĝligo ne portas IP-paketon de 1500 bajtoj. La PPPoE-kaplinio plus la PPP-protokola kampo okupas 8 bajtojn ene de la Ethernet-kadro, kio lasas 1492 por la IP-paketo. Tio estas la tradicia limo priskribita en RFC 2516. Se vi funkciigas VPN sur tia ligo, la superkosto de la tunelo venas el tiuj 1492, ne el 1500.

RFC 4638 difinas manieron intertrakti pli grandan PPP-utilan ŝarĝon, kiam kaj la aliĝkoncentrilo kaj la klienta ekipaĵo subtenas ĝin, tial «ĉi tiu konekto uzas PPPoE» sola ne pruvas specifan nombron. Loka agordo ne povas devigi interan aparaton akcepti paketon, por kiu ĝi neniam estis agordita, do la utila demando estas, kion la ligo efektive intertraktis, ne kion diras la etikedo.

Kial la paneo aspektas selektema

Malgrandaj petoj sukcesas kaj grandaj transdonoj haltas — tio estas la klasika signo de nigra truo de voja MTU. La manpremo, la DNS-demando kaj la API-voko ĉiuj eniras; la amasa transdono produktas plengrandajn segmentojn, kiuj mortas ĉe unu ligo, kaj la ICMP-mesaĝo, kiu devus raporti la problemon, neniam alvenas. La konekto aspektas bone kaj la elŝuto pendas, kio sendas homojn rigardi la servilon anstataŭ la vojon.

Dua, rilata eraro estas konfuzi tri nombrojn: la interfacan MTU, la TCP-MSS kaj la propran fragmentigan aŭ plenigan agordon de la protokolo. MSS-kunpremado ĉe enkursigilo reverkas la anoncitan MSS, por ke la sendanto konstruu pli malgrandajn segmentojn; ĝi ne ŝanĝas la tunelan MTU kaj ne helpas UDP-trafikon. Doni la saman nombron al ĉiuj tri ĉar ili ŝajnas rilataj estas la maniero, kiel bonintenca ŝanĝo rompas funkciantan agordon.

Kion ŝanĝi, en kiu ordo

Komencu per pruvoj. Konfirmu per la sondoj supre, ke la difekto estas grandodependa, poste trovu la plej malgrandan grandon, kiu pasas, kaj la plej grandan, kiu malsukcesas. Kontrolu la realan MTU de la aliĝligo antaŭ ol kulpigi la tunelon; PPPoE-ligo limigas la buĝeton antaŭ ol via VPN tuŝas ĝin. Notu la originajn valorojn, por ke la ŝanĝo povu esti malfarita.

Poste apliku la plej malgrandan ĝustigon, kiun la kliento dokumentas. Multaj klientoj proponas tunelan MTU plus MSS-riparan opcion, kaj la MSS-opcio ofte estas la pli bona levilo por TCP, ĉar ĝi atingas la sendanton sen malgrandigi ĉiun paketon. Retestu la saman celon kaj la saman transdonon, kaj notu la nombrojn, ĉe kiuj vi haltis. Tunela valoro, kiu funkcias en unu aliĝreto, ne estas universala konstanto, kaj la sekva ejo havos sian propran buĝeton.