Зашто мултикаст не прелази преко VPN-а без плана

Доступност је питање јуникаста. Прођите кроз групу, њен опсег, стање прослеђивања и једну путању од једног извора до једног примаоца пре него што додате мост или релеј.

Две локације могу савршено да се достигну преко јуникаста и ипак да се понашају као да једна од њих не види најаву откривања штампача, IPTV ток или откуцај срца кластера. Ово није покварен тунел; ово је разлика између одредишта и групе. Испорука мултикаста захтева модел чланства, стање прослеђивања дуж путање и интерфејс спреман да носи саобраћај, и ништа од тога не долази из јуникаст руте. Ходање од групе апликације до једног примаоца који ради је најкраћи пут до одговора.

Почните са групом и апликацијом

Питајте коју адресу групе апликација користи и чему саобраћај служи. Протокол откривања који објављује услуге, ток за стримовање и поздрави пакети протокола рутирања су три различита проблема са три различита прихватљива одговора. Сама адреса групе говори опсег: адресе у блоку контроле локалне мреже нису намењене да их обично рутирање прослеђује ван везе, а апликације које их користе обично претпостављају један домен емитовања. Ток за стримовање на групи глобалног опсега је другачији дизајн од протокола откривања који очекује да сваки уређај чује сваки упит, и само други мари за величину домена емитовања.

Одлучите да ли је захтев услуга или механизам откривања, јер се ти одговори разликују у цени за један ред величине. Један тражи адресу која се не мења; други тражи домен емитовања проширен преко везе широке мреже са свим што из тога следи.

Локално откривање треба да се заустави

Multicast DNS описан у RFC 6762 је дизајниран око једне везе: упити иду ка фиксној групи, одговори се шаљу истој групи, и протокол се ослања на то да сваки учесник чује све. Рутери не прослеђују тај саобраћај подразумевано, и то је дизајнерска одлука, а не пропуст. Граница постоји да уређај у једној згради не би могао тек тако да се објави у другој. Тунел који наизглед поправља откривање носећи групу свуда уклонио је ту границу за сваку апликацију, не само за ону којој је била потребна помоћ.

Понављачи и рефлектори постоје, и то су праве услуге са правим последицама: свако име објављено на једној локацији постаје видљиво на другој, укључујући имена уређаја која идентификују људе или опрему. Ако је прави захтев да одређена услуга буде пронађена, запис о услузи објављен у DNS-у је обично мања промена, и открива једно име уместо тока њих.

Три ствари које су потребне рутираном мултикасту

Рутирани мултикаст захтева три ствари које раде заједно: примаоце који се придружују групи, рутере који одржавају стање прослеђивања за њу и тунел који адресе групе третира као саобраћај који треба носити. Тунел са политиком која наводи само јуникаст подмреже одбациће саобраћај групе на граници шифровања, и зато је први симптом често тишина, а не грешка. Интерфејс заснован на рутама, као GRE или VTI тунел, носи оно што табела рутирања пошаље у њега, што чини групу доступном када стање мултикаста постоји.

Доступност извора је друга половина. Протоколи рутирања мултикаста као PIM граде стабла дистрибуције проверавајући да је пут назад до извора очекивани, па јуникаст рута која показује негде другде крши стабло и када је чланство у групи исправно. Инсталирање руте за примаоца не чини ништа за ту проверу, и то је грешка која даје пинг који ради и ток који не успева. Прво проверите повратни пут извора, затим додајте чланство и тек онда погледајте апликацију.

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-у је доступно са сваке локације којој је потребно док ништа не објављује локацијама којима није потребно, и наставља да ради када уређај буде замењен другим са другачијом адресом.

Када протокол заиста захтева мултикаст, ограничите га на групу и локације којима је потребан, документујте зашто и преиспитајте одлуку када се апликација промени. Ширење откривања свуда је лако једном, и тешко се повлачи после годину дана уређаја који тихо зависе од њега.

Повезани чланци