оригинальная статья в моём блоге.
сначала изложу изначально суть проблемы. для чего оператор,
стационарной связи использует тот или иной тип туннелей - обычно
используется PPPoE или L2TP без IPsec?
ответ довольно простой чтобы идентифицировать пользователя, а затем при помощи RADIUS сказать BRAS пускать такого пользователя или нет. обычно еще при помощи радиуса устанавливаются ограничения канала (его скорость), что особенно актуально для тарифов с ограничением полосы пропускания и фиксированной платой в месяц.
мы такие тарифы назвали "безлитными". однако многие ISP идут на хитрость и одно время популярно был термин "Турбо-трафик", т.е. трафик согласно тарифу, а после того, как пользователь упирался в определённые ограничения тариф дополнительно "заужался".
честно говоря не знаю насколько это актуально сейчас. например у нас при клиентской базе ~20 000 абонентов такие ограничения не предпринимались. боле того я старался убедить персонал работающий с абонентами не брать с них деньги за всякую мелочь. это было не очень сложно т.к. с клиентами фактически работало 2 человека и еще было ~2 монтажников, которые занимались в основном прокладкой оптических кабелей.
но вернёмся к нашим туннелям. значит пользователя согласно балансу лицевого счета пустили, скорость соединения согласно тарифу установили, что-то еще? да мы не учли интересы РКН
в чем эти интересы? в том что надо хранить статистику по абонентам кто с каким сайтом соединялся. дело осложнялось тем, что у абонента на IPv4, как правило "серый адрес" который на BRAS "натится" в публичный и все ваши абоненты представлены 80 публичными IP адресами (16 адресов на BRAS), причём невозможно определённо сказать кто каким.
хотя у меня было с этим проще. адреса были фиксированные для каждого BRAS и абоненты распределялись по адресам привязанных к серверу, на основании серого IP адреса. т.е. 172.16.n.x в зависимости от n натится в свой адрес. т.е. фактически PBR. это означает, что пока абонент не сбросит сессию у него будет фиксированный публичный IP, т.е. если BRAS штук 5 то каждый диапазон 172.16.n/20 представлен пятью возможными адресами. все хорошо, основная проблема как скинуть пользователя с линии когда его лицевой счет стал отрицательный.
у меня скриптик искал абонента по BRAS 172.16.211.11 — ваш клиент? нет идем на следующий BRAS — есть у вас 172.16.211.11? — о есть. скиньте пожалуйста сессию. конечно можно просто ограничить время жизни сессии скажем 24 часами — решение в лоб, я его даже какое-то время использовал.
но даже при таком подходе приходится хранить netfow-подобную статистику для серых адресов. приходит тебе следователь со статистикой с публичного сервера и ты сидишь выуживаешь номера портов и время, причем время кто-то штампует в UTC+0 кто-то UTC+3, кроме того на зимнее время переходит, кто-то нет. одним словом сплошная головная боль. сейчас хоть зимнего времени нет.
как известно в IPv6 нет nat6-6 т.е адресов много и абоненту вместо одного адреса + NAT на домашнем роутере выдается несколько публичных IP-адресов например 16. т.е. 16 устройств абонент может подключить. не путайте с минимальной сетью в IPv6 /64.
это уже лучше. т.е. абонент всегда представлен 16 фиксированными адресами - статистику можно не хранить вовсе, какие адреса кому принадлежат известно из билинговой системы.
теперь самое интересное нужно эти 16 адресов к абоненту "прибить", чтобы у него не было возможности их поменять. первое это конечно есть смысл настроить port-security ну а второе и главное это DHCP-relay.
конечно можно использовать механизм IPv6 PD. в этом случае через DHCPv6 клиентскому роутеру делегируется свой префикс /64. в это случае клиентский роутер сам раздаёт IPv6, может использоваться любой механизм назначения адреса узлу даже SLAAC (Stateless Address Autoconfiguration), главное что клиентскому роутеру всегда выделятся один один и тот же префикс. для этого можно использовать теже самые механизмы, но мы рассмотрим более общую задачу, настройка клиентских узлов через DHCP т.е. можно обойтись без клиентского роутера. лёгкие пути не для нас :))) впрочем данный метод даёт дополнительные преимущество - можно использовать очень примитивное клиентское оборудование без какой либо настройки.
DHCP-relay добавляет в перенаправленный DHCP серверу клиентский запрос информацию о коммутаторе и с какого порта запрос был получен запрос. т.е. абонент определяется адресом коммутатора и номером порта к которому он подключён. DHCPv6 Relay с Option 18 (Interface-ID) и Option 37 (Remote-ID) кроме того DHCPv6 Guard: запрещает устройству абонента выступать в роли DHCPv6-сервера. IPv6 Source Guard: разрешает передавать трафик только с тех IPv6-адресов, которые были получены через корректный DHCPv6-запрос.
за страшными словами DHCPv6 Guard/Snooping скрывается простая суть. нам нужно запретить RA и DHCP ответы c абонентских портов. это базовая конфигурация её смело можно сохранить. динамические же так или иначе назначаемые правила привязывают к порту префикс адресов абонента например 2001:db8:a1b1:c2d2:e3f3:a0e1::/96. вы его можете разбить ещё дальше два /97 - скажем 2001:db8:a1b1:c2d2:e3f3:a0e1:1::/97 для DHCP, а 2001:db8:a1b1:c2d2:e3f3:a0e1::/97 для ручной настройки.
так что вот так. случилась мечта моего начальника - абоненту просто дают в руки "шланг" с интернетом, при чем можно практически полностью отказаться от малоквалифицированных работников т.к. абоненту не нужно что либо настраивать, а в качестве абонентского оборудования выступает не управляемый свитч, в который он по желанию может воткнуть точку доступа.
но кто-то скажет что что это дыра в безопасности - провода переткнул и украл инет у соседа? можно cделать авторизацию на порту. по сути пользователь, когда "настраивает" wi-fi делает именно это. так даже будет лучше. вам нужно только настроить port-security - определяет максимальное число устройств у абонента и защиту DHCP.
если есть аутентификация на порту, то можно всё сделать через радиус: прошедшую аутентификацию порты попадают в один VLAN, а не прошедшую в другой. вот и получилось один VLAN Internet другой local. нет необходимости даже в DHCP можно использовать SLAAC, но тогда мы не знаем какой адрес какому устройству в какое время принадлежал. РКН за такое по головке не погладит.
ну что же отлично: так или иначе подключили всех абонентов БЕЗ использования BRAS. учли интересы РКН, не надо сбрасывать пользователя с линии. нет проблем с MTU не нужна здоровая UPS, схема благотворно влияет на счет за электричество, требует меньше места, можно использовать более дешевое оборудование... ну короче одни вкусности для бизнеса :)
ну а есть проблемы? куда же без них. фактически у вас все устройства (это еще хуже чем все абоненты) сидят в одном l2 сегменте. учитывая что коммутатор способен переварить относительно не больше число MAC адресов — обычно 16к это не есть хорошо, точнее совсем никак не есть.
т.е. сеть ~20к абонентов условно это ~40К устройств т.к. каждое устройство имеет свой MAC. в случае PPPoE проблемы примерно те же. для PPPoE каждый VLAN у меня терминировался 5 интерфейсами 5 серверов. интерфейс сервера представлен одним единственным MAC адресом в каждом VLAN. т.е. всего дополнительно 5 адресов. при этом вся сеть была разбита на 5 сегментов — 5 VLAN. абоненты разных VLAN друг друга не видят, коммутаторы разных VLAN друг о друге ничего не знают, а абоненты каждого VLAN упираются в интерфейс своего PPPoЕ сервера.
получается очень удобно сервера мало того что распределяют нагрузку, но и друг друга дублируют. теоретически из 5 РPPoE серверов можно погасить 4 и сеть формально не сломается так как каждый сервер имет интерфейс в каждом VLAN.
подобный трюк можно легко провернуть и с IPv6. агрегировать трафик
сегмента (VLAN) будет L2-коммутатор. объединять же трафик между сегментами (VLAN) будет L3-коммутатор. на L3-коммутаторе для каждого VLAN настраивается SVI (Switched Virtual Interface). мы получаем тот же эффект: один гигантский L2-домен разбивается на несколько управляемых сегментов. однако при таком подходе для его реализации нам потребуется не единственный префикс /64, а несколько или один крупный префикс (например, /48), так как каждому VLAN должна быть выделена своя собственная подсеть /64.
вы смотрите на префикс /64 и думаете: «это же невообразимое расточительство!». ваше чувство бережливости, выработанное годами работы с IPv4, кричит вам, что это неправильно. но вы должны сделать самое сложное: перестроить свое мышление. в IPv6 расточительность — это норма. более того, это осознанный архитектурный принцип. например для работы SLAAC (Stateless Address Autoconfiguration) обязательно нужна подсеть /64.
однако большие l2 сегменты требуют большего внимания. вам как минимум нужна хорошая защита от петель на стороне абонента. а то получится что абонент воткнул в свитч обе стороны пачкорда и 5К абонентов у вас легло. я дополнительно зажимал широко вещательный трафик с абонентских портов практически до упора. хотел перейти на protocol-based VLAN, чтобы вырезать PPPoE и запихнуть его в отдельный VLAN, но кто тому времени я уже увольнялся. почему не сделал сразу? в свое оправдание могу сказать, что когда мы начинали строить сеть, то использовали DLIK-3526 на котором такой функции нет.
однако переход с PPPoE на нативный IPv6 с портовой аутентификацией — это не фантастика, а вполне реализуемая архитектура. она сулит значительную экономию и упрощение сети, но требует тщательного проектирования L2-уровня и современных систем контроля широковещательного трафика. это путь от костылей и заплаток к чистой, прозрачной и управляемой сети будущего.
написано в соавторстве с deepseek.