Биллинговая система Nodeny

Хотелось бы спросить, внедряли кто то схему Nodeny+IPv6?
Поделитесь опытом.

НЕТ)

Впрочем, другого ответа и не ожидал)))

зачем утверждать отрицания.
все работает, но через костыли.....

Доброго дня, 3 роки пройшло і тут стало цікаво хтось використовує nodeny + ipv6? якщо так то поділіться схемою або як реалізовано!

Та проблем особых нет: сформулируйте ТЗ, оплатите разработку да пользуйтесь!
Проблема вся в том, что никому особо ipv6 не надо, чтобы прям взять и оплатить разработку...

точняк!

яка вартість?

я думаю тут вот это главное "Та проблем особых нет: сформулируйте ТЗ"
а от этого и будут отталкиваться

Да

С учетом того что УЖЕ реализована выдача ip адресов в виде сетей остается только создание пулов ipv6, назначение юзерам сетей /64, ну и соотв. какая-то модификация скриптов шейпера для конфигураций "все в одном".
С учетом того что переходный период длиться уже долго и еще хз сколько будет длиться и те и другие адреса должны использоваться одновременно. Исходя из того что одно - частный случай другого, это не должно быть слишком сложно.

Так IPv6 так и пинается? Так ни кто и не реализовал?

ну а оно надо кому-то? причем в такой степени, чтобы профинансировать разработку и внедрение?

На самом деле товарищи, которые интересуются приобретением биллинга уже несколько раз спрашивали типа а как там у вас с поддержкой IPv6?
 Не то что бы прям хотят финансировать, просто заглядывают сегодня не только лишь в завтрашний день )))

Я озадачился внедрением IPv6 т.к. под рукой имеется готовый полигон для этого ну и люди, которые очень хотят его внедрить. С учетом того что уже процентов 40 интернета работает на шестом протоколе а четвертая версия IP адресов стоит безумных денег а работать протоколы могут совместно, не мешая друг другу, то смысл во всем этом имеется и довольно большой.
Предлагаю начать с постановки задачи и аккумулирования опыта, который уже имеется по этой теме.

Итак, любой провайдер может без проблем получить в собственное юзанье сеть ipv6  c префиксом /32 или /48 (что скорее всего). 48я сеть - это гиганское количество адресов исчисляемое миллионами, так что и этого хватит выше крыши для большинства провайдеров.
Протокол подразумевает выдачу абоненту не адреса - а сети с префиксом /64 в которой тоже дофига миллионов адресов и ему ее хватит на всю его жизнь и его детей и внуков. В 48 сети провайдера получается что-то чуть больше 65тысяч таких префиксов. При этом никто не запрещает выдавать юзеру не 64 префикс а что-то побольше, например 111 или еще больше. На этом разговор о нехватке ip адресов можно считать закрытым.

Что же делать дальше?
Юзеры уже хотят.... а провайдеры еще не могут или не хотят?  Будем внедрять! Если кто-то чувствует в себе силы, присоединяйтесь в тему.
Итак, нужно начать с пула адресов.
Что есть для старта? У нас есть сеть, выданная нам райпом, вида ХХХХ:YYYY:ZZZZ::/48   и ее для дальнейшего юзанья нужно разбить на кучу мелких пидарасиков ). С учетом того что пидарасиков этих будет много тысяч - ручная работа с калькулятором тут не подходит.
Для создания пула нам необходимо юзать модуль перла NetAddr::IP приблизительно так:

В массиве @prefs и будут находится все префиксы 64 которые нам нужны, причем в стандартной нотации IPv6

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

Більше /128 ?  по-моєму /128 це останній префікс і там всього 1 ІР.
Модуль DHCP буде працювати? а то клієнтам не дуже хочеться диктувати 128 битну адресу, вони 4 окета з трудом вписують!
Планується тільки в Nodeny Next?

Очепятка
Впиливание в биллинг ipv6 пока моя личная инициатива. Поэтому включение в дистрибутив вообще не гарантируется. Я не собираюсь переписывать весь биллинг под это. Все будет максимально упрощено. И уж точно без DHCP который работает на IPv6 но к сожалению совершенно не понятно как его заюзать кроме как использовать опцию82 - чего я не планировал делать вообще.
Планируются статические сети, зароученные за интерфейсный IP адрес.  Самая  главная проблема заставить брас отрабатывать этот ipv6 пул. После этого появится возможность выдавать тем кто просить ipv6 и сидеть на попе ровно до тех пор, когда на Nodeny появится его поддержка. Вангую что это случиться по-любому т.к. другого пути просто нет.

Да пол года уже просим и денег предлагаем и тз писали

