+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Сервер L2TP не выдаёт клиенту шлюз по умолчанию — почему?

Сервер L2TP не выдаёт клиенту шлюз по умолчанию — почему?, RouterOS

KTamas

Guest

02.08.2018 13:45:00

Привет, я новичок в RouterOS, так что извиняюсь, если вопрос очень простой. Я гуглил, но ничего не нашёл. У меня стоит версия v6.43rc44. Настраиваю L2TP сервер с аутентификацией через Radius на Windows Server. Пользуюсь этим руководством: https://mum.mikrotik.com//presentations/LB16/presentation_3651_1466423579.pdf

Что работает:
[ ] Radius работает, долго мучился, но запустил.
[ ] Могу войти и получить IP-адрес.
[*] Могу пинговать роутер.

Что не работает:
[ ] VPN не в режиме «split», при подключении к VPN пропадает интернет (это клиентская настройка?).
[ ] Клиент не получает шлюз по умолчанию.

Что настроено:
IP роутера — 10.0.0.103, большинство локальных клиентов находятся в пуле 10.0.1.0/24, для них есть маршрут 10.0.0.0/22 с расстоянием 0. Также у нас настроен OpenVPN на 10.8.2.0/24, который маршрутизируется с расстоянием 1 через шлюз 10.0.0.250, и он работает. Пул L2TP настроен на 10.0.70.0/24 с такими же маршрутами, расстояниями и шлюзом, как и у OpenVPN, чтобы повторить его настройки. Однако шлюз не приходит, вот вывод ipconfig /all:

