IPv4 fragmentigas dumvoje; IPv6 anstataŭe sendas mesaĝon pri tro granda paketo

Malsukcesoj de IPv6 estas kulpigitaj al la protokolo multe pli ofte ol al la paketa grando, kiu kaŭzis ilin. La du familioj vere traktas tro grandan paketon malsame, kaj tunelo estas tio, kio igas tiun diferencon grava. IPv4-routeiloj rajtas fragmentigi paketon kiam la reguloj permesas, dum IPv6-routeiloj tute ne rajtas fragmentigi dumvoje. IPv6 anstataŭe diras tion al la sendanto, kaj oni atendas ke la sendanto reagos. Ĉio, kio poste misfunkcias, sekvas el tio, ĉu tiu mesaĝo alvenas.

Kion faras ĉiu familio

La tabelo estas la mekanismo en kvar linioj, kaj unu vico klarigas la plej grandan parton de la konfuzo.

IPv6 havas neniun fragmentadon dumvoje kaj neniun DF-flagon por forigi, do estas nenio, al kio reveni kiam paketo estas tro granda. Oni devas diri tion al la sendanto, kaj la sendanto devas kredi tion.

La tunelo silente mallarĝigas la vojon

VPN aldonas eksterajn kapliniojn, kaj en la ĉifrita kazo ankaŭ integrecan datumaron, antaŭ ol la paketo forlasas la gastiganton. La interna paketo povas eniri la interfacan MTU, kiun ĝi vidas, dum la ekstera paketo superas la limon de la sekva ligo, kaj tial tio aperas unue en tunelo. Intence malaltigu la MTU de la tunela interfaco, aŭ fiksu TCP MSS sur la vojo, kaj skribu, kiun nombron vi elektis kaj kial.

La ESP-superkosto dependas de la reĝimo kaj de la algoritmoj, do la ĝusta tunela MTU estas kalkulo, ne konvencio. Kion ajn vi elektos, ĝi devas lasi lokon por plena interna IPv6-paketo de 1280 bajtoj, ĉar ĉiu IPv6-ligo devas porti tiom. Tunelo, kiu ne povas porti 1280 bajtojn da IPv6, ne estas agorda problemo; ĝi estas rompita vojo por tiu familio. Ĝuste tiu limigo malaperas, kiam MTU-valoro estas kopiita el nur-IPv4-a starigo.

Kial la simptomo estas halto

La malsukceso ne estas pura eraro, kaj tial ĝi estas misdiagnozita. TCP-manpremo finiĝas, malgrandaj respondoj alvenas, kaj la konekto haltas tuj kiam komenciĝas granda respondo aŭ granda alŝuto, ĉar tiuj estas la unuaj paketoj sufiĉe grandaj por esti forĵetitaj. SSH konektiĝas kaj poste haltas ĉe la unua granda eligo, kaj paĝa kapo ŝargiĝas dum la korpo neniam finiĝas.

Se la ICMPv6-mesaĝoj pri tro granda paketo estas filtritaj, la sendanto neniam ekscias kaj daŭre provas la saman grandecon. Tio estas nigra truo, ne malrapida vojo, kaj ĝia signo estas ripetebla granda limo, ne hazarda perdo. Permesi la koncernan regadan trafikon estas parto de funkcianta IPv6-starigo, ne ĝentileco.

Ne malŝaltu la mesaĝojn, de kiuj dependas via propra vojo, kaj poste priskribu la rezulton kiel IPv6-fraŭdon. La sama argumento validas por la mesaĝoj Fragmentation Needed de IPv4, kiuj same malpopularas ĉe retfajrajaŭtoroj kaj same necesas.

Mezuru la limon, poste riparu la tavolon

Kontrolu anstataŭ diveni: uzu la flagon don't-fragment ĉe IPv4 kaj fiksajn ŝarĝgrandojn ĉe IPv6, kaj notu, kie respondoj ĉesas. ping -M do -s 1472 kaj ping -6 -s 1400 sufiĉas por establi la formon de la problemo, kaj tracepath raportas la malkovritan voj-MTU survoje.

Poste riparu la tavolon, kiu posedas la nombron: la MTU de la tunela interfaco, la MSS-fiksado por TCP, aŭ la vojo mem. RFC 8200 estas la referenco por la IPv6-regulo, kaj ĝi estas pli mallonga legaĵo ol la incidento, kiun ĝi malhelpas.

Testu la familion, kiun la aplikaĵo efektive uzas, ĉar dunivela nomo povas respondi en unu familio kaj ne en la alia, kaj aplikaĵo povas ŝanĝi post reta ŝanĝo. Notu la adreson, kiun vi testis, ĉar rezulto kontraŭ la A-rikordo diras nenion pri la AAAA-rikordo.

Traktu la grandan limon kiel pruvon

Ripetebla granda limo estas unu el la malmultaj retaj difektoj, kiuj reproduktiĝas precize, ĉe la sama bajtnombro, el la sama fonto, ĉiufoje. Tio faras ĝin donaco, ne enigmo, kaj ankaŭ signifas, ke riparo povas esti kontrolita anstataŭ esperata.

Skribu en la bileton la malkovritan MTU, la agordan tunelan MTU kaj la teston, kiu pruvis la diferencon. La sekva persono renkontos la saman aritmetikon sur alia ligo.