OpenVPN аркылуу SSM: бир булакты жана топту башынан аягына чейин көзөмөлдөө

Бир агымды жана бир кабыл алуучуну тандаңыз, анан multicast'ты категория катары сынагандын ордуна ошол жупту ар бир хоп аркылуу өткөрүңүз. Булакка мүнөздүү долбоор так төрт жердин биринде ишке ашпайт: кабыл алуучу эч качан кошулган эмес, маршрутизатор пакетти кайра жолунда четке каккан, ядродо абал жок, же туннель эч качан көчүрмө жеткирген эмес. Ушундай тартипте иштөө ар бир хопко бир нече минут талап кылат жана төртөөнүн кайсынысы чындыгында бар экенин айтат.

Алгач булакты, топту жана кабыл алуучуну бекемдеңиз

Каалаган түзмөккө тийүүдөн мурун үч маанини жазыңыз: жөнөтө турган булак дареги, кабыл алуучу кошула турган топ дареги жана кабыл алуучу жайгашкан ички тармак. Мисал катары IPv4 агымы үчүн 10.50.0.10 булагы жана 232.20.30.40 тобу булакка мүнөздүү долбоорго туура келген жуптун түрү. Бул үч мааниден даана эмес нерсени сыноого болбойт.

232/8 диапазону булакка мүнөздүү multicast үчүн корголгон, ал эми модель RFC 4607 документинде сүрөттөлгөн. Эгер тобуңуз ошол диапазондон тышкары болуп, сиз SSM иштетип жатам деп ойлосоңуз, токтоп, жайгаштыруу чындыгында эмнени көздөп жатканын ырастаңыз, анткени кабыл алуучунун кошулушу жана маршрутизатордун өткөрүү чечими экөө тең моделдин ырааттуу болушуна көз каранды.

Кабыл алуучу булакка кошулганын текшериңиз

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

Linux кабыл алуучусунда сокет чындыгында эмнеге жазылганын жана ядро эмнени жазып койгонун текшериңиз. Колдонмонун конфигурация файлы далил эмес; мүчөлүк таблицасы далил. Аны кабыл алуучу чындыгында иштеп турганда окуңуз, анткени аны түзгөн процесс бүткөндөн кийин да жазуу аз убакыт калышы мүмкүн. Мурунку сыноодон калган эскирген жазуу жалган ишенимдин ишенимдүү булагы болуп саналат.

ip maddr show dev eth0
cat /proc/net/igmp | sed -n '1,40p'

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

Туннелди караардан мурун кайра жолду текшериңиз

Multicast маршруттоо кайра жолду текшерүүнү аткарат, ал эми unicast маршруту көрсөткөн интерфейстен башка интерфейске келген пакет ыргытылат. Бул ачык жөнөтүлүп жаткан агымдын кийинки хопко эч качан жетпешинин эң кеңири тараган себеби, жана ал колдонмо деңгээлинде пайдалуу катаны такыр чыгарбайт.

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

Анан булактын TTL сиз долбоорлогон маршрутталган хоптордон өтүүгө жетиштүү чоң экенин ырастаңыз. Биринчи маршрутизатордо иштеп, экинчисинде өлгөн агым көбүнчө TTL маселеси, саясат маселеси эмес.

Конфигурациянын ордуна ядронун multicast абалын окуңуз

Конфигурация эмнени сураганыңызды айтат; ядро эмне болуп жатканын айтат. Ар бир Linux хопунда multicast маршруттоо жазууларын окуп, булак менен топтун так жубу үчүн кирүүчү жана чыгуучу интерфейстердин тизмеси бар экенин ырастаңыз. Топ үчүн универсалдуу булагы бар жазуу — башка объект, ал булакка мүнөздүү агымды түшүндүрбөйт.

ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10

Маршруттоо демондору ошол абалдын үстүндө өз көз карашын сакташат, аны басып чыгарган буйрук кайсы ишке ашыруу орнотулганына байланыштуу. Принцип туруктуу: демондон жуп үчүн анын жогорку агымдагы жазуусун сураңыз, анан ядродон өткөрүп берүү жазуусу бар-жогун сураңыз. Ядрода жазуу жок кезде өзүн өткөрүп жатат деп ойлогон демон — ошол хосттогу конфигурациянын алкагынын маселеси.

Экөө келишпесе, VPNди эмес, хостту оңдогула. Төмөндө эч нерсе сиз сураган агымды өткөрүп бербеген хоптун ордун толтура албайт. Агым иштеп турганда ар бир хоп үчүн жупту, кирүүчү интерфейсти жана чыгуучу тизмени жазып алыңыз. Ал жазуу кийинки бузулушту жаңы иликтөөнүн ордуна салыштырууга айландырат.

Туннель чындыгында кантип көчүрө турганын чечиңиз

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

Көп пункттуу сервер аркылуу бирден көп кабыл алуучу үчүн көчүрүү ачык долбоорлонушу керек. Шлюзга multicast маршрутун орнотуу VPN серверине кайсы теңтуштар көчүрмө алышы керектигин үйрөтпөйт, жана кардар тараптагы эч бир маршрут бул чечимди анын ордуна кабыл албайт. Талап көп кабыл алуучу болгон жерде колдоого алынган көчүрүүнү же атайын тандалган баламаны колдонуңуз жана кайсынысын тандаганыңызды жазыңыз.

Акырында кабыл алуучуда тар байкоо менен текшериңиз: так булак, топ жана порт, күткөн интерфейсте, бир ыйгарым укуктуу кабыл алуучу кошулган кезде. SSM жөнөтүүчүнү тандайт, ал эми тандоо ошол жөнөтүүчүнүн аутентификациясы эмес, башка multicast трафигинин ошол эле саясаттан өтүүсүнө уруксат да эмес.