Jump to content
Калькуляторы

Передать DHCP option 121 L2TP

Всем привет!

 

Такая ситуация:

 

Микротик в качестве маршрутизатора, VPN-сервера.

 

WinServer 2012 - AD, DHCP.

 

Офис - 192.168.0.0/23, впн - 192.168.5.0/24

 

Настроил релей на микротике, vpn (l2tp) сервер, объединил локалку и l2tp в бридж. Компьютеры в офисе видят впн-компьютеры по адресам подсети 192.168.5.0/24 (по Local ip).

С впн-компьютеров не видно подсети 192.168.0.0/23 (роут не создается).

Попробовал сделать scope на windows server 2012 в dhcp оснастке - по снифферу не вижу чтобы что-то ходило в момент подключения впн (не приходят dhcp option-ы).

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

Прежний шлюз на Forefront работал также (релей) и передавал 121 option l2tp клиентам без проблем. Не понимаю в чем ошибка в микротике.

Edited by MetrS

Share this post


Link to post
Share on other sites

Что-то я не понял. В соседней теме кто-то хвастал результатом:

Тоже возникла такая проблема, используется Mikrotik CCR1036-8G-2S+ в качестве замены Forefront-у.

 

1) Оставил DHCP на Windows server 2012 R2

2) Настроил релей на микротике, указав бридж в interface

3) Создал pool для L2TP

4) Объединил в бридж локалку (порт микротика, который закоммутирован в главсвитч) и L2TP (в настройках профиля L2TP (PPP)).

5) Разрешил форварды между подсетями, разрешил новые входящие соединения для подсети L2TP.

6) В настройках DHCP Windows server 2012 R2 указываем 121-й option: http://prntscr.com/dg0ula

 

Теперь маршрут передается клиенту windows без проблем через релей: http://prntscr.com/dg0vnf

Edited by nkusnetsov

Share this post


Link to post
Share on other sites

Что-то я не понял. В соседней теме кто-то хвастал результатом:

Тоже возникла такая проблема, используется Mikrotik CCR1036-8G-2S+ в качестве замены Forefront-у.

 

1) Оставил DHCP на Windows server 2012 R2

2) Настроил релей на микротике, указав бридж в interface

3) Создал pool для L2TP

4) Объединил в бридж локалку (порт микротика, который закоммутирован в главсвитч) и L2TP (в настройках профиля L2TP (PPP)).

5) Разрешил форварды между подсетями, разрешил новые входящие соединения для подсети L2TP.

6) В настройках DHCP Windows server 2012 R2 указываем 121-й option: http://prntscr.com/dg0ula

 

Теперь маршрут передается клиенту windows без проблем через релей: http://prntscr.com/dg0vnf

 

Нет, там я ошибся. Удалил пост, спасибо.

Share this post


Link to post
Share on other sites

Послушал wireshark-ом, не уходят bootp на DHCP. Бьются о 255.255.255.255 и все.

Добавил в бридж отдельный порт микротика, релей отрабатывает на ура. Уходит на DHCP и возвращается, дает нужный IP и опции.

В общем, проблема сузилась до того, чтобы разрешить l2tp пользоваться релеем.

Share this post


Link to post
Share on other sites

MetrS, ну не летят broadcast-ы в туннелях точка-точка, DHCP потому там и не живёт. Технология такая, увы. Потому же и нормальный dhcp-релей проблему решить не должен. Он не "поймает" запрос от клиента.

Посмотрите на описание протоколов точка-точка. Там рулят специфические LCP, NCP, IPCP.

При наличии DHCP-сервера на одном хосте с RRAS, можно разве что использовать общий пул адресов. Не более.

Edited by nkusnetsov

Share this post


Link to post
Share on other sites

MetrS, ну не летят broadcast-ы в туннелях точка-точка, DHCP потому там и не живёт. Технология такая, увы. Потому же и нормальный dhcp-релей проблему решить не должен. Он не "поймает" запрос от клиента.

Посмотрите на описание протоколов точка-точка. Там рулят специфические LCP, NCP, IPCP.

При наличии DHCP-сервера на одном хосте с RRAS, можно разве что использовать общий пул адресов. Не более.

Спасибо за информацию.

Интересно, почему тогда такая возможность работает в связке Forefront(Relay, VPN)+WinServer 2012 (DHCP, scope for 192.168.4.*/24)? http://prntscr.com/dgux6o

Там какие-то особо родственные отношения семейства windows? :)

Share this post


Link to post
Share on other sites

MetrS, предполагаю, нативный MS-VPN-сервер делает от своего имени DHCP-запрос и ретранслирует как-то клиенту.

За одно такой подход решает вопрос proxy-arp, т.к. клиентский IP свяжется с MAC VPN-сервера, ибо "hardware address" на туннельном интерфейсе как бы нет.

Это надо вдумчиво ковырять wireshark-ом, но практической пользы не даст.

 

