VPN MTU haqidagi afsonalar: paketlaringiz nima uchun kichrayadi va joy qayerga ketadi

Kimdir sizga VPN "MTU tufayli paket yo'qotyapti" deydi, siz tunnelni 1400 ga qo'yasiz va uzatish yana ishlaydi. Bu natija diagnozdek tuyuladi. Odatda bu arifmetik tasodif: siz hech qachon aniqlamagan chegara ostiga sig'adigan darajada kichik sonni tanladingiz va keyingi tarmoqda boshqa byudjet bilan o'sha chegaraga yana duch kelasiz.

Buning ko'p qismini ikkita afsona keltirib chiqaradi. Birinchisi — tunnel interfeysining MTU-si yo'lning MTU-si. Ikkinchisi — inkapsulyatsiya "bitta sarlavha" turadi, PPPoE esa hisoblashga arziydigan hech narsa turmaydi. Ikkalasi ham tanlagan soningiz o'zboshimchalik bilan ko'rinadigan, aslida esa aniqlangan tarzda xato.

Birinchi afsona: tunnelning MTU-si yo'lning MTU-si

Tunnel interfeysida o'rnatadigan qiymat eng katta ichki paket haqidagi mahalliy va'da bo'lib, uni amalga oshirish pastga topshiradi. Yo'lning haqiqiy sig'imi siz va uzoq uch o'rtasidagi har bir bog'lanishning xususiyati bo'lib, marshrut o'zgarganda, mobil aloqa topshirilganda yoki trafik boshqa peering olganda o'zgarishi mumkin. O'rnatilgan 1500 sizning xostingiz nima qurayotganini aytadi, tarmoq nima tashishini emas.

Yo'l MTU-sini aniqlash ikkalasini uyg'unlashtirish uchun mavjud va qayta aloqaga bog'liq. IPv4 da to'liq o'lchamli paketni uzata olmaydigan marshrutizator ICMP "fragmentation needed" xabarini yuborishi kerak, yuboruvchi esa o'z bahosini pasaytiradi. IPv6 da unga mos Packet Too Big xabari, marshrutizatorlar esa tranzitda umuman fragmentatsiya qilmaydi. Bu qayta aloqa filtrlanganda, yuboruvchi yo'l tashiy olmaydigan paketlarni ishlab chiqarishda davom etadi va hech narsa unga sababini aytmaydi.

Ikkinchi afsona: inkapsulyatsiya bitta sarlavha turadi

Tashqi qatlamlarni halol sanang. Tashqi IP sarlavhasi IPv4 da 20 bayt yoki IPv6 da 40 bayt. NAT dan o'tish uchun UDP inkapsulyatsiyasi 8 qo'shadi. Tunnel protokoli o'z sarlavhasini, initsializatsiya vektorini yoki nonce, shifr bloki yoki tekislash chegarasigacha to'ldirishni, yakuniy qismni va yaxlitlik tekshiruvi qiymatini qo'shadi. Protokol va shifrga qarab, jami ichki paket boshlanishidan oldin bemalol o'nlab baytga etadi.

Keyin ichki paketning o'z sarlavhalari uchun yana ayiring. Tunnel ichidagi TCP segmenti o'zining 20 baytli IP sarlavhasi va 20 baytli TCP sarlavhasini tashiydi, TCP ning MSS esa tunnelning nominal yukidan emas, MTU dan kelib chiqadi. Shuning uchun ping kichikroq yuk bilan muvaffaqiyat qozonishi mumkin, fayl uzatish esa tiqilib qoladi: asboblar turli narsalarni sinaydi va ulardan faqat bittasi to'liq o'lchamli TCP segmentini ishlatadi.

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

Birinchi buyruq o'rnatilgan tunnel MTU-sini xabar qiladi. Ikki sinov 1472 baytli yuk yuboradi, bu IPv4 va ICMP sarlavhalarining 28 bayti bilan 1500 baytli paket, keyin kichikroq. Agar katta sinov butunlay muvaffaqiyatsiz bo'lib, kichigi muvaffaqiyatli bo'lsa, sizda o'lchamga bog'liq nosozlik bor, umumiy marshrutlash muammosi emas.

