Привет, народ! Мы просто в ударе, пытаясь заставить RouterOS/PPC 5.11 нормально работать со статически заданным атрибутом Framed-IPv6-Prefix:. Если это хоть как-то поможет, у нас здесь L2TP/PPP, а не PPPoE/PPP, но базовые концепции одинаковы. Вот базовый PPP профиль:
/ppp profile
set default change-tcp-mss=yes name=default only-one=default remote-ipv6-prefix-pool=none use-compression=default use-encryption=default use-ipv6=yes use-mpls=default use-vj-compression=default
add change-tcp-mss=yes dhcpv6-pd-pool=adsl-dhcpv6-test dns-server=192.0.2.1,192.0.2.2 local-address=192.0.2.254 name=default-l2tp only-one=default remote-ipv6-prefix-pool=adsl-prefix-test use-compression=no use-encryption=no use-ipv6=yes use-mpls=no use-vj-compression=no
set default-encryption change-tcp-mss=yes name=default-encryption only-one=default remote-ipv6-prefix-pool=none use-compression=default use-encryption=yes use-ipv6=yes use-mpls=default use-vj-compression=default
/ppp aaa
set accounting=yes interim-update=1m use-radius=yes
Используя вышеуказанное с атрибутом remote-ipv6-prefix-pool:, каждый раз, когда пользователь подключается и успешно договаривается по IPv6CP с нашим роутером, он получает динамически выделенный префикс из этого пула, который с нашей стороны маршрутизируется через PPP-интерфейс пользователя.
Интересный момент: если мы статически задаём remote-ipv6-prefix: для пользователя:
/ppp secret
add caller-id="" disabled=no limit-bytes-in=0 limit-bytes-out=0 name=sampleuser@ourrealm.net.uk password=blah profile=default-l2tp remote-address=192.0.2.10 remote-ipv6-prefix=2001:db8:1000:2::/64 routes="" service=l2tp
— это вообще никак не влияет. Пользователь по-прежнему получает префикс из пула. Теперь, поскольку мы всё равно хотим статически назначать префиксы пользователям, мы убираем пул из PPP профиля, а в результате пользователь вообще не получает никакого префикса.
Я также проверял это с FreeRADIUS 2.1.12 (по сути, пробовал с локальной конфигурацией пользователя, чтобы исключить проблему с RADIUS) и вот таблицы radcheck/radreply:
mysql> SELECT * FROM radcheck WHERE username = 'sampleuser@ourrealm.net.uk';
+-----+----------------------------+--------------------+----+----------+
| id | username | attribute | op | value |
+-----+----------------------------+--------------------+----+----------+
| 164 | sampleuser@ourrealm.net.uk | Cleartext-Password | := | blah |
+-----+----------------------------+--------------------+----+----------+
1 row in set (0.00 sec)
mysql> SELECT * FROM radreply WHERE username = 'sampleuser@ourrealm.net.uk';
+------+----------------------------+------------------------------+----+----------------------+------+
| id | username | attribute | op | value | type |
+------+----------------------------+------------------------------+----+----------------------+------+
| 1986 | sampleuser@ourrealm.net.uk | Mikrotik-Delegated-IPv6-Pool | := | 2001:db8:1002::/48 | l2tp |
| 1984 | sampleuser@ourrealm.net.uk | Framed-IP-Address | := | 192.0.2.10 | l2tp |
| 1988 | sampleuser@ourrealm.net.uk | Framed-IPv6-Prefix | := | 2001:db8:1000:2::/64 | l2tp |
+------+----------------------------+------------------------------+----+----------------------+------+
Наш RADIUS возвращает все три атрибута, и пока атрибут Mikrotik-Delegated-IPv6-Pool обрабатывается RouterOS нормально — он виден при выполнении ‘/ipv6 dhcp-server print’, атрибут Framed-IPv6-Prefix: не обрабатывается вообще, хотя логи от нас показывают, что префикс возвращается RADIUS и при этом префикс валиден (не «искажённый» шестнадцатеричный, как упоминали предыдущие участники).
NAS (mpd5 на FreeBSD), который мы сейчас используем, обрабатывает Framed-IPv6-Prefix от нашего RADIUS без проблем.
Если мы что-то делаем не так, я готов признать свою ошибку и извиниться перед ребятами из Латвии за необоснованные жалобы, но на данный момент, похоже, с обработкой Framed-IPv6-Prefix в RouterOS 5.x реально что-то не в порядке.
Готов предоставить supout или дополнительную информацию при необходимости.
С уважением,
Терри Фрой
Spilsby Internet Solutions
/ppp profile
set default change-tcp-mss=yes name=default only-one=default remote-ipv6-prefix-pool=none use-compression=default use-encryption=default use-ipv6=yes use-mpls=default use-vj-compression=default
add change-tcp-mss=yes dhcpv6-pd-pool=adsl-dhcpv6-test dns-server=192.0.2.1,192.0.2.2 local-address=192.0.2.254 name=default-l2tp only-one=default remote-ipv6-prefix-pool=adsl-prefix-test use-compression=no use-encryption=no use-ipv6=yes use-mpls=no use-vj-compression=no
set default-encryption change-tcp-mss=yes name=default-encryption only-one=default remote-ipv6-prefix-pool=none use-compression=default use-encryption=yes use-ipv6=yes use-mpls=default use-vj-compression=default
/ppp aaa
set accounting=yes interim-update=1m use-radius=yes
Используя вышеуказанное с атрибутом remote-ipv6-prefix-pool:, каждый раз, когда пользователь подключается и успешно договаривается по IPv6CP с нашим роутером, он получает динамически выделенный префикс из этого пула, который с нашей стороны маршрутизируется через PPP-интерфейс пользователя.
Интересный момент: если мы статически задаём remote-ipv6-prefix: для пользователя:
/ppp secret
add caller-id="" disabled=no limit-bytes-in=0 limit-bytes-out=0 name=sampleuser@ourrealm.net.uk password=blah profile=default-l2tp remote-address=192.0.2.10 remote-ipv6-prefix=2001:db8:1000:2::/64 routes="" service=l2tp
— это вообще никак не влияет. Пользователь по-прежнему получает префикс из пула. Теперь, поскольку мы всё равно хотим статически назначать префиксы пользователям, мы убираем пул из PPP профиля, а в результате пользователь вообще не получает никакого префикса.
Я также проверял это с FreeRADIUS 2.1.12 (по сути, пробовал с локальной конфигурацией пользователя, чтобы исключить проблему с RADIUS) и вот таблицы radcheck/radreply:
mysql> SELECT * FROM radcheck WHERE username = 'sampleuser@ourrealm.net.uk';
+-----+----------------------------+--------------------+----+----------+
| id | username | attribute | op | value |
+-----+----------------------------+--------------------+----+----------+
| 164 | sampleuser@ourrealm.net.uk | Cleartext-Password | := | blah |
+-----+----------------------------+--------------------+----+----------+
1 row in set (0.00 sec)
mysql> SELECT * FROM radreply WHERE username = 'sampleuser@ourrealm.net.uk';
+------+----------------------------+------------------------------+----+----------------------+------+
| id | username | attribute | op | value | type |
+------+----------------------------+------------------------------+----+----------------------+------+
| 1986 | sampleuser@ourrealm.net.uk | Mikrotik-Delegated-IPv6-Pool | := | 2001:db8:1002::/48 | l2tp |
| 1984 | sampleuser@ourrealm.net.uk | Framed-IP-Address | := | 192.0.2.10 | l2tp |
| 1988 | sampleuser@ourrealm.net.uk | Framed-IPv6-Prefix | := | 2001:db8:1000:2::/64 | l2tp |
+------+----------------------------+------------------------------+----+----------------------+------+
Наш RADIUS возвращает все три атрибута, и пока атрибут Mikrotik-Delegated-IPv6-Pool обрабатывается RouterOS нормально — он виден при выполнении ‘/ipv6 dhcp-server print’, атрибут Framed-IPv6-Prefix: не обрабатывается вообще, хотя логи от нас показывают, что префикс возвращается RADIUS и при этом префикс валиден (не «искажённый» шестнадцатеричный, как упоминали предыдущие участники).
NAS (mpd5 на FreeBSD), который мы сейчас используем, обрабатывает Framed-IPv6-Prefix от нашего RADIUS без проблем.
Если мы что-то делаем не так, я готов признать свою ошибку и извиниться перед ребятами из Латвии за необоснованные жалобы, но на данный момент, похоже, с обработкой Framed-IPv6-Prefix в RouterOS 5.x реально что-то не в порядке.
Готов предоставить supout или дополнительную информацию при необходимости.
С уважением,
Терри Фрой
Spilsby Internet Solutions