PPP adapter VPN:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : VPN
Physical Address. . . . . . . . . :
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
IPv4 Address. . . . . . . . . . . : 10.0.70.11 (Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.255
Default Gateway . . . . . . . . . : 0.0.0.0
DNS Servers . . . . . . . . . . . : 10.0.0.254
NetBIOS over Tcpip. . . . . . . . : Enabled

Честно говоря, не знаю, что делать дальше, не вижу нигде в RouterOS настройки для шлюза по умолчанию. Буду благодарен за любые советы. Спасибо!

pe1chl

Guest

17.12.2019 13:11:00

Вики-страница описывает сценарий (с двумя сетями), который работает с proxy arp, но явно не говорит, что тот же самый ARP-ответ отправляется и на запросы ВНУТРИ сети. Документация Linux сообщает, что настройка proxy arp заставляет маршрутизатор отвечать на ВСЕ ARP-запросы. Опция local-proxy-arp делает то же самое, но только для ARP-запросов с адресом назначения внутри той же подсети. При этом он всё равно отвечает на ВСЕ такие ARP-запросы, даже от систем, которые могли бы ответить сами. Вероятно, разработчики не хотят менять поведение proxy arp, потому что это непредсказуемо нарушит множество конфигураций с VPN-пользователями внутри подсети (как у автора темы), даже если такое поведение было бы более соответствующим стандартам. Но реально было бы полезно иметь опцию local-proxy-arp, которая отвечает только тогда, когда это действительно нужно, то есть когда маршрутизатор знает, как переадресовать трафик на этот IP без использования напрямую подключённого маршрута для подсети (для которого считается, что другие системы тоже его используют). Заметьте, что local-proxy-arp изначально не для этого, он был задуман для случаев, когда локальная сеть не поддерживает широковещание, и клиенты не могут «слышать» ARP-запросы друг друга (например, в сетях доступа, где администраторы хотят экономить IP-адреса). Кстати, в RouterOS можно более детально управлять обработкой ARP с помощью фильтров на мостах.

zespri

Guest

10.12.2019 07:23:00

Как клиент узнает шлюз по умолчанию для сети, если роутер его не сообщает? У меня тут такая же проблема: в настройках подключения VPN L2TP Server на MikroTik включена галочка «использовать шлюз по умолчанию в удалённой сети», но Windows показывает шлюз по умолчанию как 0.0.0.0. Аналогичная конфигурация с pfSense вместо MikroTik у друга работает отлично... Интересно, что есть прямо противоположная тема: «Не навязывать шлюз по умолчанию VPN-клиентам Windows». Значит, похоже, у некоторых это действительно работает. Интересно, как так получилось…

pe1chl

Guest

10.12.2019 09:10:00

L2TP — это PPP-соединение, у него есть два IP-адреса: сервера и клиента. После того как клиент устанавливает соединение, при желании задать маршрут по умолчанию, он ставит его на адрес сервера (тот самый, который получил при подключении). Вот почему опция установки маршрута по умолчанию есть только на стороне клиента, а сервер в этом не участвует. При этом существуют фактически принятые способы настройки маршрутов для такого соединения, потому что часто нужно направлять через VPN один или несколько подсетей, а маршрут по умолчанию оставлять для выхода напрямую в интернет. Существует несколько вариантов таких «стандартов», например, Windows отправляет DHCP-запрос по соединению, чтобы получить список подсетей для маршрутизации через VPN. В последних версиях MikroTik, похоже, тоже умеет с этим работать (личного опыта у меня с этим нет).

nostromog

Guest

10.12.2019 10:20:00

Как ответил @pe1chl, у клиента есть выбор: либо направлять весь трафик (кроме самих туннельных пакетов) через туннель, либо использовать туннель только для самого туннельного трафика. Если ваш клиент отправляет трафик через туннель, а сервер его не маршрутизирует/не делает NAT, значит, проблема в правилах фаервола сервера. Вы можете увидеть весь трафик, который сервер получает от клиента, с помощью команды на сервере вроде /tool sniffer quick interface=(название интерфейса) и проверить, корректно ли сервер маршрутизирует ответы на трафик, правильно ли сделан NAT и так далее.

zespri

Guest

16.12.2019 07:29:00

Большое спасибо за ваши ответы! Думаю, в моём случае шлюз по умолчанию — это ложный след, спасибо за совет про /tool sniffer quick interface=<l2tp-user>, это прояснило ситуацию.

Я домашний пользователь и пытаюсь настроить доступ к моей домашней сети через интернет с Windows 10. Сеть — стандартный hAP ac с подсетью 192.168.88.0/24. Я сделал такие настройки:

/ip pool
add name=dhcp ranges=192.168.88.130-192.168.88.253
add name=tp-pool ranges=192.168.88.110-192.168.88.129

/ppp profile
add bridge=bridge dns-server=192.168.88.1 local-address=192.168.88.109 name=l2tp-profile remote-address=tp-pool

/interface l2tp-server server
set authentication=mschap2 default-profile=l2tp-profile enabled=yes ipsec-secret=somesecret use-ipsec=yes

/ppp secret
add name=tp-secret password=somesecret profile=l2tp-profile service=l2tp

Поскольку я использую local/remote адреса в той же подсети, где и вся остальная сеть, не ожидаю, что нужны будут какие-то специальные маршрутизаторы или NAT.

Когда я запускаю /tool sniffer quick interface=<l2tp-user> и пытаюсь получить доступ к компьютеру в сети с L2TP-клиента, вижу пакеты от клиента, но ответов нет. Клиент в итоге тайм-аутится при попытке достучаться до компьютера в сети. Я могу пропинговать сам mikrotik по адресу 192.168.88.1, но больше ничего. При этом сниффер показывает пакеты в обе стороны.

Что я упускаю?

pe1chl

Guest

16.12.2019 09:13:00

Это предположение неверно! Системы в вашей локальной подсети ожидают, что смогут напрямую обратиться к вашему VPN-клиенту, а это не работает. Нужно поместить клиент в другую подсеть — тогда всё будет нормально. Либо можно включить «proxy-arp» на вашем LAN-бридже.

Anumrak

Guest

16.12.2019 14:52:00

Привет. Мне удалось получить маршруты с DHCP-сервера с определённым параметром через PPTP-сервер, который был запущен в strongSwan на сервере Ubuntu. Но я не знаю, как экспортировать эти маршруты через ROS… Если в этом вообще есть смысл, попробуй почитать форумы про DHCP через PPTP на Ubuntu.

zespri

Guest

16.12.2019 20:03:00

Вам нужно поместить ваш клиент в другую подсеть, тогда всё заработает. У меня получилось. Я изменил конфигурацию на:

/ip pool
add name=tp-pool ranges=192.168.87.110-192.168.87.129

/ppp profile
add bridge=bridge dns-server=192.168.88.1 local-address=192.168.87.109 name=l2tp-profile remote-address=tp-pool

На клиенте с Windows 10 мне пришлось вручную добавить этот маршрут, что очень неудобно:
route add 192.168.88.0 MASK 255.255.255.0 192.168.87.109

Интересно, есть ли способ сделать это автоматически, например через опцию DHCP или что-то в этом роде...

Что меня ещё удивляет — аренда на 192.168.87.0 не отображается во вкладке Leases DHCP-сервера Mikrotik... В каком-то смысле это логично, ведь кажется, что DHCP-сервер Mikrotik вообще не используется для выдачи этих IP, но если нет, то как тогда присваиваются эти адреса?

pe1chl

Guest

#10

16.12.2019 20:48:00

Да, это то, о чём я говорил раньше: проблема с настройкой конкретных маршрутов подсетей на PPP VPN. PPP не использует DHCP. Адрес назначается (либо напрямую пользователю, либо из пула) статически для подключения. В Windows после этого отправляется DHCP-запрос, который может получить другую информацию, например маршруты подсетей, DNS-сервер и так далее. Поэтому можно дополнительно настроить DHCP-сервер на интерфейсе вашего L2TP-сервера и прописать нужные DHCP-опции для его сети. Для этого DHCP-сервера пул не обязателен, но остаются другие стандартные настройки. Чтобы сконструировать маршрут подсети, нужно немного потрудиться и сделать DHCP-опцию в шестнадцатеричном виде. Наверное, по этому вопросу есть некоторые темы, но, как я уже сказал, лично у меня с этим опыта нет. (Я делаю VPN-туннели между роутерами, так что мне не приходится заморачиваться — могу использовать протоколы типа BGP.)

zespri

Guest

#11

17.12.2019 00:44:00

Спасибо, мне нужно будет это изучить. Я тоже пробовал этот способ, и он тоже сработал — огромное спасибо! Но у меня есть ещё несколько вопросов. Есть ли какие-то побочные эффекты от включения «proxy-arp» на моём LAN-бридже? То есть есть ли причина, по которой этого делать НЕ стоит? У меня дома есть вторая подсеть для виртуальных машин, которые запущены на VM-сервере и втором роутере Mikrotik. Без схемы, наверное, звучит слишком расплывчато, но в целом — может ли это создать какие-то проблемы?

Если эта настройка для одного человека, то есть для меня, то, наверное, вместо remote-address=tp-pool для /ppp профиля я могу использовать что-то вроде local-address=192.168.88.109 remote-address=192.168.88.110, а вместо proxy-arp просто добавить /ip arp add address=192.168.88.110 interface=bridge published=yes. Сработает ли это? Есть ли у этого какие-то минусы? Что произойдёт, если я попытаюсь зайти с другого компьютера, когда уже есть активное подключение с другого места?

Если я хочу дать доступ в свою сеть другу, то для него нужно создать отдельный секрет, но /ppp профиль может быть тот же. В этом случае нужен будет пул, а не одиночный удалённый адрес. Смогу ли я использовать тот же локальный адрес? Если использовать пул, то можно взять небольшой, например, из десяти адресов, и добавить все эти десять в опубликованные ARP. Работает ли такой вариант? Есть у него какие-то недостатки?

Наконец, сейчас я занимаюсь настройкой доступа с Windows 10. Меня не особо волнует Windows 7 или 8 и другие версии, но меня интересуют клиенты на Linux и Mac, потому что я часто ими пользуюсь. Поэтому как только настройка на Windows меня устроит, я перейду к тестированию на Linux и Mac. Есть ли что-то, что, скорее всего, не будет работать на этих системах? Является ли L2TP лучшим выбором? Я не стал использовать SSTP, потому что для него нужен доверенный сертификат CA, который надо устанавливать в хранилище сертификатов Windows — а с этим связываться не хочется. OpenVPN не выбрал из-за посредственной производительности и из-за необходимости таскать с собой сертификаты. Так что L2TP показался мне самым очевидным вариантом.

pe1chl

Guest

#12

17.12.2019 09:57:00

Недостаток proxy-arp в основном в том, что на все ARP-запросы отвечает адрес роутера, и внутренняя (в вашей LAN) передача данных может оказаться «прокинутой» через роутер. Из-за этого нагрузка на роутер растёт, а производительность трафика снижается (например, когда файлобанк и рабочие станции активно обмениваются данными, которые обычно передавались бы напрямую). На самом деле, если прописать отдельные ARP-записи в роутере, это решит проблему. Нет необходимости использовать пул. Можно указать «удалённый адрес» в PPP-секрете для каждого пользователя — и этот IP-адрес будет фиксированным для пользователя в VPN. Учтите, что это означает, что соединение упадёт, если один и тот же пользователь подключится более одного раза (с другого устройства или если связь прервётся, а пользователь быстро переподключится, пока роутер не понял, что прежнее соединение действительно оборвалось). «VPN, который всегда работает для всех» — мечта, преследующая нас десятилетиями. Из-за того, что VPN страдает по принципу «Хорошее в стандартах то, что выбрать можно из кучи; а если что не нравится, просто подожди модель следующего года» (знаменитая цитата Энди Таненбаума), вся VPN-тема сейчас превратилась в один большой бардак. На этом форуме вы найдёте кучу тем от людей, которые просят реализовать ещё один протокол VPN.

mbovenka

Guest

#13

17.12.2019 10:37:00

На самом деле этого не должно происходить. Маршрутизатор отвечает на ARP-запросы только для адресов, которые он знает, что не являются локальными, а запросчики, очевидно, этого не знают (иначе они бы не отправляли ARP-запросы). Он не должен отвечать на запросы для локальных адресов, если только его специально не настроить на это (например, с помощью команды ‘ip local-proxy-arp’ в терминах Cisco).

pe1chl

Guest

#14

17.12.2019 11:18:00

К сожалению, всё не работает так просто. Он отвечает на все ARP-запросы, для которых знает маршрут (включая локальные), а дальше всё зависит от времени и поведения клиентов. Например, если сервер отвечает быстрее, чем роутер, клиент может перезаписать свою запись в ARP-таблице ответом от роутера. Есть отдельная настройка local-proxy-arp, но она работает наоборот тому, чего вы хотите в этом случае. Было бы здорово, если бы существовала настройка ARP с возможностью отвечать только на запросы с IP внутри локальной подсети, для которых есть более конкретный маршрут, чем маршрут LAN, но, к сожалению, такой настройки нет.

mbovenka Guest	#15 0 17.12.2019 12:22:00 Привет. Это не соответствует стандарту. RFC925 («Multi-LAN Address Resolution», который фактически описывает proxy ARP, даже если так это не называется) говорит: «Когда любой хост рассылает ARP-запрос по широковещательной рассылке, BOX его читает (как и все хосты в этой сети). Помимо проверки, не является ли он искомым хостом (и ответа, если да), BOX проверяет свой кэш отображений IA:HA, который он ведёт для каждой сети, к которой подключён. Случай 1: если отображение для хоста найдено в кэше именно для сети, из которой пришёл запрос, BOX не отвечает (давая возможность ответить самому искомому хосту)». (Курсив — мой). Именно так это сделано в Cisco IOS (единственной платформе, на которой мне доводилось это использовать). RouterOS же всегда отвечает, словно там включена опция «ip local-proxy-arp»? Это а) плохо и б) не соответствует тому, как я понял https://wiki.mikrotik.com/wiki/Manual:IP/ARP#Proxy_ARP. Но если так оно и работает...

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры