Chromecast və DLNA kəşfi marşrutlaşdırılmış VPN-dən heç vaxt keçmir

Yayım düyməsi heç nə göstərmir, VLC DLNA boş qalır və qarşı tərəfdəki maşın ping-ə şikayətsiz cavab verir. Bu birləşmə nə bufer problemi, nə də firewall sirridir. Bu protokollarda kəşf yerli seqmentdə qrup mübadiləsidir və marşrutlaşdırılmış tunel qrup ünvanlı trafiki daşımır. Başlamaq istədiyiniz sessiya heç vaxt təklif olunmur.

Əlçatanlıq qaydasındadır. Kəşf yoxdur.

Mif: tunelə parametr və ya daha çox tutum lazımdır

Adi təkliflər peer-to-peer trafiki aktivləşdirmək, MTU-nu artırmaq və ya tunel cihazının növünü dəyişməkdir. Heç biri yayım domeni əlavə etmir. Multicast kommutatorlar və yerli şəbəkə yığını tərəfindən çatdırılır, nöqtədən-nöqtəyə TUN interfeysinin isə su basacaq qrup ünvanı yoxdur.

Parametrləri dəyişmək nasazlığı daha ucadan edə bilər. Protokolun heç vaxt göndərmədiyi elanı görünən edə bilməz.

Kəşf mübadiləsi əslində nədir

Üç nümunə rastlaşacağınız demək olar ki, hər şeyi əhatə edir. mDNS 224.0.0.251 ünvanına UDP 5353 üzərindən göndərir, SSDP 239.255.255.250 ünvanına UDP 1900 üzərindən göndərir, köhnə SMB baxış siyahıları isə alt şəbəkənin yayım ünvanına gedirdi. Hər biri hosta deyil, qrupa ünvanlanır və hər biri eyni seqmentdə dinləyici gözləyir. Marşrutlaşdırılmış tunelin arxasındakı qəbuledici o seqmentdə deyil, ona görə heç nə çatmır.

Hətta ötürülən elan da yük daşıyır: adətən göndərənin LAN ünvanı və portu, uzaq izləyici isə sonra həmin ünvana çata bilməlidir.

Tuneli dəyişməzdən əvvəl tutma oxuyun

Tətbiq skan edərkən tunel interfeysində tutma aparın. Boş tutma elanın sərhədi heç vaxt keçmədiyini bildirir və tunelin heç bir tənzimlənməsi bunu dəyişmir. Tətbiq hələ də heç nə göstərməz ikən görünən paketlər adətən elan olunan ünvanın izləyici üçün əlçatmaz olduğunu bildirir — bu, kəşf libasında gəzən marşrutlaşdırma problemidir.

İki dəqiqəlik tutma portlar barədə bir saatlıq təxminləri əvəz edir: tcpdump -ni tun0 udp port 5353 or udp port 1900.

Üç həll, ən ucuzu birinci

Müştərini birbaşa xidmət ünvanına yönəldin. DLNA, SMB və adi media serverləri üçün bu, kəşfi tamamilə atlayır və yük yolunun işlədiyini sübut edir, bu da onu həm ən yaxşı ilk sınaq, həm də işlək müvəqqəti həll edir. Chromecast istisnadır, çünki qəbuledici ünvanlanmağı deyil, tapılmağı gözləyir.

Protokolu şlüzda ötürün. mDNS reflektor elanları tunel ilə LAN arasında təkrarlayır və Avahi açıq interfeys siyahısı alan reflektor bölməsi ilə gəlir. Ötürməni dar saxlayın və elan olunan ünvanın hər iki tərəfdən əlçatan olduğunu təsdiqləyin, əks halda cavab hələ də izləyicinin marşrutlaşa bilmədiyi alt şəbəkəyə işarə edir.

Marşrutlaşdırma əvəzinə körpü qurun. Serverin tap cihazını LAN-a körpülədiyi TAP seqmenti hər iki tərəfi bir yayım domeninə qoyur, beləliklə elanlar dəyişmədən keçir. Bu həm də ən bahalı seçimdir, çünki bir alt şəbəkə bir nasazlıq domeni deməkdir və LAN-dakı hər multicast xidməti artıq hər peer-ə çatır.

Nə kömək etmir, nə qədər tez-tez təklif olunsa da

Körpü olmadan dev tun parametrini dev tap ilə əvəz etmək hələ də marşrutlaşdırılan TAP cihazı qoyur, ona görə davranış dəyişmir. client-to-client peer-to-peer unicast icazə verir və yayımları su basmır. Kəşf portunu bir hosta yönləndirmək qrup ünvanlı trafiki çatdırmır. Bir ünvana bağlanmış media server öz konfiqurasiyası VPN interfeysini sadalayana qədər həmin ünvanda cavab verməyə davam edir.

Əvvəl bir birbaşa unicast sorğusu, sonra bir elan olunmuş sorğu sınayın. Birincisi işləyib ikincisi işləmirsə, tunel sağlamdır və bütün problem kəşfdir.