IPv4 sadala ceļā; IPv6 tā vietā sūta ziņojumu par pārāk lielu paketi

IPv6 atteices daudz biežāk piedēvē protokolam, nevis paketes izmēram, kas tās izraisīja. Abas saimes patiešām apstrādā pārāk lielu paketi atšķirīgi, un tieši tunelis padara šo atšķirību svarīgu. IPv4 maršrutētāji drīkst sadalīt paketi, kad noteikumi to atļauj, bet IPv6 maršrutētāji ceļā nedrīkst sadalīt vispār. IPv6 tā vietā pasaka sūtītājam, un no sūtītāja tiek gaidīta reakcija. Viss, kas pēc tam noiet greizi, izriet no tā, vai šis ziņojums nonāk.

Ko dara katra saime

Tabula ir mehānisms četrās rindās, un viena rinda izskaidro lielāko daļu apjukuma.

IPv6 nav sadalīšanas ceļā un nav DF karodziņa, ko notīrīt, tāpēc nav uz ko atbalstīties, kad pakete ir pārāk liela. Sūtītājam tas jāpasaka, un sūtītājam tam jātic.

Tunelis klusi sašaurina ceļu

VPN pievieno ārējos galvenes, bet šifrētā gadījumā arī integritātes datus, pirms pakete atstāj resursdatoru. Iekšējā pakete var ietilpt saskarnes MTU, ko tā redz, kamēr ārējā pakete pārsniedz nākamās saites robežu, un tāpēc tas vispirms parādās tunelī. Apzināti samaziniet tuneļa saskarnes MTU vai pievelciet TCP MSS ceļā, un pierakstiet, kādu skaitli izvēlējāties un kāpēc.

ESP papildu izmaksas ir atkarīgas no režīma un algoritmiem, tāpēc pareizais tuneļa MTU ir aprēķins, nevis tradīcija. Ko vien jūs izvēlētos, tam jāatstāj vieta pilnai 1280 baitu iekšējai IPv6 paketei, jo katrai IPv6 saitei ir jānes tik daudz. Tunelis, kas nespēj nest 1280 baitu IPv6, nav regulēšanas problēma; tas ir salauzts ceļš šai saimei. Tieši šis ierobežojums pazūd, kad MTU vērtība tiek nokopēta no izvietojuma, kurā ir tikai IPv4.

Kāpēc simptoms izskatās kā iekāršanās

Atteice nav tīra kļūda, un tāpēc tā tiek diagnosticēta nepareizi. TCP rokasspiediens pabeidzas, mazas atbildes pienāk, un savienojums apstājas līdzko sākas liela atbilde vai liela augšupielāde, jo tās ir pirmās paketes, kas ir pietiekami lielas, lai tiktu izmestas. SSH pieslēdzas un pēc tam iekaras pie pirmās lielās izvades, un lapas galvene ielādējas, kamēr pamatteksts nekad nebeidzas.

Ja ICMPv6 ziņojumi par pārāk lielu paketi tiek filtrēti, sūtītājs to nekad neuzzina un turpina mēģināt to pašu izmēru. Tas ir melnais caurums, nevis lēns ceļš, un tā pazīme ir atkārtojama izmēra robeža, nevis nejaušs zudums. Attiecīgās vadības plūsmas atļaušana ir strādājoša IPv6 izvietojuma daļa, nevis pieklājība.

Neizslēdziet ziņojumus, no kuriem atkarīgs jūsu pašu ceļš, un pēc tam neaprakstiet rezultātu kā IPv6 defektu. Tas pats arguments attiecas uz IPv4 Fragmentation Needed ziņojumiem, kas ugunsmūru autoriem ir tikpat nepopulāri un tikpat nepieciešami.

Izmēriet robežu, tad izlabojiet slāni

Pārbaudiet, nevis miniet: izmantojiet don't-fragment karodziņu IPv4 un fiksētus lietderīgās kravas izmērus IPv6, un pierakstiet, kur atbildes apstājas. ping -M do -s 1472 un ping -6 -s 1400 ir pietiekami, lai noteiktu problēmas formu, un tracepath ziņo par ceļā atklāto maršruta MTU.

Pēc tam izlabojiet to slāni, kuram pieder skaitlis: tuneļa saskarnes MTU, TCP MSS pievilkšanu vai pašu ceļu. RFC 8200 ir IPv6 noteikuma atsauce, un to lasīt ir īsāk nekā izmeklēt negadījumu, ko tā novērš.

Pārbaudiet to saimi, ko lietojumprogramma patiešām izmanto, jo divkāršā steha nosaukums var atbildēt vienā saimē un ne otrā, un lietojumprogramma var pārslēgties pēc tīkla maiņas. Pierakstiet adresi, ko pārbaudījāt, jo rezultāts pret A ierakstu neko neizsaka par AAAA ierakstu.

Uztveriet izmēra robežu kā pierādījumu

Atkārtojama izmēra robeža ir viens no nedaudzajiem tīkla defektiem, kas atkārtojas precīzi, pie tā paša baitu skaita, no tā paša avota, katru reizi. Tas to padara par dāvanu, nevis mīklu, un nozīmē arī to, ka labojumu var pārbaudīt, nevis cerēt uz to.

Pierakstiet biļetē atklāto MTU, konfigurēto tuneļa MTU un testu, kas pierādīja atšķirību. Nākamais cilvēks sastaps to pašu aritmētiku citā saitē.