Хреновые провайдеры или 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 отключил. Все работает. Все счастливы.

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 и направить выхлоп на нужный хост.

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