Dlaczego multicast nie przechodzi przez VPN bez planu

Dwie lokalizacje mogą doskonale sięgać się nawzajem przez unicast i mimo to zachowywać się tak, jakby jedna z nich nie widziała ogłoszenia odkrywania drukarki, strumienia IPTV albo bicia serca klastra. To nie jest zepsuty tunel; to różnica między celem a grupą. Dostarczanie multicastu wymaga modelu członkostwa, stanu przekazywania wzdłuż ścieżki i interfejsu gotowego nieść ruch, a nic z tego nie pochodzi z trasy unicast. Przejście od grupy aplikacji do jednego działającego odbiorcy to najkrótsza droga do odpowiedzi.

Zacznij od grupy i aplikacji

Zapytaj, jakiego adresu grupy używa aplikacja i do czego służy ruch. Protokół odkrywania ogłaszający usługi, strumień transmisji i pakiety powitania protokołu routingu to trzy różne problemy z trzema różnymi dopuszczalnymi odpowiedziami. Sam adres grupy mówi o zakresie: adresy w bloku kontroli sieci lokalnej nie są przeznaczone do przekazywania poza łącze przez zwykły routing, a aplikacje, które ich używają, zwykle zakładają jedną domenę rozgłaszania. Strumień transmisji w grupie o zasięgu globalnym to inny projekt niż protokół odkrywania, który oczekuje, że każde urządzenie usłyszy każde zapytanie, i tylko ten drugi przejmuje się rozmiarem domeny rozgłaszania.

Zdecyduj, czy wymaganiem jest usługa, czy mechanizm odkrywania, bo te odpowiedzi różnią się kosztem o rząd wielkości. Jedna prosi o adres, który się nie zmienia; druga prosi o domenę rozgłaszania rozciągniętą przez łącze sieci rozległej wraz ze wszystkim, co z tego wynika.

Odkrywanie lokalne ma się zatrzymać

Multicast DNS opisany w RFC 6762 jest zaprojektowany wokół jednego łącza: zapytania idą do stałej grupy, odpowiedzi są wysyłane do tej samej grupy, a protokół polega na tym, że każdy uczestnik słyszy wszystkich. Routery nie przekazują tego ruchu domyślnie, i to jest decyzja projektowa, nie przeoczenie. Granica istnieje po to, by urządzenie w jednym budynku nie mogło od niechcenia ogłosić się w innym. Tunel, który zdaje się naprawiać odkrywanie, przenosząc grupę wszędzie, usunął tę granicę dla każdej aplikacji, nie tylko dla tej, która potrzebowała pomocy.

Repeatery i reflektory istnieją i są prawdziwymi usługami z prawdziwymi skutkami: każda nazwa ogłoszona w jednej lokalizacji staje się widoczna w drugiej, w tym nazwy urządzeń identyfikujące osoby lub sprzęt. Jeśli prawdziwym wymaganiem jest to, by konkretna usługa była znajdowana, opublikowany w DNS rekord usługi jest zwykle mniejszą zmianą i ujawnia jedną nazwę zamiast ich strumienia.

Trzy rzeczy, których potrzebuje rutowany multicast

Rutowany multicast wymaga trzech rzeczy działających razem: odbiorców, którzy dołączają do grupy, routerów, które utrzymują dla niej stan przekazywania, oraz tunelu, który traktuje adresy grupy jako ruch do przeniesienia. Tunel z polityką wymieniającą tylko podsieci unicast odrzuci ruch grupy na granicy szyfrowania i dlatego pierwszym objawem jest często cisza, a nie błąd. Interfejs oparty na trasach, taki jak tunel GRE lub VTI, przenosi to, co wyśle do niego tablica routingu, co czyni grupę osiągalną, gdy tylko istnieje stan multicastu.

Osiągalność źródła to druga połowa. Protokoły routingu multicastu, takie jak PIM, budują drzewa dystrybucji, sprawdzając, czy ścieżka powrotna do źródła jest oczekiwana, więc trasa unicast wskazująca gdzie indziej psuje drzewo nawet wtedy, gdy członkostwo w grupie jest poprawne. Zainstalowanie trasy dla odbiorcy nic nie daje temu sprawdzeniu i to jest błąd, który daje działający ping i zawodzący strumień. Najpierw sprawdź ścieżkę powrotną źródła, potem dodaj członkostwo, a dopiero na końcu spójrz na aplikację.

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

Pierwsze dwie linie pokazują, do czego dołączył host i co przekazuje jądro, trzecia pokazuje członkostwo samej aplikacji, a ostatnia trasę unicast, której użyje sprawdzanie ścieżki odwrotnej. Czytanie ich razem odróżnia aplikację, która nigdy nie dołączyła, od sieci, która nigdy nie przekazywała.

Udowodnij to jednym źródłem i jednym odbiorcą

Zanim dotkniesz konfiguracji, potwierdź, że aplikacja działa w jednym segmencie. Jeśli zawodzi lokalnie, routing multicastu nie jest problemem i żadna zmiana tunelu nie pomoże. Następnie powtórz z jednym odbiorcą przez tunel i obserwuj pakiety po obu stronach granicy szyfrowania.

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

Pakiety widoczne wewnątrz tunelu, ale nieobecne na zewnątrz, wskazują na kapsułkowanie lub politykę; pakiety widoczne po obu stronach bez postępu aplikacji wskazują na członkostwo odbiorcy lub powiązanie aplikacji. Utrzymuj przechwyty krótkie i filtrowane, bo szeroki przechwyt multicastu w zajętym segmencie to głównie szum.

Wybierz adres usługi, gdy potrzebujesz tylko usługi

Odkrywanie istnieje po to, by znaleźć coś, co się porusza. Serwer o stabilnej nazwie nie potrzebuje odkrywania, a udokumentowany adres w prywatnym DNS odpowiada na prawdziwe pytanie użytkownika bez rozciągania domeny rozgłaszania przez łącze sieci rozległej. To samo rozumowanie dotyczy drukarek, urządzeń i wewnętrznych usług sieciowych. Nazwa w DNS jest osiągalna z każdej lokalizacji, która jej potrzebuje, nie ogłaszając nic lokalizacjom, które jej nie potrzebują, i działa dalej, gdy urządzenie zostanie zastąpione innym o innym adresie.

Gdy protokół naprawdę wymaga multicastu, ogranicz go do grupy i lokalizacji, które go potrzebują, udokumentuj dlaczego i wróć do decyzji, gdy aplikacja się zmieni. Rozciągnięcie odkrywania wszędzie jest łatwe raz, a trudne do wycofania po roku urządzeń, które po cichu na nim polegają.