[MetrS]

Всем привет!

 

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

 

Микротик в качестве маршрутизатора, 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 December 8, 2016 by MetrS

[nkusnetsov]

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

Тоже возникла такая проблема, используется 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 December 8, 2016 by nkusnetsov

[MetrS]

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

Тоже возникла такая проблема, используется 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

 

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

[MetrS]

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

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

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

[nkusnetsov]

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

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

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

Edited December 8, 2016 by nkusnetsov

[MetrS]

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? :)

[nkusnetsov]

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 December 8, 2016 by nkusnetsov

[MetrS]

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

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

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

Спасибо!

[MetrS]

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

 

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

[MetrS]

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

[nkusnetsov]

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

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

Edited December 9, 2016 by nkusnetsov

[MetrS]

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

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

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

 

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

[pppoetest]

Странно с МТ работать - вроде крутая железка

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

[MetrS]

Странно с МТ работать - вроде крутая железка

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

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

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

[pppoetest]

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

[MetrS]

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

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

[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.

[McSea]

6 hours ago, alex-63 said:

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

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

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

 

[alex-63]

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

Edited March 30, 2019 by alex-63

[McSea]

@alex-63 

 

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

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

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

Edited March 30, 2019 by McSea

[alex-63]

Микротик не берет адрес с 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 March 31, 2019 by alex-63

[tCD8]

В 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, все работает.