MikroTik RB951G-2HnD: маршрут до локального шлюза unreachable, как исправить?

Question

[Dmitry]

Есть микротик(RB951G-2HnD, RouterOS 6.37.3, 192.168.42.1), получает интернет от БиЛайн по IPoE(DHCP, без дополнительных заморочек, default-route-distance=50), локалка 192.168.42.0/24.
Внутри локальной сети, по адресу 192.168.42.253 имеется pfSense, который работает динамическим пиром для подключения к удалённой сети(192.168.4.0/24) по IPSec(работает из-за НАТ-а).
С микротика 192.168.42.253 доступен(пингуется обычно и arp-пингом с br_lan).

Так как микротик работает "основным" роутером в сети(и шлюзом по-умолчанию для устройств в локальной сети), решил маршрут до удалённой сети прописать на нём.
В Windows всё просто: route add 192.168.4.0 mask 255.255.255.0 192.168.42.253. С компьютеров сети при локальном прописывании маршрута через pfSense связь с 192.168.4.0/24 работает.
Если судить по манам и морю статей, в микротике тоже всё просто, хоть из WinBox(IP => Routes), хоть из консоли: ip route add dst-address=192.168.4.0/24 gateway=192.168.42.253

Вот только почему-то маршрут получается unreachable, и соответственно не активный. В результате попытки пингования уходят на шлюз провайдера(дефолтовый маршрут для 0.0.0.0).
Пробовал включать проверку доступности шлюза(arp/ping), пофиг - gateway-status unreachable, и роутим вместо pfSens-а на шлюз провайдера...

Добавлял в начало правил файрвола:
add action=accept chain=forward
add action=accept chain=input
add action=accept chain=output

Шлюз не обнаруживается...
Активная таблица маршрутизации:
[user@RB951G-2HnD] > ip route print detail
Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit
0 ADS dst-address=0.0.0.0/0 gateway=95.27.136.1 gateway-status=95.27.136.1 reachable via WAN distance=50 scope=30 target-scope=10 vrf-interface=WAN
1 S dst-address=192.168.4.0/24 gateway=192.168.42.253 gateway-status=192.168.42.253 unreachable distance=1 scope=30 target-scope=10
2 A S dst-address=192.168.42.0/24 gateway=br_lan gateway-status=br_lan reachable distance=1 scope=30 target-scope=10
3 A S dst-address=192.168.44.0/24 gateway=br_lan gateway-status=br_lan reachable distance=1 scope=30 target-scope=10
4 ADC dst-address=95.27.136.0/21 pref-src=95.27.142.111 gateway=WAN gateway-status=WAN reachable distance=0 scope=10
5 ADC dst-address=255.255.255.0/32 pref-src=192.168.42.1 gateway=br_lan gateway-status=br_lan reachable distance=0 scope=10

Пробовал гуглить, но все разбираются с глобальными проблемами вроде роутинга между сегментами на разных портах, и балансировкой при нескольких провайдерах. Такого простого случая как "нужно задать шлюз внутри локалки" не нагуглил.
Так как на работающем в той же сети MikroTik mAP 2hnd(работает как точка доступа, настройки сети получает по DHCP + CapsMan, порты в свиче + мост на WiFi, никаких правил Firewall/NAT) маршрут нормально добавляется и работает, похоже что тут очередной неочевидный(для меня) нюанс микротика всплыл - почему хост с микротика доступен, но при выборе его шлюзом для статического маршрута он "недостижим"? Что препятствует нормальной работе маршрута на роутере, и как это побороть(отключить проверку доступности шлюза, например)?

P.S. Оба микротика настраивал вручную после полного сброса, на обоих устройствах RouterOS 6.37.3. Пока единственная идея, это сделать полный сброс роутера и настраивать всё с нуля, параллельно проверяя работоспособность маршрута(чтобы выяснить какая настройка его поломает), но заняться этим смогу только в выходные.
P.P.S. Полный конфиг в вопрос не влезает - pastebin.com/tj4rpeUX

_____________
Добавлено: ошибка крылась в неверной интерпретации мною интерфейса Winbox, и отсутствием проверки на этот счёт вводимых данных со стороны Winbox - роутер получил адрес с маской /32, и это мешало ему использовать адрес шлюза который не попадал в "подсеть" /32. Огромная благодарность Илье Демьянову(@turbidit) за помощь в локализации этой ошибки. @2016-12-05 20:52MSK

