Неге мультикаст жоспарсыз VPN арқылы өтпейді

Қолжетімділік — юникаст мәселесі. Көпір немесе реле қоспас бұрын топты, оның ауқымын, жіберу күйін және бір көзден бір қабылдағышқа дейінгі бір жолды қарап шығыңыз.

Екі сайт юникаст арқылы бір-біріне мінсіз жете алады және солай бола тұра, біреуі принтердің табу хабарламасын, IPTV ағынын немесе кластердің жүрек соғысын көрмейтіндей әрекет етеді. Бұл сынған туннель емес; бұл межелі жер мен топ арасындағы айырмашылық. Мультикаст жеткізу үшін мүшелік моделі, жол бойы жіберу күйі және трафикті тасымалдауға дайын интерфейс қажет, және олардың ешқайсысы юникаст маршрутынан келмейді. Қолданба тобынан бір жұмыс істейтін қабылдағышқа дейін жүру — жауапқа ең қысқа жол.

Топтан және қолданбадан бастаңыз

Қолданба қай топ мекенжайын пайдаланады және трафик не үшін екенін сұраңыз. Қызметтерді жариялайтын табу протоколы, ағындық ағын және маршруттау протоколының сәлем пакеттері — үш түрлі мәселе және үш түрлі қолайлы жауап. Топ мекенжайының өзі ауқымды айтады: жергілікті желінің басқару блогындағы мекенжайлар қарапайым маршруттаумен байланыстан тыс жіберуге арналмаған, ал оларды пайдаланатын қолданбалар әдетте бір трансляциялық доменді болжайды. Жаһандық ауқымдағы топтағы ағындық ағын — әр құрылғы әр сұранысты естиді деп күтетін табу протоколынан өзгеше дизайн, және тек екіншісі ғана трансляциялық доменнің өлшемін ойлайды.

Талап қызмет пе әлде табу механизмі ме екенін шешіңіз, өйткені бұл жауаптар құны бойынша бір ретке ерекшеленеді. Біреуі өзгермейтін мекенжай сұрайды; екіншісі кең аумақты байланыс арқылы кеңейтілген трансляциялық домен-ды және одан туындайтынның бәрін сұрайды.

Жергілікті табу тоқтауы тиіс

RFC 6762-де сипатталған Multicast DNS бір байланыс айналасында жасалған: сұраныстар тұрақты топқа кетеді, жауаптар сол топқа жіберіледі, және протокол әр қатысушының барлығын еститініне сүйенеді. Маршрутизаторлар бұл трафикті әдепкі бойынша жібермейді, және бұл қателік емес, дизайн шешімі. Шекара бір ғимараттағы құрылғының екіншісіне оңай жариялана алмауы үшін бар. Топты барлық жерге тасымалдау арқылы табуды түзететіндей көрінетін туннель бұл шекараны көмек қажет болған қолданбаға ғана емес, барлық қолданбаға алып тастады.

Қайталағыштар мен шағылыстырғыштар бар, және олар нақты салдарлары бар нақты қызметтер: бір сайтта жарияланған әр атау екіншісінде көрінеді, оның ішінде адамдарды немесе жабдықты анықтайтын құрылғы атаулары да бар. Егер нақты талап белгілі бір қызметтің табылуы болса, 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-тегі атау оған мұқтаж әр сайттан қолжетімді, ал мұқтаж емес сайттарға ештеңе жарияламайды, және құрылғы басқа мекенжайлы құрылғымен ауыстырылса да жұмысын жалғастырады.

Протокол шынымен мультикастты талап етсе, оны топпен және оған мұқтаж сайттармен шектеңіз, себебін құжаттаңыз, және қолданба өзгерсе шешімді қайта қараңыз. Табуды барлық жерге кеңейту бір рет оңай, ал оған үнсіз тәуелді құрылғылармен бір жылдан кейін оны кері қайтару қиын.

Қатысты мақалалар