четверг, 6 августа 2015 г.

Mikrotik VRF, PBR, или как обеспечить удаленный доступ при совпадении подсетей.


Итак, есть задача, обеспечить доступ в 1с через VPN в удаленном филиале.
 
Задача привычная, плевая, настроил Mikrotik 951, поставил, profit!
Но появилась первая проблема после приезда в филиал - у нас совпадают подсети.
Получается такая картина:
Филиал - 192.168.8.0/24, Наш сервер терминалов 1с - 192.168.8.1

С этим я уже сталкивался, решается просто, создаем иллюзию того, что обращаться надо на хост другой подсети, например 192.168.9.1. (Разумеется по возможности мы стараемся привести в порядок сети, но не всегда это возможно сделать быстро и без потерь. Плюс политические моменты.)
Следовательно обычный dst-nat.
И вот тут то и вылезла новая проблема, уж я никак не ожидал, что где то в забытом богом месте, на заводе будет целая инфраструктура на ОС Windows.
Куча виртуалок на HYPER-V, SCVMM, DFS и тому подобное.

В частности шлюз TMG Forefront. А о нем я слышал только от коллег и в основном нецензурную брань, и это люди с сертификатами от Microsoft...
Оказалось, чтобы прописать маршрут на нем необходимо ему обеспечить ICMP доступность хоста. 
Не привычно, но ладно.
Плюс к этому, адрес у него оказался 192.168.8.1, прямо как у нашего терминального сервера, надо вешать PBR(Police Based Routing) иначе трафик будет бегать петлей обратно в локалку филиала.

И вот тут то потенциал железки за какие то 3-4 т.р показал себя в полную мощь!
VRF(Virtual Routing Forwarding) и PBR наше все! Вопрос решился довольно просто, я добавил pptp интерфейс в VRF, назовем ее vpn-vrf, туда же зарулил все маршруты пришедшие по OSPF.
Повесил правила в mangle, с целью вешать в prerouting'е routing-mark vpn-vrf на пакеты их локальной сети, а ответные пакеты заруливать в main routing table.

Таким образом пакет из их локальной сети сначала перемещался в vpn-vrf, потом отрабатывал dst-nat и вуаля, пакет убегает предварительно обработанный src-nat(mascarading) в туннель.
Обратно пакет от нашего терминально сервера добегает до микротика, отрабатывает src-nat(mascarading), далее еще один src-nat с целью подменить реальный адрес нашей терминалки на вымышленный, для корректной маршрутизации, и до хоста.

Все проблемы я отлавливал Wiresharkом, благо в mikrotik можно очень быстро настроить packet-sniffer и направить выхлоп на нужный хост.
Надо признаться что это была более менее интересная задача за последнее время.
И я в очередной раз понял насколько сильно люблю Микротики. Такой функционал, за такие смешные деньги!

среда, 27 мая 2015 г.

Проброс 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 мс для открытия странички =)
Если кого интересуют подробности, пишите, помогу с настройкой, поделюсь конфигами.