Per didelis IPv6 paketas: kodėl dideli VPN perdavimai sustoja

Ping veikia, naršyklė įkelia mažą puslapį, o failo perdavimas užstringa — visa tai per IPv6 tuo pačiu tuneliu. Toks modelis paprastai reiškia, kad siuntėjas taip ir neišmoko tikrojo kelio dydžio, o ne kad tunelis lėtas. IPv6 tikisi, kad maršrutizatoriai praneš apie problemą Packet Too Big pranešimu, o inkapsuliavimas prideda papildomų sąnaudų dar prieš paketui pasiekiant išorinį tinklą. Jei tas pranešimas filtruojamas, siuntėjas kartoja dydį, kuris negali praeiti.

Mažos užklausos, dideli užstrigimai

Tunelis apvynioja kiekvieną paketą dar viena antrašte, todėl naudingas dydis viduje yra mažesnis už dydį lauke. Paketas, suderintas su fizine jungtimi prieš inkapsuliavimą, po jo tampa per didelis. IPv4 maršrutizatoriai gali fragmentuoti kelyje, o IPv6 maršrutizatoriai to nedaro siuntėjo vardu, todėl siuntėjas turi prisitaikyti pats. Ir tas prisitaikymas visiškai priklauso nuo to, ar gaunamas grįžtamasis ryšys.

Vieno pamesto pranešimo pakanka klasikiniam simptomui: rankų paspaudimai ir maži atsakymai pavyksta, o katalogo sąrašas ar įkėlimas kaskart sustoja toje pačioje vietoje. Naudotojai tai apibūdina kaip lėtą VPN, o žurnalai nerodo jokios autentifikavimo klaidos. Abu pastebėjimai tikslūs, ir nė vienas jų neranda gedimo vietos.

Packet Too Big yra grįžtamasis ryšys, o ne srautas

ICMPv6 Packet Too Big pranešimas neša dydį, kurį gali priimti kitas šuolis, ir siuntėjas jį naudoja savo įverčiui sumažinti. Jį filtruoti tas pats, kas nuimti kelio ženklą ir tada kaltinti vairuotojus. Taisyklė, kuri išmeta visą ICMPv6, atrodo griežta, bet sugriauna kelio atradimą kiekvienoje jungtyje, kuriai jo reikia. Pranešimas yra valdymo informacija apie kelią, o ne programos naudingasis krovinys.

Selektyvus filtravimas vis dar pagrįstas. Aido užklausos ir kaimynų atradimas atlieka kitokį vaidmenį nei klaidų pranešimai, ir politika gali juos traktuoti kitaip. Vadovaukitės dokumentuotomis platformos filtravimo gairėmis, o ne priimkite ar atmeskite visą protokolą, nes RFC 8201 apibrėžia, kaip tas grįžtamasis ryšys valdo atradimą.

Tikrinkite abi adresų šeimas atskirai

Tikrinkite IPv6 atskirai, nes sėkmingas IPv4 perdavimas nieko neįrodo apie IPv6 kelią. Tada fiksuokite valdymo pranešimus, kol didelis perdavimas stringa. Abu įrašai kartu arba rodo, kad grįžtamasis ryšys išeina, arba įrodo, kad jis niekada neatėjo.

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'

Zondas siunčia paketą su nustatytu do-not-fragment bitu ir praneša dydį, kuriuo jis nepavyksta, — tai skaičius, kurį tunelis turi sutalpinti. Maršruto užklausa nurodo sąsają, kuri neštų paskirties vietą, todėl žinote, koks jungties MTU galioja. Fiksavimas filtruoja ICMPv6 2 tipą, Packet Too Big pranešimą, ir parodo, ar jis apskritai pasiekia šį hostą. Jei pranešimas matomas fiksavime, o perdavimas vis dar stringa, siuntėjas jį ignoruoja, o tai perkelia tyrimą į steką, o ne į tinklą.

Keiskite tunelio dydį tik po įrodymų

Sumažinus tunelio MTU, galima paslėpti filtruotą pranešimą ir pašalinti simptomą, tačiau už didesnes kiekvieno paketo sąnaudas. Tai apėjimas, o ne diagnozė, ir jis turėtų sekti po fiksavimo, o ne jį pakeisti. Savavališkai maža reikšmė irgi nieko matomai nesugadina, todėl išlieka konfigūracijose metų metus. Keiskite ją sąmoningai, užrašykite reikšmę ir nurodykite, kuris matavimas ją pateisino.

Kai valdote tinklų sietuvą, patikrinkite taisyklę, kuri išmeta pranešimą, o ne išjunkite ugniasienę. Viena pataisyta taisyklė yra siauresnė už politikos išimtį ir daug lengviau apginama vėliau. Ta pati logika galioja ir laiko limitams: ne kiekvienas užstrigimas yra dydžio problema, ir būtent fiksavimas atskiria abu.