Comments 35
Если не секрет то что за Mikrotik был и какой трафик через него лился?
Вот такая машинка стоит 2011UAS-2HnD. Трафик — да обычный офисный — серфинг в интернете, + работа с удалёнными серверами по web,ssh, + телефония
К чему вопрос то был.
У меня есть два RouterBOARD 2011UiAS-RM. Между ними L2TP. Одна сеть 192.168.12.0\24 вторая 192.168.88.0\24
И все бы ни чего, но периодически при открытии файлов из расшаренных папок другой подсети я вижу миросовтовсую ошибку 64 иногда «Указанное сетевое имя более не доступно». При том что если сделалть попытку номер два и повторно открыть файл то все открывается. Вот и думаю связанна ли моя проблема с тем что маршруты то же прописаны на микротиках.
У меня есть два RouterBOARD 2011UiAS-RM. Между ними L2TP. Одна сеть 192.168.12.0\24 вторая 192.168.88.0\24
И все бы ни чего, но периодически при открытии файлов из расшаренных папок другой подсети я вижу миросовтовсую ошибку 64 иногда «Указанное сетевое имя более не доступно». При том что если сделалть попытку номер два и повторно открыть файл то все открывается. Вот и думаю связанна ли моя проблема с тем что маршруты то же прописаны на микротиках.
Извините, но пора уже переползать на MPLS.
я в начале статьи написал — маршрут сначал был настроен на роутере — соединения лагали.
Кому и зачем выдавать адреса из другой посети? Серверу VPN? — можно, но есть несколько нюансов которые, пока, не позволяют это сделать.
Насчёт proxyarp спасибо — покопаю.
Кому и зачем выдавать адреса из другой посети? Серверу VPN? — можно, но есть несколько нюансов которые, пока, не позволяют это сделать.
Насчёт proxyarp спасибо — покопаю.
Вы видимо пытались «маршрутизировать» пакеты из одной подсети
верно. Дефолтный шлюз 192.168.0.1, а VPN-шлюз — 192.168.0.2
Выдача маршрутов, кроме дефолт шлюза на своей сети это вообще крайняя, костыльная мера.
Почему? Я не вижу никакой проблемы. Маршруты и маршруты — хоть 200 штук. Какая разница?
121 и 249 — формируются абсолютно одинаково
Ну я это понял и в статье отписал. Просто при первой настройке (ещё не всё голове уложилось) и заработало с тем, что под спойлером спрятано. А так — да, одинаково.
повесьте на впн сервер алиасом адрес не из локалки и маршрутизируйте на него.
Вы представляете этот уровень «костылизма», по сравнению с передачей роутов по DHCP?
1. Алиас на интерфейс VPN-шлюза (ну в линуксе это сделать просто)
2. Алиас на интерфейс локалки на микротике. — (КАК?! а вот тут что то я не нашёл решения простого)
3. В локальной сети пакеты будут бегать с адресацией из другой подсети.
Вот второй пункт как то не получится. У меня не получилось, по крайней мере. Мне нужно добавить на Микротик алиас на интерфейс, но я не нашёл как это сделать. Нашёл какие то варианты с файерволом левые — в общем я пока не представляю как это реализовать.
Если у вас впн клиенты попадают в локалку с адресами из локалки — то проксиарп
Зачем? Я не вижу преимущества. Нужно дополнительно настраивать службу на VPN-шлюзе. +1 костыль.
у меня вариант №2.
Несколько площадок, на каждой своя подсеть. На VPN сервере поднят ещё и OSPF. VPN у меня полносвязный одноточечный — tinc — мешсеть на его основе.
У меня нет простой возможности вынести VPN сервер из локалки. Я не хочу заморачиваться vlan`ами — пока нет такой острой необходимости. Я бы с удовольствием терменировал VPN на микротике, если бы была возможность — пока я её не видел.
Насчёт 200 маршуртов DHCP — это я пошутил, но я пока так и не понял, чем мой вариант плох.
Где я занялся ерундой? И почему выдача доп. маршрутов это «костыльная мера» если это заложено в RFC?
Несколько площадок, на каждой своя подсеть. На VPN сервере поднят ещё и OSPF. VPN у меня полносвязный одноточечный — tinc — мешсеть на его основе.
У меня нет простой возможности вынести VPN сервер из локалки. Я не хочу заморачиваться vlan`ами — пока нет такой острой необходимости. Я бы с удовольствием терменировал VPN на микротике, если бы была возможность — пока я её не видел.
Насчёт 200 маршуртов DHCP — это я пошутил, но я пока так и не понял, чем мой вариант плох.
Пора перестать заниматься ерундой
Выдача маршрутов, кроме дефолт шлюза на своей сети это вообще крайняя, костыльная мера.
Где я занялся ерундой? И почему выдача доп. маршрутов это «костыльная мера» если это заложено в RFC?
Я думаю можно закрыть обсуждение, т.к. вы высказываете своё ИМХО, но внятного пояснения, чем плохо выдавать маршруты по DHCP, я пока так и не увидел.
RFC на то и RFC, что производители и разработчики следуют описанным стандартам. Раз данная опция существует и не пропала со времени создания этого RFC, значит ничего криминального и «технически неоправданного» тут нет.
Не придумывайте лишние сущности. Борьба со спуфингом, настройка коммутаторов, это уже другая тема. Откуда вы знаете какие у меня коммутаторы стоят? Может у нас очень мало денег и мы купили дешевые неуправляемые коммутаторы? (это не так, но для примера сойдёт).
Есть задача, есть варианты решения. Мой вариант ничем не хуже.
RFC на то и RFC, что производители и разработчики следуют описанным стандартам. Раз данная опция существует и не пропала со времени создания этого RFC, значит ничего криминального и «технически неоправданного» тут нет.
Не придумывайте лишние сущности. Борьба со спуфингом, настройка коммутаторов, это уже другая тема. Откуда вы знаете какие у меня коммутаторы стоят? Может у нас очень мало денег и мы купили дешевые неуправляемые коммутаторы? (это не так, но для примера сойдёт).
Есть задача, есть варианты решения. Мой вариант ничем не хуже.
А почему самими Тиком не ВПНите?
Вот набросал python функцию для этого, может еще кому пригодится ;-)
Спасибо. Добавил апдейтом к статье.
Ну, а для откровенных лентяев ниже написан скрипт ;), правда не на python, а на perl…
незначащие нули не кушает? на маске /15 получилось F
Я бы обратил внимание на эту фразу в RFC3442:
Во всех ваших примерах в опции 121 маршрут по умолчанию отсутствует. То есть к обоим строчкам лучше в конце дописать 00c0a80001 (0.0.0.0/0 via 192.168.0.1).
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 точно обрабатывают, причём для них маршрут по умолчанию добавлять нет необходимости.
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)?
Один нюанс: я правильно понимаю, что в третьем примере ошибка из-за копипаста и имелась в виду сеть 172.16.4.0/29? И шлюз там не должен быть аналогичен второму примеру (192.168.0.2 = c0 a8 00 02)?
И где пример с маршрутами одной строкой, поясните, пожалуйста — как микротик определяет, где заканчивается один маршрут и начинается второй, если поля разной длины (например, когда 10.0.0.0 интерпретируется в 0A, а не в 0A 00 00 00)?
Рад что пригодилось.
Совершенно верно.
Чуть выше вашего комментария скрипт oldengremlin который собирает в одну строку.
Маршруты разделяются по маске подсети.
Маска подсети — 8 бит. Это означает, что сетевая часть адреса — первый октет. Всё. Больше искать смысла нет т.к. остальное это адреса хостов подсети.
Если сетевая маска 24 бита, то сетевая часть адреса это 3 октета. Как то так ))
я правильно понимаю, что в третьем примере ошибка из-за копипаста
Совершенно верно.
как микротик определяет, где заканчивается один маршрут и начинается второй
Чуть выше вашего комментария скрипт 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
Обнаружил способ сделать значение опции более читабельным и поддерживаемым. В документации указана возможность задавать значения в одинарных кавычках и тогда оно автоматически преобразуется в двоичный формат. Если указано число или IP адрес, то они сразу же целиком переводятся в двоичный формат. При этом написано "Now it is also possible to combine data types into one", что даёт возможность писать серию десятичных чисел и IP адресов подряд друг за другом без мутотени с ручным преобразованием. Не очень понятно к какой конкретно версии ROS относится слово "now", но оно появилось в документации в районе ноября 2021 года, так что думаю речь идёт про ROS 6.49 и выше.
Пример 1 из статьи можно записать как '24''10''0''0''192.168.0.2'
Чтобы не запутаться в кавычках, напишу как оно делится: '24' + '10' + '0' + '0' + '192.168.0.2'. То есть отдельно в кавычках маска, отдельно каждый октет адреса назначения и адрес роутера целиком. Но записывать нужно без промежутков (без пробелов и т.п.).
Пример 2 - '8''10''192.168.0.2'
Пример 3 - '29''172.16.4.0''192.168.0.2'
В 3 примере автор накосячил. Либо ошибся когда копипастил, либо просто запутался в преобразованиях. Кстати, если маска адреса назначения 25 и больше, то адрес назначения можно написать не раздельно, а сразу целиком.
Sign up to leave a comment.
Mikrotik, DHCP Classless Route