ну что же я рассмотрел IPoE в целом, рассмотрел доступ из IPv6 сети к ресурсам старой IPv4 сети, была рассмотрена автоматическая конфигурация клиентских узлов в IPv6 сети. что осталось? рассмотреть собственно сам доступ к IPoE сети. в сущности отличается от классической сети с BRAS минимальны — и там и там используется RADIUS. разница лишь в том что в классической сети у вас есть одно место авторизации ваши BRAS сервера, которые по RADIUS общаются с билингвой системой, RADIUS говорит BRAS кого пускать, а кого нет, при помощи дополнительных RADIUS атрибутов устанавливается ограничения канала (его скорость).
в случае IPoE ситуация мало чем отличается. только устройств на которых будут авторизовываться пользователи много. т.е. система стала распределённой. это конечно создаёт дополнительные проблемы, но и в тоже время плюсов тоже много. самый основной что BRAS достаточно медленный и дорогой при этом коммутаторы доступа все равно устанавливаются т.е. просто используем более быструю и энергоэффективную схему.
что же уходим от BRAS к IPoE ради производительности и стоимости. но абонентов в любом случае авторизировать надо. более того авторизовать абонента нужно в распределённой системе. какие есть варианты?
вариант 1 не делать ничего.
это тоже стратегия. смысл в том чтобы использовать stateless режимы получения адреса как было написано в статье про автоматическую настройку, но такой вариант мало того что имет проблемы с безопасностью, он не устроит РКН. потому что процесс получения адреса около случайный. даже если генерация глобально маршрутизируемого адреса происходит на основании аппаратного адреса MAC. MAC на большинстве устройств можно легко поменять. поэтому даже жёсткую привязка глобального адреса к MAC нельзя назвать надёжной. да это в теории упрощает отслеживание устройства, но надёжности нет.
вариант 2 наивный «наколеночный»
т.е. мы тоже не используем радиус вообще. в место него работает DHCPv6 Relay Option 18 (Interface-ID) и Option 37 (Remote-ID). т.е. коммутатор заполняет опции 18 и 37. DHCPv6 ориентируется на эти опции и выдаёт адреса из пула привязанного к этому порту.
но это еще не всё нужно предоставлять доступ к интернету в зависимости от состояния лицевого счёта абонента. с этой задачей отлично справится FireWall. некий скрипт должен скажем выкидывать адреса из таблицы для который доступ в интернету разрешён. для FreeBSD команды будут выглядеть как-то так.
ipfw add allow ip from "table(inet)" to any via ${if_inet}
ipfw add deny all from any to any
пусть у пользователя диапазон из 16 адресов /124 так просто удобнее если адреса идут в подряд, а не в разнобой.
тогда биллинг должен добавлять данные в эту таблицу командной ipfw table inet add 2001:db08:a721:b3c8:d4f1:df3a:e3a0:d758/124 когда баланс становится положительным. и удалять их в случае отрицательного баланса. ipfw table inet delete 2001:db8:a721:b3c8:d4f1:df3a:e3a0:d758/124.
первый недостаток решения, что роутер программный. мы поменяли шило на мыло. да во FreeBSD удобный объект IPFW table, но роутер будет вносить существенную задержку.
поэтому с точки зрения скорости лучше будет если роутер будет аппаратным — например l3 коммутатор. но хоть современные L3-коммутаторы аппаратно поддерживают тысячи и десятки тысяч ACL без потери производительности, но управление тысячами ACL и особенно управление ACL на коммутаторе доступа (добавление, удаление при изменении баланса) превращается в операционный кошмар.
так что решение на IPFW FreeBSD выглядит значительно более практичным хоть и с недостатками присущими программным роутерам. т.е. для небольшой сети или как временное решение на этапе миграции с BRAS этот вариант может быть оправдан из-за своей простоты реализации и низкой стоимости, однако для крупных провайдеров он не рекомендуется.
второй и главный недостаток это безопасность. мы ориентируемся только на номер порта конкретного коммутатора. т.е. кто угодно может подключится в этот порт коммутатора и получить доступ к сети. в этом плане вариант мало отчается от самого первого. у нас только адреса привязаны к портам коммутатора. поэтому в сетях IPoE необходимо использовать EAP (Extensible Authentication Protocol) и RADIUS.
вариант 3 (правильный): 802.1X + RADIUS.
APoL (EAP over LAN) это простой способ инкапсулировать EAP-кадры в Ethernet-кадры (IEEE 802.1X). RADIUS: это уже прикладной протокол , который обеспечивает доставку учётных данных и атрибутов от коммутатора к RADIUS-серверу. клиент (supplicant) говорит с коммутатором по APoL. коммутатор говорит с RADIUS-сервером по RADIUS.
получается очень удобно. порты по умолчанию на ходятся в гостевом VLAN из которого доступен например только портал статистики. порты прошедшие авторизацию попадают в интернет VLAN. полезно если можно установить ограничения канала. и желательно чтобы что бы это были безбуферные ограничители скорости — ведь мы же строим сеть с малой задержкой.
для сброса пользователя с линии (перевода порта снова в гостевой VLAN) например когда баланс его лицевого счета стал отрицательным, RADIUS-сервер будет использовать механизм RADIUS Change of Authorization (CoA) / Disconnect Message (DM). CoA/DM — это отдельный пакет, который RADIUS-сервер отправляет на коммутатор, где висит сессия пользователя.
команда Disconnect: принудительно разрывает сессию пользователя. команда CoA-Request может не только разорвать сессию, но и изменить её параметры "на лету" (например, применить другой ACL, ограничивающий скорость).
это не отменяет заполнение Option 18 (Interface-ID) и Option 37 (Remote-ID). нам для учёта все равно нужно чётко сопоставить адреса которые могут получить устройства абонента с сам абонентом. но в этом случае кто попало уже доступ к порту коммутатора не получит.
в этом случае принципе нет необходимости даже хранить детальную статистику. однако нужно озаботиться чтобы абонент мог использовать только адреса выданные ему по DHCP (DHCP Snooping). тогда мы всегда точно знаем что абонент представлен выделенными ему адресами при любых обстоятельствах.
ну что же все выглядит даже слишком хорошо, а есть ли проблемы? конечно, да куда же без них.
самая большая головная боль вы перешли с изолированных туннелей PPPoE к общей L2-среде. а тут простор для мошенников. перечислим основные угрозы:
- ARP Spoofing / IPv6 Neighbor Spoofing: злоумышленник в том же VLAN может начать рассылать фальшивые ARP-ответы или NA-сообщения, представляясь шлюзом по умолчанию - классическая атака "человек посередине".
- DHCPv6 Spoofing / IPv4 DHCP Spoofing: аналогично — запуск собственного DHCP-сервера для раздачи клиентам ложного шлюза и DNS.
- MAC-флуд: Переполнение таблицы MAC-адресов на коммутаторе, приводящее к его переходу в режим хаба и передаче трафика на все порты.
к счастью, эти угрозы легко снимаются настройкой на коммутаторах функций DHCP Snooping, IP Source Guard, RA Guard и Port-Security. без включения этих функций на всех абонентских портах развёртывание сети по схеме IPoE небезопасно. кроме того важно грамотное проектирование сети и грамотное её обслуживание.
есть еще некоторое количество принципиальных проблем:
- не все клиентские устройства поддерживают 802.1X: например различные IoT-устройства. для них вам потребуется обходной манёвр — MAC Authentication Bypass (MAB). но MAB это уязвимость . MAC-адрес легко подделать и любой может прописать себе MAC легального устройства и получить доступ к сети.
- разношёрстные реализация DHCPv6-клиентов: некоторые старые или дешёвые устройства могут криво реализовывать стандарты, требовать только SLAAC или не понимать определённые DHCP опции.
поэтому лучше решение это конечно роутер. в принципе его «умный» функционал и будет сведён к авторизации т.к. от NAT мы избавились.
что еще можно пожелать? хорошо бы что бы это устройство (роутер) предоставлял SLAAC внутри своей сети. такого поведения можно дробится делегировав префикс через DHCPv6-PD (Prefix Delegation). роутер будет использовать его для организации SLAAC в своей внутренней сети. это будет особенно полезно если нужно подключить сравнительно большую организацию.
вот теперь основные проблемы и преимущества решения освещены. да IPoE сеть требует более вдумчивой настройки и проектирования, но правильно построенная сеть обеспечит значительно меньшую задержку по сравнении с классической схемой на BRAS, более низкое энергопотребление потребление, лучшую безопасность и лучшую отказоустойчивость.
текст создан при экспертной поддержке DeepSeek