IPv4 skaido kelyje; IPv6 vietoj to siunčia pranešimą apie per didelį paketą

IPv6 gedimai daug dažniau priskiriami protokolui, o ne paketo dydžiui, kuris juos sukėlė. Abi šeimos iš tikrųjų skirtingai tvarko per didelį paketą, ir būtent tunelis padaro tą skirtumą svarbų. IPv4 maršrutizatoriai gali suskaidyti paketą, kai taisyklės tai leidžia, o IPv6 maršrutizatoriai kelyje neturi skaidyti visai. IPv6 vietoj to pasako siuntėjui, ir tikimasi, kad siuntėjas sureaguos. Viskas, kas vėliau nepavyksta, kyla iš to, ar tas pranešimas atkeliauja.

Ką daro kiekviena šeima

Lentelė yra mechanizmas keturiose eilutėse, ir viena eilutė paaiškina didžiąją dalį painiavos.

IPv6 neturi skaidymo kelyje ir neturi DF vėliavėlės, kurią reikėtų išvalyti, todėl nėra ko atsiremti, kai paketas per didelis. Siuntėjui reikia pasakyti, ir siuntėjas turi tuo patikėti.

Tunelis tyliai susiaurina kelią

VPN prideda išorines antraštes, o šifruotu atveju ir vientisumo duomenis, prieš paketui paliekant hostą. Vidinis paketas gali tilpti į matomą sąsajos MTU, o išorinis paketas viršija kitos grandies ribą, todėl tai pirmiausia pasirodo tunelyje. Sąmoningai sumažinkite tunelio sąsajos MTU arba kelio ruože suveržkite TCP MSS ir užsirašykite, kokį skaičių pasirinkote ir kodėl.

ESP sąnaudos priklauso nuo režimo ir algoritmų, todėl teisingas tunelio MTU yra skaičiavimas, o ne konvencija. Ką bebepasirinktumėte, tai turi palikti vietos visam 1280 baitų vidiniam IPv6 paketui, nes kiekviena IPv6 grandis privalo tiek nešti. Tunelis, kuris negali nešti 1280 baitų IPv6, nėra derinimo problema; tai sugedęs kelias tai šeimai. Būtent šis apribojimas išnyksta, kai MTU reikšmė nukopijuojama iš diegimo, skirto tik IPv4.

Kodėl simptomas atrodo kaip užstrigimas

Gedimas nėra švari klaida, todėl jis diagnozuojamas neteisingai. TCP rankos paspaudimas baigiasi, maži atsakymai ateina, ir ryšys sustoja vos prasidėjus dideliam atsakymui ar dideliam įkėlimui, nes tai pirmieji paketai, pakankamai dideli, kad būtų išmesti. SSH prisijungia ir tada užstringa ties pirmu dideliu išvedimu, o puslapio antraštė įkeliama, kol turinys niekada nebaigiamas.

Jei ICMPv6 pranešimai apie per didelį paketą filtruojami, siuntėjas niekada nesužino ir vis kartoja tą patį dydį. Tai juodoji skylė, o ne lėtas kelias, ir jo požymis yra pasikartojanti dydžio riba, o ne atsitiktinis praradimas. Leisti atitinkamą valdymo srautą yra veikiančio IPv6 diegimo dalis, o ne mandagumas.

Neišjunkite pranešimų, nuo kurių priklauso jūsų pačių kelias, ir tada neaprašykite rezultato kaip IPv6 gedimo. Tas pats argumentas galioja IPv4 Fragmentation Needed pranešimams, kurie ugniasienių autoriams ne tokie pat nepopuliarūs ir ne mažiau būtini.

Išmatuokite ribą, tada pataisykite sluoksnį

Tikrinkite, o ne spėkite: naudokite don't-fragment vėliavėlę IPv4 atveju ir fiksuotus naudingosios apkrovos dydžius IPv6 atveju, ir užrašykite, kur atsakymai sustoja. ping -M do -s 1472 ir ping -6 -s 1400 pakanka problemos formai nustatyti, o tracepath praneša kelyje aptiktą maršruto MTU.

Tada pataisykite sluoksnį, kuriam priklauso skaičius: tunelio sąsajos MTU, TCP MSS suveržimą arba patį kelią. RFC 8200 yra IPv6 taisyklės nuoroda, ir ji trumpesnė skaityti nei incidentas, kurio ji išvengia.

Išbandykite šeimą, kurią programa iš tikrųjų naudoja, nes dvigubo kamino vardas gali atsakyti vienoje šeimoje, o kitoje ne, ir programa gali persijungti po tinklo pakeitimo. Užrašykite adresą, kurį išbandėte, nes rezultatas prieš A įrašą nieko nesako apie AAAA įrašą.

Vertinkite dydžio ribą kaip įrodymą

Pasikartojanti dydžio riba yra vienas iš nedaugelio tinklo gedimų, kurie atsikuria tiksliai, tuo pačiu baitų skaičiumi, iš to paties šaltinio, kiekvieną kartą. Tai daro ją dovana, o ne mįsle, ir taip pat reiškia, kad pataisymą galima patikrinti, o ne tikėtis.

Užrašykite biliete aptiktą MTU, sukonfigūruotą tunelio MTU ir testą, kuris įrodė skirtumą. Kitas žmogus susidurs su ta pačia aritmetika kitoje grandyje.