Если бы в стандартном пуле ип адрес хранился и обрабатывался как обычная строка а не int(10) было бы сильно проще. Как оказывается в mysql нет специальных механизмов для хранения IPv6 адресов и придется их хранить как обычную строку.
Что-то я не вижу у народа энтузиазма. Все только потребители? Никто не хочет поучаствовать больше?

Выдавать надо 64 подсети, так как роутеры через ND отдают. И даже если порежешь на 128, роутер отдаст абону 64 и будет нехорошо. Испытано уже

Готов оплатить разработку, назовите цену и сроки

причем необязательно на интерфейсе выдавать маршрутизируемые в интернет ипв6 :)

так и есть

якщо отримати /48 і віддавати клієнтам /64, то цього вистачить більшості провайдерів. Але автоматизувати видачу ІР було б дуже корисно, хоча б через SLAAC.

В этом прекрасно все, кроме того, что это никак нельзя заюзать для блиллинга ((( кроме как каждый раз вводить пароль в заглушке - для меня это неприемлемо. Лучше уж пусть будет просто статика.

INET6_ATON()   Return the numeric value of an IPv6 address
INET6_NTOA()   Return the IPv6 address from a numeric value
https://dev.mysql.com/doc/refman/5.7/en/miscellaneous-functions.html#function_inet6-aton (https://dev.mysql.com/doc/refman/5.7/en/miscellaneous-functions.html#function_inet6-aton)


DHCP + Radius + Opt82 Opt37 \ QinQ (VlanPerUser)

планирую разрабатывать поддержку IPv6 для себя, но пока начальство даже пул не запросило.
для DHCPv6 нужно учитывать хто запрашивает, роутер(\64) \ конечный пк(не помню маску)
по этому нужно 2 класса пулов для двух масок
не обязательно сразу генерить весь пул, т.к. адресов будет дохреналион, достаточно сделать при запросе генерацию на лету с использованием того же NetAddr::IP, а результат уже вносить в БД

Предлагаю для начала описать ТЗ публично, чтоб каждый заинтересованный мог внести предложения, что б потом не переделывать структуру кучу раз

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

Это здорово, что в 5.7 появилась поддержка. Я не знал, когда читал об этом всем, все грустили об отсутствии. Но, во-первых int(10) все равно не о чем, а во-вторых у меня кое где еще до сих пор 5.5 юзается. Не хотелось бы что бы это дело было чувствительно к версии базы данных.
В таком варианте довольно хлопотно определять какие из префиксов уже заняты а какие нет. Проще генерировать пул определенного размера, увеличивая его по мере необходимости.

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

тогда просто принимаем, что /64 префикс - это один клиент, некий аналог 1 адреса ipv4

Об этом и речь. Генерим необходимое количество префиксов (т.к. 65тыс. в большинстве случаев никому не нужно) и принимаем что /64 это один клиент. НО
Нужно еще адреса на интерфейсную пару. Самосгенерированные для этого не подходят, на них только icmp ходит. Поэтому на каждый влан навешиваем еще по сеточке /64 или больше для организации интерфейсных пар (которые можно не маршрутизировать в интернет). Вполне себе нормальный способ обезопасить себя от хулиганья. И нафиг не нужны опции, влан на юзера и т.п.

а как же безопасность? а как юзать с dual-stack? а как внедрять в существующую топологию? а как бить с брасами типа цыски, джун и прочие? как в билинге в6 к абонам цеплять, шейпить и мониторить?
или ты планируешь абонам отдавать либо в4 либо в6?

или ты просто планируешь запустить в6 конкретно под себя?
тогда смысл здесь на форуме это обсуждать?

если делать функционал, то уже нормально 

Спрашивали, отвечаем:
Я не солнце, чтобы всем нравится и переписать весь биллинг для того чтобы кому-то показалось что сделано "нормально".
Что качается безопасности - сначала попробуйте сделать что-то с ipv6 в одном влане ))) а оптом громко заявлять по безопасность. Это другой протокол! и довольно продвинутый. Что касается совместной работы - то оно работает аж в путь.
Я ищу вариант прикрутить IPv6 к биллингу чтобы сделать жизнеспособной схему которая уже работает!!!!!! без шейперов и ограничений.
Для того чтобы это стало все жизнеспособным - биллинг должен поддерживать IPv6 хоть в каком-то виде, т.е. нужно наладить учет и переписать noserver для поддержки нового пула. Я планирую использовать  IPv4 и IPv6 одновременно. Выдавать оба варианта юзеру одновременно  - они друг другу не мешают.
Что делать с брасами которых у меня нет в заведовании - мне глубоко фиолетово, это должна быть забота админов, которые их используют.
Как-то так. И еще... я так особо никому ничего не должен, а на форуме пишу потому, что биллинг IPv6 не поддерживает ни в каком виде, ни в "нормальном" ни в каком-либо еще. Поэтому кому-то это может быть полезно. Можно эту тему не читать, если режет глаза.
Что-то конкретики никакой нет, одна критика. Кроме Элита вообще всем пофиг?

