Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

• Главная
• Автоматическое добавление маршрутов для VPN-соединения в Windows

Автоматическое добавление маршрутов для VPN-соединения в Windows

В последнее время значительно вырос интерес к технологиям удаленного доступа для обеспечения работы сотрудников из любого места. Ключевую роль здесь играет VPN, как универсальное и безопасное средство для получения доступа во внутреннюю сеть предприятия. Наиболее привлекательно использовать для этого те протоколы, которые штатно поддерживаются в Windows, что позволяет организовать соединение на любом ПК без установки на него стороннего ПО. Но у данного способа есть одна проблема — добавление маршрутной информации, сегодня мы рассмотрим один из штатных способов, позволяющих легко управлять маршрутами для VPN-соединений.

Стандартные сетевые возможности Windows многим хороши, кроме одного — управление маршрутами для VPN-соединений. Именно это заставляло многих системных администраторов выбирать альтернативные технологии, например, OpenVPN, но это не совсем удобно если речь идет о личных устройствах сотрудников, так как требует установки дополнительного ПО, что, к тому же, не всегда возможно. Кроме того, мы неоднократно сталкивались с ситуациями, когда пользователи удаляли данное ПО, устанавливали конфликтующие приложения, теряли ярлыки для подключения, блокировали его антивирусным ПО и т.д. и т.п.

Подключение средствами ОС в этом плане более привлекательно, так как позволяет снять большую часть указанных выше проблем и подразумевает единообразие пользовательского интерфейса, что позволяет сделать простые и понятные инструкции.

Но вернемся к нашему вопросу. Для добавления маршрутов в удаленную сеть традиционно использовали несколько методов:

• Статическая маршрутизация — на первый взгляд все просто, что прописали руками — то и работает. Но добавление маршрутов требует привилегий администратора, не всегда возможно заранее прописать маршрут из-за отсутствия интерфейса, при переподключении маршруты могут стать недействительными.
• Маршрутизация на основе классов — требует тщательного планирования адресного пространства, нет возможности прокинуть дополнительные маршруты, сложно работать с сетями 192.168.х.х.
• CMAK и различные скрипты — требуют административных привилегий, сложны в настройке, непрозрачны.

В тоже время начиная с Windows 8 существует штатное решение в виде командлета PowerShell, которое позволяет привязать маршруты к VPN-подключению и добавлять их при его запуске, при отключении соединения маршруты будут автоматически удалены.

Запустим консоль PowerShell и прежде всего узнаем имена имеющихся в системе VPN-подключений:

Результатом работы команды будет информация обо всех коммутируемых подключениях, нас интересует поле Name:

Теперь добавим маршрут к удаленной сети для подключения с именем L2TP MT:

где в параметр ConnectionName содержит имя подключения, взятое в кавычки, а DestinationPrefix — необходимую сеть назначения или узел.

Теперь проверим как это все работает. Проверим таблицу маршрутизации при отключенном VPN-подключении и убедимся, что маршруты в удаленную сеть отсутствуют:

Теперь подключимся к VPN-серверу и снова проверим таблицу маршрутизации — в ней появится указанный нами маршрут к удаленной сети:

Если нужно добавить несколько маршрутов — выполняем команду несколько раз. При этом можно добавлять маршруты не только к удаленной сети, но и к определенному узлу, что в ряде случаев более предпочтительно по соображениям безопасности, например:

Данная команда добавит маршрут к узлу 192.168.111.101, к другим узлам удаленной сети доступа у VPN-пользователя не будет.

Чтобы удалить маршрут следует воспользоваться командой Remove-VPNConnectionRoute, синтаксис которой полностью повторяет команду добавления маршрута:

Как видим, современные версии Windows дают нам в руки достаточно простой и удобный инструмент управления маршрутами для VPN-подключений.

Важно! Данные возможности не поддерживаются в Windows 7.

Дополнительные материалы:

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал:

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.

Подписывайтесь на канал Яндекс.Дзен и узнавайте первыми о новых материалах, опубликованных на сайте.

ЕСЛИ СЧИТАЕТЕ СТАТЬЮ ПОЛЕЗНОЙ,
НЕ ЛЕНИТЕСЬ СТАВИТЬ ЛАЙКИ И ДЕЛИТЬСЯ С ДРУЗЬЯМИ.

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.

Если считаете статью полезной,
не ленитесь ставить лайки и делиться с друзьями.

Комментариев: 35

А не проще взять Д-линк или другой нормальный роутер ?

Сергей, не подскажете что подразумевается под «нормальными» роутерами? На 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

Маршрут на клиенте не будет появляться, но когда вы сделаете запрос к этой сети, пакет отправиться на шлюз local ip l2tp микротика

Каким образом клиентская машина поймёт, что пакеты для другой, неизвестной ей сети, следует отправлять именно в VPN-канал, если такого маршрута у клиента нет? Ещё раз обращаю внимание, что он НЕ ЯВЛЯЕТСЯ ШЛЮЗОМ ПО УМОЛЧАНИЮ!

И уж поверьте, я не раз проверил что там передаётся, а что нет.

Что могу сказать, плохо вы проверяли. Клиентская машина отправляет пакет в Вашу необходимую сеть, машина видит, что такой сети она не знает, поэтому отправляет на шлюз l2tp local ip микротика. А сам уже микротик знает про этот маршрут и доставит его именно в нужную сеть, таким же образом пакет вернется обратно к источнику.

Я смотрю, что Вы любите спорить. Вам отписываю готовое решение, а Вы его не можете реализовать. Если не хватает знаний в микротике, либо идите обучайтесь, либо пользуйтесь железкой Keenetic

. машина видит, что такой сети она не знает, поэтому отправляет на шлюз l2tp local ip микротика.

Данное утверждение справедливо в случае, когда 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 \

/ip firewall raw add action=notrack chain=prerouting

dst-address= protocol=udp src-address= \

На сервере по адресу поднимаем 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.

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

И не поможет. Задавал вопрос про отправку маршрута клиенту с Микротика сертифицированным тренерам по программе обучения микротов и там сказали, что никто не заявлял такого функционала. Так что увы, Кинетики оказались лучше, хоть и подороже.