Nega multicast rejasiz VPN orqali o'tmaydi

Ikki sayt unicast orqali bir-biriga mukammal yetib borishi mumkin va shunga qaramay ulardan biri printerning aniqlash e'lonini, IPTV oqimini yoki klasterning yurak urishini ko'rmayotgandek tutishi mumkin. Bu buzilgan tunnel emas; bu manzil va guruh o'rtasidagi farq. Multicast yetkazib berish uchun a'zolik modeli, yo'l bo'ylab uzatish holati va trafikni tashishga tayyor interfeys kerak, va ularning hech biri unicast marshrutidan kelmaydi. Ilovaning guruhidan bitta ishlaydigan qabul qiluvchigacha borish javobga eng qisqa yo'ldir.

Guruh va ilovadan boshlang

Ilova qaysi guruh manzilini ishlatishini va trafik nima uchun ekanini so'rang. Xizmatlarni e'lon qiluvchi aniqlash protokoli, oqimli oqim va marshrutlash protokolining salom paketlari uch xil muammo va uch xil maqbul javobdir. Guruh manzilining o'zi qamrovni aytadi: mahalliy tarmoq boshqaruv blokidagi manzillar oddiy marshrutlash bilan havoladan tashqariga uzatilishga mo'ljallanmagan, va ularni ishlatadigan ilovalar odatda bitta eshittirish domenini nazarda tutadi. Global qamrovli guruhdagi oqimli oqim har bir qurilma har bir so'rovni eshitadi deb kutadigan aniqlash protokolidan boshqacha dizayn, va faqat ikkinchisi eshittirish domenining hajmi bilan shug'ullanadi.

Talab xizmatmi yoki aniqlash mexanizmi ekanini hal qiling, chunki bu javoblar xarajatda bir tartib bilan farq qiladi. Biri o'zgarmaydigan manzilni so'raydi; ikkinchisi keng hudud havolasi orqali kengaytirilgan eshittirish domeni va undan kelib chiqadigan hamma narsani so'raydi.

Mahalliy aniqlash to'xtashi kerak

RFC 6762 da tasvirlangan Multicast DNS bitta havola atrofida qurilgan: so'rovlar qat'iy guruhga boradi, javoblar o'sha guruhga yuboriladi, va protokol har bir ishtirokchi hammani eshitishiga tayanadi. Marshrutizatorlar bu trafikni sukut bo'yicha uzatmaydi, va bu xato emas, dizayn qarori. Chegara bir binodagi qurilma boshqasiga o'zini bemalol e'lon qila olmasligi uchun mavjud. Guruhni hamma joyga olib borib aniqlashni tuzatayotgandek ko'ringan tunnel bu chegarani yordam kerak bo'lgan ilovadan emas, balki barcha ilovalardan olib tashladi.

Takrorlagichlar va aks ettirgichlar mavjud, va ular haqiqiy natijalarga ega haqiqiy xizmatlardir: bitta saytda e'lon qilingan har bir nom boshqasida ko'rinadi, odamlarni yoki jihozlarni identifikatsiya qiluvchi qurilma nomlari ham. Agar haqiqiy talab ma'lum bir xizmatning topilishi bo'lsa, DNS da e'lon qilingan xizmat yozuvi odatda kichikroq o'zgarish, va u nomlar oqimi o'rniga bitta nomni oshkor qiladi.

Marshrutlangan multicastga kerak bo'ladigan uch narsa

Marshrutlangan multicast birgalikda ishlaydigan uch narsani talab qiladi: guruhga qo'shiladigan qabul qiluvchilar, u uchun uzatish holatini saqlaydigan marshrutizatorlar va guruh manzillarini tashilishi kerak bo'lgan trafik deb qaraydigan tunnel. Siyosatida faqat unicast quyi tarmoqlari sanab o'tilgan tunnel guruh trafigini shifrlash chegarasida tashlab yuboradi, shuning uchun birinchi alomat ko'pincha xato emas, sukunat bo'ladi. GRE yoki VTI tunneliga o'xshash marshrutga asoslangan interfeys marshrutlash jadvali yuborgan narsani tashiydi, bu multicast holati mavjud bo'lganda guruhni yetib boriladigan qiladi.

