Multicast niyə plan olmadan VPN-dən keçmir

İki sahə unicast ilə bir-birinə mükəmməl çata bilər və yenə də sanki biri printerin kəşf bildirişini, IPTV yayımını və ya klasterin ürək döyüntüsünü görmür kimi davrana bilər. Bu pozulmuş tunel deyil; bu, təyinat ilə qrup arasındakı fərqdir. Multicast çatdırılması üzvlük modeli, yol boyunca yönləndirmə vəziyyəti və trafiki daşımağa hazır interfeys tələb edir və bunların heç biri unicast marşrutundan gəlmir. Tətbiqin qrupundan işləyən bir qəbulediciyə qədər getmək cavaba ən qısa yoldur.

Qrupdan və tətbiqdən başlayın

Tətbiqin hansı qrup ünvanından istifadə etdiyini və trafikin nə üçün olduğunu soruşun. Xidmətləri elan edən kəşf protokolu, yayım axını və marşrutlaşdırma protokolunun salam paketləri üç fərqli problem və üç fərqli məqbul cavabdır. Qrup ünvanı özü əhatəni deyir: yerli şəbəkə nəzarət blokundakı ünvanlar adi marşrutlaşdırma ilə linkdən kənara yönləndirilmək üçün deyil və onlardan istifadə edən tətbiqlər adətən tək yayım domenini fərz edir. Qlobal əhatəli qrupda yayım axını hər cihazın hər sorğunu eşitməsini gözləyən kəşf protokolundan fərqli bir dizayndır və yalnız ikincisi yayım domeninin ölçüsü ilə maraqlanır.

Tələbin xidmət, yoxsa kəşf mexanizmi olduğuna qərar verin, çünki bu cavablar maya dəyəri baxımından bir tərtib fərqlənir. Biri dəyişməyən ünvan istəyir; digəri isə geniş ərazil şəbəkə linki boyunca uzadılmış yayım domeni istəyir və ondan irəli gələn hər şeyi də.

Link-local kəşf dayanmaq üçün nəzərdə tutulub

RFC 6762 sənədində təsvir olunan Multicast DNS tək link ətrafında dizayn edilib: sorğular sabit qrupa gedir, cavablar eyni qrupa göndərilir və protokol hər iştirakçının hamını eşitməsinə güvənir. Marşrutlaşdırıcılar bu trafiki standart olaraq yönləndirmir və bu, səhv deyil, dizayn qərarıdır. Sərhəd ona görə mövcuddur ki, bir binadakı cihaz özünü rahatlıqla digərinə elan edə bilməsin. Qrupu hər yerə daşımaqla kəşfi guya düzəldən tunel bu sərhədi köməyə ehtiyacı olan tətbiqə deyil, bütün tətbiqlərə görə aradan qaldırıb.

Təkrarlayıcılar və əks etdiricilər var və bunlar real nəticələri olan real xidmətlərdir: bir sahədə elan edilən hər ad digərində görünür, o cümlədən insanları və ya avadanlığı müəyyən edən cihaz adları. Əgər əsl tələb konkret xidmətin tapıla bilməsidirsə, DNS-də dərc edilən xidmət qeydi adətən daha kiçik dəyişiklikdir və bir adı açır, adlar axınını deyil.

Yönləndirilən multicastın üç ehtiyacı

Yönləndirilən multicast üç şeyin birlikdə işləməsini tələb edir: qrupa qoşulan qəbuledicilər, onun üçün yönləndirmə vəziyyətini saxlayan marşrutlaşdırıcılar və qrup ünvanlarını daşınacaq trafik kimi qəbul edən tunel. Siyasətində yalnız unicast alt şəbəkələri sadalayan tunel qrup trafikini şifrələmə sərhədində atacaq və buna görə ilk simptom çox vaxt xəta deyil, sükut olur. GRE və ya VTI tuneli kimi marşruta əsaslanan interfeys marşrut cədvəlinin ona göndərdiyini daşıyır və multicast vəziyyəti yaranan kimi qrupu əlçatan edir.

Mənbəyə əlçatanlıq ikinci yarıdır. PIM kimi multicast marşrutlaşdırma protokolları paylama ağaclarını mənbəyə geri yolun gözlənilən yol olduğunu yoxlamaqla qurur, ona görə başqa yerə yönələn unicast marşrutu qrup üzvlüyü düzgün olsa da ağacı pozur. Qəbuledici üçün marşrut qurmaq bu yoxlamaya heç nə etmir və işləyən ping ilə uğursuz yayımı yaradan səhv elə budur. Əvvəlcə mənbənin qayıdış yolunu yoxlayın, sonra üzvlüyü əlavə edin və yalnız ondan sonra tətbiqə baxın.

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

İlk iki sətir hostun nəyə qoşulduğunu və kernelin nəyi yönləndirdiyini, üçüncü sətir tətbiqin öz üzvlüyünü, sonuncu isə əks yol yoxlamasının istifadə edəcəyi unicast yolunu göstərir. Onları birlikdə oxumaq heç vaxt qoşulmayan tətbiqi heç vaxt yönləndirməyən şəbəkədən ayırır.

Bir mənbə və bir qəbuledici ilə sübut edin

Konfiqurasiyaya toxunmazdan əvvəl tətbiqin bir seqmentdə işlədiyini təsdiqləyin. Yerli olaraq uğursuz olursa, problem multicast marşrutlaşdırması deyil və heç bir tunel dəyişikliyi kömək etməyəcək. Sonra tunel boyunca bir qəbuledici ilə təkrarlayın və şifrələmə sərhədinin hər iki tərəfində paketlərə baxın.

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

Tunelin içində görünən, lakin xaricində olmayan paketlər inkapsulyasiyaya və ya siyasətə işarə edir; hər iki tərəfdə görünən, amma tətbiqdə irəliləyiş olmayan paketlər qəbuledicinin üzvlüyünə və ya tətbiqin bağlanmasına işarə edir. Çəkilişləri qısa və filtrlənmiş saxlayın, çünki məşğul seqmentdə geniş multicast çəkilişi əsasən küydür.

Yalnız xidmət lazımdırsa, xidmət ünvanını seçin

Kəşf hərəkət edən bir şeyi tapmaq üçün mövcuddur. Sabit adı olan serverə kəşf lazım deyil və özəl DNS-də sənədləşdirilmiş ünvan istifadəçinin əsl sualına cavab verir, yayım domenini geniş ərazil şəbəkə linki boyunca uzatmadan. Eyni məntiq printerlərə, cihazlara və daxili veb xidmətlərinə də aiddir. DNS-dəki ada ehtiyacı olan hər sahədən çatmaq olar, ehtiyacı olmayan sahələrə isə heç nə elan edilmir və cihaz fərqli ünvanlı biri ilə dəyişdirildikdə də işləməyə davam edir.

Protokol həqiqətən multicast tələb edəndə onu qrupla və ehtiyacı olan sahələrlə məhdudlaşdırın, səbəbini sənədləşdirin və tətbiq dəyişəndə qərarı yenidən nəzərdən keçirin. Kəşfi hər yerə yaymaq bir dəfə asandır və bir il boyunca ona səssizcə güvənən cihazlardan sonra geri qaytarmaq çətindir.