SSM przez OpenVPN: śledzenie jednego źródła i grupy od początku do końca

Wybierz jeden strumień i jednego odbiorcę, a następnie poprowadź tę parę przez każdy skok zamiast testować multicast jako kategorię. Projekt specyficzny dla źródła zawodzi dokładnie w jednym z czterech miejsc: odbiorca nigdy się nie przyłączył, router odrzucił pakiet na ścieżce powrotnej, jądro nie ma stanu albo tunel nigdy nie dostarczył kopii. Praca w tej kolejności kosztuje kilka minut na skok i mówi, który z czterech przypadków naprawdę masz.

Najpierw ustal źródło, grupę i odbiorcę

Zapisz trzy wartości, zanim dotkniesz jakiegokolwiek urządzenia: adres źródła, które będzie wysyłać, adres grupy, do której przyłączy się odbiorca, oraz podsieć, w której mieszka odbiorca. Dla przykładowego strumienia IPv4 źródło 10.50.0.10 i grupa 232.20.30.40 to właśnie ta para, która pasuje do projektu specyficznego dla źródła. Niczego mniej precyzyjnego niż te trzy wartości nie da się przetestować.

Zakres 232/8 jest zarezerwowany dla multicastu specyficznego dla źródła, a model opisano w RFC 4607. Jeśli twoja grupa leży poza tym zakresem, a uważasz, że uruchamiasz SSM, zatrzymaj się i potwierdź, co naprawdę zamierza wdrożenie, ponieważ przyłączenie odbiorcy i decyzja routera o przekazywaniu zależą obie od spójności modelu.

Sprawdź, czy odbiorca przyłączył się do źródła

Raport członkostwa dotyczący tylko grupy nie jest przyłączeniem specyficznym dla źródła. Zapytaj odbiorcę, jakiego źródła zażądał, a na routerze pierwszego skoku obejrzyj stan grupy, aby zobaczyć, czy pojawia się lista źródeł. Jeśli raport nie niesie źródła, router potraktuje go jako przyłączenie do dowolnego źródła, a cały projekt po cichu zdegeneruje się w coś, czego nie planowałeś.

Na odbiorcy z Linuksem sprawdź, do czego gniazdo rzeczywiście się zasubskrybowało i co zapisało jądro. Plik konfiguracyjny aplikacji nie jest dowodem; tabela członkostwa jest. Czytaj ją, gdy odbiorca naprawdę działa, bo wpis może chwilę pozostać po zakończeniu procesu, który go utworzył. Nieaktualny wpis z wcześniejszego testu jest pewnym źródłem fałszywej pewności.

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

Jeśli przyłączenie jest obecne z oczekiwanym źródłem, przejdź do routerów. Jeśli go brakuje, żadna konfiguracja tunelu nie pomoże, bo nie ma czego przekazywać.

Sprawdź ścieżkę powrotną, zanim spojrzysz na tunel

Routing multicast wykonuje kontrolę ścieżki powrotnej, a pakiet, który przychodzi innym interfejsem niż ten wskazany przez trasę unicast, jest odrzucany. To najczęstsza przyczyna, dla której strumień wyraźnie wysyłany nigdy nie dociera do następnego skoku, i nie daje przy tym żadnego użytecznego błędu na poziomie aplikacji.

Na routerze zwróconym w stronę źródła porównaj trasę do źródła z interfejsem, na którym pakiety naprawdę przychodzą. Na routerze zwróconym w stronę odbiorcy zrób to samo dla własnej podsieci odbiorcy i potwierdź, że lista interfejsów wyjściowych zawiera łącze w jej stronę. Niezgodność w którymkolwiek kierunku to awaria RPF, a nie awaria członkostwa.

Następnie potwierdź, że TTL źródła jest wystarczająco duży, by przetrwać zaprojektowane skoki routingu. Strumień, który działa na pierwszym routerze i ginie na drugim, często jest kwestią TTL, a nie polityki.

Czytaj stan multicast jądra, a nie konfigurację

Konfiguracja mówi, o co poprosiłeś; jądro mówi, co się dzieje. Na każdym skoku Linuksa odczytaj wpisy routingu multicast i potwierdź, że dla dokładnej pary źródła i grupy istnieje lista interfejsów wejściowych i wyjściowych. Wpis dla grupy ze źródłem wieloznacznym to inny obiekt i nie wyjaśni strumienia specyficznego dla źródła.

ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10

Demony routingu trzymają własny widok na tym stanie, a polecenie, które go wypisuje, zależy od tego, która implementacja jest zainstalowana. Zasada jest stała: zapytaj demona o jego wpis nadrzędny dla pary, a potem zapytaj jądro, czy istnieje wpis przekazywania. Demon, który uważa, że przekazuje, gdy jądro nie ma wpisu, to problem zakresu konfiguracji na tym hoście.

Kiedy oba się nie zgadzają, napraw host, a nie VPN. Nic poniżej nie zrekompensuje skoku, który nie przekazuje strumienia, o który pytałeś. Zapisuj parę, interfejs wejściowy i listę wyjściową dla każdego skoku, dopóki strumień działa. Taki zapis zamienia następną awarię w porównanie zamiast nowego śledztwa.

Zdecyduj, jak tunel naprawdę replikuje

Tu multicast przez VPN przestaje być rutyną. Tunel punkt-punkt dostarcza pakiet do jedynego peera po drugiej stronie, więc kopia dociera dokładnie do jednego klienta. Segment mostkowany zachowuje się bardziej jak łącze współdzielone, bo tunel niesie ramkę, a most decyduje, co zalewać. To różne modele dostarczania, a projekt, który zakłada drugi, działając na pierwszym, będzie wyglądał na działający dla jednego odbiorcy i zawiedzie dla następnego.

Dla więcej niż jednego odbiorcy przez serwer wielopunktowy replikację trzeba zaprojektować jawnie. Zainstalowanie trasy multicast na bramie nie uczy serwera VPN, które peery mają otrzymać kopię, i żadna trasa po stronie klienta nie podejmuje tej decyzji za niego. Tam, gdzie wymaganiem jest wielu odbiorców, użyj obsługiwanej replikacji lub świadomie wybranej alternatywy i zapisz, którą wybrałeś.

Na koniec zweryfikuj u odbiorcy w wąskiej obserwacji: dokładne źródło, grupę i port, na oczekiwanym interfejsie, gdy przyłączony jest jeden upoważniony odbiorca. SSM wybiera nadawcę, a wybór nie jest uwierzytelnieniem tego nadawcy ani pozwoleniem, by inny ruch multicast przekraczał tę samą politykę.