Проброс DLNA в удаленную сеть
Итак, появилась необходимость дать возможность просматривать фильмы с моего сервера на телевизоре. Ну казалось бы, поднимаем DLNA, например miniDLNA и проблема решена. Так и было, пока не появилась нужда дать такую же возможность родителям, которые живут в другом месте, и ставить им там сервер или простенький nas не хотелось. Было принято решение объединить наши сети путем туннелирования трафика и дать доступ к моей фильмотеке.
Подготовка:
У родителей я уже давно поставил отличный роутер, с которым я давно работаю и доверяю — Mikrotik 951Ui 12HnD. Кто не знаком с этим великолепным маршрутизатором, советую познакомиться. Ценовая политика позволяет подобрать решения как для дома, так и для офиса. При этом получаем функционал, как у дорогих enterprise решений.
У меня в квартире так же стоял Mikrotik, лишь с одним отличием, у меня были все порты гигабитные. Я не долго думая поднял pptp туннель и тут началось…
Первые проблемы:
В отличии от классического способа передачи потокового аудио и видео сегмента данных DLNA несколько отличается. И это сразу стало понятно, после того как я посниффил трафик.
1. Все общение между медиа сервером и телевизором происходит по протоколу HTTP
2. Телевизор делает мультикаст рассылку SSDP пакетов на адрес 239.255.255.255.250, в которой регистрирует себя как сервис перед лицом медиа серверов.
3. DLNA сервера при виде нового сервиса начинают обращаться к телевизору напрямую, после пары пакетов отправляет свою информацию внутри.
root xmlns="urn:schemas-upnp-org:device-1-0" xmlns:dlna="urn:schemas-dlna-org:device-1-0" xmlns:sec="https://www.sec.co.kr/dlna"> specVersion> major>1 major> minor>0 minor> specVersion> device> dlna:X_DLNADOC xmlns:dlna="urn:schemas-dlna-org:device-1-0">DMS-1.50 dlna:X_DLNADOC> dlna:X_DLNADOC xmlns:dlna="urn:schemas-dlna-org:device-1-0">M-DMS-1.50 dlna:X_DLNADOC> dlna:X_DLNACAP xmlns:dlna="urn:schemas-dlna-org:device-1-0">av-upload,image-upload,audio-upload dlna:X_DLNACAP> sec:ProductCap>smi,DCM10,getMediaInfo.sec,getCaptionInfo.sec sec:ProductCap> sec:X_ProductCap>smi,DCM10,getMediaInfo.sec,getCaptionInfo.sec sec:X_ProductCap> deviceType>urn:schemas-upnp-org:device:MediaServer:1 deviceType> friendlyName>[PC]DESKTOP-SBP6BH3 friendlyName> manufacturer>Samsung Electronics manufacturer> manufacturerURL>https://www.samsung.com/sec manufacturerURL> modelDescription>Samsung PC DMS modelDescription> modelName>PC modelName> modelNumber>AllShare1.0 modelNumber> modelURL>https://www.samsung.com/sec modelURL> UDN>uuid:0d1cef00-0032-1000-8823-f46d043e5ae2 UDN> sec:deviceID>H3CJEO6BEFKMU sec:deviceID> iconList> icon> mimetype>image/jpeg mimetype> width>48 width> height>48 height> depth>24 depth> url>/smp_2_ url> icon> icon> mimetype>image/jpeg mimetype> width>120 width> height>120 height> depth>24 depth> url>/smp_3_ url> icon> icon> mimetype>image/png mimetype> width>120 width> height>120 height> depth>24 depth> url>/smp_4_ url> icon> icon> mimetype>image/png mimetype> width>48 width> height>48 height> depth>24 depth> url>/smp_5_ url> icon> iconList> serviceList> service> serviceType>urn:schemas-upnp-org:service:ConnectionManager:1 serviceType> serviceId>urn:upnp-org:serviceId:ConnectionManager serviceId> SCPDURL>/smp_7_ SCPDURL> controlURL>/smp_8_ controlURL> eventSubURL>/smp_9_ eventSubURL> service> service> serviceType>urn:schemas-upnp-org:service:ContentDirectory:1 serviceType> serviceId>urn:upnp-org:serviceId:ContentDirectory serviceId> SCPDURL>/smp_10_ SCPDURL> controlURL>/smp_11_ controlURL> eventSubURL>/smp_12_ eventSubURL> service> serviceList> device> root>
4. После того, как вы выбрали медиа файл, который хотите прослушать\посмотреть начинается обмен по TCP, как я понимаю телевизор начинает кешировать медиа файл.
Через PPTP некоторые из этих запросов пробегали, некоторые нет. После того как я изучил дамп трафика, пришел к следующим выводам:
- Со стороны сервера мы должны увеличить ttl трафика от DLNA сервера, ибо по умолчанию ttl=1. (Это необходимо только для SSDP трафика)
- Установить пакет multicast на микротики, и включить PIM на интерфейсы туннеля.
- Не забываем прописать маршруты до локальных сетей за туннелями.
- Со стороны сервера DLNA прописываем маршрут 239.255.255.250 в качестве шлюза указываем туннельный интерфейс.
Казалось бы, все предусмотрел, я на телевизоре родителей увидел свой DLNA сервер, подключился к нему, открыл фильм, и тут я успел увидеть 2 кадра и все. Он просто отключился от сервера. Я начал заново, пробежался по всей конфигурации на обоих маршрутизаторах, грешил на фаервол. Потом опять взглянул на дамп трафика и увидел то самое.
don’t fragment
И тут меня осенило! Размер пакета превышает MTU, который нам предоставляет PPTP, а фрагментировать нельзя! К сожалению в настройках miniDLNA сервера я не смог найти возможность ограничить длину пакета.
Победное решение:
В итоге самый простой IP-IP туннель предоставляет нам нужный MTU, MRU, и MSS, но сталкиваемся с проблемой динамической адресации от провайдера, если у вас на обоих концах статика, вам повезло!
Еще можно попробовать ограничить mtu на интерфейсе, к которому подключен NAS. В таком случае пакеты будут заведомо с небольшим MTU, который пролезет в любой туннель, но это может существенно нагрузить CPU
Дополнение:
Не стоит забывать что просмотр фильмов — это нехилая нагрузка на сеть в плане ширины канала. Когда в пределах локальной сети, не страшно, а вот между сетями, когда ширину канала контролирует провайдер… В общем всем советую включить QoS, отдать приоритет своему серверу, и любым подключениям к нему, а мы можем и подождать дополнительных 30 мс для открытия странички.
Проброс DLNA в удаленную сеть
Итак, появилась необходимость дать возможность просматривать фильмы с моего сервера на телевизоре. Ну казалось бы, поднимаем DLNA, например miniDLNA и проблема решена. Так и было, пока не появилась нужда дать такую же возможность родителям, которые живут в другом месте, и ставить им там сервер или простенький nas не хотелось. Было принято решение объединить наши сети путем туннелирования трафика и дать доступ к моей фильмотеке.
Подготовка:
У родителей я уже давно поставил отличный роутер, с которым я давно работаю и доверяю — Mikrotik 951Ui 12HnD. Кто не знаком с этим великолепным маршрутизатором, советую познакомиться. Ценовая политика позволяет подобрать решения как для дома, так и для офиса. При этом получаем функционал, как у дорогих enterprise решений.
У меня в квартире так же стоял Mikrotik, лишь с одним отличием, у меня были все порты гигабитные. Я не долго думая поднял pptp туннель и тут началось…
В отличии от классического способа передачи потокового аудио и видео сегмента данных DLNA несколько отличается. И это сразу стало понятно, после того как я посниффил трафик.
- Все общение между медиа сервером и телевизором происходит по протоколу HTTP
- Телевизор делает мультикаст рассылку SSDP пакетов на адрес 239.255.255.255.250, в которой регистрирует себя как сервис перед лицом медиа серверов.
- DLNA сервера при виде нового сервиса начинают обращаться к телевизору напрямую, после пары пакетов отправляет свою информацию внутри
1 0 DMS-1.50 M-DMS-1.50 av-upload,image-upload,audio-upload smi,DCM10,getMediaInfo.sec,getCaptionInfo.sec smi,DCM10,getMediaInfo.sec,getCaptionInfo.sec urn:schemas-upnp-org:device:MediaServer:1 [PC]DESKTOP-SBP6BH3 Samsung Electronics http://www.samsung.com/sec Samsung PC DMS PC AllShare1.0 http://www.samsung.com/sec uuid:0d1cef00-0032-1000-8823-f46d043e5ae2 H3CJEO6BEFKMU image/jpeg 48 48 24 /smp_2_ image/jpeg 120 120 24 /smp_3_ image/png 120 120 24 /smp_4_ image/png 48 48 24 /smp_5_ urn:schemas-upnp-org:service:ConnectionManager:1 urn:upnp-org:serviceId:ConnectionManager /smp_7_ /smp_8_ /smp_9_ urn:schemas-upnp-org:service:ContentDirectory:1 urn:upnp-org:serviceId:ContentDirectory /smp_10_ /smp_11_ /smp_12_ 
Через PPTP некоторые из этих запросов пробегали, некоторые нет. После того как я изучил дамп трафика, пришел к следующим выводам:
- Со стороны сервера мы должны увеличить ttl трафика от DLNA сервера, ибо по умолчанию ttl=1. (Это необходимо только для SSDP трафика)
- Установить пакет multicast на микротики, и включить PIM на интерфейсы туннеля.
- Не забываем прописать маршруты до локальных сетей за туннелями.
- Со стороны сервера DLNA прописываем маршрут 239.255.255.250 в качестве шлюза указываем туннельный интерфейс.
И тут меня осенило! Размер пакета превышает MTU, который нам предоставляет PPTP, а фрагментировать нельзя! К сожалению в настройках miniDLNA сервера я не смог найти возможность ограничить длину пакета.
В итоге самый простой IP-IP туннель предоставляет нам нужный MTU, MRU, и MSS, но сталкиваемся с проблемой динамической адресации от провайдера, если у вас на обоих концах статика, вам повезло!
Еще можно попробовать ограничить mtu на интерфейсе, к которому подключен NAS. В таком случае пакеты будут заведомо с небольшим MTU, который пролезет в любой туннель, но это может существенно нагрузить CPU.
Не стоит забывать что просмотр фильмов — это нехилая нагрузка на сеть в плане ширины канала. Когда в пределах локальной сети, не страшно, а вот между сетями, когда ширину канала контролирует провайдер… В общем всем советую включить QoS, отдать приоритет своему серверу, и любым подключениям к нему, а мы можем и подождать дополнительных 30 мс для открытия странички.
Если будут пожелания, опишу детально как настраивать Mikrotik.
Уважаемые! Если вы минусуете статью, пожалуйста, напишите в комментариях почему, и я улучшу ее!
Буду рад критике и замечаниям!
DLNA на Mikrotik, разные подсети
Пару дней потратил на поиски информации — как настроить два и более mikrotik устройств так, чтобы работающий сервер DLNA, вещал в разные подсети свой контент.
На одном из форумов нашел дельное предложение (как мне кажется). Сразу оговорка, не претендую на самую правильную схему работы данным методом. Себе настроил, работает. Решил поделиться.
Итак, есть у меня mikrotik с сетью 192.168.10.0/24, где крутится DLNA сервер, на котором храню скромную коллекцию фильмов (около 400шт и пополняю). В рамках своей подсети 10.0/24 просмотр фильмов происходит успешно.
Не так давно, коллега, узнав, что у меня есть сервер с фильмами, попросил доступ. Я не был против. И, мы замутили сетку на двух mikrotik через EoIP с одной подсетью 10.0/24. Настроили пулы адресов на каждой стороне (выделили по 50 ip для каждого). Всё работало отлично.
Спустя некоторое время, сетка расширилась, присоединились родственники, еще коллеги с работы, и, ip адресов стало как то не хватать. Начал гуглить, искать как вещать в разные подсети DLNA трафик, нашел несколько статей, включая на Хабр, но без конкретных инструкций. Путем проб и ошибок, пришел к следующему методу: на всех mikrotik для бриджа выставил сеть с маской /16, DHCP на каждом mikrotik раздает свою подсеть с маской /16. При этом блокируем «регистрацию» устройств на «чужих» dhcp серверах. Соединяем все mikrotik по принципу сервер-клиент, где сервер это mikrotik с dlna по EoIP.
После настройки по данному способу, на всех подсетях, вещается dlna, результатом доволен. На счёт производительности и всего остального не заморачивался, ибо за несколько дней пользования не обнаружил ни каких подвохов.
1. Настроил адресацию для bridge
2. Настроил DHCP сервер и пул адресов
Прошу сильно не пинать 🙂 Только начинаю разбираться в данном направлении.