SSM через OpenVPN: простежити одне джерело й групу від початку до кінця

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

Спершу зафіксуйте джерело, групу й отримувача

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

Діапазон 232/8 зарезервований для multicast, специфічного для джерела, а модель описано в RFC 4607. Якщо ваша група лежить поза цим діапазоном, а ви вважаєте, що запускаєте SSM, зупиніться й підтвердьте, що насправді має на увазі розгортання, бо приєднання отримувача й рішення маршрутизатора про пересилання обидва залежать від узгодженості моделі.

Перевірте, що отримувач приєднався до джерела

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

На отримувачі Linux перевірте, на що сокет справді підписався і що записало ядро. Файл конфігурації застосунку не є доказом; доказом є таблиця членства. Читайте її, поки отримувач справді працює, бо запис може затриматися ненадовго після виходу процесу, що його створив. Застарілий запис із попереднього тесту — надійне джерело хибної впевненості.

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

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

Перевірте зворотний шлях, перш ніж дивитися на тунель

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

На маршрутизаторі, повернутому до джерела, порівняйте маршрут до джерела з інтерфейсом, через який пакети справді приходять. На маршрутизаторі, повернутому до отримувача, зробіть те саме для власної підмережі отримувача й підтвердьте, що список вихідних інтерфейсів містить канал до неї. Розбіжність у будь-якому напрямку — це відмова RPF, а не відмова членства.

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

Читайте стан multicast у ядрі, а не конфігурацію

Конфігурація каже вам, що ви запросили; ядро каже, що відбувається. На кожному переході Linux прочитайте записи маршрутизації multicast і підтвердьте, що для точної пари джерела й групи існує список вхідних і вихідних інтерфейсів. Запис для групи з універсальним джерелом — це інший об’єкт, і він не пояснить потік, специфічний для джерела.

ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10

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

Коли ці двоє не збігаються, виправляйте хост, а не VPN. Ніщо нижче за потоком не компенсує перехід, який не пересилає потік, про який ви питали. Записуйте пару, вхідний інтерфейс і вихідний список для кожного переходу, поки потік працює. Цей запис перетворює наступну відмову на порівняння, а не на нове розслідування.

Вирішіть, як тунель насправді реплікує

Тут multicast через VPN перестає бути рутиною. Тунель «точка-точка» доставляє пакет єдиному партнеру на іншому кінці, тож копія доходить рівно до одного клієнта. Сегмент, з’єднаний мостом, поводиться радше як спільний канал, бо тунель несе кадр, а міст вирішує, що затоплювати. Це різні моделі доставки, і дизайн, який припускає другу, працюючи за першою, виглядатиме робочим для одного отримувача й відмовить для наступного.

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

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