Хреновые провайдеры или MikroTik спасет мир

По долгу службы постоянно приходится налаживать связь в самых отдаленных уголках РФ. Чаще всего на севере страны. И почти постоянно сталкиваюсь с полной безграмотностью местных интернет провайдеров в отношении услуг, что они предоставляют.

Чаще всего доступ дают через VPN, но не редки случаи, когда доступ предоставляется тупо через серую подсеть...То есть вам по DHCP выдают некий серый адрес, и далее вас NATят.
Про предоставление объединений я вообще молчу...Для некоторых L3VPN, VRF, или на худой конец VLAN - это что-то инопланетное.
Но в прочем статья не об этом. Не так давно столкнулся с интересной ситуацией. У меня на каждом объекте стоит микротик, который поднимает туннель до головного офиса и проблем, как правило не возникает. Не так давно с одного из объектов начали жаловаться. Мол беда беда, интернет есть, сервисы организации не работают. Начинаю смотреть, пинги бегают внутри туннеля без потерь, задержки вполне себе хорошие, порядка 80 мс. Но при попытке открыть корпоративный портал или иной сервис действительно вижу затык...Подсказал мне браузер, при открытии страницы нашего сервиса, он мгновенно прогрузил заголовки, я увидел <title> страницы. А вот содержимого нет...И тут меня озарило, конечно же MTU. Дабы не ломать туннель путем изменения MTU, я решил пойти другим путем - а именно поправить MSS налету. В современных прошивках MSS сразу выставляется под MTU интерфейса. Но мы то не пролезаем, в связи с чем я добавил новые правила:

/ip firewall mangle add chain=forward protocol=tcp tcp-flags=syn tcp-mss=1361-65535 action=change-mss new-mss=1360 disabled=no out-interface=my-tunnel-ppp

/ip firewall mangle add chain=forward protocol=tcp tcp-flags=syn tcp-mss=1361-65535 action=change-mss new-mss=1360 disabled=no in-interface=my-tunnel-ppp

Таким образом я зажимаю все данные (кроме заголовков) TCP пакетов в 1360 байт. Почему именно это значение? Опытным путем, понижал с 1390 до данного значения, пока не стабилизировалась работа. И это решило проблему. Убедившись, что странички наших сервисов и приложения стали работать корректно, я понизил MTU на туннельном интерфейсе, он переподнялся, и правила MSS отключил. Все работает. Все счастливы.

Проброс DLNA в удаленную сеть

Предистория:

Итак, появилась необходимость дать возможность просматривать фильмы с моего сервера на телевизоре. Ну казалось бы, поднимаем DLNA, например miniDLNA и проблема решена. Так и было, пока не появилась нужда дать такую же возможность родителям, которые живут в другом месте, и ставить им там сервер или простенький nas не совсем правильный путь. Было принято решение объединить наши сети путем туннелирования траффика и дать доступ к моей фильмотеке.

Подготовка:

У родителей я уже давно поставил отличный роутер, с которым я давно работаю, и доверяю - Mikrotik 951Ui 12HnD. Кто не знаком с этим великолепным маршрутизатором, советую познакомиться. Ценовая политика позволяет подобрать решения как  для дома, так и для офиса. При этом получаем функционал, как у дорогих enterprise решений.

У меня в квартире так же стоял Mikrotik, лишь с одним отличием, у меня были все порты гигабитные. Я не долго думая поднял pptp туннель и тут началось...

Первые проблемы:

В отличии от классического способа передачи потокового аудио и видео сегмента данных DLNA несколько отличается. И это сразу стало понятно, после того как я посниффил траффик. Через PPTP некоторые запросы пробегали, некоторые нет. После того как я изучил дамп траффика, пришел к следующим выводам:

1. Со стороны сервера мы должны увеличить ttl траффика от DLNA сервера, я увеличил на 100.
2. Установить пакет multicast на микротики, и включить PIM на интерфейсы туннеля.
3. Не забываем прописать маршруты до локальных сетей за туннелями.
4. Со стороны сервера DLNA прописываем маршрут 239.255.255.250 в качестве шлюза указываем туннельный интерфейс.

Казалось бы, все предусмотрел, я на телевизоре родителей увидел свой DLNA сервер, подключился к нему, открыл фильм, и тут я успел увидеть 2 кадра и все. Он просто отключился от сервера. Я начал заново, пробежался по всей конфигурации на обоих маршрутизаторах, грешил на фаервол, на все. Потом опять взглянул на дамп траффика и увидел то самое.."don't fragment". И тут меня осенило! Размер пакета превышает MTU, который нам предоставляет PPTP, а фрагментировать нельзя! К сожалению в настройках miniDLNA сервера я не смог найти возможность ограничить длину пакета.

Победное решение:

В итоге самый простой IP-IP туннель, но сталкиваемся с проблемой динамической адресации от провайдера, если у вас на обоих концах статика, вам повезло!

Еще можно попробовать ограничить mtu на интерфейсе, к которому подключен NAS. В таком случае пакеты будут заведомо с небольшим MTU, который пролезет в любой туннель.

Дополнение:

Не стоит забывать что просмотр фильмов - это нехилая нагрузка на сеть в плане ширины канала. Когда в пределах локальной сети, не страшно, а вот между сетями, когда ширину канала контролирует провайдер...В общем всем советую включить QoS, отдать приоритет своему серверу, и любым подключениям к нему, а мы можем и подождать дополнительных 10 мс для открытия странички =)

Если кого интересуют подробности, пишите, помогу с настройкой, поделюсь конфигами.