Manbaga yetib borish ikkinchi yarmi. PIM kabi multicast marshrutlash protokollari manbaga qaytish yo'li kutilgan yo'l ekanini tekshirib tarqatish daraxtlarini quradi, shuning uchun boshqa joyga ishora qiluvchi unicast marshrut guruh a'zoligi to'g'ri bo'lsa ham daraxtni buzadi. Qabul qiluvchi uchun marshrut o'rnatish bu tekshiruvga hech narsa qilmaydi, va bu ishlaydigan ping va muvaffaqiyatsiz oqimni keltiradigan xatodir. Avval manbaning qaytish yo'lini tekshiring, keyin a'zolikni qo'shing, va shundan keyingina ilovaga qarang.

ip maddr show dev tun0
ip mroute show
ss -gnu | grep 239.255.0.10
ip route get 10.20.5.20

Birinchi ikki satr host nimaga qo'shilganini va yadro nimani uzatishini ko'rsatadi, uchinchisi ilovaning o'z a'zoligini, oxirgisi esa teskari yo'l tekshiruvi ishlatadigan unicast yo'lni ko'rsatadi. Ularni birga o'qish hech qachon qo'shilmagan ilovani hech qachon uzatmagan tarmoqdan ajratadi.

Buni bitta manba va bitta qabul qiluvchi bilan isbotlang

Konfiguratsiyaga tegishdan oldin ilova bitta segmentda ishlashiga ishonch hosil qiling. Agar u mahalliy ravishda muvaffaqiyatsiz bo'lsa, multicast marshrutlash muammo emas va hech qanday tunnel o'zgarishi yordam bermaydi. Keyin tunnel bo'ylab bitta qabul qiluvchi bilan takrorlang va shifrlash chegarasining ikki tomonida paketlarni kuzating.

tcpdump -ni tun0 -c 10 'ip multicast'
tcpdump -ni eth0 -c 10 'ip multicast and host 239.255.0.10'

Tunnel ichida ko'rinadigan, lekin tashqarisida bo'lmagan paketlar inkapsulyatsiya yoki siyosatga ishora qiladi; ikki tomonda ko'rinadigan, lekin ilovada olg'a siljish bo'lmagan paketlar qabul qiluvchining a'zoligiga yoki ilovaning bog'lanishiga ishora qiladi. Yozuvlarni qisqa va filtrlangan holda saqlang, chunki band segmentdagi keng multicast yozuvi asosan shovqin.

Faqat xizmat kerak bo'lsa, xizmat manzilini tanlang

Aniqlash harakatlanadigan narsani topish uchun mavjud. Barqaror nomli serverga aniqlash kerak emas, va xususiy DNS da hujjatlashtirilgan manzil keng hudud havolasi orqali eshittirish domenini kengaytirmasdan foydalanuvchining haqiqiy savoliga javob beradi. Xuddi shu mulohaza printerlar, qurilmalar va ichki veb-xizmatlarga ham tegishli. DNS dagi nom unga muhtoj har bir saytdan yetib boriladigan, muhtoj bo'lmagan saytlarga hech narsa e'lon qilmaydi, va qurilma boshqa manzilli qurilma bilan almashtirilganda ham ishlashda davom etadi.

Protokol haqiqatan multicastni talab qilsa, uni guruh va unga muhtoj saytlar bilan cheklang, sababini hujjatlashtiring, va ilova o'zgarganda qarorni qayta ko'rib chiqing. Aniqlashni hamma joyga kengaytirish bir marta oson, va unga jimgina tayanadigan qurilmalar bir yil o'tgach uni qaytarib olish qiyin.