SSM over OpenVPN: følg én kilde og gruppe fra ende til anden

Vælg én strøm og én modtager, og følg derefter det par gennem hvert hop i stedet for at teste multicast som en kategori. Et kildespecifikt design fejler præcis ét af fire steder: modtageren meldte sig aldrig til, routeren afviste pakken på dens omvendte vej, kernen har ingen tilstand, eller tunnellen leverede aldrig en kopi. At arbejde i den rækkefølge koster minutter per hop og fortæller dig, hvilken af de fire du faktisk har.

Fastlæg kilden, gruppen og modtageren først

Skriv tre værdier ned, før du rører nogen enhed: kildeadressen, der vil sende, gruppeadressen, som modtageren vil tilslutte sig, og det subnet, modtageren bor på. For en illustrativ IPv4-strøm er en kilde på 10.50.0.10 og en gruppe på 232.20.30.40 netop det par, der passer til et kildespecifikt design. Alt mere uklart end disse tre værdier kan ikke testes.

Området 232/8 er reserveret til kildespecifik multicast, og modellen er beskrevet i RFC 4607. Hvis din gruppe ligger uden for dette område, mens du mener at køre SSM, så stop og bekræft, hvad udrulningen faktisk sigter mod, fordi modtagerens tilslutning og routerens videresendelsesbeslutning begge afhænger af, at modellen er konsistent.

Kontrollér, at modtageren har tilsluttet sig kilden

En medlemskabsrapport kun for gruppen er ikke en kildespecifik tilslutning. Spørg modtageren, hvilken kilde den bad om, og se på første-hop-routeren på gruppetilstanden for at se, om der dukker en kildeliste op. Hvis rapporten ikke bærer nogen kilde, vil routeren behandle den som en tilslutning til enhver kilde, og hele designet degenererer lydløst til noget, du ikke havde planlagt.

På en Linux-modtager skal du kontrollere, hvad socketten faktisk abonnerede på, og hvad kernen registrerede. Applikationens konfigurationsfil er ikke bevis; medlemskabstabellen er. Læs den, mens modtageren faktisk kører, fordi en post kan blive hængende et kort stykke tid, efter at processen, der oprettede den, er afsluttet. En forældet post fra en tidligere test er en pålidelig kilde til falsk tryghed.

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

Hvis tilslutningen er der med den forventede kilde, så gå videre til routerne. Hvis den mangler, vil ingen mængde tunnelkonfiguration hjælpe, fordi der ikke er noget at videresende.

Bekræft den omvendte vej, før du ser på tunnellen

Multicast-routing udfører et omvendt vej-tjek, og en pakke, der ankommer på en anden grænseflade end den, unicast-ruten peger på, bliver droppet. Det er den mest almindelige grund til, at en strøm, der tydeligt sendes, aldrig når det næste hop, og det giver slet ingen nyttig fejl på applikationsniveau.

På routeren, der vender mod kilden, skal du sammenligne ruten mod kilden med den grænseflade, pakkerne faktisk ankommer på. På routeren, der vender mod modtageren, gør du det samme for modtagerens eget subnet og bekræfter, at listen over udgående grænseflader indeholder linket mod det. Uoverensstemmelse i hvilken som helst retning er en RPF-fejl, ikke en medlemskabsfejl.

Bekræft derefter, at kildens TTL er stor nok til at overleve de rutede hop, du har designet. En strøm, der virker på den første router og dør på den anden, er ofte et TTL-spørgsmål snarere end et politikspørgsmål.

Læs kernens multicast-tilstand i stedet for konfigurationen

Konfigurationen fortæller dig, hvad du bad om; kernen fortæller dig, hvad der sker. På hvert Linux-hop skal du læse multicast-routingposterne og bekræfte, at der findes en liste over indgående og udgående grænseflader for det præcise par af kilde og gruppe. En post for gruppen med en jokertegn-kilde er et andet objekt og vil ikke forklare en kildespecifik strøm.

ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10

Routingdæmoner holder deres eget syn oven på den tilstand, og kommandoen, der udskriver det, afhænger af, hvilken implementering der er installeret. Princippet er konstant: spørg dæmonen om dens upstream-post for parret, og spørg derefter kernen, om der findes en videresendelsespost. En dæmon, der tror, den videresender, mens kernen ikke har nogen post, er et konfigurationsomfangsproblem på den vært.

Når de to er uenige, så ret værten i stedet for VPN’en. Intet nedstrøms kan kompensere for et hop, der ikke videresender den strøm, du spurgte om. Notér parret, den indgående grænseflade og den udgående liste for hvert hop, mens strømmen virker. Den registrering gør den næste fejl til en sammenligning i stedet for en ny undersøgelse.

Beslut, hvordan tunnellen faktisk replikerer

Det er her, multicast over en VPN holder op med at være rutine. En punkt-til-punkt-tunnel leverer en pakke til den eneste peer i den anden ende, så en kopi når præcis én klient. Et broet segment opfører sig mere som et delt link, fordi tunnellen bærer rammen, og broen beslutter, hvad der skal oversvømmes. Det er forskellige leveringsmodeller, og et design, der antager den anden, mens det kører den første, vil se ud til at virke for én modtager og fejle for den næste.

For mere end én modtager over en multipunkt-server skal replikering designes eksplicit. At installere en multicast-rute på gatewayen lærer ikke VPN-serveren, hvilke peers der skal modtage en kopi, og ingen rute på klientsiden træffer den beslutning for den. Hvor kravet er mange modtagere, brug understøttet replikering eller et bevidst valgt alternativ, og skriv ned, hvilket du valgte.

Til sidst skal du bekræfte ved modtageren under en snæver observation: den præcise kilde, gruppe og port på den grænseflade, du forventer, mens én autoriseret modtager er tilsluttet. SSM vælger en afsender, og valget er ikke autentificering af den afsender, og heller ikke tilladelse til, at anden multicast-trafik krydser samme politik.