Proč multicast nepřekročí VPN bez plánu

Dvě lokality se mohou po unicastu dokonale dostat jedna na druhou a přesto se chovat, jako by jedna z nich neviděla oznámení o objevení tiskárny, IPTV stream nebo heartbeat clusteru. To není rozbitý tunel; to je rozdíl mezi cílem a skupinou. Doručení multicasting vyžaduje model členství, stav předávání podél cesty a rozhraní ochotné nést provoz, a nic z toho nepřichází z unicast trasy. Projít od skupiny aplikace k jednomu funkčnímu příjemci je nejkratší cesta k odpovědi.

Začněte skupinou a aplikací

Zeptejte se, kterou adresu skupiny aplikace používá a k čemu provoz slouží. Protokol objevování, který oznamuje služby, streamovací kanál a hello pakety směrovacího protokolu jsou tři různé problémy se třemi různými přijatelnými odpověďmi. Adresa skupiny sama říká rozsah: adresy v bloku správy lokální sítě nejsou určeny k tomu, aby je běžné směrování předávalo mimo link, a aplikace, které je používají, obvykle předpokládají jednu broadcast doménu. Streamovací kanál na skupině s globálním rozsahem je jiný návrh než protokol objevování, který očekává, že každé zařízení uslyší každý dotaz, a jen ten druhý se zajímá o velikost broadcast domény.

Rozhodněte, zda je požadavkem služba, nebo mechanismus objevování, protože tyto odpovědi se v nákladech liší o řád. Jeden žádá adresu, která se nemění; druhý žádá broadcast doménu rozšířenou přes link rozsáhlé sítě se vším, co z toho plyne.

Link-local objevování má skončit

Multicast DNS popsaný v RFC 6762 je navržen kolem jednoho linku: dotazy jdou na pevnou skupinu, odpovědi se posílají stejné skupině a protokol spoléhá na to, že každý účastník slyší všechny. Směrovače tento provoz ve výchozím nastavení nepředávají, a to je rozhodnutí návrhu, ne opomenutí. Hranice existuje proto, aby se zařízení v jedné budově nemohlo jen tak ohlásit do jiné. Tunel, který objevování zdánlivě opraví tím, že skupinu nosí všude, tuto hranici odstranil pro každou aplikaci, ne jen pro tu, která potřebovala pomoc.

Repetitory a reflektory existují a jsou to skutečné služby se skutečnými důsledky: každé jméno oznámené na jedné lokalitě se stane viditelným na druhé, včetně jmen zařízení, která identifikují lidi nebo vybavení. Pokud je skutečným požadavkem, aby konkrétní služba byla dohledatelná, záznam služby publikovaný v DNS je obvykle menší změna a prozradí jedno jméno místo proudu jmen.

Tři věci, které směrovaný multicast potřebuje

Směrovaný multicast vyžaduje tři věci, které fungují společně: příjemce, kteří se ke skupině připojí, směrovače, které pro ni udržují stav předávání, a tunel, který adresy skupiny považuje za provoz, který má nést. Tunel se zásadou, která uvádí jen unicast podsítě, zahodí provoz skupiny na hranici šifrování, a proto je prvním příznakem často ticho, ne chyba. Rozhraní založené na trasách, jako je tunel GRE nebo VTI, nese to, co do něj pošle směrovací tabulka, což učiní skupinu dostupnou, jakmile stav multicasting existuje.

Dostupnost zdroje je druhá polovina. Směrovací protokoly multicasting jako PIM staví distribuční stromy tím, že kontrolují, zda cesta zpět ke zdroji je očekávaná, takže unicast trasa ukazující jinam strom rozbije, i když je členství ve skupině správné. Instalace trasy pro příjemce pro tuto kontrolu nic nedělá, a to je chyba, která dává fungující ping a selhávající stream. Nejprve ověřte zpětnou cestu zdroje, poté přidejte členství a teprve pak se podívejte na aplikaci.

ip maddr show dev tun0
ip mroute show
ss -gnu | grep 239.255.0.10
ip route get 10.20.5.20

První dva řádky ukazují, k čemu se host připojil a co jádro předává, třetí ukazuje vlastní členství aplikace a poslední unicast cestu, kterou použije kontrola zpětné cesty. Čtení dohromady odliší aplikaci, která se nikdy nepřipojila, od sítě, která nikdy nepředávala.

Dokažte to jedním zdrojem a jedním příjemcem

Než se dotknete konfigurace, potvrďte, že aplikace funguje v jediném segmentu. Pokud selže lokálně, směrování multicasting není problém a žádná změna tunelu nepomůže. Poté to zopakujte s jedním příjemcem přes tunel a sledujte pakety na obou stranách hranice šifrování.

tcpdump -ni tun0 -c 10 'ip multicast'
tcpdump -ni eth0 -c 10 'ip multicast and host 239.255.0.10'

Pakety viditelné uvnitř tunelu, ale chybějící vně, ukazují na zapouzdření nebo zásadu; pakety viditelné na obou stranách bez pokroku aplikace ukazují na členství příjemce nebo navázání aplikace. Držte záznamy krátké a filtrované, protože široký záznam multicasting na vytíženém segmentu je většinou šum.

Dejte přednost adrese služby, když potřebujete jen službu

Objevování existuje, aby našlo něco, co se pohybuje. Server se stabilním jménem objevování nepotřebuje a zdokumentovaná adresa v privátním DNS odpovídá na skutečnou uživatelovu otázku, aniž by rozšiřovala broadcast doménu přes link rozsáhlé sítě. Stejná úvaha platí pro tiskárny, spotřebiče a interní webové služby. Jméno v DNS je dostupné z každé lokality, která ho potřebuje, nic neoznamuje lokalitám, které ho nepotřebují, a funguje dál, když je zařízení nahrazeno jiným s jinou adresou.

Když protokol skutečně vyžaduje multicast, omezte ho na skupinu a lokality, které ho potřebují, zdokumentujte proč a rozhodnutí přezkoumejte, když se aplikace změní. Rozšířit objevování všude je snadné jednou a těžké vzít zpět po roce zařízení, která na něm tiše závisí.