IPv6-paketo tro granda: kial grandaj VPN-transigoj haltas

Ping funkcias, la retumilo ŝarĝas malgrandan paĝon, kaj la dosiera transigo pendas — ĉio per IPv6 tra la sama tunelo. Tiu ŝablono kutime signifas, ke la sendanto neniam lernis la realan grandecon de la vojo, ne ke la tunelo estas malrapida. IPv6 atendas, ke enkursigiloj raportos la problemon per mesaĝo Packet Too Big, kaj enkapsuligo aldonas superkoston antaŭ ol paketo eĉ atingas la eksteran reton. Se tiu mesaĝo estas filtrita, la sendanto daŭre ripetas grandecon, kiu ne povas trapasi.

Malgrandaj petoj, grandaj haltoj

Tunelo envolvas ĉiun paketon en alian kaplinion, do la uzebla grandeco interne estas pli malgranda ol la grandeco ekstere. Paketo dimensionita por la fizika ligo antaŭ enkapsuligo fariĝas tro granda poste. IPv4-enkursigiloj povas fragmentigi laŭvoje, dum IPv6-enkursigiloj ne faras tion nome de la sendanto, do la sendanto devas adaptiĝi mem. Kaj tiu adaptiĝo tute dependas de ricevi la retronutradon.

Unu sola perdita mesaĝo sufiĉas por la klasika simptomo: manpremoj kaj malgrandaj respondoj sukcesas, kaj dosieruja listo aŭ suprenŝuto pendas ĉiufoje ĉe la sama punkto. Uzantoj priskribas tion kiel malrapidan VPN, kaj la protokoloj montras nenion maltrafan ĉe aŭtentikigo. Ambaŭ observoj estas ĝustaj, kaj nek unu lokigas la misfunkcion.

Packet Too Big estas retronutrado, ne trafiko

Mesaĝo ICMPv6 Packet Too Big portas la grandecon, kiun la sekva salto povas akcepti, kaj la sendanto uzas ĝin por malaltigi sian takson. Filtri ĝin egalas al forigi vojsignon kaj poste kulpigi la ŝoforojn. Regulo, kiu forĵetas ĉiun ICMPv6, aspektas strikta dum ĝi rompas vojotrovadon sur ĉiu ligo, kiu bezonas ĝin. La mesaĝo estas kontrola informo pri la vojo, ne aplikada utilŝarĝo.

Selektema filtrado ankoraŭ estas racia. Eĥopetoj kaj najbarotrovado ludas aliajn rolojn ol erarmesaĝoj, kaj politiko povas trakti ilin alie. Sekvu la dokumentitajn filtrigajn gvidliniojn de la platformo anstataŭ akcepti aŭ forĵeti la tutan protokolon, ĉar RFC 8201 difinas kiel tiu retronutrado stiras trovadon.

Testu ambaŭ adresajn familiojn aparte

Testu IPv6 aparte, ĉar sukcesa IPv4-transigo pruvas nenion pri la IPv6-vojo. Poste kaptu kontrolmesaĝojn dum la granda transigo pendas. La du rikordoj kune aŭ montras, ke la retronutrado eliras, aŭ pruvas, ke ĝi neniam alvenis.

ping -6 -M do -s 1400 host.internal
ip -6 route get 2001:db8:2::10
sudo tcpdump -ni any 'icmp6 and ip6[40] == 2'

La sondilo sendas paketon kun la bito do-not-fragment agordita kaj raportas la grandecon, ĉe kiu ĝi malsukcesas — la nombro, kiun la tunelo devas enteni. La vojdemando nomas la interfacon, kiu portus la celon, do vi scias, kiu MTU de ligo validas. La kapto filtras ICMPv6 tipon 2, la mesaĝon Packet Too Big, kaj montras, ĉu ĝi entute atingas ĉi tiun gastiganton. Se la mesaĝo aperas en la kapto kaj la transigo ankoraŭ pendas, la sendanto ignoras ĝin, kio movas la enketon al la stako anstataŭ al la reto.

Alĝustigu la tunelan grandecon nur post la pruvoj

Malaltigi la MTU de la tunelo povas kaŝi filtritan mesaĝon kaj malaperigi la simptomon, je la kosto de pli da superkosto por ĉiu paketo. Tio estas ĉirkaŭvojo, ne diagnozo, kaj ĝi sekvu la kapton anstataŭ anstataŭi ĝin. Arbitre malalta valoro ankaŭ rompas nenion videble, tial ĝi pluvivas en agordoj dum jaroj. Ŝanĝu ĝin konscie, registru la valoron, kaj notu, kiu mezuro pravigis ĝin.

Kiam vi regas la enirejon, ekzamenu la regulon, kiu forĵetas la mesaĝon, anstataŭ malŝalti la fajroŝirmilon. Unu korektita regulo estas pli mallarĝa ol politika escepto kaj multe pli facile defendebla poste. La sama rezonado validas por tempolimoj: ne ĉiu halto estas grandeca problemo, kaj kapto estas tio, kio apartigas la du.