Подтверждаю, и даже усилю: у меня вообще со стороны клиента стоит опция Optional encryption (другое дело, что есс-но возможность подключения без шифрования заблокирована на VPN роутере). Результат
И даже это неполная правда, ибо есть еще powershell в котором есть Set-VpnConnectionIPsecConfiguration - выставляйте те параметры подключению, какие вам нравятся (если, конечно, соответствующие алгоритмы выставлены и со стороны VPN роутера)
Ну так у тебя, наверное, непосредственно с серверной стороны настроен L2TP именно поверх IPSec - как оно, собственно, и положено. Конечно, правильнее апдейт снести - не сносить же шифрование для VPN
Судя по тому, что я вижу в логах - проблема не с L2TP как таковым, а с IPSec. Создание шифротуннеля (если у вас L2TP over IPSec) это самый первый шаг при установке VPN подключения - и обламывается уже он. Так что полагаю, что работает у тех, у кого VPN подключения не закрыты IPSec-ом
И что в этом страшного? мы же его не привязываем к физическому интерфейсу, так что ethernet фреймов от него в сети не будет. Рассматривайте его как классический цисковский лупбэк, которому вдруг зачем-то дополнительно навесили MAC адрес - да, бессмысленный и бесполезный функционал, но от которого нет никакого вреда.
Коллеги, идея отправлять OSPFом суммарный маршрут вместо кучи мелких - разумеется, правильная, причем правильная сама по себе, в отвязке от описанного бага. Но почему столь обычную задачу предлагается решать таким слегка извращенным способом? Зачем нам костыль в виде статики и ее редистрибуции, если есть вполне себе стандартный, почти штатный способ анонсировать нужный маршрут сразу в OSPF?
OSPF - это link-state протокол. Он завязан на состояние интерфейсов. Маршруты передаются для тех подсетей, которые нацеплены на интерфейсы, которые мы анонсировали в OSPF и которые подняты в данный момент. Корень зла описанного бага - в том, что RouterOS 6 прекрасно умел самостоятельно анонсировать OSPFy поднятые L2TP Binding интерфейсы (они всегда присутствовали в OSPF во вкладке Interfaces) и а Router OS 7 почему-то разучился это делать. Ну, разучился - значит надо просто сделать свой интерфейс, который всегда будет поднят. Лупбэков у Микрота нету - ну, не беда, сделаем, например, бридж, он тоже всегда в апе. Нацепим на него адрес с подсеткой, соответствующие или перекрывающие наш пул адресов для L2TP (надо только не забыть исключить этот адрес из пула, иначе Микрот его в какой-то момент может выдать клиенту - по хорошему он должен хотя бы пингами проверять, не отвечает ли такой адрес в данный момент, но не знаю, заморачивается ли он этим). После этого осталось анонсировать этот интерфейс вместе с заданной подсеткой в OSPF - и вуаля, нужный маршрут разлетается со свистом.
Подтверждаю, и даже усилю: у меня вообще со стороны клиента стоит опция Optional encryption (другое дело, что есс-но возможность подключения без шифрования заблокирована на VPN роутере). Результат
SRC-ADDRESS DST-ADDRESS AUTH-ALGORITHM ENC-ALGORITHM ENC-KEY-SIZE
a.b.c.d:4500 q.l.m.n:4500 sha1 aes-cbc 256
И даже это неполная правда, ибо есть еще powershell в котором есть Set-VpnConnectionIPsecConfiguration - выставляйте те параметры подключению, какие вам нравятся (если, конечно, соответствующие алгоритмы выставлены и со стороны VPN роутера)
Ну так у тебя, наверное, непосредственно с серверной стороны настроен L2TP именно поверх IPSec - как оно, собственно, и положено. Конечно, правильнее апдейт снести - не сносить же шифрование для VPN
Судя по тому, что я вижу в логах - проблема не с L2TP как таковым, а с IPSec. Создание шифротуннеля (если у вас L2TP over IPSec) это самый первый шаг при установке VPN подключения - и обламывается уже он. Так что полагаю, что работает у тех, у кого VPN подключения не закрыты IPSec-ом
И что в этом страшного? мы же его не привязываем к физическому интерфейсу, так что ethernet фреймов от него в сети не будет. Рассматривайте его как классический цисковский лупбэк, которому вдруг зачем-то дополнительно навесили MAC адрес - да, бессмысленный и бесполезный функционал, но от которого нет никакого вреда.
Коллеги, идея отправлять OSPFом суммарный маршрут вместо кучи мелких - разумеется, правильная, причем правильная сама по себе, в отвязке от описанного бага. Но почему столь обычную задачу предлагается решать таким слегка извращенным способом? Зачем нам костыль в виде статики и ее редистрибуции, если есть вполне себе стандартный, почти штатный способ анонсировать нужный маршрут сразу в OSPF?
OSPF - это link-state протокол. Он завязан на состояние интерфейсов. Маршруты передаются для тех подсетей, которые нацеплены на интерфейсы, которые мы анонсировали в OSPF и которые подняты в данный момент. Корень зла описанного бага - в том, что RouterOS 6 прекрасно умел самостоятельно анонсировать OSPFy поднятые L2TP Binding интерфейсы (они всегда присутствовали в OSPF во вкладке Interfaces) и а Router OS 7 почему-то разучился это делать. Ну, разучился - значит надо просто сделать свой интерфейс, который всегда будет поднят. Лупбэков у Микрота нету - ну, не беда, сделаем, например, бридж, он тоже всегда в апе. Нацепим на него адрес с подсеткой, соответствующие или перекрывающие наш пул адресов для L2TP (надо только не забыть исключить этот адрес из пула, иначе Микрот его в какой-то момент может выдать клиенту - по хорошему он должен хотя бы пингами проверять, не отвечает ли такой адрес в данный момент, но не знаю, заморачивается ли он этим). После этого осталось анонсировать этот интерфейс вместе с заданной подсеткой в OSPF - и вуаля, нужный маршрут разлетается со свистом.
/interface bridge add name=Loopback_L2TP_clients
/ip address add address=10.0.2.254/24 interface=Loopback_L2TP_clients network=10.0.2.0
/routing ospf interface-template add area=local interfaces=Loopback_L2TP_clients networks=10.0.2.0/24 passive