Есть альтернативное решение для виндовых vpn-клиентов (для маков не пробовал. возможно тоже работает): поднять на клиентском интерфейсе "слушатель RIP". На микротике запустить RIP, чтобы анонсировал сети. Винда начиная с XP и выше примет маршрут по RIP и будет использовать его.

 

Второй вариант: выдавать vpn-клиентам адреса и той же подсети 192.168.0.0/23. Правда винда считая себя "шибко умной" автоматом прикрутит к интерфейсу классовый роут 192.168.0.0/24 и эта подсеть будет доступна. Надо будет еще proxy-arp включить на LAN-интерфейсе.

 

P.S. У Вас подводные грабли лежат в дизайне сети - если клиент окажется за каким-нибудь "домашним" роутером у которых подсеть часто именно 192.168.0.0/24, то будет конфликт маршрутов. И тут пофигу mikrotik, forefront или еще какой tmg

Советую сменить адресацию пока не стало совсем поздно. И лучше на 172.16.х.х - тогда с удаленным доступом проще.

Edited by nkusnetsov

Share this post


Link to post
Share on other sites

Было время, мутил СМАК на pptp подключении и запускал routes.cmd с нужными маршрутами, сейчас такой колхоз очень не хочется делать.

Более красивый вариант, конечно, через RIP, даже с условием вмешательства в компоненты windows. Попробую.

С подсетью 192.168.0.0/23 никаких проблем за 5 лет работы небыло, как я уточнил у предыдущего админа, с домашними роутами тоже, но согласен - использовать в офисе такую адресацию не стоит. я бы перевел на 10.0.

Спасибо!

Share this post


Link to post
Share on other sites

Нарыл пост за 2011 год:

 

"Микротик такое не умеет (там голый IPCP для ppp-интерфейсов), выставлять DHCP в тоннель умеет Cisco, Windows Server и OS X. Под Linux/FreeBSD рабочей реализации тоже не встречал."

Share this post


Link to post
Share on other sites

Решили уйти с L2TP и переходить на OpenVPN c блекджеком сертификатами, пора расти :)

Share this post


Link to post
Share on other sites

MetrS, OpenVPN работает медленнее, т.к. в реализации MikroTik это только TCP, а сами потроха OpenVPN работают в user space и имеют меньший приоритет при дележе ресурсов процессора. Так, что "расти" тут термин весьма сомнительный.

К тому же ставить сторонний ("несертифицированный", "не прошедший спецпроверку") софт на клиентские компьютеры - иногда это просто запрещено политикой безопасности.

Edited by nkusnetsov

Share this post


Link to post
Share on other sites

MetrS, OpenVPN работает медленнее, т.к. в реализации MikroTik это только TCP, а сами потроха OpenVPN работают в user space и имеют меньший приоритет при дележе ресурсов процессора. Так, что "расти" тут термин весьма сомнительный.

К тому же ставить сторонний ("несертифицированный", "не прошедший спецпроверку") софт на клиентские компьютеры - иногда это просто запрещено политикой безопасности.

Да, гораздо медленнее. Задержки до 250 мс, хотя при L2TP - 9 мс. UDP рулит. Будем надеяться, что MT сделают UDP в OpenVPN. Остались на L2TP, сделал для клиентов SFX архив с скриптом внутри, который заносит в планировщик задач запуск роутов нужных при подключении. Разослал по пользователям, вроде работает.

 

Странно с МТ работать - вроде крутая железка, а элементарных вещей нет... За что не схватись - там сыро, там нельзя ничего сделать, тут не ходит, там не плавает.

Share this post


Link to post
Share on other sites
Странно с МТ работать - вроде крутая железка

Вы ошибаетесь.

Share this post


Link to post
Share on other sites
Странно с МТ работать - вроде крутая железка

Вы ошибаетесь.

Перед покупкой https://routerboard.com/CCR1036-8G-2Splus за овертыщ рублей, мы излазили все что можно и изучали возможности роутера, но вот такие подводные камни не находили.

Учимся на своих ошибках, короче.

Share this post


Link to post
Share on other sites

Почитайте данный форум. Здесь кладезь информации. По микротику тоже. Со всеми его плюсами и минусами.

Share this post


Link to post
Share on other sites

Почитайте данный форум. Здесь кладезь информации. По микротику тоже. Со всеми его плюсами и минусами.

Да, спасибо. Форум и вправду замечательный.

Share this post


Link to post
Share on other sites

Понимаю, что тема старая, но несмотря на прошедшие годы, вопрос все еще актуальный. Мне удалось заставить это работать, но с внешним DHCP сервером (на Windows 2012). На Микротике делаем правило dst-nat, транслирующеее  broadcast (прямо пишем 255.255.255.255 в Dst Address) в адрес Windows-сервера. И еще одно правило no-track в raw для обратных пакетов (если не сделать, он честно натит ответ в src=255.255.255.255!).