Comments

[Ilya Demyanov]

Зачем ты добавлял статический маршрут на 42-ю сетку, если она у тебя должна быть директ коннектед (ADC), т.к. на микртике есть адрес из этой сети ?

[Dmitry]

Если отключаю этот маршрут, то отваливается Winbox(по IP), только что ещё раз проверил(полезная кнопка Safe Mode :). В какой момент это правило появилось сказать затрудняюсь(экспериментировал много, железка для меня непривычная). Если я правильно понял, этот маршрут должен создаваться автоматом(динамически) на основании IP -> Addresses?

[Ilya Demyanov]

Д@BDI: вы с winbox находит в той же сети? да, правило динамическое - если вы задаете ip на интерфейс, например, 192.168.42.1/24, то должен появиться маршрут на 192.168.42.0/24 со статусом ADC (активный, динамический, подключенный).

Покажите ip address print.

[Dmitry]

Winbox в одной сети с микротиком, я в той 192.168.44.0(я на работе, микротик дома). Так что не летальные действия(которые не нарушат моё подключение к домашней сети) могу произвести сейчас, летальные - только вечером.
[user@RB951G-2HnD] > ip address print
Flags: X - disabled, I - invalid, D - dynamic
# ADDRESS NETWORK INTERFACE
0 10.103.42.1/32 255.255.255.0 br_lan
1 D 95.27.142.111/21 95.27.136.0 WAN

[Ilya Demyanov]

Dmitry: и где тут адрес из 42-ой сети?

[Dmitry]

Пардон, одну из реальных подсетей таки засветил(паранойя заставила максимально поменять сети в конфиге перед публикацией, а не только пароли) :(
В контексте описания проблемы правильно читать так:
[user@RB951G-2HnD] > ip address print
Flags: X - disabled, I - invalid, D - dynamic
# ADDRESS NETWORK INTERFACE
0 192.168.42.1/32 255.255.255.0 br_lan
1 D 95.27.142.111/21 95.27.136.0 WAN

[Ilya Demyanov]

Dmitry: Ну тогда странно. Проверь на всякий - последняя ли у тебя прошивка
> system routerboard print

[Ilya Demyanov]

Ilya Demyanov: и да, ты когда выводил ip route print detail - ты пробелом до конца списка долистал?

[Dmitry]

[user@RB951G-2HnD] > system routerboard print
routerboard: yes
model: 951G-2HnD
serial-number: ************
firmware-type: ar9344
factory-firmware: 3.22
current-firmware: 3.33
upgrade-firmware: 3.33

Распечатка маршрутов полная(подключаюсь через putty, после выполнения команды сразу возвращается в командную строку), все 6 маршрутов отображаемых в Winbox на месте.

[Ilya Demyanov]

Dmitry: Проглядел. У тебя маска 32я. Должна же быть 24я.

[Dmitry]

Невероятно, но факт.
Указывал в Winbox 192.168.42.1 в качестве адреса, 255.255.255.0 в качестве сети(сказалась многолетняя привычка к маскам, и микротик не ругался что я вместо адреса сети маску сети указал). Поменял в Winbox адрес на 192.168.42.1/24 - сеть стала 192.168.42.0, добавился автоматический маршрут на локалку(старый, добавленный вручную, безболезненно погасил), и правило маршрутизации стало видеть шлюз!
Огромное спасибо, вы спасли мой рассудок!

Answer 1

[Ilya Demyanov]

На вопрос ответил в комментариях - проблема была в маске подсети - 32-я.

В MikroTik маска задается через /XX после IP. Если ее не указать, то автоматом проставляется 32-я.
Через это не создался динамический маршрут connected на 24-ую подстеть, в которой был шлюз 253.

Answer 2

[Клёвый Админ]

У вас конфликтующее правило
dst-address=192.168.42.0/24 gateway=br_lan gateway-status=br_lan reachable distance=1 scope=30 target-scope=10
Непонятно зачем оно вообще нужно.

Или оно же на пастебин (убрать\выключить второе и третье)
/ip route
add distance=1 dst-address=192.168.4.0/24 gateway=192.168.42.253
add distance=1 dst-address=192.168.42.0/24 gateway=br_lan
add distance=1 dst-address=192.168.44.0/24 gateway=br_lan

Comments

[Dmitry]

Правило не то чтобы конфликтующее, просто оно должно было создаваться автоматически - как и произошло после того как я исправил ошибку в адресе роутера, на которую мне указал Ilya Demyanov в комментариях к вопросу. Третье правило нужно чтобы с самого роутера пинговались ресурсы 44-ой сети(подключается на микротике по IPSec). По крайней мере если это правило погасить, то хосты удалённой сети с роутера не доступны, хотя с компьютеров в сети микротика к удалённой сети доступ есть. Для меня это странно, но микротик мне вообще очень непревычен после продукции ZyXel, D-Link, Asus, Cisco - такое впечатление что многое из, что того на других роутерах делается автоматически(спрятано "под капотом"), в MikroTik нужно делать самому.

[Клёвый Админ]

Dmitry: в этом и проблема, эти правила вам не позволяют достичь нужных сетей. Отключите их. Проверьте, что на PFsense не заблокирован входящий пинг

[Dmitry]

Повторюсь. Доступ к pfSense из локалки никак не ограничен(изначально проблема на втором микротике, получающем настройки по DHCP, и хостах локалки, отсутствовала), трафик с микротика в локалку тоже не ограничен. После исправления адреса роутера, и появления динамического маршрута, дубль созданный мною вручную я отключил - всё заработало.
Т.о. ошибка крылась в неверной интерпретации мною интерфейса Winbox, и отсутствием проверки на этот счёт вводимых данных со стороны Winbox - роутер получил адрес с маской /32, и это мешало ему использовать адрес шлюза который не попадал в "подсеть" /32.

P.S. Отключение маршрута к 44-ой сети приводит к недоступности хостов 44-ой сети с микротика(но не из локалки в сети микротика) - т.е. отсутствие, а не наличие этого маршрута мешают достичь нужной сети(с микротика - не критично, но предпочитаю чтобы пинги с микротика так же ходили нормально).

[Клёвый Админ]

Dmitry: Вы можете повторять ещё и ещё, но маршруты в текущем их виде - это ошибка. Шлюзом для маршрута не может быть адрес интерфейса с множественным доступом (в данном случа это бридж, с ethernet в портах).
То что эта конкретная ошибка не влияла на изначальную проблему, не значит что так настраивать правильно. =)

