MikroTik L2TP/IPsec сервер не отправляет маршрут клиенту
После двух дней мучений, готов признать что хвалёный MikroTik не справился с простой задачей, которая на Keenetic Ultra II решается в пару кликов. Возможно, это вовсе не связано с недоработками в RouterOS, а у меня просто не хватило терпения или знании, чтобы заставить L2TP/IPsec на «микротике» добавлять маршрут клиенту при соединении.
Полазив по тематическим форумам и wiki, посвященных настройке оборудования MikroTik, найти решения так и не удалось. Собственно, в чём суть проблемы? При подключении к L2TP/IPsec серверу, клиент не видит компьютеры локальной сети за ним, впрочем как и самого роутера. Пинги дальше виртуальной сети не проходят.
Решение 1: Отправлять весь трафик клиента через VPN
Если в настройке соединения на клиенте указать что следует «Отправлять весь трафик через VPN», локальная сеть за роутером прекрасно видится. Но в этом случае мы гоним весь собственный трафик, вместе торрентами и прочим барахлом через удалённый офис, где запущен L2TP/IPsec сервер. Зачем это всё, если нам требуется просто получить доступ к терминальному серверу в удалённой сети?
Windows 10 по умолчанию заворачивает весь трафик в VPN канал при создании подключения. Проверить это можно открыв свойства протокола IP версии 4 (TCP/IPv4) и в дополнительных параметрах TCP/IP будет активирован пункт «Использовать основной шлюз удаленной сети».
Решение 2: Прописать дополнительный статический маршрут на клиенте
Странно, но по всей видимости, MikroTik не умеет самостоятельно отправлять дополнительный маршрут клиенту при подключении к L2TP/IPsec серверу. Замечу, что Keenetic Ultra II прекрасно справляется с аналогичной задачей и поднять на нём L2TP/IPsec сервер может обычный пользователь. Лишний раз убеждаюсь, что «микроты» придуманы, чтобы наполнять жизнь упоротых любителей копания в настройках смыслом.
Раз не получилось сотворить задуманное в настройках L2TP сервера, придётся добавить требуемый маршрут к удалённой сети на клиенте ручками. Для примера, пусть локальная сеть за MikroTik будет 192.168.88.0/24 и local-address L2TP/IPsec сервера 10.8.0.10:
sudo route -n add 192.168.88.0/24 10.8.0.10
Как ни крути, но такое решение тоже "костыль". И как бы не утверждали на одном из форумов по настройке "микротов", что заворачивать весь клиентский трафик в VPN канал благо, я с этим не согласен. Потому буду рад, если кто напишет как заставить MikroTik самостоятельно назначать маршруты клиентам вместе с выдачей IP.
- Manual:Interface/L2TP https://wiki.mikrotik.com/wiki/Manual:Interface/L2TP






