История одной диагностики, которая затянулась, но закончилась хеппи-эндом

Если у вас MikroTik, два провайдера, настроена балансировка (PCC), вы включили DNS-over-HTTPS (DoH) для безопасности, а IPTV на Android-приставке работает с перебоями или замирает при включении второго WAN канала — эта статья для вас.

Я прошёл этот путь от начала до конца и хочу поделиться готовым решением.

Исходные данные

1)      Роутер: MikroTik RB

2)      Провайдеры: BVV (основной, он же ether2_b) и TVV (wan_t)

3)      Балансировка: Настроена по схеме PCC (per connection classifier) для распределения трафика между двумя каналами

4)      Безопасность: Включён DoH (use-doh-server=https://...)

5)      Локальная сеть 192.168.144.ХХХ

6)      Адрес TV приставки 192.168.144.116

7)      У от BVV есть белый статический IP и gateway=91.31.31.41 routing-table=to_BVV_tv и он считается основным источником IP TV, хотя при перенастройки IGMP Proxy на провайдера TVV телевидение тоже работает.

 

Проблема: IPTV на Android-приставке работало стабильно только при отключённом одном из провайдеров. При двух активных каналах видео начинало "замирать" через некоторое время после переключения каналов. В логах роутера при включении второго канала (в нашей логике это wan_t) появлялись ошибки:

DoH server connection error: while reading - Connection reset by peer

DoH server connection error: timeout waiting data

DoH server connection error: timeout waiting data [ignoring repeated messages]

 

 

Диагностика: что проверил (и что не помогло)

1. IGMP-прокси

Первым делом проверили настройки IGMP-прокси — ведь именно он отвечает за multicast-трафик IPTV.

 /routing igmp-proxy interface print

Убедились, что upstream (интерфейс, смотрящий на провайдера) только один — BVV. Всё верно, но проблему не решило.

 

2. Firewall

Проверили правила, разрешающие UDP и IGMP. Создали точное правило для multicast-трафика:

 /ip firewall filter add chain=forward action=accept dst-address=224.0.0.0/4 in-interface=ether2_b out-interface=bridge_lan protocol=udp comment="Allow IPTV multicast stream"

Поставили его повыше, но счётчики всё равно не росли — трафик шёл через общие UDP-правила. Это не критично, но симптом.

 

3. Fasttrack и connection tracking

Отключали fasttrack, добавляли notrack для multicast в таблице raw — не помогло.

 

4. Policy-based routing (PBR)

Пытался жёстко привязать IP-адрес приставки к каналу BVV, чтобы весь её трафик шёл только через одного провайдера.

/ip firewall mangle add chain=prerouting src-address=192.168.144.116 action=mark-routing new-routing-mark=to_BVV_tv

/ip route add gateway=91.31.31.41 routing-table=to_BVV_tv

 

Результат: приставка полностью теряла изображение. Оказалось, что она использует не только multicast, но и unicast-трафик (авторизация, EPG, список каналов), который, возможно, должен ходить через TVV.

 

5. Блокировка multicast с TVV

Пробовали отбрасывать весь multicast, приходящий с интерфейса TVV, на самом раннем этапе:

 

/ip firewall raw add chain=prerouting in-interface=wan_t dst-address=224.0.0.0/4 action=drop

Счётчик оставался нулевым — TVV и не слал multicast. Не помогло.

 

Ключевое наблюдение

Ошибки DoH в логах появлялись одновременно с включением второго WAN интерфейса и после, через некоторое время ТВ канал, который работал стабильно, начинал заикаться и отваливался или зависал. Тогда я решил отключить DoH и включить use-peer-dns=yes на DHCP интерфейсах провайдеров и IPTV заработало нормально даже с двумя активными каналами.

 Вывод: DoH «ломает» DNS для приставки. Приставка использует обычные (нешифрованные) DNS-запросы для получения служебной информации. Когда роутер пытается все DNS-запросы шифровать и отправлять на DoH-сервер, а тот по каким-то причинам сбрасывает соединение или не отвечает, приставка остаётся без DNS — и видео начинает «замирать».

 

Решение:

Выводим приставку из-под влияния DoH и отказываемся от приходящих DOH на DHCP для приставки!

