OpenVPN ustida SSM: bitta manba va guruhni boshdan oxirigacha kuzatish

Bitta oqim va bitta qabul qiluvchini tanlang, so’ngra multicast ni toifa sifatida sinash o’rniga o’sha juftlikni har bir hop bo’ylab kuzatib boring. Manbaga xos dizayn to’rt joydan aynan bittasida muvaffaqiyatsiz bo’ladi: qabul qiluvchi hech qachon qo’shilmadi, marshrutizator paketni qaytish yo’lida rad etdi, yadroda holat yo’q, yoki tunnel hech qachon nusxa yetkazmadi. Shu tartibda ishlash har bir hop uchun bir necha daqiqa oladi va to’rttadan qaysi biri sizda borligini aytadi.

Avval manba, guruh va qabul qiluvchini belgilang

Istalgan qurilmaga tegishdan oldin uchta qiymatni yozib qo’ying: yuboruvchi manba manzili, qabul qiluvchi qo’shiladigan guruh manzili va qabul qiluvchi joylashgan quyi tarmoq. Misol IPv4 oqimi uchun 10.50.0.10 manbasi va 232.20.30.40 guruhi manbaga xos dizaynga mos keladigan juftlik turidir. Bu uch qiymatdan noaniqroq narsani sinab bo’lmaydi.

232/8 diapazoni manbaga xos multicast uchun ajratilgan va model RFC 4607 hujjatida tavsiflangan. Agar siz SSM ishlatyapman deb o’ylayotganingizda guruhingiz shu diapazondan tashqarida bo’lsa, to’xtang va joylashtirish aslida nimani nazarda tutayotganini tasdiqlang, chunki qabul qiluvchining qo’shilishi ham, marshrutizatorning uzatish qarori ham modelning izchilligiga bog’liq.

Qabul qiluvchi manbaga qo’shilganini tekshiring

Faqat guruh uchun a’zolik hisoboti manbaga xos qo’shilish emas. Qabul qiluvchidan qaysi manbani so’raganini so’rang va birinchi hop marshrutizatorida guruh holatini ko’rib, manbalar ro’yxati paydo bo’ladimi-yo’qmi aniqlang. Agar hisobotda manba bo’lmasa, marshrutizator uni har qanday manbadan qo’shilish deb qabul qiladi va butun dizayn siz rejalashtirmagan narsaga jimgina aylanadi.

Linux qabul qiluvchisida soket aslida nimaga obuna bo’lganini va yadro nima yozib olganini tekshiring. Ilovaning konfiguratsiya fayli dalil emas; a’zolik jadvali dalildir. Uni qabul qiluvchi haqiqatan ishlab turganda o’qing, chunki uni yaratgan jarayon chiqqandan keyin ham yozuv biroz qolishi mumkin. Avvalgi sinovdan qolgan eski yozuv yolg’on ishonchning ishonchli manbasidir.

ip maddr show dev eth0
cat /proc/net/igmp | sed -n '1,40p'

Agar kutilgan manba bilan qo’shilish mavjud bo’lsa, marshrutizatorlarga o’ting. Bo’lmasa, hech qanday tunnel konfiguratsiyasi yordam bermaydi, chunki uzatadigan narsa yo’q.

Tunnelga qarashdan oldin qaytish yo’lini tekshiring

Multicast marshrutlash qaytish yo’lini tekshiradi va unicast marshruti ko’rsatgan interfeysdan boshqa interfeysga kelgan paket tashlab yuboriladi. Bu aniq yuborilayotgan oqimning keyingi hopga hech qachon yetmasligining eng keng tarqalgan sababi va u ilova darajasida hech qanday foydali xato chiqarmaydi.