Поддерживаю и читаю. На будущее нужный функционал. :)

Хех, IPv6 тема ожила. И без меня даже.
На самом деле у меня тоже лежит в планах доработка, но сразу несколько нюансов.

/48 провайдеру - мало, это обычно PI блок, который нельза выдавать клиентам.
Если вы LIR то спокойно получаете /32../29 (а вообще при последнем выделении v4 заставляли сначала v6 блок взять).

Клиенту надо выделять /56 (Ну или /64 плюс делать резервирование блока адресов до /56), юрикам рекомендация выдавать /48 (чтобы они уже внутри себя разруливали).
Патамушта /64 для домашней сети может быть тупо мало и могут запросить расширение.
https://www.ripe.net/publications/docs/ripe-690#1--executive-summary

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

Пример, есть блок 2000::/32
Это 65,536  сетей /48.

Для простоты можно просто в качестве третьего блока адресов подставлять UID или его HEX представление, для большинства сетей этого хватит.
То есть технически самое простое решение выделять на один UID клиента /48, но в зависимости от условий отдавать клиенту /64 блок, оставляя за собой возможность расшириться в случае необходимости до /56 или до /48

2000:0000:UID::/64
2000:0000:UID::/56
2000:0000:UID::/48

Для ситуации с /48 блоком и распиливанием меньше чем на /64 блоки считайте сами, но уж если внедрять, то сразу нормально.

Если отвлечься от обсуждения размера префикса, то это вообще интересная идея, которая подлежит осмыслению.
С другой стороны что нам это дает?  С таким же успехом в пуле имеется поле uid которое связывает ип адрес и абонента.

Биллинг может вообще не знать о существовании IPv6 адресов как класса и не надо будет городить лишние костыли чтобы вкорячивать хранение префиксов, делегирование блоков итд.
Максимум например хранить размер блока который ты отдаешь клиенту в допполе, можно как целое число и уже на базе простой математики отдавать все параметры на стороне noserver'а или radius'a

Это интересная идея. Нужно будет подумать над этим.

От тут непанятка. З якого переляку 18446744073709551616 адрес (/64) в домашній мережі може бути мало? /48 це 65536 /64 підмереж. Тут варто враховувати ще вартість /48 і як його раціонально розділяти клієнтам.
З.І. З ІРv6 знайомий тільки в теорії, тому якщо щось не розумію, то ткніть носом

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

А можно просто взять и выдать 2-3-10 префиксов /64 в зависимости от того что попросит клиент. На этом считаю дискуссии на тему размера префикса нужно прекращать ))) а то это затянется как внедрение телевидение высокой четкости ))) стандарты которого пытались утвердить еще в моем детстве, да так и не смогли пока японцы взяли да не запустили HD формат. А прошло всего-то 40 лет )
 

Кто то уже тестирует IPv6 с nodeny?
Обновлю тему, ибо v6 уже актуально.

Пока нет, но в планах все еще стоит, очень долго мигрировали с ND50

Я пилю потихоньку. С биллингом уже все хорошо, осталось связку с брасом нафигачить.
Это конечно все партизанщина, но концепция выдачи префиксов на основе айди абонента мне шибко понравилась (спасибо goletsa за идею).

Очень интересно. Я так понимаю, на брасе noserver.pl пилить.
Но как быть с dhcp и make_config ?
 Кстати, у Вас выдаются серые IP и V6, а как бы привязать серые IP к префиксу /64. То есть по какому то алгоритму, выдаешь клиенту серый IP, и он автоматом получает префикс /64 с твоей /48 ?

один из октетов (четвертый) - это айди абонента в HEX формате, все просто до безобразия.
DHCP для 6 версии я не рассматриваю т.к. оно как ни крути а работает криво (да простят меня боги) и привязывать клиентов возможно только через опции что не всегда возможно технически (вернее почти всегда невозможно по разным причинам). Поэтому пока только статика. Ну хоть какое-то движение вперед.
Через пару лет все равно проблема с адресами встанет раком и все окажутся перед фактом.

Интеграция с брас и есть основной гемор.
С точки зрения биллинга я вообще не видел проблемы адреса отдавать.

Проблема там одна - сесть и переписать по образу и подобию. Главный вопрос - время.

Как-то так получается

А как префиксы выдаются? Это скрипт или радиус?