Uchinchi afsona: PPPoE hali ham sizga toza 1500 beradi

An'anaviy PPPoE kirish bog'lanishi 1500 baytli IP paketini tashimaydi. PPPoE sarlavhasi va PPP protokoli maydoni Ethernet kadri ichida 8 baytni egallaydi, bu IP paketiga 1492 qoldiradi. Bu RFC 2516 da tasvirlangan an'anaviy chegara. Agar shunday bog'lanish ustida VPN yuritsangiz, tunnelning qo'shimcha xarajati 1500 dan emas, o'sha 1492 dan chiqadi.

RFC 4638 kattaroq PPP yuki bo'yicha muzokara qilish usulini belgilaydi, agar kirish konsentratori ham, mijoz uskunasi ham qo'llab-quvvatlasa, shuning uchun "bu ulanish PPPoE ishlatadi" degan gapning o'zi aniq sonni isbotlamaydi. Mahalliy sozlama oraliq qurilmani u uchun hech qachon sozlanmagan paketni qabul qilishga majburlay olmaydi, shuning uchun foydali savol — yorliq nima deyishi emas, bog'lanish aslida nima bo'yicha kelishgani.

Nega nosozlik tanlab olingandek ko'rinadi

Kichik so'rovlarning muvaffaqiyati va katta uzatishlarning tiqilib qolishi yo'l MTU-sining qora tuynugi klassik belgisidir. Qo'l berib ko'rishish, DNS so'rovi va API chaqiruvi barchasi sig'adi; ommaviy uzatish bir bog'lanishda o'ladigan to'liq o'lchamli segmentlarni yaratadi, muammoni xabar qilishi kerak bo'lgan ICMP xabari esa hech qachon yetib kelmaydi. Ulanish yaxshi ko'rinadi va yuklab olish osilib qoladi, bu odamlarni yo'l o'rniga serverga qarashga undaydi.

Ikkinchi, bog'liq xato — uchta sonni aralashtirish: interfeys MTU-si, TCP ning MSS-si va protokolning o'z fragmentatsiya yoki to'ldirish sozlamasi. Marshrutizatordagi MSS siqish e'lon qilingan MSS ni qayta yozadi, shunda yuboruvchi kichikroq segmentlar quradi; u tunnel MTU-sini o'zgartirmaydi va UDP trafigiga yordam bermaydi. Ular bog'liq ko'ringani uchun uchalasiga bir xil son berish — yaxshi niyatli o'zgarish ishlayotgan sozlamani buzish usuli.

Nimani va qanday tartibda o'zgartirish kerak

Dalildan boshlang. Yuqoridagi sinovlar bilan nosozlikning o'lchamga bog'liqligini tasdiqlang, so'ng o'tadigan eng kichik o'lchamni va muvaffaqiyatsiz bo'ladigan eng kattasini toping. Tunnelni ayblashdan oldin kirish bog'lanishining haqiqiy MTU-sini tekshiring; PPPoE bog'lanishi VPN unga tegishidan oldin byudjetni cheklaydi. O'zgartirishni qaytarish mumkin bo'lishi uchun boshlang'ich qiymatlarni yozib qo'ying.

So'ng mijoz hujjatlashtiradigan eng kichik tuzatishni qo'llang. Ko'p mijozlar tunnel MTU-si va MSS tuzatish opsiyasini taklif qiladi, MSS opsiyasi esa TCP uchun ko'pincha yaxshiroq dastak, chunki har bir paketni kichraytirmasdan yuboruvchiga yetadi. Xuddi shu manzil va xuddi shu uzatishni qayta sinang va to'xtagan raqamlaringizni yozib oling. Bitta kirish tarmog'ida ishlaydigan tunnel qiymati universal konstanta emas va keyingi joyning o'z byudjeti bo'ladi.