DNS solviĝas, la SSH seanco restas aktiva, kaj tiam granda alŝuto frostas dum ping al la sama gastiganto ankoraŭ respondas. Tiu disiĝo montras al paketa grando, ne al rompita tunelo. Nestitaj tuneloj atingas tion ĉe grandoj, kiujn neniu tunelo sola atingus. La interna seanco estas en ordo; oni simple transdonas al ĝi pakaĵojn, kiuj jam ne taŭgas.

Kien la MTU de la vojo efektive iras

Ĉiu enkapsuligo elspezas bajtojn antaŭ ol la sekva tavolo ricevas sian vicon. Ethernet-vojo proponas 1500 bajtojn al la ekstera pakaĵo, kaj la ekstera tunelo prenas sian parton antaŭ ol io ajn interne povas esti adresita. Unu divenita superkosta valoro estos malĝusta ĝuste je la kvanto, kiu gravas.

Listigu la tavolojn laŭ ordo: alirvojo, ekstera transporto, ekstera tunelo, interna transporto, interna tunelo, aplikaĵo. Kalkulu ĉiun kaplinion unufoje, kaj tenu UDP aparte de la propra kaplinio kaj etikedo de la tunelo.

Du WireGuard-tavoloj, kalkulitaj unufoje

Prenu IPv4-alirvojon kun unu WireGuard-tunelo ene de alia. La ekstera tavolo kostas 20 bajtojn da IPv4, 8 da UDP kaj 32 por la datenkaplinio de WireGuard plus ĝia aŭtentiga etikedo. Ene de tio, la interna tunelo bezonas sian propran 20-bajtan IPv4-kaplinion kaj 8-bajtan UDP-kaplinion antaŭ siaj duaj 32 bajtoj da WireGuard-superkosto. Kio restas, enhavas IPv4-kaplinion, TCP-kaplinion kaj la datenojn. Ekstera IPv6-vojo kostas 40 anstataŭ 20 kaj lasas 1320.

LayerBytes
Path MTU1500
Outer IPv4 header20
Outer UDP header8
Outer WireGuard header and tag32
Inner transport IPv4 header20
Inner UDP header8
Inner WireGuard header and tag32
Innermost IPv4 header20
TCP header20
Payload that fits1340

La aritmetiko finiĝas ĉe 1340 bajtoj. Unu tavolo laŭ la samaj reguloj lasas 1400 por la TCP-utilaĵo, kio estas 1500 minus 20, 8, 32, 20 kaj 20, kaj la diferenco de 60 bajtoj estas ĝuste la interna enkapsuligo, kiun aldonas la dua tunelo.

Apliku 1400 al nestita vojo kaj la interna tunelo mankas je 60 bajtoj, nevideble ĝis pakaĵo estos sufiĉe granda por bezoni ilin. Rempuŝo kaj la propra fragmentiga opcio de protokolo denove movas la ciferojn, do fidu la tabelon.

MTU, MSS kaj fragmentigo agas en malsamaj lokoj

La MTU de la interfaco limigas tion, kion la interfaco elsendos, dum TCP MSS-premo ŝanĝas tion, kion TCP-partnero pretas sendi. Premo riparas TCP-seancojn kaj faras nenion por granda UDP-datagramo, tiel riparo aspektas sukcesa por unu aplikaĵo kaj silente maltrafas la sekvan. La propra fragmentiga opcio de protokolo estas tria levilo kun propraj malsukcesoj. La MTU de la interfaco estas la kutima unua movo kaj la plej maldelikata.

Pontitaj kaj enkursigitaj tuneloj portas malsamajn kadrojn, do ciferoj el alia enkonduko malofte transiĝas. Malkovro de voja MTU, priskribita en RFC 8201, helpas nur dum la ICMP-mesaĝoj, de kiuj ĝi dependas, estas enlasitaj.

Trovi la tavolon, kiu mankas

Kontrolu ĉiun tunelon sola antaŭ ol nesti ilin, se la postuloj permesas komparon. Sondilo de fiksa grandeco solvas ĝin: ping -M do -s 1472 -c 3 10.8.0.1 sendas plenan IPv4-pakaĵon de 1500 bajtoj ene de tiu tavolo. Aldonu la duan tavolon kaj ripetu la saman sondilon, por ke ajna malsukceso apartenu al konata ŝanĝo.

Kiam transdono haltas, ŝanĝu unu dokumentitan parametron samtempe kaj notu la malsukcesan grandecon. Kontrolu ankaŭ la revenan vojon, ĉar nestita vojrekuro povas imiti paketgrandan problemon sufiĉe proksime por kosti posttagmezon. Filtrita ICMP-respondo povas kaŝi la veran limon, do la sondilo pli gravas ol la rezonado.

Skribu la buĝeton tie, kie la sekva persono trovos ĝin

Tabelo kun unu vico por tavolo postvivas regulon de dikfingro. Tenu ĝin apud la tunela diagramo, por ke neniu refaru la aritmetikon sub premo.

Pli da tuneloj signifas pli da dependecoj, do retroplano gajnas sian lokon apud la buĝeto. Se la ciferoj ankoraŭ ne sumiĝas, mezuru la vojon anstataŭ diveni denove. La celo estas cifero, kiun vi povas defendi, ne memori.

Rilataj artikoloj