Windows l2tp маршрут по умолчанию

Добрый день!
Версия ОС 6.27.
Настроил подключение client-to-site с помощью L2TP без IPSec.
/ppp secret
add local-address=192.168.255.11 name=laptop password=laptop profile=clients \
remote-address=192.168.255.12 service=l2tp

Подключение с ОС Windows настроил. Проблема в том, что соединение происходит, но доступ к сети за маршрутизатором отсутствует. Доступ появляется только, если я через командную строку на ОС добавляю статический маршрут командой route add 192.168.0.0 mask 255.255.0.0 192.168.255.11 metric 1

Вопрос: можно ли как-то сделать, что бы при подключении Windows-клиента маршрутизатор передавал ему информацию о маршруте автоматически?
Добрый день.
Чтобы передавал автоматически, пока нельзя.
Вы можете попробовать 2 варинанта
1. Установить в Windows в свойствах подключения галку «Использовать как шлюз в удаленной сети»
2. Настроить BCP (Bridge Control Protocol). Тогда компьютер с Windows окажется в общей L2 сети удаленными компьютерами.
Илья, помог первый вариант. Правда в этом случае весь траффик идет через шлюз в удаленной сети, но в целом, заработало.
Спасибо.
Всегда пожалуйста.
Вообще, то что весь трафик в этом случае идет через шлюз в удаленной сети, скорее правильно. Так позволяет централизовать правила работы.
Подскажите, я правильно понимаю, что передать параметры подключения (IP, DNS, маршруты) VPN клиенту, по DHCP RouterOS не умеет ?
Спасибо.
По умолчанию не умеет.
Теоретически можно клиента «засунуть» в бридж, а на бридж повесить DHCP-сервер. Смотрите в направлении BCP.
Но сам так делать не пробовал.
Еще вариант: чтобы не добавлять маршрут на клиенте и чтобы на клиенте можно было отключить «использовать удаленный шлюз», можно выдавать удаленным клиентам адреса из локальной подсети и включить proxy-arp на локальном интерфейсе

Т.е. к примеру локальная сеть 192.168.1.0/24
делаем отдельный vpn_pool 192.168.1.191-192.168.1.199
и потом
add local-address=192.168.1.190 name=laptop password=laptop profile=clients remote-address=vpn_pool service=l2tp
Это не совсем то.
При таком подключении не нужно на стороне клиента прописывать сеть 192.168.1.0/24 и можно лазить по этой сети. Но есть необходимость передать клиенту пути к другим сетям, на пример 192.168.20.0/24 Gateway 192.168.1.250. Через DHCP это можно.
Да, конечно, для такой схемы мой вариант не пойдет.
А вы пробовали вариант, предложенный Ильей?

После того, как был настроен L2TP сервер на Mikrotik, клиенты могут успешно подключаться и работать с удалёнными ресурсами, включая другие подсети, т.к. обычно в настройках L2TP-клиента (Windows) используется удалённый шлюз по-умолчанию и весь трафик клиента идёт через удалённый сервер L2TP, создавая дополнительную нагрузку. Напрашивается логичный вопрос: как этого избежать и что нужно для этого сделать? Ниже я расскажу простые и правильные решения без использования костылей.

Во многих мануалах встречаются такие советы, как ручное прописывание маршрутов на клиентских машинах. Например:

сеть для VPN – 192.168.10.0/24
Удалённый шлюз, соответственно, из этой же подсети 192.16.10.1
Иные подсети, например, основная для офиса – 192.168.20.0/24, до которой необходим доступ.

Пользователь устанавливает соединение, получает адрес из пула 192.168.10.0/24, маршрут по умолчанию – 192.16.10.1 и весь трафик бежит через удалённый сервер и, казалось бы, всё хорошо. Но если на маршрутизаторе настроены лимиты по скорости, какие-то ограничения или же пользователь просто не хочет, чтобы его трафик, который адресован не в удалённую сеть, шёл через VPN? Оно и логично, а потому снимается галочка “Использовать удалённый шлюз” в настройках VPN-соединения под Windows.

Но тут пользователь сталкивается с тем, что остается доступ только до сети 192.168.10.0/24 , а до нужной 192.168.20.0/24 теряется, т.к. маршрут до неё L2TP не передал. Некоторые системные администраторы пишут bat-скрипты, которые пользователи должны запускать: в результате маршруты прописаны и снова всё хорошо.

