SSM přes OpenVPN: sledování jednoho zdroje a skupiny od začátku do konce

Vyberte jeden tok a jednoho příjemce a pak tuto dvojici proveďte každým skokem, místo abyste multicast testovali jako kategorii. Návrh specifický pro zdroj selhává přesně na jednom ze čtyř míst: příjemce se nikdy nepřipojil, směrovač paket na zpětné cestě odmítl, jádro nemá stav, nebo tunel nikdy nedoručil kopii. Práce v tomto pořadí stojí minuty na skok a řekne vám, které ze čtyř skutečně máte.

Nejprve zafixujte zdroj, skupinu a příjemce

Zapište tři hodnoty, než se dotknete jakéhokoli zařízení: adresu zdroje, který bude odesílat, adresu skupiny, ke které se příjemce připojí, a podsíť, ve které příjemce žije. Pro ilustrativní tok IPv4 je zdroj 10.50.0.10 a skupina 232.20.30.40 přesně ten typ dvojice, který sedí k návrhu specifickému pro zdroj. Cokoli vágnějšího než tyto tři hodnoty testovat nelze.

Rozsah 232/8 je vyhrazen pro multicast specifický pro zdroj a model je popsán v RFC 4607. Pokud vaše skupina leží mimo tento rozsah, zatímco si myslíte, že provozujete SSM, zastavte se a potvrďte, co nasazení skutečně zamýšlí, protože připojení příjemce i rozhodnutí směrovače o předávání závisí na tom, že model je konzistentní.

Ověřte, že se příjemce připojil ke zdroji

Zpráva o členství pouze pro skupinu není připojením specifickým pro zdroj. Zeptejte se příjemce, který zdroj požadoval, a na směrovači prvního skoku se podívejte na stav skupiny, zda se objeví seznam zdrojů. Pokud zpráva nenese zdroj, směrovač ji bude považovat za připojení k libovolnému zdroji a celý návrh tiše degradovat v něco, co jste neplánovali.

Na přijímači s Linuxem zkontrolujte, k čemu se socket skutečně přihlásil a co jádro zaznamenalo. Konfigurační soubor aplikace není důkaz; tabulka členství ano. Čtěte ji, dokud příjemce skutečně běží, protože záznam může krátce přetrvat poté, co proces, který jej vytvořil, skončí. Zastaralý záznam z dřívějšího testu je spolehlivým zdrojem falešné jistoty.

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

Pokud je připojení přítomno s očekávaným zdrojem, přejděte ke směrovačům. Pokud chybí, žádná konfigurace tunelu nepomůže, protože není co předávat.

Ověřte zpětnou cestu, než se podíváte na tunel

Multicastové směrování provádí kontrolu zpětné cesty a paket, který dorazí na jiné rozhraní, než na které ukazuje unicastová trasa, se zahodí. To je nejčastější důvod, proč tok, který se zjevně odesílá, nikdy nedorazí k dalšímu skoku, a nevzniká při tom žádná užitečná chyba na úrovni aplikace.

Na směrovači obráceném ke zdroji porovnejte trasu ke zdroji s rozhraním, na kterém pakety skutečně přicházejí. Na směrovači obráceném k příjemci udělejte totéž pro vlastní podsíť příjemce a potvrďte, že seznam odchozích rozhraní obsahuje spoj k ní. Neshoda v kterémkoli směru je selhání RPF, ne selhání členství.

Poté potvrďte, že TTL zdroje je dost velké, aby přežilo směrované skoky, které jste navrhli. Tok, který funguje na prvním směrovači a umírá na druhém, je často otázka TTL, nikoli politiky.

Čtěte multicastový stav jádra, ne konfiguraci

Konfigurace vám říká, co jste požadovali; jádro vám říká, co se děje. Na každém skoku Linuxu přečtěte záznamy multicastového směrování a potvrďte, že pro přesnou dvojici zdroj a skupina existuje seznam vstupních a výstupních rozhraní. Záznam pro skupinu se zástupným zdrojem je jiný objekt a tok specifický pro zdroj nevysvětlí.

ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10

Směrovací démoni si nad tímto stavem drží vlastní pohled a příkaz, který jej vypisuje, závisí na tom, která implementace je nainstalována. Princip je stálý: zeptejte se démona na jeho upstream záznam pro dvojici, pak se zeptejte jádra, zda existuje záznam předávání. Démon, který si myslí, že předává, zatímco jádro záznam nemá, je problém rozsahu konfigurace na tom hostiteli.

Když se oba rozcházejí, opravte hostitele, ne VPN. Nic níže po proudu nemůže vykompenzovat skok, který nepředává tok, na který jste se ptali. Zapisujte dvojici, vstupní rozhraní a výstupní seznam pro každý skok, dokud tok funguje. Takový záznam promění příští selhání v porovnání místo v nové vyšetřování.

Rozhodněte, jak tunel skutečně replikuje

Tady multicast přes VPN přestává být rutinou. Tunel typu bod-bod doručí paket jedinému protějšku na druhém konci, takže kopie dorazí přesně jednomu klientovi. Přemostěný segment se chová spíš jako sdílené spojení, protože tunel nese rámec a most rozhoduje, co zaplaví. To jsou různé modely doručení a návrh, který předpokládá druhý, zatímco běží první, bude pro jednoho příjemce vypadat funkčně a pro dalšího selže.

Pro více než jednoho příjemce přes vícebodový server se replikace musí navrhnout výslovně. Instalace multicastové trasy na bráně nenaučí VPN server, kteří protějšky mají dostat kopii, a žádná trasa na straně klienta toto rozhodnutí za něj neudělá. Kde je požadavkem mnoho příjemců, použijte podporovanou replikaci nebo záměrně zvolenou alternativu a zapište, kterou jste zvolili.

Nakonec to ověřte na příjemci při úzkém pozorování: přesný zdroj, skupina a port, na rozhraní, které očekáváte, zatímco je připojen jeden autorizovaný příjemce. SSM vybírá odesílatele a výběr není ověřením totožnosti tohoto odesílatele ani povolením, aby stejnou politikou procházel jiný multicastový provoz.