[Клёвый Админ]

gateway=br_lan - так делать не верно.

[Dmitry]

В микротике я нуб, не буду спорить верно или не верно указывать шлюзом интерфейс. Тем не менее:
1. Именно такой маршрут создаёт сам микротик при правильном указании адреса, править динамические правила Winbox не позволяет.
2. wiki.mikrotik.com/index.php?title=Manual:IP/Route&... - в данном разделе я не вижу почему неверно указывать шлюзом интерфейс(множественного или не множественного доступа) вместо IP, может быть поясните почему можно указать несколько инерфейсов в качестве шлюза, но неправильно указывать в качестве шлюза "интерфейс с множественным доступом"? Если вы имеете в виду "routes with interface nexthops are not used for nexthop lookup", то подскажите чем это грозит в данном конкретном частном случае - маршрут до локальной сети роутера, и маршрут до удалённой сети, доступной через поднятой на самом роутере VPN подключение(или просто "так не принято"? )? Что именно не будет работать? В данный момент у меня всё работает. Если указать шлюзом для доступа к 44-ой сети сам микротик(192.168.44.1), то маршрут получается неактивный(unreachable). Есть простые способы объяснить микротику где находится 44-ая подсеть(IPSec VPN к которой на нём же самом и поднят)? Если нет, то меня устроит не каноничный, но работающий вариант с маршрутом на бридж.

[Клёвый Админ]

1. Правило не такое же, а "очень похожее" - у того, что создаёт микротик, есть метка "C" = connected, это означает, что данная сеть напрямую подключена в устройство, и этот девайс её хозяин. В вашем же случае, всё получается наоборот, сеть есть - вот она, а "кто за неё отвечает?" - а вот сходи вот в этот интерфейс и там ищи. Т.е. с точки зрения микротика - ничего не изменится, а вот с точки зрения любого, кто захочет её при помощи вашего микротика достичь - будут проблемы (в лёгком сценарии правило будет неактивно, и активируется только если у вас изчезнет адрес из сети на устройстве, а в плохом - добро пожаловать в мир постоянного широковещательного трафика).

