Liiga suur IPv6-pakett: miks suured VPN-ülekanded takerduvad

Ping töötab, brauser laadib väikese lehe ja failiülekanne jääb kinni — kõik IPv6 kaudu sama tunneliga. See muster tähendab tavaliselt, et saatja ei õppinud kunagi tee tegelikku suurust, mitte et tunnel on aeglane. IPv6 ootab, et ruuterid teataksid probleemist Packet Too Big sõnumiga, ja kapseldamine lisab lisakoormust enne, kui pakett üldse välisvõrku jõuab. Kui see sõnum filtreeritakse, kordab saatja suurust, mis ei saa läbi pääseda.

Väikesed päringud, suured takerdumised

Tunnel mähkib iga paketi veel ühte päisesse, seega kasutatav suurus sees on väiksem kui suurus väljas. Enne kapseldamist füüsilisele lingile mõõdetud pakett muutub pärast liiga suureks. IPv4 ruuterid võivad teel fragmenteerida, IPv6 ruuterid aga ei tee seda saatja eest, seega peab saatja ise kohanema. Ja see kohanemine sõltub täielikult tagasiside saamisest.

Ühest kadunud sõnumist piisab klassikalise sümptomi tekitamiseks: käepigistused ja väikesed vastused õnnestuvad ning kataloogi loend või üleslaadimine takerdub iga kord samas kohas. Kasutajad kirjeldavad seda aeglase VPN-ina ning logid ei näita autentimises midagi valesti. Mõlemad tähelepanekud on täpsed ja kumbki ei leia riket.

Packet Too Big on tagasiside, mitte liiklus

ICMPv6 Packet Too Big sõnum kannab suurust, mille järgmine hüpe suudab vastu võtta, ja saatja kasutab seda oma hinnangu vähendamiseks. Selle filtreerimine on sama, kui eemaldada teeviit ja siis süüdistada juhte. Reegel, mis viskab kõik ICMPv6 ära, näeb range välja, kuid rikub teeavastust igal lingil, mis seda vajab. Sõnum on tee kohta käiv juhtimisteave, mitte rakenduse kasulik koormus.

Valikuline filtreerimine on siiski mõistlik. Kaja-päringud ja naabrite avastamine mängivad veateadetest erinevat rolli ning poliitika võib neid erinevalt kohelda. Järgige platvormi dokumenteeritud filtreerimisjuhiseid, selle asemel et kogu protokoll vastu võtta või ära visata, sest RFC 8201 määrab, kuidas see tagasiside avastust juhib.

Testige mõlemat aadresside perekonda eraldi

Testige IPv6 eraldi, sest edukas IPv4 ülekanne ei tõesta IPv6 tee kohta midagi. Seejärel jäädvustage juhtimissõnumid, kui suur ülekanne takerdub. Kaks kirjet koos näitavad kas seda, et tagasiside lahkub, või tõestavad, et see ei jõudnud kunagi kohale.

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'

Sond saadab paketi, millel on do-not-fragment bitt seatud, ja teatab suuruse, mille juures see ebaõnnestub — arv, mille tunnel peab mahutama. Marsruudipäring nimetab liidese, mis sihtkohta kannaks, seega teate, milline lingi MTU kehtib. Jäädvustus filtreerib ICMPv6 tüüp 2, Packet Too Big sõnumi, ja näitab, kas see üldse sellesse hosti jõuab. Kui sõnum on jäädvustuses ja ülekanne takerdub endiselt, eirab saatja seda, mis viib uurimise pigem virna kui võrku.

Muutke tunneli suurust alles pärast tõendeid

Tunneli MTU vähendamine võib peita filtreeritud sõnumi ja panna sümptomi kaduma, ent iga paketi suurema lisakoormuse hinnaga. See on mööraminek, mitte diagnoos, ja see peaks järgnema jäädvustusele, mitte seda asendama. Meelevaldselt madal väärtus ei riku samuti midagi nähtavat, mistõttu püsib see konfiguratsioonides aastaid. Muutke seda teadlikult, kirjutage väärtus üles ja märkige, milline mõõtmine seda õigustas.

Kui te lüüsi kontrollite, uurige reeglit, mis sõnumi ära viskab, selle asemel et tulemüür välja lülitada. Üks parandatud reegel on kitsam kui poliitika erand ja hiljem palju lihtsam kaitsta. Sama loogika kehtib aegumiste kohta: iga takerdumine ei ole suuruse probleem ja jäädvustus on see, mis eristab neid kahte.