Разумеется, в правилах нужно обеспечить соответствующую селекцию по адресам PPP пула и протоколу DHCP (UDP client port 68 server port 67). И всё работает!

 

А родной DHCP сервер Микротика принимать сообщения от PPP интерфейсов удалось только через петлю на другое устройство с еще одним NAT-ом. Но это также не заработало, хотя клиент Windows ответ получил (смотрел Wireshark-ом). В данном случае проблема в том, что клиент MS отправляет DHCPInform с HType=10 и HLen=0, и ожидает аналогичное в ответе, а DHCP сервер Микротика возвращает HType=1, Hlen=6 и нули в качестве MAC, как будто это Ethernet.

Share this post


Link to post
Share on other sites
6 hours ago, alex-63 said:

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

Теперь менее актуальный, т.к. MS сделал в виндовс Add-VpnConnectionRoute.

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

 

Share this post


Link to post
Share on other sites

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

Edited by alex-63

Share this post


Link to post
Share on other sites

@alex-63 

 

Согласен, что лучше иметь возможность на стороне сервера управлять этим делом.

Не совсем понял, как вы это сделали, на Микротике для L2TP сервера в профиле либо сервера либо конкретного логина указывается только либо конкретный IP адрес, либо пул адресов на самом микротике. 

Как сделать, чтобы микротик брал этот адрес с DHCP, да еще стороннего ?

Edited by McSea

Share this post


Link to post
Share on other sites

Микротик не берет адрес с DHCP. Microsoft RRAS тоже может использовать статический пул, а может брать с DHCP, причем по умолчанию, насколько помню, берет сразу 20 адресов, у уж потом раздает их клиентам. Клиенты PPP всегда берут адреса c сервера по IPCP и никогда с DHCP. После отработки IPCP, клиент выдает broadcast DHCPInform, чтобы получить c DHCP сервера дополнительные параметры, не предусмотренные IPCP (прежде всего маршруты и доменный суффикс, чтобы можно было писать server вместо server.myfirm.local). Это совершенно независимый процесс. DHCPInform, согласно RFC, специально предназначено для получения сетевых параметров клиентами, получающими IP другим путем (Жаль, что Винда не умеет так по Ethernet, было бы удобно централизованно раздавать сетевые параметры компьютерам со статическими IP).

 

Собственно, нестандартность в этом решении только в том, что вместо настоящего DHCP relay сделан dst-nat (настоящий relay в Микротике не хочет вешаться на PPP так же, как и DHCP server). Оказалось, что, по крайней мере микрософтовскому DHCP по фиг на отсутствие в пакете поля Relay Address, он выбирает область, из описания которой извлекаются опции, по адресу отправителя. На DHCP сервере определил область, совпадающую с пулом PPP на Микротике, но задал исключение на всю область, чтобы никто и не помышлял о том, что отсюда можно какие-то IP брать :).

Edited by alex-63

Share this post


Link to post
Share on other sites
В 30.03.2019 в 16:07, alex-63 сказал:

Понимаю, что тема старая, но несмотря на прошедшие годы, вопрос все еще актуальный. Мне удалось заставить это работать, но с внешним DHCP сервером (на Windows 2012). На Микротике делаем правило dst-nat, транслирующеее  broadcast (прямо пишем 255.255.255.255 в Dst Address) в адрес Windows-сервера. И еще одно правило no-track в raw для обратных пакетов (если не сделать, он честно натит ответ в src=255.255.255.255!).

Разумеется, в правилах нужно обеспечить соответствующую селекцию по адресам PPP пула и протоколу DHCP (UDP client port 68 server port 67). И всё работает!

 

А родной DHCP сервер Микротика принимать сообщения от PPP интерфейсов удалось только через петлю на другое устройство с еще одним NAT-ом. Но это также не заработало, хотя клиент Windows ответ получил (смотрел Wireshark-ом). В данном случае проблема в том, что клиент MS отправляет DHCPInform с HType=10 и HLen=0, и ожидает аналогичное в ответе, а DHCP сервер Микротика возвращает HType=1, Hlen=6 и нули в качестве MAC, как будто это Ethernet.

/ip firewall mangle add action=mark-connection chain=prerouting comment="dhcp request mark for pptp/sstp" dst-address=255.255.255.255 dst-port=67 in-interface=all-ppp new-connection-mark=dhcp passthrough=no protocol=udp
/ip firewall nat add action=dst-nat chain=dstnat comment=dhcp_relay_for_vpn dst-address=255.255.255.255 dst-port=67 in-interface=all-ppp protocol=udp to-addresses=10.0.0.14
/ip firewall nat add action=src-nat chain=srcnat connection-mark=dhcp to-addresses=10.0.0.14

Внешний dhcp сервер 10.0.0.14, все работает.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this