SSM və OpenVPN: bir mənbəyi və qrupu başdan-başa izləmək

Bir axın və bir qəbuledici seçin, sonra multicastı kateqoriya kimi sınamaq əvəzinə həmin cütü hər hopdan keçirərək izləyin. Mənbəyə xas dizayn dörd yerdən tam birində uğursuz olur: qəbuledici heç vaxt qoşulmayıb, marşrutlaşdırıcı paketi əks yolda rədd edib, nüvədə vəziyyət yoxdur və ya tunel heç bir nüsxə çatdırmayıb. Bu sıra ilə işləmək hər hop üçün bir neçə dəqiqə çəkir və dördündən hansına sahib olduğunuzu söyləyir.

Əvvəlcə mənbəyi, qrupu və qəbuledicini təsbit edin

Hər hansı cihaza toxunmadan əvvəl üç dəyər yazın: göndərəcək mənbə ünvanı, qəbuledicinin qoşulacağı qrup ünvanı və qəbuledicinin yerləşdiyi alt şəbəkə. Nümunə üçün IPv4 axınında 10.50.0.10 mənbəyi və 232.20.30.40 qrupu mənbəyə xas dizayna uyğun cüt növüdür. Bu üç dəyərdən daha qeyri-müəyyən olan heç nə sınana bilməz.

232/8 diapazonu mənbəyə xas multicast üçün ayrılıb və model RFC 4607 sənədində təsvir olunur. Əgər qrupunuz SSM işlətdiyinizi düşündüyünüz halda bu diapazondan kənardadırsa, dayanın və yerləşdirmənin həqiqətən nə nəzərdə tutduğunu təsdiqləyin, çünki qəbuledicinin qoşulması və marşrutlaşdırıcının ötürmə qərarı hər ikisi modelin uyğunluğundan asılıdır.

Qəbuledicinin mənbəyə qoşulduğunu yoxlayın

Yalnız qrup üçün üzvlük hesabatı mənbəyə xas qoşulma deyil. Qəbuledicidən hansı mənbəyi tələb etdiyini soruşun və ilk hop marşrutlaşdırıcısında qrup vəziyyətinə baxaraq mənbə siyahısının görünüb-görünmədiyini yoxlayın. Əgər hesabat heç bir mənbə daşımırsa, marşrutlaşdırıcı onu istənilən mənbədən qoşulma kimi qəbul edəcək və bütün dizayn səssizcə planlamadığınız bir şeyə çevriləcək.

Linux qəbuledicisində soketin həqiqətən nəyə abunə olduğunu və nüvənin nə qeyd etdiyini yoxlayın. Tətbiqin konfiqurasiya faylı sübut deyil; üzvlük cədvəli sübutdur. Onu qəbuledici həqiqətən işləyərkən oxuyun, çünki onu yaradan proses bitdikdən sonra giriş bir müddət qala bilər. Əvvəlki sınaqdan qalmış köhnə giriş yalançı əminliyin etibarlı mənbəyidir.

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

Əgər qoşulma gözlənilən mənbə ilə varsa, marşrutlaşdırıcılara keçin. Yoxdursa, heç bir tunel konfiqurasiyası kömək etməyəcək, çünki ötürüləcək heç nə yoxdur.

Tunelə baxmazdan əvvəl əks yolu yoxlayın

Multicast marşrutlaşdırması əks yol yoxlaması aparır və unicast marşrutunun göstərdiyi interfeysdən başqa interfeysdə gələn paket atılır. Bu, açıq şəkildə göndərilən axının növbəti hopa heç vaxt çatmamasının ən geniş yayılmış səbəbidir və heç bir faydalı tətbiq səviyyəli xəta yaratmır.

Mənbəyə baxan marşrutlaşdırıcıda mənbəyə doğru marşrutu paketlərin həqiqətən gəldiyi interfeyslə müqayisə edin. Qəbulediciyə baxan marşrutlaşdırıcıda qəbuledicinin öz alt şəbəkəsi üçün eyni şeyi edin və çıxan interfeys siyahısının ona doğru keçidi ehtiva etdiyini təsdiqləyin. Hər iki istiqamətdə uyğunsuzluq RPF nasazlığıdır, üzvlük nasazlığı deyil.

Sonra mənbənin TTL dəyərinin layihələndirdiyiniz marşrutlaşdırılmış hoplardan keçmək üçün kifayət qədər böyük olduğunu təsdiqləyin. Birinci marşrutlaşdırıcıda işləyib ikincidə ölən axın çox vaxt siyasət deyil, TTL məsələsidir.

Konfiqurasiya əvəzinə nüvənin multicast vəziyyətini oxuyun

Konfiqurasiya sizə nə istədiyinizi deyir; nüvə isə nə baş verdiyini deyir. Hər Linux hopunda multicast marşrutlaşdırma girişlərini oxuyun və dəqiq mənbə-qrup cütü üçün gələn və çıxan interfeys siyahısının mövcud olduğunu təsdiqləyin. Qrup üçün vəhşi kart mənbəli giriş başqa obyektdir və mənbəyə xas axını izah etməyəcək.

ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10

Marşrutlaşdırma demonları həmin vəziyyətin üstündə öz baxışlarını saxlayır və onu çap edən əmr hansı tətbiqin quraşdırıldığından asılıdır. Prinsip sabitdir: demondan cüt üçün yuxarı axın girişini soruşun, sonra nüvədən yönləndirmə girişinin olub-olmadığını soruşun. Nüvədə giriş yoxkən özünü yönləndirir hesab edən demon həmin hostda konfiqurasiya əhatəsi problemidir.

İkisi ziddiyyət təşkil etdikdə VPN-i deyil, hostu düzəldin. Aşağı axında heç nə soruşduğunuz axını ötürməyən hopu kompensasiya edə bilməz. Axın işləyərkən hər hop üçün cütü, gələn interfeysi və çıxan siyahını qeyd edin. Bu qeyd növbəti nasazlığı yeni araşdırma yerinə müqayisəyə çevirir.

Tunelin həqiqətən necə təkrarladığına qərar verin

Multicastın VPN üzərindən işləməsi burada adi iş olmaqdan çıxır. Nöqtədən-nöqtəyə tunel paketi digər tərəfdəki tək həmə çatdırır, yəni nüsxə tam olaraq bir müştəriyə çatır. Körpülənmiş seqment daha çox paylaşılan keçid kimi davranır, çünki tunel kadrı daşıyır və körpü nəyin daşacağına qərar verir. Bunlar fərqli çatdırılma modelləridir və birincini işlədərkən ikincini fərz edən dizayn bir qəbuledici üçün işləyəcək, növbəti üçün uğursuz olacaq.

Çoxnöqtəli server üzərindən birdən çox qəbuledici üçün təkrarlama açıq şəkildə layihələndirilməlidir. Şlüzə multicast marşrutu quraşdırmaq VPN serverinə hansı həmlərin nüsxə almalı olduğunu öyrətmir və heç bir müştəri tərəfli marşrut bu qərarı onun yerinə vermir. Tələb çox qəbuledici olduqda dəstəklənən təkrarlamadan və ya qəsdən seçilmiş alternativdən istifadə edin və hansını seçdiyinizi yazın.

Nəhayət, qəbuledicidə dar müşahidə ilə yoxlayın: dəqiq mənbə, qrup və port, gözlədiyiniz interfeysdə, bir səlahiyyətli qəbuledici qoşulmuş halda. SSM göndərəni seçir və seçim həmin göndərənin autentifikasiyası deyil, digər multicast trafikinin eyni siyasətdən keçməsinə icazə də deyil.