DNS išsprendžiamas, SSH sesija išlieka, o tada didelis įkėlimas užšąla, nors ping į tą patį hostą vis dar atsako. Šis atskyrimas rodo paketo dydį, o ne sugedusį tunelį. Įdėtieji tuneliai tai pasiekia tokiais dydžiais, kurių nė vienas tunelis vienas nepasiektų. Vidinė sesija yra tvarkinga; jai tiesiog perduodami paketai, kurie nebetelpa.

Kur iš tikrųjų dingsta kelio MTU

Kiekviena inkapsuliacija išleidžia baitus, kol kitas sluoksnis gauna savo eilę. Ethernet kelias siūlo išoriniam paketui 1500 baitų, o išorinis tunelis pasiima savo dalį, kol dar nieko jo viduje negalima adresuoti. Viena spėjama pridėtinių išlaidų reikšmė bus neteisinga būtent tiek, kiek tai svarbu.

Išvardykite sluoksnius iš eilės: prieigos kelias, išorinis transportas, išorinis tunelis, vidinis transportas, vidinis tunelis, programa. Kiekvieną antraštę skaičiuokite vieną kartą, o UDP laikykite atskirai nuo paties tunelio antraštės ir žymos.

Du WireGuard sluoksniai, suskaičiuoti vieną kartą

Paimkite IPv4 prieigos kelią su vienu WireGuard tuneliu kitame. Išorinis sluoksnis kainuoja 20 baitų IPv4, 8 UDP ir 32 WireGuard duomenų antraštei bei jos autentifikavimo žymai. To viduje vidiniam tuneliui reikia savo 20 baitų IPv4 antraštės ir 8 baitų UDP antraštės prieš antrąjį 32 baitų WireGuard papildomą sluoksnį. Kas lieka, talpina IPv4 antraštę, TCP antraštę ir duomenis. Išorinis IPv6 kelias kainuoja 40 vietoj 20 ir palieka 1320.

LayerBytes
Path MTU1500
Outer IPv4 header20
Outer UDP header8
Outer WireGuard header and tag32
Inner transport IPv4 header20
Inner UDP header8
Inner WireGuard header and tag32
Innermost IPv4 header20
TCP header20
Payload that fits1340

Aritmetika baigiasi ties 1340 baitų. Vienas sluoksnis pagal tas pačias taisykles palieka 1400 TCP naudingajai apkrovai, tai yra 1500 minus 20, 8, 32, 20 ir 20, o 60 baitų skirtumas yra būtent vidinė inkapsuliacija, kurią prideda antrasis tunelis.

Pritaikykite 1400 įdėtajam keliui ir vidiniam tuneliui trūksta 60 baitų, nepastebimai, kol paketas netampa pakankamai didelis, kad jų prireiktų. Užpildymas ir protokolo paties fragmentavimo parinktis vėl pastumia skaičius, todėl pasitikėkite lentele.

MTU, MSS ir fragmentavimas veikia skirtingose vietose

Sąsajos MTU riboja, ką sąsaja išsiųs, o TCP MSS suspaudimas keičia, ką TCP partneris sutinka siųsti. Suspaudimas sutvarko TCP sesijas ir nieko nedaro didelei UDP datagramai, todėl pataisa atrodo sėkminga vienai programai ir tyliai praleidžia kitą. Paties protokolo fragmentavimo parinktis yra trečioji svirtis su savo nesėkmėmis. Sąsajos MTU yra įprastas pirmas veiksmas ir grubiausias.

Tiltiniai ir maršrutizuoti tuneliai perduoda skirtingus kadrus, todėl skaičiai iš kito diegimo retai persikelia. Kelio MTU aptikimas, aprašytas RFC 8201, padeda tik tol, kol leidžiami ICMP pranešimai, nuo kurių jis priklauso.

Rasti sluoksnį, kurio trūksta

Patikrinkite kiekvieną tunelį atskirai prieš juos įdedant, jei reikalavimai leidžia palyginimą. Fiksuoto dydžio zondas tai išsprendžia: ping -M do -s 1472 -c 3 10.8.0.1 siunčia visą 1500 baitų IPv4 paketą tame sluoksnyje. Pridėkite antrą sluoksnį ir pakartokite tą patį zondą, kad bet kokia nesėkmė priklausytų žinomam pakeitimui.

Kai perdavimas sustoja, keiskite po vieną dokumentuotą parametrą ir užrašykite dydį, kuriuo jis nepavyksta. Patikrinkite ir grįžimo kelią, nes įdėtoji maršrutų rekursija gali pakankamai tiksliai imituoti paketo dydžio problemą, kad kainuotų pusdienį. Filtruotas ICMP atsakymas gali paslėpti tikrąją ribą, todėl zondas svarbesnis už samprotavimą.

Užrašykite biudžetą ten, kur jį ras kitas žmogus

Lentelė su viena eilute vienam sluoksniui išgyvena ilgiau nei nykščio taisyklė. Laikykite ją prie tunelio schemos, kad niekas neatliktų aritmetikos dar kartą esant spaudimui.

Daugiau tunelių reiškia daugiau priklausomybių, todėl atsukimo planas nusipelno vietos prie biudžeto. Jei skaičiai vis tiek nesueina, išmatuokite kelią, o ne spėliokite dar kartą. Tikslas yra skaičius, kurį galite apginti, o ne atsiminti.

Susiję straipsniai