MikroTik в DHCP умеет предоставлять в аренду другие DNS сервера, отличные от указанных в настройках DHCP.

"Грубо" адрес приставки должен выглядеть так:

IP-адрес: 192.168.144.116

Маска подсети: 255.255.255.0

DNS-серверы: 8.8.8.8 и 8.8.4.4 или DNS вашего провайдера

Вместо

IP-адрес: 192.168.144.116

Маска подсети: 255.255.255.0

DNS-серверы: 192.168.144.1 (адрес вашего роутера, который DHCP сервер и DNS)

 

Для этого нужно:

Шаг 1. Настраиваем приставку на получение адреса через DHCP сервер.

В настройках приставки в разделе Сети указываем DHCP. Больше в приставке мы ничего не трогаем и не меняем.

Шаг 2. Переводим динамическую запись на роутере в статическую

Чтобы зарезервировать этот адрес за MAC-адресом приставки и исключить его раздачу другим устройствам:

/ip dhcp-server lease add address=192.168.144.116 mac-address=00:00:00:00:00:00 comment="TV STB static"

Где:

add address=192.168.144.116 – адрес вашей приставки

mac-address=00:00:00:00:00:00 – mac адрес вашей приставки

Второй путь: воспользоваться интерфейсом WinBox.

В DHCP Server – Leases выбрать запись вашей приставки и нажать на кнопку Make Static. В разделе General в DHCP Lease прописать Comment "TV STB static".

 

Шаг 3. Создаем запись об не шифрованных DNS серверах

В процессе диагностики выяснилось, что многие ошибаются при создании DHCP-опции для нескольких DNS-серверов.

Важно: правильный синтаксис DHCP-опции с несколькими DNS:

/ip dhcp-server option add name="plain-dns" code=6 value="'8.8.8.8''8.8.4.4'"

Второй путь: воспользоваться интерфейсом WinBox.

Обратите внимание: два IP-адреса, каждый в своих одинарных кавычках, идущих подряд. Никаких запятых.

Шаг 4. Назначаем созданный пул DNS серверов

В настройках аренды IP адреса, в разделе DHCP Options указываем созданный нами план DNS серверов – plan-dns

Тут сразу идем вторым путем: воспользоваться интерфейсом WinBox.

Вместо 192.168.144.116 должен быть адрес приставки, вместо 00:00:00:00:00:00 mac адрес приставки. Эти данные появляются когда приставка получает аренду.
Вместо 192.168.144.116 должен быть адрес приставки, вместо 00:00:00:00:00:00 mac адрес приставки. Эти данные появляются когда приставка получает аренду.

 

Приставка больше не получает DNS от роутера DHCP.

Её DNS-запросы идут напрямую на указанные вручную серверы, минуя DoH-резолвер.

DoH на роутере продолжает работать для всех остальных клиентов, которые получают настройки по DHCP.

Статическая запись на роутере гарантирует, что выбранный IP не будет выдан другому устройству.

IGMP Proxy настроен работать на одном WAN канале (у меня на BVV) и правила для протоколов IGMP и UDP в Firewall прописаны для двух WAN каналов (BVV и TVV).

 

Инструменты для диагностики на Android

Чтобы быстро проверить, какие настройки получило устройство, рекомендую поставить одно из этих приложений:

Fing — показывает все устройства в сети, их IP и DNS.

IP Tools: WiFi Analyzer — мощный комбайн с ping, traceroute, whois.

WiFi Tools: Network Scanner — удобно показывает DNS и внешний IP.

 

Итог

Проблема оказалась не в балансировке, не в IGMP-прокси и не в firewall, а в конфликте DoH с обычными DNS-запросами приставки.

Решение — полный вывод приставки из-под влияния DoH через настройку перевод аренды в статику IP и ручного назнач��ния DNS не из настроек DHCP. При этом DoH остаётся включённым для всех остальных устройств, и балансировка между провайдерами продолжает работать.

 

Никаких сложных VLAN, никаких танцев с бубном вокруг policy routing. Просто, надёжно и стабильно.

 

Если вы столкнулись с похожей ситуацией — попробуйте этот метод. Он сэкономит вам часы диагностики и метры логов.