VPN MTU mitai: kodėl jūsų paketai mažėja ir kur dingsta vieta

Kažkas jums sako, kad VPN "praranda paketus dėl MTU", jūs nustatote tunelį į 1400, ir perdavimas vėl veikia. Toks rezultatas atrodo kaip diagnozė. Dažniausiai tai aritmetinis sutapimas: pasirinkote skaičių, pakankamai mažą, kad tilptų po riba, kurios niekada nenustatėte, ir su ta pačia riba vėl susidursite kitame tinkle su kitu biudžetu.

Daugumą to sukelia du mitai. Pirmasis – kad tunelio sąsajos MTU yra kelio MTU. Antrasis – kad inkapsuliavimas kainuoja "vieną antraštę", o PPPoE nekainuoja nieko, ką verta skaičiuoti. Abu klaidingi taip, kad pasirinktas skaičius atrodo savavališkas, nors iš tikrųjų yra nulemtas.

Pirmas mitas: tunelio MTU yra kelio MTU

Reikšmė, kurią nustatote tunelio sąsajoje, yra vietinis pažadas dėl didžiausio vidinio paketo, kurį įgyvendinimas perduos žemyn. Tikrasis kelio pajėgumas yra kiekvienos grandies tarp jūsų ir tolimojo galo savybė, ir jis gali keistis, kai keičiasi maršrutas, kai mobilusis ryšys perduodamas arba kai srautas pasirenka kitą peering. Nustatytas 1500 pasako, ką pastatys jūsų hostas, o ne ką perneš tinklas.

Kelio MTU nustatymas egzistuoja tam, kad suderintų abu, ir priklauso nuo grįžtamojo ryšio. IPv4 atveju maršrutizatorius, negalintis persiųsti viso dydžio paketo, turėtų siųsti ICMP "fragmentation needed" pranešimą, ir siuntėjas sumažina savo įvertį. IPv6 atveju atitikmuo yra Packet Too Big pranešimas, o maršrutizatoriai tranzitu visai nefragmentuoja. Kai tas grįžtamasis ryšys filtruojamas, siuntėjas toliau kuria paketus, kurių kelias negali pernešti, ir niekas nepasako kodėl.

Antras mitas: inkapsuliavimas kainuoja vieną antraštę

Sąžiningai suskaičiuokite išorinius sluoksnius. Išorinė IP antraštė yra 20 baitų IPv4 arba 40 IPv6. UDP inkapsuliavimas NAT praėjimui prideda 8. Tunelio protokolas prideda savo antraštę, inicijavimo vektorių arba nonce, užpildymą iki šifro bloko arba lygiavimo ribos, pabaigos dalį ir vientisumo patikros reikšmę. Priklausomai nuo protokolo ir šifro, suma patogiai siekia dešimtis baitų dar prieš prasidedant vidiniam paketui.

Tada vėl atimkite paties vidinio paketo antraštes. TCP segmentas tunelio viduje neša savo 20 baitų IP antraštę ir 20 baitų TCP antraštę, o TCP MSS išvedamas iš MTU, o ne iš nominalios tunelio naudingosios apkrovos. Štai kodėl ping su mažesne apkrova gali pavykti, kol failo perdavimas stringa: įrankiai tikrina skirtingus dalykus, ir tik vienas jų naudoja viso dydžio TCP segmentą.

ip link show tun0
ping -M do -s 1472 192.0.2.10
ping -M do -s 1400 192.0.2.10

Pirmoji komanda praneša nustatytą tunelio MTU. Du zondai siunčia 1472 baitų apkrovą, kuri su 28 baitais IPv4 ir ICMP antraščių yra 1500 baitų paketas, o paskui mažesnį. Jei didelis zondas visiškai nepavyksta, o mažas pavyksta, turite nuo dydžio priklausantį gedimą, o ne bendrą maršrutizavimo problemą.

Trečias mitas: PPPoE vis dar duoda švarų 1500

Įprasta PPPoE prieigos grandis neperneša 1500 baitų IP paketo. PPPoE antraštė ir PPP protokolo laukas užima 8 baitus Ethernet kadre, todėl IP paketui lieka 1492. Tai tradicinė riba, aprašyta RFC 2516. Jei per tokią grandį leidžiate VPN, tunelio sąnaudos imamos iš tų 1492, o ne iš 1500.

RFC 4638 apibrėžia būdą derėtis dėl didesnės PPP naudingosios apkrovos, kai tai palaiko ir prieigos koncentratorius, ir kliento įranga, todėl vien "šis ryšys naudoja PPPoE" neįrodo konkretaus skaičiaus. Vietinis nustatymas negali priversti tarpinio įrenginio priimti paketą, kuriam jis niekada nebuvo sukonfigūruotas, todėl naudingas klausimas yra tai, dėl ko grandis iš tikrųjų susiderėjo, o ne ką sako etiketė.

Kodėl gedimas atrodo selektyvus

Mažų užklausų sėkmė ir didelių perdavimų strigimas yra klasikinis kelio MTU juodosios skylės požymis. Rankos paspaudimas, DNS užklausa ir API kvietimas visi telpa; masinis perdavimas sukuria viso dydžio segmentus, kurie miršta vienoje grandyje, o ICMP pranešimas, kuris turėjo pranešti apie problemą, niekada neatvyksta. Ryšys atrodo tvarkingas, o atsisiuntimas stringa, todėl žmonės ima žiūrėti į serverį, o ne į kelią.

Antra, susijusi klaida – painioti tris skaičius: sąsajos MTU, TCP MSS ir paties protokolo fragmentavimo ar užpildymo nustatymą. MSS suspaudimas maršrutizatoriuje perrašo skelbiamą MSS, kad siuntėjas kurtų mažesnius segmentus; jis nekeičia tunelio MTU ir nepadeda UDP srautui. Duoti visiems trims tą patį skaičių, nes jie atrodo susiję, yra būdas, kuriuo geranoriškas pakeitimas sugadina veikiančią konfigūraciją.

Ką keisti ir kokia tvarka

Pradėkite nuo įrodymų. Patvirtinkite aukščiau pateiktais zondais, kad gedimas priklauso nuo dydžio, tada raskite mažiausią dydį, kuris praeina, ir didžiausią, kuris nepavyksta. Prieš kaltindami tunelį patikrinkite tikrąjį prieigos grandies MTU; PPPoE grandis apriboja biudžetą dar prieš VPN jį paliesdamas. Užsirašykite pradines reikšmes, kad pakeitimą būtų galima atšaukti.

Tada pritaikykite mažiausią koregavimą, kurį dokumentuoja klientas. Daugelis klientų siūlo tunelio MTU ir MSS taisymo parinktį, o MSS parinktis dažnai yra geresnė svirtis TCP, nes pasiekia siuntėją nesumažindama kiekvieno paketo. Dar kartą išbandykite tą patį tikslą ir tą patį perdavimą ir užsirašykite skaičius, prie kurių apsistojote. Tunelio reikšmė, veikianti viename prieigos tinkle, nėra universali konstanta, ir kita vietovė turės savo biudžetą.