Защо мултикастът не преминава през VPN без план

Два обекта могат да се достигат перфектно чрез юникаст и въпреки това да се държат така, сякаш единият не вижда обявяването за откриване на принтера, IPTV потока или сърдечния сигнал на клъстера. Това не е счупен тунел; това е разликата между дестинация и група. Доставката на мултикаст изисква модел на членство, състояние на препращане по пътя и интерфейс, готов да носи трафика, и нищо от това не идва от юникаст маршрут. Преминаването от групата на приложението до един работещ получател е най-краткият път до отговор.

Започнете с групата и приложението

Попитайте кой адрес на група използва приложението и за какво е трафикът. Протокол за откриване, който обявява услуги, поток за стрийминг и пакетите за поздрав на протокол за маршрутизация са три различни проблема с три различни приемливи отговора. Самият адрес на групата ви казва обхвата: адресите в блока за управление на локалната мрежа не са предназначени да се препращат извън връзката чрез обикновена маршрутизация, а приложенията, които ги използват, обикновено предполагат един домейн на излъчване. Поток върху група с глобален обхват е различен дизайн от протокол за откриване, който очаква всяко устройство да чуе всяка заявка, и само второто се интересува от размера на домейна на излъчване.

Решете дали изискването е услугата или механизмът за откриване, защото тези отговори се различават по цена с порядък. Едното иска адрес, който не се променя; другото иска домейн на излъчване, разширен през връзка от глобална мрежа с всичко, което следва от това.

Откриването в локалната мрежа трябва да спира

Multicast DNS, описан в RFC 6762, е проектиран около една връзка: заявките отиват към фиксирана група, отговорите се изпращат към същата група и протоколът разчита всеки участник да чува всички. Маршрутизаторите не препращат този трафик по подразбиране и това е решение за дизайна, а не пропуск. Границата съществува, за да не може устройство в една сграда просто да се обяви в друга. Тунел, който сякаш поправя откриването, като носи групата навсякъде, е премахнал тази граница за всяко приложение, не само за това, което се нуждаеше от помощ.

Ретранслатори и отражатели съществуват и са реални услуги с реални последствия: всяко име, обявено на един обект, става видимо на другия, включително имена на устройства, които идентифицират хора или оборудване. Ако действителното изискване е конкретна услуга да бъде откриваема, запис за услуга, публикуван в DNS, обикновено е по-малката промяна и разкрива едно име вместо поток от имена.

Три неща, които маршрутизираният мултикаст изисква

Маршрутизираният мултикаст изисква три неща да работят заедно: получатели, които се присъединяват към групата, маршрутизатори, които поддържат състояние на препращане за нея, и тунел, който третира адресите на групата като трафик за пренасяне. Тунел с политика, която изброява само юникаст подмрежи, ще изхвърли трафика на групата на границата на криптиране и затова първият симптом често е тишина, а не грешка. Интерфейс, базиран на маршрути, като тунел GRE или VTI, носи каквото таблицата за маршрутизация изпрати в него, което прави групата достижима, след като състоянието на мултикаст съществува.

Достижимостта на източника е втората половина. Протоколи за маршрутизация на мултикаст като PIM изграждат дървета за разпространение, като проверяват дали пътят обратно към източника е очакваният, така че юникаст маршрут, който сочи другаде, чупи дървото дори когато членството в групата е правилно. Инсталирането на маршрут за получателя не прави нищо за тази проверка и това е грешката, която дава работещ ping и провалящ се поток. Проверете първо обратния път на източника, после добавете членство и едва след това погледнете приложението.

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

Първите два реда показват към какво се е присъединил хостът и какво препраща ядрото, третият показва собственото членство на приложението, а последният — юникаст пътя, който ще използва проверката на обратния път. Четенето им заедно различава приложение, което никога не се е присъединило, от мрежа, която никога не е препращала.

Докажете го с един източник и един получател

Преди да пипате конфигурация, потвърдете, че приложението работи в един сегмент. Ако се проваля локално, проблемът не е в маршрутизацията на мултикаст и никаква промяна на тунела няма да помогне. След това повторете с един получател през тунела и наблюдавайте пакетите от двете страни на границата на криптиране.

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

Пакети, видими вътре в тунела, но липсващи извън него, сочат към инкапсулация или политика; пакети, видими от двете страни без напредък в приложението, сочат към членството на получателя или обвързването на приложението. Пазете записите кратки и филтрирани, защото широк запис на мултикаст в натоварен сегмент е предимно шум.

Предпочитайте адрес на услуга, когато ви трябва само услугата

Откриването съществува, за да намери нещо, което се движи. Сървър със стабилно име не се нуждае от откриване, а документиран адрес в частен DNS отговаря на истинския въпрос на потребителя, без да разширява домейн на излъчване през връзка от глобална мрежа. Същото важи за принтери, уреди и вътрешни уеб услуги. Име в DNS е достижимо от всеки обект, който се нуждае от него, без да обявява нищо на обектите, които не се нуждаят, и продължава да работи, когато устройството бъде заменено с такова с друг адрес.

Когато протокол наистина изисква мултикаст, ограничете го до групата и обектите, които се нуждаят от него, документирайте защо и преразгледайте решението, когато приложението се промени. Разширяването на откриването навсякъде е лесно веднъж и трудно за отменяне след година устройства, които тихо разчитат на него.