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. Ништа низводно не може надокнадити скок који не прослеђује ток о ком сте питали. Забележите пар, улазни интерфејс и одлазни списак за сваки скок док ток ради. Тај запис претвара следећи квар у поређење уместо у нову истрагу.

Одлучите како тунел стварно реплицира

Овде multicast преко VPN-а престаје да буде рутина. Тунел тачка-тачка испоручује пакет једином peer-у на другој страни, па копија стиже тачно једном клијенту. Премосни сегмент понаша се више као дељени линк, јер тунел носи оквир, а мост одлучује шта ће преплавити. То су различити модели испоруке, а дизајн који претпоставља други док ради први изгледаће исправан за једног примаоца и пасти за следећег.

За више од једног примаоца преко вишеструко тачкастог сервера репликација се мора пројектовати изричито. Инсталирање multicast руте на гејтвеју не учи VPN сервер који peer-ови треба да добију копију, и ниједна рута на страни клијента не доноси ту одлуку уместо њега. Где је захтев много прималаца, користите подржану репликацију или намерно одабрану алтернативу и запишите коју сте одабрали.

Коначно, проверите на примаоцу под уским посматрањем: тачан извор, групу и порт, на интерфејсу који очекујете, док је придружен један овлашћени прималац. SSM бира пошиљаоца, а избор није аутентификација тог пошиљаоца, нити дозвола другом multicast саобраћају да прође исту политику.