Комментариев: 37
А не проще взять Д-линк или другой нормальный роутер ?
Сергей, не подскажете что подразумевается под "нормальными" роутерами? На Keenetic данная конкретная задача решается проще, но микротик, как ни крути, более функционален.
Я не надеялась, но обновление решило проблему. Спасибо огромное
длинк давно перестал быть нормальным....
Была задачи в филиальной сети заменить роутеры на DD-WRT в которых уже использовался OpenVPN. Приобрели хваленый микротик, т.к. в нем заявлена поддержка OpenVPN. И что же оказалось - она есть, но куцая и нам не подошла, т.к нам бы пришлось все переделывать. Взяли Zyxel Keenetic, а вот там поддержка OpenVPN оказалась той что нужно. На них и остановились. Keenetic'и замечательно справляются со свое задачей не только с OpenVPN, но и без особых заморочек строить туннели Ipsec.
правила надо было прописавать и masquerade настроеть под vpn. и все на тиках ходит....
Павел, не подскажите какие именно правила отправляют маршрут клиенту? и как на это влияет masquerade?
вот правила для фаервола
пускаем IP нашего VPN-пула в локалку:
По-умолчанию masquerade настроен для физического WAN-интерфейса(sfp1/ether1 и тд) , а нам надо запустить все через L2TP
Делаем следующее правило:
Еще есть ньюанс, что локальные интерфейсы в бридже надо перевести в proxy-arp
Павел, а вы сами пробовали так делать? Как это влияет на отправку маршрута клиенту?
Совершенно дилетантский подход к настройке железа. Ды, сударь, с кошками или джунами работали? Прежде чем написать статью - загуглите что и как настраивается, дело двух строк (и вам уже подсказали их) . А то круто получается: графоманством пострадать - норм, время есть, а в гугле настройку канала найти - "ай-яй-яй, микрот гавно"
Роман, ну а вам что мешает написать эту пару строк настроек сюда, раз так хорошо владеете гуглом? Готов признать себя дилетантом, если поделитесь вашим тайным знанием.
dre@mer, а на хрена? Статью написать, хайпануть, получить бабло за просмотр - это мы запросто, а изучить матчасть по настройке железа - "нафиг надо, хомячки схавают". Тем более, что вам уже подсказали как это сделать.
Роман, отвечу в вашем стиле: "Все пи##Rасы, один я Дартаньян..." Ну а по сути, вы сами пробовали то что написано? Почитайте внимательно о чём статья. Проблема в том, что "микрот" не умеет отправлять маршрут клиенту при L2TP/IPsec, как Keenetik. Поэтому и приходится заворачивать весь пользовательский трафик в канал.
И насчёт хайпа... вы реально считаете данную тему хайповой и что на ней можно заработать? Да она интересна только узким специалистам.
если бы я не обслуживал парк порядка 30 микротов в 8 офисах, двух датацентрах (site-to-site ipsec, обычные l2tp каналы (с шифрование и без) , включая l2tp дублирующие, с распределенной маршрутизацией) - я бы молчал. Суть моего негодования сводится к тому, что не разобравшись с матчастью клепается чудо-статейка о том, какое говно этот микрот, и ничего он не умеет *рукалицо*.
И, да, у меня все прекрасно работает, только дело в том, что микрот отправляет клиенту дефолт (если в курсе что это) , а сам трафик рулится маршрутам уже на микроте, и там его можно завернуть в любую дырку, но важно ещё понимать принцип работы firewall. А сравнивать его с длинком или зухелем, млять, это как сравнить инвалидку и болид формулы-1: и то и то машина, но какая разница между ними....
За сим откланяюсь. Если написанное мной дошло до вас, и вы поняли что в статье вы категорически неправы, и по стараетесь изучить матчасть - я буду рад. Если нет - то продолжать дискуссию вообще не имеет смысла.
Роман, я очень рад что вы освоили дефолтные маршруты, только статья не об этом
Сколько баталий, интриг и войн. Предложение с firewall и nat это лишние костыли, все гораздо проще решается. Микротик умеет выполнять данное требование, желательно пройти курс MTCNA, после которого все вопросы данного рода отпадут. PPP - Secrets, когда создаете запись, в этой записи есть такая настройка, как Routes, именно здесь и указывается необходимая Вам сеть, куда надо попасть. Эта сеть добавляется в таблицу маршрутизации микротика и после и все запросы к этой сети, будут отправляться через local ip l2tp микротика. Easy win
Вы путаете, я знаю про поле Routes и в нём прописывается сеть клиента, который подключается к L2TP серверу, а вот отправлять маршрут клиенту, Mikrotik пока не умеет. Не верите мне, почитайте форумы или задайте вопрос преподавателям курсов. Возможно это будет решено в 7-ой версии прошивки.
Вы неправильно понимаете работу поле Routes. Оно прописывает дополнительный маршрут, куда должны попадать пакеты через vpn туннель. Маршрут на клиенте не будет появляться, но когда вы сделаете запрос к этой сети, пакет отправиться на шлюз local ip l2tp микротика, а там уже будет динамическая запись к вашей сети, куда надо попасть. Я эту схему реализовал, это работает. А вы вместо того, чтоб спорить, возьмите и проделайте. Если в боевую сеть страшно запускать, тогда соберите стенд с одним микротиком и проверьте.
Более детально распишу. К примеру, у нас есть локальная сеть 192.168.1.0/24
подключенная к ether2 микротика. Так же есть сеть 192.168.2.0/24, подключенная в другой порт, порты между собой независимы. Для сети 192.168.1.0/24 на микротике Вы создаете туннель, допустим, loсal ip 10.0.0.1 and remote ip 10.0.0.2. Так вот, чтобы из сети 192.168.1.0/24 попасть в сеть 192.168.2.0/24, мы прописываем в это поле Routes 192.168.2.0/24. После того, как клиент подключиться по впн, в таблице маршрутизации появится динамическая запись о сети 192.168.2.0/24 через созданный туннель. А маршрутизатор в свою очередь знает о сети 192.168.2.0/24 и как туда добраться. Соответственно компы из сети 192.168.1.0/24 смогут увидеть сетку 192.168.2.0/24
Каким образом клиентская машина поймёт, что пакеты для другой, неизвестной ей сети, следует отправлять именно в VPN-канал, если такого маршрута у клиента нет? Ещё раз обращаю внимание, что он НЕ ЯВЛЯЕТСЯ ШЛЮЗОМ ПО УМОЛЧАНИЮ!
И уж поверьте, я не раз проверил что там передаётся, а что нет.
Что могу сказать, плохо вы проверяли. Клиентская машина отправляет пакет в Вашу необходимую сеть, машина видит, что такой сети она не знает, поэтому отправляет на шлюз l2tp local ip микротика. А сам уже микротик знает про этот маршрут и доставит его именно в нужную сеть, таким же образом пакет вернется обратно к источнику.
Я смотрю, что Вы любите спорить. Вам отписываю готовое решение, а Вы его не можете реализовать. Если не хватает знаний в микротике, либо идите обучайтесь, либо пользуйтесь железкой Keenetic
Данное утверждение справедливо в случае, когда VPN-интерфейс выступает шлюзом по умолчанию. Так что это не мне не хватает знаний по микротикам, а вам по сетевой маршрутизации, либо вы упорно игнорируете то, о чём я пишу.
Мне кажется вы пытаетесь описать ситуацию с объединением сетей, где клиентами выступают сами микротики и являются шлюзами для локальных сетей за ними. Тогда, действительно, все запросы идут к ним.
Я же пишу о L2TP/IPsec клиенте непосредственно на удалённых клиентских машинах, когда у них уже есть настроенный шлюз по умолчанию и соединение устанавливается из любой точки мира, где имеется выход в интернет.
Я заведомо подразумевал, что галочка на клиентской машине по Вашим требованиям должна быть выключена. Вот Вы и дальше продолжаете со мной спорить, гораздо эффективнее было бы, если Вы попробовали реализовать. Выключайте галочку на клиентских компах и добавьте routes.
Все выше сказанные посты имеют свою правду. Дело в том, что я столкнулся с приблизительно такой же проблемой. При создании VPN L2TP Server Mikrotik с использованием IpSec и VPN клиенте Windows без использования основного шлюза в удаленной сети, локальная сеть за сервером L2TP недоступна через сеть сделанную для VPN соединения. Добавление постоянных маршрутов на клиенте решало эту проблему, но при разрыве VPN соединения и при установке нового соединения сеть была не доступной. Решение оказалось простым. Необходимо сделать маршрут в созданном VPN в локальную сеть за микротиком. Что для этого необходимо:
1. Для каждого пользователя VPN назначить ip address клиента и сервера, т.е. в PPP Secret указать в поле Local Address -это адрес сервера при создании тунеля из пула адресов созданных для данного VPN, в поле Remote Address - это адрес клиента. При установке VPN пользователи будут получать именно те адреса которые вы укажите.
2. В поле Routes указать сеть куда необходимо маршрутизировать трафик (локальная сеть за микротиком).
3. Прописать постоянный маршрут на Windows VPN-клиенте через адрес полученный при установке VPN.
Люди добрые, почитал эту ветку и ужаснулся.
А для чего на микроте протоколы динамической маршрутизации RIP, OSPF?
Любой маршрут можно передать клиенту, ничего руками прописывать не надо.
Кому интересно, пишите.
Расскажите как это настраивается в данном случае?
Включите прослушиватель RIP на винде.
Создайте server binding для vpn клиента.
Запустите протокол RIP на роутере Routing-Rip-Interfaces - добавьте интерфейс vpn клиента, далее в Networks пропишите ip адрес туннеля vpn клиента и там же анонсируйте маршрут (подсеть), который хотите передать. Вот и всё!!!
Доброго времени суток! Комментатор 184, а как быть mac os и ios
Тоже бился с данной проблемой, пока добрые люди с чатика Mikrotik Training ссылкой не поделились на доку. https://mum.mikrotik.com/presentations/KZ18/presentation_6153_1539617171.pdf
хех, и как мне допустим к 9.9.9.9 на клиенте получить доступ через vpn, а потом к 34.34.34.34 и т.д при снятом флаге что весь трафик через vpn
DHCP сервер Микротика никак не заставить работать с PPP, а вот направить запрос DHCPInfo из PPP на другой DHCP сервер в сети предприятия -- можно. На этом сервере настраивается область, из которой никаких IP рааздаваться не будет, но можно раздать маршруты (опция 121) и суффикс DNS, чтобы на рабочие компьютеры ходить по коротким именам. Работает с любым PPP интерфейсом, проверено
Делается примерно так:
/ip firewall nat add action=dst-nat chain=dstnat \
dst-address=255.255.255.255 dst-port=67 in-interface=all-ppp protocol=udp \
src-address= to-addresses=
/ip firewall raw add action=notrack chain=prerouting
dst-address= protocol=udp src-address= \
src-port=67
На сервере по адресу поднимаем DHCP для области (адреса реально раздаваться не будут, их раздаст Микротик), задаем нужные опции и радуемся.
Лучше бы, конечно, если бы сам Микротик это умел, но разработчики отвечают, что DHCP с PPP никогда работать не будет, поскольку в PPP не бывает бродкаста. На самом деле с подачи Майкрософта все распространенные PPP-клиенты выдают запрос DHCPInform на бродкаст (255.255.255.255). И он доходит до PPP-сервера (а куда ему еще деваться), и если сервер ответит -- полученные опции используются! Насколько я знаю, именно так всегда раздаются маршруты в PPTP, L2TP и т. д. (кроме OVPN). Самое смешное, что и в RRAS от MS тоже нужно трясти бубном, чтобы это заработало! Но там удается использовать DHCP на самом сервере удаленного доступа, установив Loopback Adapter. (Не тот loopback, который 127.0.0.1, а отдельный драйвер, эмулирующий Ethernet, на который можно DHCP повесить!). На Микротике аналога я не нашел.
Угловые скобки вместе с содержимым съелись :(. В первом правиле to-address и во втором правиле src-address -- адрес сервера DHCP. В первом правиле src-address и во втором dst-address -- диапазон адресов клиентов PPP.
у меня такая же проблема. мучаюсь уже третий день. нечего не выходит. тунель между роутерами работает. а между микротик виндовсу без использования шлюжа не пингуется сервер.
И не поможет. Задавал вопрос про отправку маршрута клиенту с Микротика сертифицированным тренерам по программе обучения микротов и там сказали, что никто не заявлял такого функционала. Так что увы, Кинетики оказались лучше, хоть и подороже.
Комментатор 198, сделайте бридж, в профиле впн(на микроте) настройте добавление в этот бридж, после на микроте надо настроить Routing-RIP, при настройке RIP используйте тот бридж который сделали для впн, на винде установить прослушиватель RIP, и если есть брандмауэр(или какие-либо антивирусы), то открыть порт udp 520.
https://www.youtube.com/watch?v=JgsN_qPnEBw
https://www.youtube.com/watch?v=kRvDgudmMFo
Ни L2TP, ни L2TP IPsec, ни PPTP, ни SSTP не умеют push route в принципе. То, что у вас работает на кинетике - это кинетик даёт интернет через себя. Чтобы так же было на микротике, нужно настроить правильно nat.
Push route умеет ТОЛЬКО OpenVPN и IKEv2, а так же сторонние протоколы и приложения типа циско коннект.