Но я считаю такой подход костылями: пользователь ничего не должен у себя прописывать, а просто подключается по готовой отлаженной инструкции без всяких скриптов и прописывания чего-то там для него непонятного. Ведь может поменяться сеть, кто-то просто не умеет запускать консоль, у кого-то нет нужных прав на выполнение скрипта – много нюансов может быть.

Думаю, основная проблема понятна. Решений есть несколько:

использование динамической маршрутизации RIP на клиенте
использование классовой маршрутизации

Первый случай является более сложным и правильным – этому можно посвятить отдельную статью. Но в таком случае пользователю так или иначе придётся что-то дополнительно настроить. А потому стоит рассмотреть второй вариант, который более простой, на мой взгляд.

Вся адресация переводится на новую сеть 172.16.0.0/16, в которой может быть 256 подсетей по /24. Среди них нарезаются новые подсети, например:

172.16.1.0/24 – офисная сеть
172.16.2.0/24 – пользователи VPN
172.16.3.0/24 – сервера
& etc…

Теперь пользователь, установив соединение с VPN-сервером, получает маршрут до всей 172.16.0.0/16. Можно спокойно пользоваться ресурсами и в офисной подсети и в серверной и во всех других в рамках 172.16.0.0/16 , т.к. строится классовый маршрут.

В итоге получается всё очень удобно и просто, особенно при планировании сети организации с нуля.

Источник

В современных версиях Windows есть интересная возможность автоматического добавления статических маршрутов при активации определённого VPN подключения. Когда VPN подключение разрывается, данный маршрут автоматически удаляется из таблицы маршрутизации Windows. Для добавления IPv4 или IPv6 маршрута для VPN подключения используется PowerShell командлет Add-VpnConnectionRoute.

Вы конечно, можете вручную в командной строке добавлять нужные маршруты для VPN подключения, но главная проблема в том, что такие маршруты очищаются после отключения от VPN. Поэтому при следующем подключении, вам придется опять руками прописывать маршруты.

Допустим, вы хотите, чтобы через ваше VPN подключение маршрутизировались только пакеты для двух подсетей (192.168.111.24/ и 10.1.0.0/16), а весь основной трафик должен идти через вашего провайдера.

Откройте консоль PowerShell и выведите список всех настроенных VPN подключений в Windows:

Get-VpnConnection

В первую очередь нужно отключить опцию “Use default gateway in remote network” (Использовать основной шлюз в удаленной сети). Это можно сделать в свойствах VPN подключения в панели управления или командой:

Set-VpnConnection –Name workVPN -SplitTunneling $True

Подробнее про SplitTunneling здесь.

Добавим два статических маршрута для нашего VPN-соединения:

Add-VpnConnectionRoute -ConnectionName "workVPN" -DestinationPrefix 192.168.111.0/24 –PassThru Add-VpnConnectionRoute -ConnectionName "workVPN" -DestinationPrefix 10.1.0.0/16 –PassThru

В параметре DestinationPrefix нужно указать подсеть, или конкретный IP адрес хоста, трафик к которому нужно маршрутизировать через VPN. Для добавления одного IP адреса используйте формат 10.1.1.26/32.

DestinationPrefix : 192.168.111.0/24
InterfaceIndex :
InterfaceAlias : workVPN
AddressFamily : IPv4
NextHop : 0.0.0.0
Publish : 0
RouteMetric : 1

Если у вас активно VPN подключение, вам нужно переподключиться, чтобы новые маршруты добавились в таблицу маршрутизации.

Новые маршруты привязаны к VPN подключению и добавляются при его запуске. Когда вы отключаетесь от VPN сервера, маршруты автоматически удаляются.

Отключитесь от VPN и проверьте таблицу маршрутизации. Маршрут к вашей удаленной сети удалился автоматически, а Get-NetRoute вернет, что маршрут не найден:

Get-NetRoute : No MSFT_NetRoute objects found with property 'DestinationPrefix' equal to '192.168.111.0/24'. Verify the value of the property and retry. CmdletizationQuery_NotFound_DestinationPrefix,Get-NetRoute

Вывести список статических маршрутов для подключения:
(Get-VpnConnection -ConnectionName workVPN).Routes

Чтобы полностью удалить статических маршрут для VPN подключения, используйте команду:
Remove-VpnConnectionRoute -ConnectionName workVPN -DestinationPrefix 192.168.111.0/24 -PassThru

Если вам нужно изменить порядок разрешения DNS имен при активном VPN, познакомьтесь со статьей.

