Prečo multicast neprejde cez VPN bez plánu

Dve lokality sa môžu po unicaste dokonale dosiahnuť a napriek tomu sa správať, akoby jedna z nich nevidela oznámenie o objavení tlačiarne, IPTV tok alebo tep srdca klastra. To nie je pokazený tunel; to je rozdiel medzi cieľom a skupinou. Doručenie multicastu si vyžaduje model členstva, stav preposielania pozdĺž cesty a rozhranie ochotné niesť prevádzku, a nič z toho neprichádza z unicast trasy. Prejsť od skupiny aplikácie k jednému funkčnému príjemcovi je najkratšia cesta k odpovedi.

Začnite skupinou a aplikáciou

Opýtajte sa, ktorú adresu skupiny aplikácia používa a na čo je prevádzka. Protokol objavovania, ktorý oznamuje služby, streamovací tok a hello pakety smerovacieho protokolu sú tri rôzne problémy s tromi rôznymi prijateľnými odpoveďami. Samotná adresa skupiny hovorí rozsah: adresy v bloku správy lokálnej siete nie sú určené na to, aby ich bežné smerovanie preposielalo mimo linku, a aplikácie, ktoré ich používajú, zvyčajne predpokladajú jednu doménu vysielania. Streamovací tok na skupine s globálnym rozsahom je iný návrh než protokol objavovania, ktorý očakáva, že každé zariadenie vypočuje každú požiadavku, a len druhý sa stará o veľkosť domény vysielania.

Rozhodnite, či je požiadavkou služba alebo mechanizmus objavovania, pretože tieto odpovede sa v nákladoch líšia o rád. Jeden žiada adresu, ktorá sa nemení; druhý žiada doménu vysielania rozšírenú cez link rozsiahlej siete so všetkým, čo z toho vyplýva.

Lokálne objavovanie sa má zastaviť

Multicast DNS opísaný v RFC 6762 je navrhnutý okolo jedného linku: požiadavky idú na pevnú skupinu, odpovede sa posielajú tej istej skupine a protokol sa spolieha na to, že každý účastník počuje všetkých. Smerovače túto prevádzku predvolene nepreposielajú, a to je rozhodnutie návrhu, nie opomenutie. Hranica existuje preto, aby sa zariadenie v jednej budove nemohlo len tak ohlásiť do inej. Tunel, ktorý objavovanie zjavne opraví tým, že skupinu nosí všade, túto hranicu odstránil pre každú aplikáciu, nielen pre tú, ktorá potrebovala pomoc.

Opakovače a reflektory existujú a sú to skutočné služby so skutočnými dôsledkami: každé meno oznámené v jednej lokalite sa stane viditeľným v druhej, vrátane mien zariadení, ktoré identifikujú ľudí alebo vybavenie. Ak je skutočnou požiadavkou, aby konkrétna služba bola dohľadateľná, záznam služby publikovaný v DNS je zvyčajne menšia zmena a prezradí jedno meno namiesto prúdu mien.

Tri veci, ktoré smerovaný multicast potrebuje

Smerovaný multicast potrebuje tri veci, ktoré fungujú spoločne: príjemcov, ktorí sa pripoja ku skupine, smerovače, ktoré pre ňu udržiavajú stav preposielania, a tunel, ktorý adresy skupiny považuje za prevádzku, ktorú treba niesť. Tunel so zásadou, ktorá uvádza len unicast podsiete, zahodí prevádzku skupiny na hranici šifrovania, a preto je prvým príznakom často ticho, nie chyba. Rozhranie založené na trasách, ako tunel GRE alebo VTI, nesie to, čo doň pošle smerovacia tabuľka, čo urobí skupinu dostupnou, hneď ako stav multicastu existuje.

Dostupnosť zdroja je druhá polovica. Smerovacie protokoly multicastu ako PIM stavajú distribučné stromy kontrolou, či cesta späť k zdroju je očakávaná, takže unicast trasa ukazujúca inam strom rozbije aj vtedy, keď je členstvo v skupine správne. Inštalácia trasy pre príjemcu pre túto kontrolu nič nerobí, a to je chyba, ktorá dáva fungujúci ping a zlyhávajúci tok. Najprv overte spätnú cestu zdroja, potom pridajte členstvo a až potom sa pozrite na aplikáciu.

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

Prvé dva riadky ukazujú, ku čomu sa host pripojil a čo jadro preposiela, tretí ukazuje členstvo samotnej aplikácie a posledný unicast cestu, ktorú použije kontrola spätnej cesty. Čítanie spolu odlíši aplikáciu, ktorá sa nikdy nepripojila, od siete, ktorá nikdy nepreposielala.

Dokážte to jedným zdrojom a jedným príjemcom

Skôr než sa dotknete konfigurácie, potvrďte, že aplikácia funguje v jedinom segmente. Ak zlyhá lokálne, smerovanie multicastu nie je problém a žiadna zmena tunela nepomôže. Potom to zopakujte s jedným príjemcom cez tunel a sledujte pakety na oboch stranách hranice šifrovania.

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

Pakety viditeľné vnútri tunela, ale chýbajúce vonku, ukazujú na zapuzdrenie alebo zásadu; pakety viditeľné na oboch stranách bez pokroku aplikácie ukazujú na členstvo príjemcu alebo naviazanie aplikácie. Držte záznamy krátke a filtrované, pretože široký záznam multicastu na vyťaženom segmente je väčšinou šum.

Uprednostnite adresu služby, keď potrebujete len službu

Objavovanie existuje preto, aby našlo niečo, čo sa hýbe. Server so stabilným menom objavovanie nepotrebuje a zdokumentovaná adresa v súkromnom DNS odpovedá na skutočnú používateľovu otázku bez rozšírenia domény vysielania cez link rozsiahlej siete. Rovnaká úvaha platí pre tlačiarne, spotrebiče a interné webové služby. Meno v DNS je dostupné z každej lokality, ktorá ho potrebuje, nič neoznamuje lokalitám, ktoré ho nepotrebujú, a funguje ďalej, keď je zariadenie nahradené iným s inou adresou.

Keď protokol skutočne vyžaduje multicast, obmedzte ho na skupinu a lokality, ktoré ho potrebujú, zdokumentujte prečo a rozhodnutie prehodnoťte, keď sa aplikácia zmení. Rozšíriť objavovanie všade je raz ľahké a ťažké vziať späť po roku zariadení, ktoré na ňom ticho závisia.