SSM over OpenVPN: følg éi kjelde og éi gruppe frå start til slutt

Vel éin straum og éin mottakar, og følg deretter det paret gjennom kvar hopp i staden for å teste multicast som ein kategori. Eit kjeldetilpassa design feilar på nøyaktig eitt av fire stader: mottakaren vart aldri med, rutaren avviste pakken på returvegen, kjernen har ingen tilstand, eller tunnelen leverte aldri ein kopi. Å arbeide i den rekkjefølgja kostar minutt per hopp og fortel deg kva for ein av dei fire du faktisk har.

Fest kjelda, gruppa og mottakaren først

Skriv ned tre verdiar før du rører noka eining: kjeldeadressa som skal senda, gruppeadressa mottakaren skal bli med i, og subnettet mottakaren bur på. For ein illustrerande IPv4-straum er ei kjelde på 10.50.0.10 og ei gruppe på 232.20.30.40 nettopp det paret som passar til eit kjeldetilpassa design. Noko vagare enn desse tre verdiane kan ikkje testast.

Området 232/8 er reservert for kjeldetilpassa multicast, og modellen er skildra i RFC 4607. Viss gruppa di ligg utanfor dette området medan du trur du køyrer SSM, stopp og stadfest kva utrullinga faktisk har tenkt, fordi innmeldinga til mottakaren og videresendingsavgjerda til rutaren båe er avhengige av at modellen er konsistent.

Kontroller at mottakaren har meldt seg inn i kjelda

Ein medlemskapsrapport berre for gruppa er ikkje ei kjeldetilpassa innmelding. Spør mottakaren kva kjelde han bad om, og på førstehoppsrutaren sjå på gruppetilstanden for å sjå om ei kjeldeliste dukkar opp. Viss rapporten ikkje ber noka kjelde, vil rutaren handsame han som ei innmelding frå kva kjelde som helst, og heile designet blir lydlaust forringa til noko du ikkje planla.

På ein Linux-mottakar må du kontrollere kva socketen faktisk abonnerte på og kva kjernen registrerte. Konfigurasjonsfila til applikasjonen er ikkje prov; medlemskapstabellen er det. Les han medan mottakaren faktisk køyrer, fordi ei oppføring kan henge att ei kort stund etter at prosessen som laga henne har avslutta. Ei utdatert oppføring frå ein tidlegare test er ei påliteleg kjelde til falsk tryggleik.

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

Viss innmeldinga er der med den forventa kjelda, gå vidare til rutarane. Viss ho manglar, vil ingen tunnelkonfigurasjon hjelpe, fordi det ikkje er noko å videresende.

Stadfest returvegen før du ser på tunnelen

Multicast-ruting utfører ein returvegkontroll, og ein pakke som kjem inn på eit anna grensesnitt enn det unicast-ruta peikar på, blir droppa. Dette er den vanlegaste grunnen til at ein straum som tydeleg blir send, aldri når neste hopp, og det gir ingen nyttig feil på applikasjonsnivå i det heile.

På rutaren som vender mot kjelda, samanlikn ruta mot kjelda med grensesnittet pakkane faktisk kjem inn på. På rutaren som vender mot mottakaren, gjer det same for mottakaren sitt eige subnett og stadfest at lista over utgåande grensesnitt inneheld lenkja dit. Uoverensstemmelse i kva retning som helst er ein RPF-feil, ikkje ein medlemskapsfeil.

Stadfest deretter at TTL-en til kjelda er stor nok til å overleve dei ruta hoppa du har designa. Ein straum som fungerer på den første rutaren og døyr på den andre, er ofte eit TTL-spørsmål og ikkje eit policespørsmål.

Les multicast-tilstanden til kjernen i staden for konfigurasjonen

Konfigurasjonen fortel deg kva du bad om; kjernen fortel deg kva som skjer. På kvar Linux-hopp, les multicast-ruteoppføringane og stadfest at det finst ei liste over inngåande og utgåande grensesnitt for det nøyaktige paret av kjelde og gruppe. Ei oppføring for gruppa med ein jokerteiknkjelde er eit anna objekt, og ho vil ikkje forklare ein kjeldetilpassa straum.

ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10

Rutedemonar held si eiga vising over den tilstanden, og kommandoen som skriv han ut er avhengig av kva implementasjon som er installert. Prinsippet er konstant: spør demonen om oppstraumsføringa hans for paret, og spør deretter kjernen om det finst ei videresendingsføring. Ein demon som trur han videresender medan kjernen ikkje har noka oppføring, er eit konfigurasjonsomfangsproblem på den verten.

Når dei to er usamde, reparer verten og ikkje VPN-en. Ingenting nedstraums kan kompensere for ein hopp som ikkje videresender straumen du spurde om. Noter paret, det inngåande grensesnittet og den utgåande lista for kvar hopp medan straumen verkar. Den registreringa gjer neste feil til ein samanlikning i staden for ei ny undersøking.

Avgjer korleis tunnelen faktisk replikerer

Det er her multicast over ein VPN sluttar å vere rutine. Ein punkt-til-punkt-tunnel leverer ein pakke til den einaste peeren i den andre enden, så ein kopi når nøyaktig éin klient. Eit brua segment oppfører seg meir som ei delt lenkje, fordi tunnelen ber ramma og brua avgjer kva som skal oversvømmast. Det er ulike leveringsmodellar, og eit design som føreset den andre medan det køyrer den første, vil sjå ut til å verke for ein mottakar og feile for den neste.

For meir enn éin mottakar over ein fleirpunktserver må replikeringa designast eksplisitt. Å installere ei multicast-rute på gatewayen lærer ikkje VPN-serveren kva peerar som skal motta ein kopi, og inga rute på klientsida tek den avgjerda for han. Der kravet er mange mottakarar, bruk støtta replikering eller eit medvite valt alternativ, og skriv ned kva du valde.

Til slutt, stadfest hos mottakaren under ein smal observasjon: den nøyaktige kjelda, gruppa og porten, på grensesnittet du forventar, medan éin autorisert mottakar er innmeldt. SSM vel ein sendar, og valet er ikkje autentisering av den sendaren, og heller ikkje løyve for annan multicast-trafikk å krysse same policy.