В предыдущих версиях Windows (Windows 7/ Server 2008R2) для динамического добавления маршрутов после установления VPN подключений приходилось использовать CMAK и различные скрипты с командами
add route
.

Например, можно создать командный файл vpn_route.netsh для добавления маршрутов.

interface ipv4 add route prefix=192.168.111.24 interface="workVPN" store=active add route prefix=10.1.0.0/16 interface="workVPN" store=active exit

Данный файл нужно запускать через задание планировщика, которое срабатывает на событие установки VPN подключения в Event Viewer (RasMan 20225)

schtasks /create /F /TN "Add VPN routes" /TR "netsh -f C:\PS\vpn_route.netsh" /SC ONEVENT /EC Application /RL HIGHEST /MO "*[System[(Level=4 or Level=0) and (EventID=20225)]] and *[EventData[Data='My VPN']]"

Источник

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

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

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

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

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

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

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

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

Get-VpnConnection

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

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

Add-VpnConnectionRoute -ConnectionName "L2TP MT" -DestinationPrefix 192.168.111.0/24 -PassThru

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

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

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

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

Add-VpnConnectionRoute -ConnectionName "L2TP MT" -DestinationPrefix 192.168.111.101/32 -PassThru

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

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

Remove-VpnConnectionRoute -ConnectionName "L2TP MT" -DestinationPrefix 192.168.111.0/24 -PassThru

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

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

Источник

@Vetal78a said in Маршрутизация l2tp/ipsec при подключении.:

Адресация сети не совпадает.
Если убрать «Использовать шлюз удаленной сети», маршрут не понимает куда ему ходить и начинает искать данный маршрут через wan интерфейс, а не через туннель

@werter said in Маршрутизация l2tp/ipsec при подключении.:

При снятии галки «Использовать шлюз удаленной сети» в Туннель как раз пойдет ВЕСЬ трафик, не относящийся к его лок. сети. Если адресация сети Клиента и сети ЗА пф совпадают — Вам крупно неповезло (

Тема уже поднималась,
https://forum.netgate.com/topic/131703/pfsence-%D0%B8-l2tp/12
@werter, вы даже отписывались в комментариях.

Микрософт придумала хитрый\странный способ для таких случаев
процитирую сам себя:

*Речь о том, что даже со снятой галкой «использовать шлюз в удаленной сети» он все равно будет по умолчанию заворачивать трафик в «серые» сети в туннель. Майкрософт сняла с пользователя проблему передачи маршрутов в своих реализациях VPN и по умолчанию пихает в него все «серые» сети.
За это отвечает другая галка — Disable class based route addition\Отключить добавление маршрута, основанное на классе.
В клиенте в настройках IP эта галка в инверсном виде — Отключить добавление маршрута, основанное на классе. По умолчанию (галка снята) Windows автоматически добавляет на VPN-интерфейс маршрут на соответствуюющую классовую сеть — 10/8, 172./16, 192.168./24
При этом приоритет(метрика) для VPN ставится меньшей и именно поэтому, находясь в LAN 192.168.0/24 клиент Windows может попасть в удаленную сеть с той же адресацией.
Автоматически это может вызвать (и вызывает) проблемы с доступом в собственную LAN — но это уже совсем другая история.
Более того, говорят в некоторых редакциях Windows 10 такой настройки вообще нет, и исправлять при необходимости, надо так:

There is no such option (реально — есть, зависит, вероятно, от версии Windows 10) in Windows 10, so you need to edit the phonebook file in %AppData%\Microsoft\Network\Connections\Pbk\rasphone.pbk
и добавить
DisableClassBasedDefaultRoute=1
https://superuser.com/questions/121528/what-is-disable-class-based-route-addition-good-for*

Реально это работает, но криво — в сети из 10/8 попасть можно (в моем случае — в сети, работающие через OpenVPn (10/8) — можно, в работающие через IPSEC — нет, вероятно потому, что сеть там 192.168/21 а не 192.168/24

@Vetal78a, возможно, поможет передача маршрута через DHCP-options, не знаю, реализовано ли это в PF.
Как вариант — перейти на Open VPN. Получите централизованное (все настройки маршрутов только на стороне сервера), гибкое управление маршрутами как для индивидуальных пользователей, так и для сетей филиалов. Open VPN поддерживается всеми ОС, включая мобильные и большинством роутеров с правильными\альтернативными прошивками.
Для Windows в PF есть пакет экспорта готового инсталлятора, полностью устанавливающее все необходимое для работы клиента.

Источник