2. Не очень понял на какой раздел вы кинули ссылку, потому напишу просто:
В таблице маршрутизации, в поле указания шлюза, благодаря технологии ECMP мы можем указывать несколько шлюзов. Понимаете, ключевое слово последнее - шлюзы.
В среде множественного доступа (это такая физическая среда, в которой одновременно в пределах l2 домена может быть множество участников, более двух) - в ethernet'е шлюз это всегда конкретный адрес. Адрес какого-то хоста или виртуальный адрес, но никак не интерфейс.
В среде единственного доступа (а это все виды PPP туннелей, и некоторые виды физических сред - serial port например) - шлюзом может быть конкретный интерфейс, так как в нём - в этом интерфейсе, всё равно кроме нас и соседа никого нет.

Резюмируя. Такой маршрут не верный, в лучшем (самом лёгком способе) - он просто неактивен, создавать его следует только в сценариях нескольких таблиц маршрутизации чётко осознавая что и зачем мы делаем, и не забывая указывать pref-sorce.
Шлюзом может быть интерфейс, но если это интерфейс является туннелем (т.е. в нём всегда не более двух участников), оставляя за скобками все "странные" варианты, администраторы которых прекрасно (или не очень) понимают что они делают и зачем
Шлюзом в сети ethernet (равно как и во многих других) должен быть конкретный адрес (или несколько адресов - несколько шлюзов).

В вашем случае такой маршрут является лишним и паразитным. Отключите его и ищите причину неправильно работы в других местах.

[Dmitry]

Спасибо за подробное разъяснение. Ссылку давал на раздел "Routes with interface as a gateway".
Пункт 2(и предложение отключить маршрут) относится к маршруту add distance=1 dst-address=192.168.44.0/24 gateway=br_lan ?
При его отключении с самого микротика перестаёт пинговаться удалённая сеть, а трейс уходит на шлюз провайдера. При этом с компьютеров в сети микротика доступ к 44-ой сети остаётся. Почему при отсутствии этого маршрута микротик спокойно заворачивает в тонель трафик из сети, но не трафик инициированный самим микротиком я понять не могу. Если подскажете в каком направлении копать, буду весьма благодарен - работающий костыль хоть работает, но костылём остаётся, и если есть способ сделать всё правильно, то я конечно предпочту его костыльному решению.

[Клёвый Админ]

*тогда ответил правильно.

Если эта сеть находится за каким либо устройством - то он должен быть шлюзом в этом правиле, если сеть находится в вашей же локальной сети - то микротик должен получить адрес из этой сети к себе на интерфейс.

Но и то и другое догадки, очень похоже что у вас всё сложнее, и телепатия мне не помогает.

[Dmitry]

192.168.42.0 - домашняя локальная сеть. Для устройств в домашней сети микротик основной шлюз. 192.168.44.0 - сеть офиса. Подключение к офисной сети выполняется самим микротиком(IPSec, конфиг на пастбин - всё что дал export, только реальные адреса и пароли заменил). Когда к удалённой сети обращается компьютер из локалки, микротик знает куда послать. Когда я пробую пинговаться с самого микротика - без "паразитного маршрута" он пытается достичь удалённой сети не через тонель, а через шлюз провайдера. Не знаю как это объяснить ещё нагляднее. IPSec настраивал по документации микротика(Site_to_Site_IpSec_Tunnel), но возможно опять упустил какой-то нюанс.

[Клёвый Админ]

Dmitry: хороший кейс, сходу даже ответа нет, как бы не получилось что маршрут нужен, но не просто так, а в связке с route rules. Поищу инфу, может найду что. Но мои остальные рекомендации в силе.

[Dmitry]

Ок, надеюсь вам удастся найти ответ - в выходные я ещё попробую повоевать сам, но так как я далеко не сетевик, то могу пропустить очевидное, даже если оно будет у меня перед глазами(как ошибка с адресом).
В любом случае, спасибо за всё вышеизложенное.