Pull to refresh

Comments 30

Если не секрет то что за Mikrotik был и какой трафик через него лился?
Вот такая машинка стоит 2011UAS-2HnD. Трафик — да обычный офисный — серфинг в интернете, + работа с удалёнными серверами по web,ssh, + телефония
К чему вопрос то был.
У меня есть два RouterBOARD 2011UiAS-RM. Между ними L2TP. Одна сеть 192.168.12.0\24 вторая 192.168.88.0\24
И все бы ни чего, но периодически при открытии файлов из расшаренных папок другой подсети я вижу миросовтовсую ошибку 64 иногда «Указанное сетевое имя более не доступно». При том что если сделалть попытку номер два и повторно открыть файл то все открывается. Вот и думаю связанна ли моя проблема с тем что маршруты то же прописаны на микротиках.
Извините, но пора уже переползать на MPLS.
UFO just landed and posted this here
я в начале статьи написал — маршрут сначал был настроен на роутере — соединения лагали.
Кому и зачем выдавать адреса из другой посети? Серверу VPN? — можно, но есть несколько нюансов которые, пока, не позволяют это сделать.
Насчёт proxyarp спасибо — покопаю.
UFO just landed and posted this here
Вы видимо пытались «маршрутизировать» пакеты из одной подсети

верно. Дефолтный шлюз 192.168.0.1, а VPN-шлюз — 192.168.0.2

Выдача маршрутов, кроме дефолт шлюза на своей сети это вообще крайняя, костыльная мера.

Почему? Я не вижу никакой проблемы. Маршруты и маршруты — хоть 200 штук. Какая разница?

121 и 249 — формируются абсолютно одинаково

Ну я это понял и в статье отписал. Просто при первой настройке (ещё не всё голове уложилось) и заработало с тем, что под спойлером спрятано. А так — да, одинаково.

повесьте на впн сервер алиасом адрес не из локалки и маршрутизируйте на него.

Вы представляете этот уровень «костылизма», по сравнению с передачей роутов по DHCP?
1. Алиас на интерфейс VPN-шлюза (ну в линуксе это сделать просто)
2. Алиас на интерфейс локалки на микротике. — (КАК?! а вот тут что то я не нашёл решения простого)
3. В локальной сети пакеты будут бегать с адресацией из другой подсети.

Вот второй пункт как то не получится. У меня не получилось, по крайней мере. Мне нужно добавить на Микротик алиас на интерфейс, но я не нашёл как это сделать. Нашёл какие то варианты с файерволом левые — в общем я пока не представляю как это реализовать.

Если у вас впн клиенты попадают в локалку с адресами из локалки — то проксиарп

