OpenVPN rozsyła multicast do każdego klienta, nie do subskrybentów

"Obsługuje multicast" odpowiada na pytanie o protokół i pozostawia pytanie o przepustowość nietknięte. Operacyjnie liczy się to, ile kopii serwer wysyła dla jednego pakietu grupowego i które tunele je przenoszą. Jedna zasubskrybowana aplikacja odbierająca strumień dowodzi tylko, że dostarczanie gdzieś działa. Nie dowodzi, że niezainteresowanym klientom oszczędzono pasma.

Trzy pytania w jednym twierdzeniu o funkcji

Członkostwo w grupie pyta, czy odbiorca dołączył do grupy. Dostarczanie przez tunel pyta, czy pakiet w ogóle przeszedł przez tunel. Polityka replikacji pyta, ile kopii serwer utworzył i komu. Oświadczenie dostawcy może być prawdziwe w pierwszym przypadku i milczeć o trzecim, a właśnie tam mieszka koszt.

Trzymaj je osobno, gdy określasz rozmiar łącza. Tylko trzecie pytanie ustala budżet wychodzący po stronie serwera.

Co serwer w przestrzeni użytkownika robi z pakietem grupowym

W tradycyjnym serwerze w przestrzeni użytkownika OpenVPN 2.6 przychodzący pakiet broadcast lub multicast jest klasyfikowany na ścieżce wejściowej TUN/TAP i przekazywany do procedury rozsyłania broadcast zamiast do wyszukiwania według grupy. Ta procedura przechodzi przez instancje klientów, pomija nadawcę i każdą zatrzymaną instancję, stosuje kontrolę VLAN tam, gdzie jest skonfigurowana, i umieszcza kopię w kolejce dla każdego pozostałego klienta. Żaden krok tej pętli nie zagląda do tabeli członkostwa. To replikacja w stylu broadcast, i to jest cały mechanizm.

Traktuj to jako właściwość tej ścieżki kodu, a nie uniwersalne prawo. Przyspieszone ścieżki danych, inne implementacje i różne wersje mogą zachowywać się inaczej, i nic z tego nie czyni TAP wymogiem ani naprawą.

Zaplanuj kopie, zanim cokolwiek zmierzysz

Weź szybkość ładunku i pomnóż ją przez liczbę kwalifikujących się klientów. Strumień wysyłający jeden megabit na sekundę do dwudziestu klientów wytwarza dwadzieścia megabitów na sekundę ładunku opuszczającego serwer, przed enkapsulacją, retransmisją i jakimkolwiek narzutem na klienta. Ta arytmetyka to budżet, a nie pomiar twojego wdrożenia.

ip -s link show tun0

Odczytaj licznik wysłanych bajtów przed i po stałym interwale z jednym znanym aktywnym nadawcą. Podziel przez interwał i porównaj z szybkością ładunku pomnożoną przez liczbę klientów. Liczba bliska szybkości pojedynczego strumienia oznacza, że replikacja jest ograniczona; liczba bliska szybkości pomnożonej oznacza, że każdy klient otrzymuje kopię.

Licznik obejmuje też własny ruch tunelu, więc trzymaj okno testu krótko, a host poza tym cicho. Precyzja mniej się liczy niż rząd wielkości, i to wszystko, czego potrzebujesz, by odróżnić jedną kopię od dwudziestu.

Test z dwoma klientami, który rozstrzyga kwestię zasięgu

Podłącz jednego klienta, który powinien odbierać strumień, i drugiego, który nie powinien. Uruchom nadawcę, a potem obserwuj liczniki tunelu drugiego klienta przez ten sam interwał. Wzrost u drugiego klienta jest bezpośrednim dowodem szerokiej replikacji, cokolwiek mówiła lista funkcji.

Filtruj przechwytywanie na adres grupy, aby nie czytać niepowiązanego ruchu, i ogranicz je do interfejsu tunelu. Przechwytywanie interfejsu fizycznego na zajętym hoście tworzy plik, którego nikt nie potrafi zinterpretować, i może zachować dane użytkowników, których nie zamierzałeś zbierać.

Następnie zamień role. Jeśli wynik podąża za odbiorcą, a nie za grupą, patrzysz na coś świadomego członkostwa, a wcześniejsze założenie było błędne na twoją korzyść.

Wybór ograniczonego projektu zamiast usuwania limitów

Gdy rozsyłanie jest zbyt szerokie, poprawką jest obsługiwany ograniczony układ dystrybucji, a nie usuwanie wszystkich posiadanych zabezpieczeń. Opcje obejmują przybliżenie punktu dystrybucji do odbiorców, użycie modelu subskrypcji specyficznego dla źródła, który niesie tożsamość źródła wraz z grupą, lub podział strumienia tak, aby niezainteresowane lokalizacje nigdy nie stały na tej samej granicy dystrybucji.

Trzymaj tożsamość źródła i grupy osobno od nagiego faktu, że cel jest multicast. Odbiorca, który rozpoznaje grupę, ale nie źródło, jest innym subskrybentem niż ten, który poprosił o konkretny kanał. Mieszanie obu sprawia, że późniejsze planowanie przepustowości staje się zgadywaniem.

Model kanału multicast specyficznego dla źródła jest odniesieniem dla tego rozróżnienia. Jakikolwiek projekt wybierzesz, zapisz zbiór kwalifikujących się partnerów, właściciela replikacji i licznik, który odczytasz następnym razem; ten zapis zamienia niespodziankę pasmową w znany koszt.