SSM OpenVPN арқылы: бір көзді және топты басынан аяғына дейін қадағалау

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