Зачем? Я не вижу преимущества. Нужно дополнительно настраивать службу на VPN-шлюзе. +1 костыль.
UFO just landed and posted this here
у меня вариант №2.
Несколько площадок, на каждой своя подсеть. На VPN сервере поднят ещё и OSPF. VPN у меня полносвязный одноточечный — tinc — мешсеть на его основе.
У меня нет простой возможности вынести VPN сервер из локалки. Я не хочу заморачиваться vlan`ами — пока нет такой острой необходимости. Я бы с удовольствием терменировал VPN на микротике, если бы была возможность — пока я её не видел.
Насчёт 200 маршуртов DHCP — это я пошутил, но я пока так и не понял, чем мой вариант плох.
Пора перестать заниматься ерундой
Выдача маршрутов, кроме дефолт шлюза на своей сети это вообще крайняя, костыльная мера.

Где я занялся ерундой? И почему выдача доп. маршрутов это «костыльная мера» если это заложено в RFC?
UFO just landed and posted this here
Я думаю можно закрыть обсуждение, т.к. вы высказываете своё ИМХО, но внятного пояснения, чем плохо выдавать маршруты по DHCP, я пока так и не увидел.
RFC на то и RFC, что производители и разработчики следуют описанным стандартам. Раз данная опция существует и не пропала со времени создания этого RFC, значит ничего криминального и «технически неоправданного» тут нет.
Не придумывайте лишние сущности. Борьба со спуфингом, настройка коммутаторов, это уже другая тема. Откуда вы знаете какие у меня коммутаторы стоят? Может у нас очень мало денег и мы купили дешевые неуправляемые коммутаторы? (это не так, но для примера сойдёт).
Есть задача, есть варианты решения. Мой вариант ничем не хуже.
как подключить его к VPN сети на tinc? Я просто искал подобное, но не нашёл такой возможности на микротике. Ну и "+" в том, что все сервера управляются через puppet — мне проще так показалось.
Я имел ввиду что почему не использовать Микротик как сервер ВПН. Он же на входе в сеть. И ни чего не надо было городить. Куча разных протоколов. Маршрутизируй не хочу.
Вы знаете как включить Микротик в VPN сеть на TINC?
Я нет.
Спасибо. Добавил апдейтом к статье.
Ну, а для откровенных лентяев ниже написан скрипт ;), правда не на python, а на perl…
Я бы обратил внимание на эту фразу в RFC3442:
DHCP server administrators [...] should specify the default router(s) both in the Router option and in the Classless Static Routes option.

Во всех ваших примерах в опции 121 маршрут по умолчанию отсутствует. То есть к обоим строчкам лучше в конце дописать 00c0a80001 (0.0.0.0/0 via 192.168.0.1).
Интересно, какие версии Windows не обрабатывают опцию 121?
Windows 7 SP1, Windows 8, Windows 8.1, Windows 2012 R2 точно обрабатывают, причём для них маршрут по умолчанию добавлять нет необходимости.
Никак не вкурю как вычислять если маска не кратна 8, например 10.84.113.0/26 via 192.168.0.1
Основной коментарий приведён несколько ниже, тут кратко:
$ rfc3442.route-4-dhcp.pl 10.84.113.0/26 192.168.0.1
option_121_route_10.84.113.0/26_via_192.168.0.1 : 0x1a0a547100c0a80001
option_249_route_10.84.113.0/26_via_192.168.0.1 : 0x1a0a547100c0a80001
aggregate_opt_121 : 0x1a0a547100c0a80001
aggregate_opt_249 : 0x1a0a547100c0a80001
Может кому поможет скрипт, который родился исключительно из-за лени rfc3442.route-4-dhcp.pl.

Использовать его просто:
$ rfc3442.route-4-dhcp.pl 10.0.0.0/8 192.168.88.2 172.16.0.0/12 192.168.88.2 192.168.0.0/16 192.168.88.2 0.0.0.0/0 192.168.88.1
option_121_route_10.0.0.0/8_via_192.168.88.2 : 0x080ac0a85802
option_249_route_10.0.0.0/8_via_192.168.88.2 : 0x080ac0a85802
option_121_route_172.16.0.0/12_via_192.168.88.2 : 0x0cac10c0a85802
option_249_route_172.16.0.0/12_via_192.168.88.2 : 0x0cac10c0a85802
option_121_route_192.168.0.0/16_via_192.168.88.2 : 0x10c0a8c0a85802
option_249_route_192.168.0.0/16_via_192.168.88.2 : 0x10c0a8c0a85802
option_121_route_0.0.0.0/0_via_192.168.88.1 : 0x00c0a85801
option_249_route_0.0.0.0/0_via_192.168.88.1 : 0x00c0a85801
aggregate_opt_121 : 0x080ac0a858020cac10c0a8580210c0a8c0a8580200c0a85801
aggregate_opt_249 : 0x080ac0a858020cac10c0a8580210c0a8c0a8580200c0a85801
Спасибо за статью! Приятно, что кто-то раскурил это до меня :)

Один нюанс: я правильно понимаю, что в третьем примере ошибка из-за копипаста и имелась в виду сеть 172.16.4.0/29? И шлюз там не должен быть аналогичен второму примеру (192.168.0.2 = c0 a8 00 02)?

И где пример с маршрутами одной строкой, поясните, пожалуйста — как микротик определяет, где заканчивается один маршрут и начинается второй, если поля разной длины (например, когда 10.0.0.0 интерпретируется в 0A, а не в 0A 00 00 00)?
Рад что пригодилось.
я правильно понимаю, что в третьем примере ошибка из-за копипаста

Совершенно верно.

как микротик определяет, где заканчивается один маршрут и начинается второй

Чуть выше вашего комментария скрипт oldengremlin который собирает в одну строку.
Маршруты разделяются по маске подсети.

LEN (маска подсети назначения) = 8 = 0x08
DESTINATION = 10.0.0.0 = 0A

Маска подсети — 8 бит. Это означает, что сетевая часть адреса — первый октет. Всё. Больше искать смысла нет т.к. остальное это адреса хостов подсети.
Если сетевая маска 24 бита, то сетевая часть адреса это 3 октета. Как то так ))
Интересно, «перебить» выданный стандартным DHCP маршрут по умолчанию так можно? Мне на ум тольков вариант приходит вместо пути для 0.0.0.0/0 прислать два пути для 0.0.0.0/1 и 128.0.0.0/1 — маска у них точнее, будут иметь приоритет.
Нашёл ошибку:
/ip dhcp-server option
add code=121 name=opt_121_10 value=0x180A0000c0a80002
set 0 dhcp-option=opt_121_10

— там третья строка неверная. Правильная:
/ip dhcp-server network set 0 dhcp-option=opt_121_10
Sign up to leave a comment.

Articles