SSM over OpenVPN: følg én kilde og én gruppe fra start til slutt

Velg én strøm og én mottaker, og følg deretter det paret gjennom hvert hopp i stedet for å teste multicast som en kategori. Et kildespesifikt design feiler på nøyaktig ett av fire steder: mottakeren ble aldri med, ruteren avviste pakken på returveien, kjernen har ingen tilstand, eller tunnelen leverte aldri en kopi. Å arbeide i den rekkefølgen koster minutter per hopp og forteller deg hvilken av de fire du faktisk har.

Fest kilden, gruppen og mottakeren først

Skriv ned tre verdier før du berører noen enhet: kildeadressen som skal sende, gruppeadressen mottakeren skal bli med i, og subnettet mottakeren bor på. For en illustrerende IPv4-strøm er en kilde på 10.50.0.10 og en gruppe på 232.20.30.40 nettopp det paret som passer til et kildespesifikt design. Noe vagere enn disse tre verdiene kan ikke testes.

Området 232/8 er reservert for kildespesifikk multicast, og modellen er beskrevet i RFC 4607. Hvis gruppen din ligger utenfor dette området mens du tror du kjører SSM, stopp og bekreft hva utrullingen faktisk har tenkt, fordi mottakerens innmelding og ruterens videresendingsbeslutning begge avhenger av at modellen er konsistent.

Kontroller at mottakeren har meldt seg inn i kilden

En medlemskapsrapport bare for gruppen er ikke en kildespesifikk innmelding. Spør mottakeren hvilken kilde den ba om, og på førstehoppsruteren se på gruppetilstanden for å se om en kildeliste dukker opp. Hvis rapporten ikke bærer noen kilde, vil ruteren behandle den som en innmelding fra hvilken som helst kilde, og hele designet forringes lydløst til noe du ikke planla.

På en Linux-mottaker må du kontrollere hva socketen faktisk abonnerte på og hva kjernen registrerte. Applikasjonens konfigurasjonsfil er ikke bevis; medlemskapstabellen er det. Les den mens mottakeren faktisk kjører, fordi en oppføring kan henge igjen kort etter at prosessen som opprettet den har avsluttet. En utdatert oppføring fra en tidligere test er en pålitelig kilde til falsk trygghet.

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

Hvis innmeldingen er der med den forventede kilden, gå videre til ruterne. Hvis den mangler, vil ingen tunnelkonfigurasjon hjelpe, fordi det ikke er noe å videresende.

Bekreft returveien før du ser på tunnelen

Multicast-ruting utfører en returveikontroll, og en pakke som ankommer på et annet grensesnitt enn det unicast-ruten peker på, blir droppet. Dette er den vanligste grunnen til at en strøm som tydelig sendes aldri når neste hopp, og det gir ingen nyttig feil på applikasjonsnivå i det hele tatt.

På ruteren som vender mot kilden, sammenlign ruten mot kilden med grensesnittet pakkene faktisk ankommer på. På ruteren som vender mot mottakeren, gjør det samme for mottakerens eget subnett og bekreft at listen over utgående grensesnitt inkluderer lenken dit. Uoverensstemmelse i hvilken som helst retning er en RPF-feil, ikke en medlemskapsfeil.

Bekreft deretter at kildens TTL er stort nok til å overleve de rutede hoppene du har designet. En strøm som fungerer på den første ruteren og dør på den andre, er ofte et TTL-spørsmål og ikke et policyspørsmål.

Les kjernens multicast-tilstand i stedet for konfigurasjonen

Konfigurasjonen forteller deg hva du ba om; kjernen forteller deg hva som skjer. På hvert Linux-hopp, les multicast-ruteoppføringene og bekreft at det finnes en liste over inngående og utgående grensesnitt for det nøyaktige paret av kilde og gruppe. En oppføring for gruppen med en jokertegnkilde er et annet objekt, og den vil ikke forklare en kildespesifikk strøm.

ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10

Rutedemoner holder sin egen visning over den tilstanden, og kommandoen som skriver den ut avhenger av hvilken implementasjon som er installert. Prinsippet er konstant: spør demonen om dens oppstrømsoppføring for paret, og spør deretter kjernen om det finnes en videresendingsoppføring. En demon som tror den videresender mens kjernen ikke har noen oppføring, er et konfigurasjonsomfangsproblem på den verten.

Når de to er uenige, reparer verten og ikke VPN-en. Ingenting nedstrøms kan kompensere for et hopp som ikke videresender strømmen du spurte om. Noter paret, det inngående grensesnittet og den utgående listen for hvert hopp mens strømmen virker. Den registreringen gjør neste feil til en sammenligning i stedet for en ny undersøkelse.

Bestem hvordan tunnelen faktisk replikerer

Det er her multicast over en VPN slutter å være rutine. En punkt-til-punkt-tunnel leverer en pakke til den eneste peeren i den andre enden, så en kopi når nøyaktig én klient. Et broet segment oppfører seg mer som en delt lenke, fordi tunnelen bærer rammen og broen bestemmer hva som skal oversvømmes. Det er forskjellige leveringsmodeller, og et design som antar den andre mens det kjører den første, vil se ut til å virke for én mottaker og feile for den neste.

For mer enn én mottaker over en multipunkt-server må replikeringen designes eksplisitt. Å installere en multicast-rute på gatewayen lærer ikke VPN-serveren hvilke peerer som skal motta en kopi, og ingen rute på klientsiden tar den beslutningen for den. Der kravet er mange mottakere, bruk støttet replikering eller et bevisst valgt alternativ, og skriv ned hvilket du valgte.

Til slutt, bekreft ved mottakeren under en smal observasjon: den nøyaktige kilden, gruppen og porten, på grensesnittet du forventer, mens én autorisert mottaker er innmeldt. SSM velger en sender, og valget er ikke autentisering av den senderen, og heller ikke tillatelse for annen multicast-trafikk å krysse samme policy.