Эмне үчүн мультикаст плансыз 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 ичиндеги ат ага муктаж ар бир сайттан жеткиликтүү, муктаж эмес сайттарга эч нерсе жарыялабайт, жана түзмөк башка даректеги түзмөк менен алмаштырылса да ишин улантат.

Протокол чын эле мультикастты талап кылса, аны топ жана ага муктаж сайттар менен чектеңиз, себебин документтештириңиз, жана колдонмо өзгөрсө чечимди кайра карап чыгыңыз. Издөөнү бардык жерге кеңейтүү бир жолу оңой, ал эми ага үнсүз көз каранды болгон түзмөктөр менен бир жылдан кийин аны кайтарып алуу кыйын.