Управление по API

В общем я закончил с прикручиванием IPv6 плюс брас на базе mikrotik.
К сожалению никакой динамической выдачи префиксов юзерам пока нет и не думаю, что скоро появится т.к. пока нет вменяемого механизма назначения ип по дхцп кроме как при помощи опции82 а это не всегда возможно.
Но делать что-то надо, поэтому концепция пока простая - статическая выдача префиксов и .... ручная настройка оборудования клиента. Все как мы любим с начала 2000х )

Начиная свои изыскания на эту тему я исходил из того, что на настоящий момент не только лишь всем нужен IPv6, но и многие вообще не в курсе что это такое. Поэтому выдавать мы его будем тем кто спросит. А там, поживем и увидим. Тут больше вопрос здоровой конкуренции, отличный от привычного всем демпинга цен.
Итак....
Общая идея такая что раз выдаваемых адресов шестой верссии овер-дофига, то можно к каждому юзеру биллинга прибить гвоздями его префикс /64 на основе его id в биллинге.
Такая концепция имеет свои ограничения, и они связаны с количеством юзеров не более 65 тысяч - что приемлимо для 99.5% провайдеров использующих этот биллинг.
Итак, допустим, что нам выдали префикс   2001:aaaa:bbbb::/48  в нем содержится более 65 тысяч префиксов /64, для того чтобы назначить префикс юзеру нужно просто расчитать этот префикс
на основе его id (это делает биллинг и все входящие в модуль скрипы самостоятельно). Например  юзер с id 3031 будет иметь префикс  2001:aaaa:bbbb:bd7::/64 а с id 6522 будет 2001:aaaa:bbbb:197a::/64

Учитываем в концепции что юзеры разбиты и булькают в разных вланах, поэтому для каждого из вланов нужно организовывать свою интерфейсную сеть адресация для которой тоже рассчитывается биллингом автоматически.
Подход такой же как и с юзерами но, чтобы префексы не пересекались с юзерами добавляем к id влана  число 60000 (60 тысяч). Т.е. для влана с id  501  число будет 60501 или в HEX формате ec55. Таким образом интерфейсный адрес для влана 501 получается 2001:aaaa:bbbb:ec55::1/64 и соотвественно интерфейсный адрес на роутере юзера c id 6522 должен быть  2001:aaaa:bbbb:ec55::197a/64

Включение и выключение поддержки IPv6 для юзера осуществляется из карточки клиента. При этом автоматически при помощи API микротика на нем прописывается необходимый маршрут и создаются шейпера и аксесс-листы (всеми нами любимый goodboys). Далее все работает как мы все привыкли. Нет денег - нет трафика. Шейпера меняются, все булькает.

К сожалению у меня пока нет необходимости делать это для других брасов. Поэтому интергировано это все пока только в микротик.

Спасибо всем кто помогал, советовал и поддерживал.

Я все еще не до конца согласен с выдачей префикса всего /64. Хотя бы /60 тогда.
LIR спокойно получают /32 и из него кроить /64 это свинство.

Ну не становиться же ради этого лиром )))) что за бред?

така ситуація, незнаю чи хтось використовує IPv6 але з ipv6 не можливо нічого зробити у білінгу) зовсім. проблема в реєстрації ip з якого робляться зміни.
Скажемо якщо робити зміни з ip 10.1.5.24 то
Все ок, але якщо зайти з ipv6.
моя IPv6: 2a0e:b107:17b0:13:857c:e6ca:71e3:69ec з якої роблю зміни)

Вот это называется "Добрый вечер!" )))
Мы ехали ехали и наконец приехали.

у вас нема такої проблеми? або ви робили зміни?

можно заметить, что откинуты все буквы, а оставлены одни цифры

Воно зараз так і робить на автоматі.
Орігінальна 2a0e:b107:17b0:13:857c:e6ca:71e3:69ec
а в білінг пише 2010717013857671369

Вы не выкупаете красоту момента..... то что буковок нет - это просто под фильтр переменная попала, то горе не большое, а вот то что функция INET_ATON в mysql ничего не знает об IPv6 - это беда. Т.к. используется эта функция много где и делает невозможным юзанья биллинга через IPv6. Исправить-то можно, просто это подвиг наверное проще совершить.

я зрозумів що під фільтр.. Чоловік зверху написав що видалити букви з ip. я сказав їх і так видалило...
а у вас такої проблеми немає? чи ви не заходили в білінг під ipv6)?

Ну как бы больше себе на заметку.

Можно и без HEX обойтись, но тогда нужно тип данных в поле таблицы менять на VARBINARY(16) (чтобы работало и для версии 4 и для 6)