SSM över OpenVPN: följ en källa och en grupp från början till slut

Välj en ström och en mottagare och följ sedan det paret genom varje hopp i stället för att testa multicast som en kategori. En källspecifik design misslyckas på exakt en av fyra platser: mottagaren anslöt aldrig, routern avvisade paketet på returvägen, kärnan har inget tillstånd, eller tunneln levererade aldrig någon kopia. Att arbeta i den ordningen kostar minuter per hopp och berättar vilken av de fyra du faktiskt har.

Lås först källan, gruppen och mottagaren

Skriv ner tre värden innan du rör någon enhet: källadressen som ska skicka, gruppadressen som mottagaren ska gå med i och subnätet där mottagaren bor. För en illustrativ IPv4-ström är en källa på 10.50.0.10 och en grupp på 232.20.30.40 precis det par som passar en källspecifik design. Inget vagare än dessa tre värden kan testas.

Intervallet 232/8 är reserverat för källspecifik multicast, och modellen beskrivs i RFC 4607. Om din grupp ligger utanför det intervallet medan du tror att du kör SSM, stanna och bekräfta vad utrullningen faktiskt avser, eftersom mottagarens anslutning och routerns vidarebefordran båda hänger på att modellen är konsistent.

Kontrollera att mottagaren har anslutit till källan

En medlemskapsrapport bara för gruppen är ingen källspecifik anslutning. Fråga mottagaren vilken källa den begärde, och på första hoppets router titta på gruppens tillstånd för att se om en källista dyker upp. Om rapporten inte bär någon källa behandlar routern den som en anslutning från vilken källa som helst, och hela designen urartar tyst till något du inte planerade.

På en Linux-mottagare, kontrollera vad socketen faktiskt prenumererade på och vad kärnan registrerade. Applikationens konfigurationsfil är inte bevis; medlemskapstabellen är det. Läs den medan mottagaren faktiskt körs, eftersom en post kan dröja kvar en kort stund efter att processen som skapade den har avslutats. En inaktuell post från ett tidigare test är en pålitlig källa till falsk trygghet.

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

Om anslutningen finns med den förväntade källan, gå vidare till routrarna. Om den saknas hjälper ingen tunnelkonfiguration, eftersom det inte finns något att vidarebefordra.

Verifiera returvägen innan du tittar på tunneln

Multicast-routing utför en returvägskontroll, och ett paket som anländer på ett annat gränssnitt än det som unicast-rutten pekar på släpps. Det är den vanligaste orsaken till att en ström som tydligt skickas aldrig når nästa hopp, och det ger ingen användbar felindikation på applikationsnivå alls.

På routern som vetter mot källan, jämför rutten mot källan med gränssnittet som paketen faktiskt anländer på. På routern som vetter mot mottagaren, gör samma sak för mottagarens eget subnät och bekräfta att listan över utgående gränssnitt innehåller länken dit. En avvikelse i någon riktning är ett RPF-fel, inte ett medlemskapsfel.

Bekräfta sedan att källans TTL är tillräckligt stor för att överleva de routade hopp du har designat. En ström som fungerar på den första routern och dör på den andra är oftast en TTL-fråga och inte en policyfråga.

Läs kärnans multicast-tillstånd i stället för konfigurationen

Konfigurationen berättar vad du bad om; kärnan berättar vad som händer. På varje Linux-hopp, läs multicast-routingposterna och bekräfta att det finns en lista över inkommande och utgående gränssnitt för det exakta paret av källa och grupp. En post för gruppen med en jokerteckenkälla är ett annat objekt, och den förklarar inte en källspecifik ström.

ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10

Routingdaemoner håller sin egen vy ovanpå det tillståndet, och kommandot som skriver ut den beror på vilken implementation som är installerad. Principen är konstant: fråga daemonen efter dess uppströmspost för paret och fråga sedan kärnan om det finns en vidarebefordringspost. En daemon som tror att den vidarebefordrar medan kärnan inte har någon post är ett konfigurationsomfångsproblem på den datorn.

När de två inte stämmer överens, åtgärda värden och inte VPN:en. Inget nedströms kan kompensera för ett hopp som inte vidarebefordrar den ström du frågade om. Anteckna paret, det inkommande gränssnittet och den utgående listan för varje hopp medan strömmen fungerar. Den anteckningen gör nästa fel till en jämförelse i stället för en ny utredning.

Bestäm hur tunneln faktiskt replikerar

Här slutar multicast över en VPN att vara rutin. En punkt-till-punkt-tunnel levererar ett paket till den enda peeren i andra änden, så en kopia når exakt en klient. Ett bryggat segment beter sig mer som en delad länk, eftersom tunneln bär ramen och bryggan avgör vad som ska översvämmas. Det är olika leveransmodeller, och en design som antar den andra medan den kör den första kommer att se ut att fungera för en mottagare och misslyckas för nästa.

För mer än en mottagare över en multipunktsserver måste replikeringen designas uttryckligen. Att installera en multicast-rutt på gatewayen lär inte VPN-servern vilka peers som ska få en kopia, och ingen rutt på klientsidan fattar det beslutet åt den. Där kravet är många mottagare, använd stödd replikering eller ett medvetet valt alternativ, och skriv ner vilket du valde.

Verifiera slutligen vid mottagaren under en snäv observation: den exakta källan, gruppen och porten, på det gränssnitt du förväntar dig, medan en auktoriserad mottagare är ansluten. SSM väljer en avsändare, och valet är inte autentisering av den avsändaren, och inte heller tillstånd för annan multicast-trafik att korsa samma policy.