Manbaga qaragan marshrutizatorda manbaga ketuvchi marshrutni paketlar haqiqatan keladigan interfeys bilan solishtiring. Qabul qiluvchiga qaragan marshrutizatorda qabul qiluvchining o’z quyi tarmog’i uchun ham shunday qiling va chiquvchi interfeyslar ro’yxatiga u tomonga ketuvchi ulanish kirganini tasdiqlang. Har qanday yo’nalishdagi nomuvofiqlik RPF nosozligi, a’zolik nosozligi emas.

So’ngra manbaning TTL qiymati siz loyihalagan marshrutlangan hoplardan o’tish uchun yetarlicha katta ekanini tasdiqlang. Birinchi marshrutizatorda ishlab, ikkinchisida o’ladigan oqim ko’pincha TTL masalasi, siyosat masalasi emas.

Konfiguratsiya o’rniga yadroning multicast holatini o’qing

Konfiguratsiya nima so’raganingizni aytadi; yadro nima bo’layotganini aytadi. Har bir Linux hopida multicast marshrutlash yozuvlarini o’qing va manba hamda guruhning aniq juftligi uchun kiruvchi va chiquvchi interfeyslar ro’yxati borligini tasdiqlang. Guruh uchun umumiy manbaga ega yozuv boshqa obyekt va u manbaga xos oqimni tushuntirmaydi.

ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10

Marshrutlash demonlari bu holat ustida o’z qarashlarini saqlaydi va uni chop etuvchi buyruq qaysi tatbiq o’rnatilganiga bog’liq. Tamoyil doimiy: demondan juftlik uchun uning yuqori oqim yozuvini so’rang, so’ngra yadrodan uzatish yozuvi bor-yo’qligini so’rang. Yadroda yozuv bo’lmaganda o’zini uzatyapti deb hisoblaydigan demon o’sha xostdagi konfiguratsiya doirasining muammosi.

Ikkalasi kelishmasa, VPN ni emas, xostni tuzating. Siz so’ragan oqimni uzatmaydigan hopni quyida hech narsa qoplay olmaydi. Oqim ishlab turganda har bir hop uchun juftlikni, kiruvchi interfeysni va chiquvchi ro’yxatni yozib boring. Bu yozuv keyingi nosozlikni yangi tekshiruv emas, taqqoslashga aylantiradi.

Tunnel aslida qanday nusxalashini hal qiling

Aynan shu yerda VPN ustidagi multicast odatiy ish bo’lishdan to’xtaydi. Nuqta-nuqtaga tunnel paketni narigi tomondagi yagona tengdoshga yetkazadi, shuning uchun nusxa aynan bitta mijozga yetadi. Ko’prik bilan bog’langan segment umumiy ulanish kabi ko’proq tutadi, chunki tunnel kadrni tashiydi va ko’prik nima toshirilishini hal qiladi. Bular turli yetkazib berish modellari va birinchisini ishlatib, ikkinchisini faraz qilgan dizayn bitta qabul qiluvchi uchun ishlaydigandek ko’rinib, keyingisida muvaffaqiyatsiz bo’ladi.

Ko’p nuqtali server orqali birdan ortiq qabul qiluvchi uchun nusxalash aniq loyihalanishi kerak. Shlyuzga multicast marshrutini o’rnatish VPN serveriga qaysi tengdoshlar nusxa olishi kerakligini o’rgatmaydi va mijoz tomonidagi hech qanday marshrut bu qarorni uning o’rniga qabul qilmaydi. Talab ko’p qabul qiluvchi bo’lganda qo’llab-quvvatlanadigan nusxalash yoki ataylab tanlangan alternativadan foydalaning va qaysi birini tanlaganingizni yozing.

Nihoyat, qabul qiluvchida tor kuzatuv ostida tekshiring: aniq manba, guruh va port, siz kutgan interfeysda, bitta vakolatli qabul qiluvchi qo’shilgan holda. SSM yuboruvchini tanlaydi va tanlov o’sha yuboruvchining autentifikatsiyasi emas, boshqa multicast trafigining ham xuddi shu siyosatdan o’tishiga ruxsat ham emas.