Если клиент подлерживает IKEv2 c аутентфикацией по имени и паролю, то должно работать. Но надо проверять. Альтернативные разработчики могли реализовать в своём клиенте собственное видение стандарта.
Приемлемо работает в простых конфигурациях. Когда конфиг более сложный - возможны сюрпризы. Они и так иногда с обновлениями прилетают. Самый частый когда-то был, это когда /32 маршруты в ospf терялись. И до сих пор латыши не починили BFD, насколько знаю.
В данном случае решение уже вполне рабочее в ветке "Satble". В целом да, по поводу "Stable" vs "Long-Term" абсолютно с Вами согласен. Данное руководство нацелено на будущее и, надеюсь, за счёт этого побудет актуальным чуть дольше. У латвийского вендора есть существенные проблемы с разработкой ввиду внутренних причин, которые я тут озвучивать не могу.
https://forum.mikrotik.com/viewtopic.php?t=189205 Здесь описан процесс подробно. Есть даже большой пример скрипта. Если по шагам,то: 1. Убирают старый сертификат; 2. Открывают 80 порт и запрашивают новый сертификат; 3. Закрывают 80 порт; 4. Привязывают новый сертификат к службам.
Это и называется полноценная интеграция. Когда инженер не костылит суммарку+Netmap "чтобы вот ща пинги полетели" и не убегает пить пиво. За такого рода работу инженерам ЗП платят.
Без скриптов, все ОС семейства Windows умеют получать классовый маршрут. Но для этого "сетевой архитектор" должен был правильно проектировать адресное пространство компании. Например, при получении на свою сторону VPN-тунеля адреса "192.168.C.D", windows добавляет маршрут с маской "255.255.255.0" через VPN, адресуя 1 сеть /24. При получении на свою сторону VPN-тунеля адреса "172.16.C.D" (172.16-31.C.D), windows добавляет маршрут с маской "255.255.0.0" через VPN, адресуя 256 сетей по /24 При получении на свою сторону VPN-тунеля адреса "10.B.C.D", windows добавляет маршрут с маской "255.0.0.0" через VPN, адресуя 65536 сетей по /24 Для этого достаточно убрать в свойствах VPN-подключения галочку "Использовать основной шлюз в удаленной сети"
Использование классового маршрута в ОС Windows
При получении адреса 10.10.4.99 на VPN-адаптер, построится классовый маршрут: 10.0.0.0 mask 255.0.0.0 -> VPN При получении адреса 172.30.4.99 на VPN-адаптер, построится классовый маршрут: 172.30.0.0 mask 255.255.0.0 -> VPN
Windows XP не получает. Windows 7 имеет проблемы с получением маршрутов. Windows 8 под рукой к сожалению, нет. Windows 10 успешно устанавливает маршруты в таблицу маршрутизации.
Вендор, конечно, может приостановить свои формальные процедуры, но прекратить использование оборудования в РФ они пока не могут. Текущие задачи по поддержанию инфраструктуры на имеющемся оборудовании MikroTik тоже никто не отменял. Кроме того, по-прежнему остается вероятность, что объявленные ограничения имеют временный характер, т.к. это деятельность образовательная.
Компания МикроТик, вероятно, сейчас испытывает существенное внешнее давление. Обычно ребята стремились (и, я надеюсь, продолжат) оставаться подальше от политики.
Учитывая сохраняющуюся высокую заинтересованность наших коллег - системных и сетевых администраторов, мы продолжаем свою деятельность в России самостоятельно, без прямой поддержки вендора. Будем проводить курсы в разных городах РФ и РБ, обучать, делиться опытом и наработками. Расписание, обновление условий курсов доступно на сайте https://mikrotik-courses.ru
P.S. Пока никаких явных "закладок", блокирующих работу софта в РФ/РБ не обнаружено. И вряд ли они появятся с обновлениями - политика вендора объявлена как приостановка НОВЫХ поставок. В пользу этого говорит еще и то, что открытые на момент объявления санкции учебные группы успешно продолжили обучение.
Пересобрал лабу. Действительно, для не-ospf клиентов LSA не генерятся (нет с флагом "S - self-originated")ю Но работает через редистрибуцию. Как альтернатива Вашему - "Redistribute Static" и тоже с фильтрами. Но это, конечно уже, менее безопасный способ.
Клиент r2 получает IP 10.1.1.20 на vpn и видит сети соседа включая линковочную vpn: [admin@r2] > ip ro pr Flags: D - DYNAMIC; A - ACTIVE; c, o, d, y - COPY Columns: DST-ADDRESS, GATEWAY, DISTANCE DST-ADDRESS GATEWAY DISTANCE DAd 0.0.0.0/0 192.168.10.1 1 D o 10.1.1.1/32 10.1.1.1%l2tp-out1 110 DAc 10.1.1.1/32 l2tp-out1 0 DAo 10.1.1.19/32 10.1.1.1%l2tp-out1 110 DAo 172.16.1.0/24 10.1.1.1%l2tp-out1 110 DAc 172.16.2.0/24 bridge1 0 DAo 172.16.3.0/24 10.1.1.1%l2tp-out1 110 DAc 192.168.10.0/24 ether1 0
Клиент r3 получает IP 10.1.1.19 на vpn и видит сети соседа включая линковочную vpn: [admin@r3] > ip ro pr Flags: D - DYNAMIC; A - ACTIVE; c, o, d, y - COPY Columns: DST-ADDRESS, GATEWAY, DISTANCE DST-ADDRESS GATEWAY DISTANCE DAd 0.0.0.0/0 192.168.10.1 1 D o 10.1.1.1/32 10.1.1.1%l2tp-out1 110 DAc 10.1.1.1/32 l2tp-out1 0 DAo 10.1.1.20/32 10.1.1.1%l2tp-out1 110 DAo 172.16.1.0/24 10.1.1.1%l2tp-out1 110 DAo 172.16.2.0/24 10.1.1.1%l2tp-out1 110 DAc 172.16.3.0/24 bridge1 0 DAc 192.168.10.0/24 ether1 0
Перехватывать можно содержимое туннеля при использовании в профиле "use-encryption=no". Со своей стороны склонен использовать "use-encryption=required" или, как минимум "yes".
Я бы еще "sessino-timeout=00:59:00" добавил, т. к. в сессии будут какое-то время ходить пакетики, idle-timeout обнулится.
Да, клиенту придется при этом переустанавливать соединение один раз в час. Но это даже полезно от "брошеннных и забытых" пользователями vpn-соединений.
Интересное решение с прослойкой из PHP.
Только с масштабированием "«1хN» – 1 SMS-шлюз на неограниченное количество роутеров" возникает проблема единой базы логинов и паролей. Она имеет два быстрых решения:
1. Реплекация /ppp secrets на неограниченное количество роутеров при помощи скриптов/API.
2. Установка некоего дополнительно стороннего Radius-сервера. Тогда будет логин будет всегда по номеру телефона.
Для обеспечения принципа "Не важно какое устройство инициировало VPN-соединение, авторизация по ссылке из SMS", сервис авторизации нужно выставить в Интернет. Это может быть нежелательно в ряде случаев.
p.s. если VPN-соединение сможет провисеть час, то не прошедший проверку клиент всё равно получит доступ к внутренним ресурсам сети.
Человек не способный понять 25 строк конфига, вряд ли должен вообще совать ручки к сетевому оборудованию.
К тому же, радиус на 2FA настроить нисколько не проще. Там тоже есть где убиться без подготовки с тупой копипасты.
Да и отделтная дадача "поднять радиус" некоторыз ставит в тупик. Даже со встроенным в Windoa Server вариантом многие разобраться не способны.
Здесь же как раз решение "не плодить лишние сущности". Потому оно оказывается пригодным для сетей малого и среднего бизнеса.
Возможно, в программировании Вы разбираетесь гораздо лучше. Но арзитектура сетей — это пока не Ваше.
Создавать большие L2-broadcast сегменты воообще так-себе решение. Тем более, "растягивать" их через интернет и удаленный доступ.
По поводу сертификации — покадите сертификаты. ФСТЭК на примененное Вами ПО OpenVPN.
Из-за таких непродуманных решений КИИ оказывается уязвимой.
За оформление статьи с иллюстрациями "5".
А за сетевую арзитектуру "троечка", увы.
Да. Промежуточный сертификат R3 можно установить на стороне микротика, указав вместе с сертификатом хоста identity. Такой вариант тоже работает.
Если клиент подлерживает IKEv2 c аутентфикацией по имени и паролю, то должно работать. Но надо проверять. Альтернативные разработчики могли реализовать в своём клиенте собственное видение стандарта.
Да. Правильно. С любым внешним.
В данном примере UserManager - локальный radius-сервер в составе RouterOS.
Приемлемо работает в простых конфигурациях. Когда конфиг более сложный - возможны сюрпризы. Они и так иногда с обновлениями прилетают. Самый частый когда-то был, это когда /32 маршруты в ospf терялись. И до сих пор латыши не починили BFD, насколько знаю.
Win+R ncpa.cpl
В данном случае решение уже вполне рабочее в ветке "Satble".
В целом да, по поводу "Stable" vs "Long-Term" абсолютно с Вами согласен. Данное руководство нацелено на будущее и, надеюсь, за счёт этого побудет актуальным чуть дольше. У латвийского вендора есть существенные проблемы с разработкой ввиду внутренних причин, которые я тут озвучивать не могу.
https://forum.mikrotik.com/viewtopic.php?t=189205
Здесь описан процесс подробно. Есть даже большой пример скрипта. Если по шагам,то:
1. Убирают старый сертификат;
2. Открывают 80 порт и запрашивают новый сертификат;
3. Закрывают 80 порт;
4. Привязывают новый сертификат к службам.
Это и называется полноценная интеграция. Когда инженер не костылит суммарку+Netmap "чтобы вот ща пинги полетели" и не убегает пить пиво.
За такого рода работу инженерам ЗП платят.
Без скриптов, все ОС семейства Windows умеют получать классовый маршрут. Но для этого "сетевой архитектор" должен был правильно проектировать адресное пространство компании.
Например, при получении на свою сторону VPN-тунеля адреса "192.168.C.D", windows добавляет маршрут с маской "255.255.255.0" через VPN, адресуя 1 сеть /24.
При получении на свою сторону VPN-тунеля адреса "172.16.C.D" (172.16-31.C.D), windows добавляет маршрут с маской "255.255.0.0" через VPN, адресуя 256 сетей по /24
При получении на свою сторону VPN-тунеля адреса "10.B.C.D", windows добавляет маршрут с маской "255.0.0.0" через VPN, адресуя 65536 сетей по /24
Для этого достаточно убрать в свойствах VPN-подключения галочку "Использовать основной шлюз в удаленной сети"
При получении адреса 10.10.4.99 на VPN-адаптер, построится классовый маршрут: 10.0.0.0 mask 255.0.0.0 -> VPN
При получении адреса 172.30.4.99 на VPN-адаптер, построится классовый маршрут: 172.30.0.0 mask 255.255.0.0 -> VPN
Windows XP не получает. Windows 7 имеет проблемы с получением маршрутов.
Windows 8 под рукой к сожалению, нет.
Windows 10 успешно устанавливает маршруты в таблицу маршрутизации.
Вот, так внезапно я оказался в персональном санкционном списке. Чуть ли не вместе с Путиным и Шойгу :-)
Вендор, конечно, может приостановить свои формальные процедуры, но прекратить использование оборудования в РФ они пока не могут. Текущие задачи по поддержанию инфраструктуры на имеющемся оборудовании MikroTik тоже никто не отменял. Кроме того, по-прежнему остается вероятность, что объявленные ограничения имеют временный характер, т.к. это деятельность образовательная.
Компания МикроТик, вероятно, сейчас испытывает существенное внешнее давление. Обычно ребята стремились (и, я надеюсь, продолжат) оставаться подальше от политики.
Учитывая сохраняющуюся высокую заинтересованность наших коллег - системных и сетевых администраторов, мы продолжаем свою деятельность в России самостоятельно, без прямой поддержки вендора. Будем проводить курсы в разных городах РФ и РБ, обучать, делиться опытом и наработками. Расписание, обновление условий курсов доступно на сайте https://mikrotik-courses.ru
P.S. Пока никаких явных "закладок", блокирующих работу софта в РФ/РБ не обнаружено. И вряд ли они появятся с обновлениями - политика вендора объявлена как приостановка НОВЫХ поставок. В пользу этого говорит еще и то, что открытые на момент объявления санкции учебные группы успешно продолжили обучение.
Пересобрал лабу. Действительно, для не-ospf клиентов LSA не генерятся (нет с флагом "S - self-originated")ю
Но работает через редистрибуцию. Как альтернатива Вашему - "Redistribute Static" и тоже с фильтрами. Но это, конечно уже, менее безопасный способ.
RouterOS 7.1.1.
Что-то не так вы делаете с VPN+OSPF. Простой стенд в GNS3. 1 сервер + 2 клиента.
Локалки 172.16.х.0/24. Линки VPN по /32 из 10.1.1.0/24
Сервер:
/ip address
add address=172.16.1.1/24 interface=bridge1 network=172.16.1.0
/ip pool
add name=vpn ranges=10.1.1.2-10.1.1.20
/ppp profile
add change-tcp-mss=yes local-address=10.1.1.1 name=profile1 remote-address=vpn use-encryption=yes
/ppp secret
add name=1
add name=2
/routing ospf instance
add name=ospf-instance-1 router-id=1.1.1.1
/routing ospf area
add instance=ospf-instance-1 name=ospf-area-1
/routing ospf interface-template
add area=ospf-area-1 networks=172.16.1.0/24 passive
add area=ospf-area-1 networks=10.1.1.0/24 type=ptp
Клиенты аналогичны. Отличия в адресах LAN и OSPF RID. Экспорт с r2:
/interface l2tp-client
add connect-to=server.local disabled=no name=l2tp-out1 user=u1
/ip address
add address=172.16.2.1/24 interface=bridge1 network=172.16.2.0
/routing ospf instance
add name=ospf-instance-1 router-id=2.2.2.2
/routing ospf area
add instance=ospf-instance-1 name=ospf-area-1
/routing ospf interface-template
add area=ospf-area-1 networks=172.16.2.0/24
add area=ospf-area-1 networks=10.1.1.0/24 type=ptp
Клиент r2 получает IP 10.1.1.20 на vpn и видит сети соседа включая линковочную vpn:
[admin@r2] > ip ro pr
Flags: D - DYNAMIC; A - ACTIVE; c, o, d, y - COPY
Columns: DST-ADDRESS, GATEWAY, DISTANCE
DST-ADDRESS GATEWAY DISTANCE
DAd 0.0.0.0/0 192.168.10.1 1
D o 10.1.1.1/32 10.1.1.1%l2tp-out1 110
DAc 10.1.1.1/32 l2tp-out1 0
DAo 10.1.1.19/32 10.1.1.1%l2tp-out1 110
DAo 172.16.1.0/24 10.1.1.1%l2tp-out1 110
DAc 172.16.2.0/24 bridge1 0
DAo 172.16.3.0/24 10.1.1.1%l2tp-out1 110
DAc 192.168.10.0/24 ether1 0
Клиент r3 получает IP 10.1.1.19 на vpn и видит сети соседа включая линковочную vpn:
[admin@r3] > ip ro pr
Flags: D - DYNAMIC; A - ACTIVE; c, o, d, y - COPY
Columns: DST-ADDRESS, GATEWAY, DISTANCE
DST-ADDRESS GATEWAY DISTANCE
DAd 0.0.0.0/0 192.168.10.1 1
D o 10.1.1.1/32 10.1.1.1%l2tp-out1 110
DAc 10.1.1.1/32 l2tp-out1 0
DAo 10.1.1.20/32 10.1.1.1%l2tp-out1 110
DAo 172.16.1.0/24 10.1.1.1%l2tp-out1 110
DAo 172.16.2.0/24 10.1.1.1%l2tp-out1 110
DAc 172.16.3.0/24 bridge1 0
DAc 192.168.10.0/24 ether1 0
Перехватывать можно содержимое туннеля при использовании в профиле "use-encryption=no". Со своей стороны склонен использовать "use-encryption=required" или, как минимум "yes".
Я бы еще "sessino-timeout=00:59:00" добавил, т. к. в сессии будут какое-то время ходить пакетики, idle-timeout обнулится.
Да, клиенту придется при этом переустанавливать соединение один раз в час. Но это даже полезно от "брошеннных и забытых" пользователями vpn-соединений.
Чтобы соединение было разорвано по таймауту, жто должно быть явно указано в PPP-PROFILE. По-умолчанию, ограничения на длителтность ppp-соединения нет.
Только с масштабированием "«1хN» – 1 SMS-шлюз на неограниченное количество роутеров" возникает проблема единой базы логинов и паролей. Она имеет два быстрых решения:
1. Реплекация /ppp secrets на неограниченное количество роутеров при помощи скриптов/API.
2. Установка некоего дополнительно стороннего Radius-сервера. Тогда будет логин будет всегда по номеру телефона.
Для обеспечения принципа "Не важно какое устройство инициировало VPN-соединение, авторизация по ссылке из SMS", сервис авторизации нужно выставить в Интернет. Это может быть нежелательно в ряде случаев.
p.s. если VPN-соединение сможет провисеть час, то не прошедший проверку клиент всё равно получит доступ к внутренним ресурсам сети.
Человек не способный понять 25 строк конфига, вряд ли должен вообще совать ручки к сетевому оборудованию.
К тому же, радиус на 2FA настроить нисколько не проще. Там тоже есть где убиться без подготовки с тупой копипасты.
Да и отделтная дадача "поднять радиус" некоторыз ставит в тупик. Даже со встроенным в Windoa Server вариантом многие разобраться не способны.
Здесь же как раз решение "не плодить лишние сущности". Потому оно оказывается пригодным для сетей малого и среднего бизнеса.
Возможно, в программировании Вы разбираетесь гораздо лучше. Но арзитектура сетей — это пока не Ваше.
Создавать большие L2-broadcast сегменты воообще так-себе решение. Тем более, "растягивать" их через интернет и удаленный доступ.
По поводу сертификации — покадите сертификаты. ФСТЭК на примененное Вами ПО OpenVPN.
Из-за таких непродуманных решений КИИ оказывается уязвимой.
За оформление статьи с иллюстрациями "5".
А за сетевую арзитектуру "троечка", увы.