Чому multicast не проходить через VPN без плану

Два сайти можуть ідеально діставати один одного через unicast і все ж поводитися так, ніби один із них не бачить оголошення виявлення принтера, потік IPTV або пульс кластера. Це не зламаний тунель; це різниця між адресатом і групою. Доставка multicast потребує моделі членства, стану пересилання вздовж шляху та інтерфейсу, готового нести трафік, і ніщо з цього не береться з unicast-маршруту. Пройти від групи застосунку до одного працездатного отримувача — найкоротший шлях до відповіді.

Почніть із групи та застосунку

Запитайте, яку адресу групи використовує застосунок і для чого потрібен трафік. Протокол виявлення, що оголошує служби, потоковий канал і пакети вітання протоколу маршрутизації — це три різні задачі з трьома різними прийнятними відповідями. Сама адреса групи говорить про область: адреси в блоці керування локальної мережі не призначені для пересилання за межі каналу звичайною маршрутизацією, а застосунки, які їх використовують, зазвичай припускають один широкомовний домен. Потоковий канал на групі з глобальною областю — це інший проєкт, ніж протокол виявлення, який чекає, що кожен пристрій почує кожен запит, і лише другому важливий розмір широкомовного домену.

Вирішіть, чи потрібна служба, чи механізм виявлення, бо ці відповіді різняться за вартістю на порядок. Одна просить адресу, що не змінюється; інша просить широкомовний домен, розтягнутий через канал глобальної мережі з усім, що з цього випливає.

Локальне виявлення має зупинитися

Multicast DNS, описаний у RFC 6762, побудований навколо одного каналу: запити йдуть до фіксованої групи, відповіді надсилаються до тієї самої групи, і протокол покладається на те, що кожен учасник чує всіх. Маршрутизатори не пересилають такий трафік типово, і це проєктне рішення, а не недогляд. Межа існує для того, щоб пристрій в одній будівлі не міг просто так оголосити себе в іншій. Тунель, який нібито виправляє виявлення, переносячи групу всюди, зняв цю межу для кожного застосунку, а не лише для того, якому потрібна була допомога.

Повторювачі та відбивачі існують, і це справжні служби зі справжніми наслідками: кожне ім'я, оголошене на одному сайті, стає видимим на іншому, зокрема імена пристроїв, що ідентифікують людей або обладнання. Якщо справжня вимога полягає в тому, щоб певну службу можна було знайти, запис служби, опублікований у DNS, зазвичай є меншою зміною, і він розкриває одне ім'я замість їхнього потоку.

Три речі, потрібні маршрутизованому multicast

Маршрутизованому multicast потрібні три речі, що працюють разом: отримувачі, які приєднуються до групи, маршрутизатори, які підтримують для неї стан пересилання, і тунель, який ставиться до адрес групи як до трафіку, що його треба нести. Тунель із політикою, де перелічено лише unicast-підмережі, відкине трафік групи на межі шифрування, і саме тому першим симптомом часто буває тиша, а не помилка. Інтерфейс на основі маршрутів, наприклад тунель GRE або VTI, несе те, що в нього надсилає таблиця маршрутизації, і це робить групу досяжною, щойно стан multicast існує.

Досяжність джерела — друга половина. Протоколи маршрутизації multicast, такі як PIM, будують дерева розподілу, перевіряючи, що зворотний шлях до джерела є очікуваним, тому unicast-маршрут, що вказує в інше місце, ламає дерево навіть за правильного членства в групі. Встановлення маршруту для отримувача нічого не дає цій перевірці, і це та помилка, яка дає робочий ping і потік, що падає. Спершу перевірте зворотний шлях джерела, потім додайте членство і лише після цього дивіться на застосунок.

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

Перші два рядки показують, до чого приєднався хост і що пересилає ядро, третій показує членство самого застосунку, а останній — unicast-шлях, який використає перевірка зворотного шляху. Спільне читання відрізняє застосунок, що ніколи не приєднувався, від мережі, що ніколи не пересилала.

Доведіть це одним джерелом і одним отримувачем

Перш ніж торкатися конфігурації, переконайтеся, що застосунок працює в одному сегменті. Якщо він збоїть локально, маршрутизація multicast ні до чого і жодна зміна тунелю не допоможе. Потім повторіть з одним отримувачем через тунель і поспостерігайте за пакетами з обох боків межі шифрування.

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

Пакети, видимі всередині тунелю, але відсутні зовні, вказують на інкапсуляцію або політику; пакети, видимі з обох боків без поступу застосунку, вказують на членство отримувача або прив'язку застосунку. Тримайте записи короткими й відфільтрованими, бо широкий захват multicast на завантаженому сегменті — це здебільшого шум.

Обирайте адресу служби, коли потрібна лише служба

Виявлення існує, щоб знайти те, що рухається. Серверу зі стабільним ім'ям виявлення не потрібне, а задокументована адреса в приватному DNS відповідає на справжнє питання користувача, не розтягуючи широкомовний домен через канал глобальної мережі. Ті самі міркування стосуються принтерів, побутових приладів і внутрішніх вебслужб. Ім'я в DNS доступне з кожного сайту, якому воно потрібне, нічого не оголошуючи сайтам, яким воно не потрібне, і воно далі працює, коли пристрій замінюють іншим з іншою адресою.

Коли протокол справді вимагає multicast, обмежте його групою та сайтами, яким він потрібен, задокументуйте чому і перегляньте рішення, коли застосунок зміниться. Розтягнути виявлення всюди легко один раз і важко скасувати після року пристроїв, які тихо від нього залежать.