Раздача маршрутов IPv6 клиентам VPN

[ns88ns]

Приветствую.

Вопрос про IPv6 и VPN клиентов. Что-то не соображу, как раздать IPv6 маршруты VPN клиентам. Для простоты настройки (чтоб понять, вообще, оно как делается) использую PPTP. VPN клинт - стандартный, виндовый.

На ROS настроен PPTP server с профилем. Виндовый клиент подключается, получает от сервера IPv6 префикс и пула. В ROS появляется динамический интерфейс, на который автоматически назначается link-local IPv6 адрес. Вроде все гуд. Аутентификация - через радиус, который интергрирован с виндовым NPS. "Использовать шлюз по умолчанию в удаленной сети" - выключено, потому что я не хочу весь трафик форвардить туда.

Какие, вообще, способы есть в ROS раздать IPv6 маршруты клиентам VPN? Гуглевание утверждает, что статическая маршрутизация с ручным прописыванием маршрутов на клиенте спасет меня от всех бед, но мне кажется, что сегодня - это глупости.

[Chupaka]

Бодрого дня.

Для раздачи маршрутов в PPTP Microsoft использует расширение в виде DHCP over PPTP, которое в RouterOS не реализовано.

Похоже, единственный способ передать какие-либо маршруты от RouterOS клиенту VPN - это Mode Config в IPSec (ну, может, ещё RIP поднять - винда ж в него умеет?), но и у него, похоже, проблемы с IPv6.

[ns88ns]

Ну, в общем-то да, для IPv4 - только RIP плучается, а для IPv6 - практически и нет ничего.

[ns88ns]

Вот тогда по другому спрошу: a есть ли способ пробросить (фрварднуть) бродкаст/мультикаст от ВПН клиента в LAN? Про BCP я знаю, но виндовый VPN клиент его не поддерживает, поэтому ppp интрефейс в бридж не добавить.

Еще как-то можно это сделать?

[Chupaka]

Я таких путей не знаю. А винда вообще будет слать бродкаст-мультикаст в PPP-интерфейс? Ведь бродкаст и мультикаст определяются, строго говоря, по MAC-адресу (у бродкаста FF:FF:FF:FF:FF:FF, у мультикаста первый бит в первом октете - единичка, как помню), а в PPP никаких MAC-адресов нет...

[ns88ns]

DHCP over PPTP в Винде - он, фактически, over PPP и работает через бродкаст, но не на L2. Виндовый VPN клиент отправляет DHCP Discovery (для IPv4) в PPP линк на 255.255.255.255 и его можно увидеть на PPP интерфейсе в ROS. Для IPv6 она делает то же самое, только отправляет DHCP Solicit на мульткаст ff02::1:2, и он, тоже, ловится на PPP интерфейсе в ROS. Но, так как в этих запросах есть SRC_IP, то ответы уже приходят юникастом. Так что, да - именно это она и делает.

Я просто тут подумал, что если бы был способ перенаправить этот трафик в ЛАН, то можно было бы обмануть ROS, замкнув исходящий ЛАН порт на другой (не бриджовый), где уже и поймать этот трафик DHCP релеем или сервером.

Но, кажется, без бриждевания PPP интерфейса и LAN интерфейса - ничего не получится. А без BCP этого не сделать.

На RRAS я такое делал в качестве экперимента, но там надобности в таких мутках нет, там можно на PPP линк повесить DHCP релей. А ROS такого делать не позволяет. Совственно, в этом и проблема, из-за чего DHCP over PPP в ROS не реализуем.

Впрочем, это не решит проблему раздачи маршрутов для IPv6, потому что ROS не умеет в router advertisement непосредственно на PPP линках. Т.е. без бриджевания, все равно, не обойтись.

Из рабочих вариантов получилась только схема из трех шлюзов:

- ROS для S2S соединений, как по мне лучше ROS этого никто не умеет, но он не может полноценно ни в виндовые VPN клиенты, ни в IPv6.
- RRAS для P2S VPN, потому что он лучше всех умеет в виндовые VPN клиенты, но S2S у него сильно хуже, чем в ROS. Вернее, он в S2S умеет, и очень не дурно, но только, когда на другой стороне тоже RRAS. Или линукс - его тоже можно более-менее обучить спариванию с RRAS. Иначе - боль и страдания.
- pfSense для IPv6 PBR/NPT, потому что этого не умеет ни ROS, ни RRAS, но ограничен в VPN серверах и S2S туннелировании.

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