Ping ishlaydi, brauzer kichik sahifani yuklaydi, fayl uzatish esa to'xtaydi — barchasi bitta tunnel orqali IPv6 da. Bunday holat odatda tunnel sekinligini emas, yuboruvchi yo'lning haqiqiy o'lchamini hech qachon bilmaganini bildiradi. IPv6 routerlar muammoni Packet Too Big xabari bilan bildirishini kutadi, inkapsulyatsiya esa paket tashqi tarmoqqa yetib bormasdan oldin qo'shimcha yuk qo'shadi. Agar bu xabar filtrlansa, yuboruvchi o'ta olmaydigan o'lchamni takrorlayveradi.

Kichik so'rovlar, katta to'xtashlar

Tunnel har bir paketni yana bir sarlavhaga o'raydi, shuning uchun ichkarida ishlatiladigan o'lcham tashqaridagidan kichik. Inkapsulyatsiyadan oldin jismoniy havola uchun o'lchangan paket keyin juda katta bo'lib qoladi. IPv4 routerlar yo'lda bo'laklashi mumkin, IPv6 routerlar esa buni yuboruvchi nomidan qilmaydi, shuning uchun yuboruvchi o'zi moslashishi kerak. Va bu moslashuv butunlay qayta aloqa olinishiga bog'liq.

Bitta yo'qolgan xabar klassik belgini keltirib chiqarish uchun yetarli: qo'l siqishlar va kichik javoblar muvaffaqiyatli o'tadi, katalog ro'yxati yoki yuklash esa har safar bir xil joyda to'xtaydi. Foydalanuvchilar buni sekin VPN deb ta'riflaydi, jurnallar autentifikatsiyada hech qanday xato ko'rsatmaydi. Ikkala kuzatuv ham to'g'ri va hech biri nosozlik joyini topmaydi.

Packet Too Big — qayta aloqa, trafik emas

ICMPv6 Packet Too Big xabari keyingi sakrash qabul qila oladigan o'lchamni tashiydi, yuboruvchi undan o'z bahosini tushirish uchun foydalanadi. Uni filtrlash yo'l belgisini olib tashlab, keyin haydovchilarni ayblash bilan barobar. Barcha ICMPv6 ni tashlab yuboradigan qoida qattiq ko'rinadi, ammo unga muhtoj har bir havolada yo'l topishni buzadi. Xabar yo'l haqidagi boshqaruv ma'lumoti, ilova yuki emas.

Tanlab filtrlash hali ham o'rinli. Exo so'rovlari va qo'shnilarni topish xato xabarlaridan boshqa rol o'ynaydi, siyosat ularga boshqacha munosabatda bo'lishi mumkin. Butun protokolni qabul qilish yoki tashlash o'rniga platformaning hujjatlashtirilgan filtrlash yo'riqnomasiga amal qiling, chunki RFC 8201 bu qayta aloqaning topishni qanday boshqarishini belgilaydi.

Ikki manzil oilasini alohida sinang

IPv6 ni alohida sinab ko'ring, chunki muvaffaqiyatli IPv4 uzatishi IPv6 yo'li haqida hech narsani isbotlamaydi. So'ngra katta uzatish to'xtab turganda boshqaruv xabarlarini ushlang. Ikki yozuv birgalikda qayta aloqa chiqayotganini ko'rsatadi yoki u hech qachon yetib kelmaganini isbotlaydi.

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'

Zond do-not-fragment bitini o'rnatib paket yuboradi va u muvaffaqiyatsiz bo'ladigan o'lchamni xabar qiladi — bu tunnel sig'dirishi kerak bo'lgan raqam. Marshrut so'rovi manzilni olib boradigan interfeysni nomlaydi, shuning uchun qaysi havolaning MTU si amal qilishini bilasiz. Ushlash ICMPv6 2-turini, ya'ni Packet Too Big xabarini filtrlaydi va u bu hostga yetib borishini ko'rsatadi. Agar xabar ushlashda ko'rinsa va uzatish hali ham to'xtab tursa, yuboruvchi uni e'tiborsiz qoldirmoqda, bu tekshiruvni tarmoqdan stekka o'tkazadi.

Tunnel o'lchamini faqat dalillardan keyin o'zgartiring

Tunnel MTU sini pasaytirish filtrlangan xabarni yashirib, belgini yo'qotishi mumkin, ammo har bir paketga ko'proq yuk hisobiga. Bu yechim emas, chetlab o'tish va u ushlashdan keyin kelishi kerak, uni almashtirmasligi kerak. O'zboshimchalik bilan past qiymat ham ko'rinadigan hech narsani buzmaydi, shuning uchun u yillar davomida konfiguratsiyalarda qoladi. Uni ataylab o'zgartiring, qiymatni yozib qo'ying va qaysi o'lchov uni oqlaganini belgilang.

Darvoza sizning nazoratingizda bo'lsa, xavfsizlik devorini o'chirish o'rniga xabarni tashlaydigan qoidani tekshiring. Bitta tuzatilgan qoida siyosatdagi istisnodan torroq va keyinchalik himoya qilish ancha oson. Xuddi shu mantiq taym-autlarga ham tegishli: har bir to'xtash o'lcham muammosi emas va ikkalasini ajratadigan narsa — ushlash.

O'xshash maqolalar