DHCP + Opt82 + Radius

[Cell]

Cell
дядька, от тут ты точно не прав
accel - действительно крутая штука

Во-первых я не говорил что он плох, по этому я не понимаю почему я точно не прав.
Во-вторых разу уж ты точно знаешь что это крутая штука, так обоснуй каким-то другим способом. Например расскажи как ведет себя аксель, когда у него в лизинге находится какой-то ип адрес скажем А от порта скажем Б и вдруг с порта Б приходит запрос на получение адреса для совершенно другого устройства. Ситуация вполне жизненная - абонент выключил свой комп и включил ноутбук соседа или утюг подключил к сети или еще что-то.
Я, например не знаю, как он себя ведет, но ты, видимо поюзав его основательно (ну для того чтобы сказать что я ТОЧНО не прав) как раз знаешь это очень хорошо.

[Cell]

Обычно от дхцп в таких случаях хотят чтобы абонент получал адрес в ответ на запрос с любого мака

По-моему так и должно быть, как клиент сможет авторизоваться на порту если у него не будет Ip? А неизвестные маки и их Ip уже редиректить на заглушку авторизации. В случае с радиусом можно можно выдавать Access-Reject и обрабатывать как угодно.

Научитесь сначала читать, а потом понимать то что написано.

[fet4]

Efendy насколько я понял надо бы еще передать эти два параметра в sql.conf

Код:

authorize_check_query = "call radcheck('%{User-Name}', '%{DHCP-Agent-Remote-Id}', '%{DHCP-Agent-Circuit-Id}')"

И потом обработать их в radcheck.

Или вы хотите просто посмотреть что отдает данная Вами процедура radreply?

Cell

Например расскажи как ведет себя аксель, когда у него в лизинге находится какой-то ип адрес скажем А от порта скажем Б и вдруг с порта Б приходит запрос на получение адреса для совершенно другого устройства.

Я проверю как он ведет себя. Но думаю до выдачи дело не дойдет т.к. ip-source-guard на коммутаторе заблокирует такое поведение до момент пока связка на порту Б не закончится.

Научитесь сначала читать, а потом понимать то что написано.

Давайте делом заниматься. 

[Efendy]

я не хочу ничего смотреть) я написал процедуру, которая по идее должна работать. Почему по идее? Я ее потестил локально, т.е она работает. Дальше уже надо смотреть не ошибся ли я в логике. Ибо логика при опции 82 и без несколько отличается, хотя кажется, что по сути ничего не меняется: в одном случае у клиента проверяется мак, в другом случае мак+устройство+порт. Вроде бы отличий нет за исключением количества проверяемого. Но на самом деле есть, например, если меняется устройство или порт, то у нас есть 2 варианта поведения:
1) если абонента перетыкнули в другой порт или сменили свич, то необходимо "забыть" связку и назначить новую после ввода пароля в личном кабинете
2) послать нафик ибо это могла быть вовсе не ситуация с перетыканием в другой порт, а кто-то пытается подменить мак
Я выбрал первый вариант ибо он наиболее вероятен, в противном случае придется все эти ситуации разруливать в админке постоянно выслушивая по телефону "долбоебы, когда у меня будет инет". С другой стороны если таки будет хакер, то самой попыткой подменить мак он затрет связку валидного абона и тому придется заново вводить пароль. Думаю этим можно принебречь

[fet4]

Efendy
Да первый вариант лучше.
"Один на порту" будет отрабатывать ?
Я правильно понял мы меняем всего-лишь radreply по данной документации (h__p://nodeny.com.ua/wiki/index.php/Dhcp%2BRadius)?

[Cell]

Я проверю как он ведет себя. Но думаю до выдачи дело не дойдет т.к. ip-source-guard на коммутаторе заблокирует такое поведение до момент пока связка на порту Б не закончится.
......
Давайте делом заниматься.  

Давайте.
Вы ошибаетесь. До выдачи дойдет ))) вы плохо представляете как этот гуард работает. Если вы сильно прикрутите правила на порту и разрешите только 1 мак - тем самым усложните жизнь и себе и абонентам. Потому что вам придется сбрасывать связку всякий раз при смене устройства. Это не очень удобно, особенно если лизинг у вас будет не 10 минут а побольше. Да в любом случае даже 10 минут -  это много. Адрес должен выдаваться мгновенно и в соответствии  с номером порта и устройства - вот это правильное поведение. А уж потом... всякие там снупинги-гуарды. Я к чему все это веду: нужно сначала определиться с самим дхцп - умеет он поступать так как положено в данной ситуации или нет. Я очень-приочень много времени потратил на организацию работы по опции82. Пришлось патчить dhcpd   чтобы он повторно выдавал адрес из занятого пула - иначе не красивенько вообще получалось. До такой степени не красивенько, что просто вымораживало. Но самое хреновое в этой ситуации то, что все свичи ведут себя с этой сраной опцией по разному. Бюджетные длинки за 90 баксов вообще через жопу с ней обоходятся. Нет, саму опцию нормально отправляют, тут вопросов нет, но реализация IPSG это какой-то ..... в общем желаю вам терпения ))))  Хорошо, если вы под проект закупили сразу штук 300 каких-нибудь нормальных свитчей. Иначе намучаетесь.

[Efendy]

radreply, поддерживающее "один на порту" + я добавил фичу, что для незарегистрированных юзеров будет стараться выдавать один и тот же ip при переключениях:

Код:

DROP PROCEDURE IF EXISTS `radreply`;
DELIMITER $$
CREATE PROCEDURE `radreply`(IN login VARCHAR(64), IN dev_mac VARCHAR(64), IN port VARCHAR(64))
BEGIN
    DECLARE usr_mac VARCHAR(12);
    DECLARE usr_ip VARCHAR(15);
    DECLARE usr_id INT;
    DECLARE one_connect INT;
    SELECT REPLACE(login, ':', '') INTO usr_mac;
    SELECT REPLACE(dev_mac, ':', '') INTO dev_mac;
    SELECT uid, oneconnect INTO usr_id, one_connect FROM mac_uid
        WHERE device_mac=dev_mac AND device_port=port
            AND (mac=usr_mac OR (oneconnect>0 AND device_mac<>''))
        LIMIT 1;
    IF usr_id IS NOT NULL AND usr_id > 0 THEN
        SELECT get_ip(usr_id) INTO usr_ip;
        UPDATE mac_uid SET ip=0 WHERE ip=INET_ATON(usr_ip) AND uid<>usr_id;
        UPDATE mac_uid SET ip=INET_ATON(usr_ip), time=UNIX_TIMESTAMP() WHERE uid=usr_id;
        IF one_connect > 0 THEN
            UPDATE mac_uid SET mac=NULL
                WHERE mac=usr_mac AND oneconnect=0;
            UPDATE mac_uid SET mac=usr_mac
                WHERE device_mac=dev_mac AND device_port=port AND oneconnect>0;
        END IF;
    ELSE
        UPDATE mac_uid SET ip=0 WHERE uid=0 AND time<(UNIX_TIMESTAMP()-3600);
        UPDATE mac_uid SET mac=NULL WHERE mac=usr_mac AND oneconnect>0;
        START TRANSACTION;
        SELECT INET_NTOA(ip) INTO usr_ip FROM ip_pool p WHERE uid=0 AND type='dynamic'
            AND NOT EXISTS (SELECT ip FROM mac_uid WHERE ip=p.ip)
            ORDER BY RAND() LIMIT 1 FOR UPDATE;
        INSERT INTO mac_uid VALUES(
            NULL, usr_mac, INET_ATON(usr_ip), 0, UNIX_TIMESTAMP(), dev_mac, port, 0)
        ON DUPLICATE KEY
            UPDATE ip=IF(ip>0 AND device_mac=dev_mac AND device_port=port, ip, INET_ATON(usr_ip)),
                uid=0, device_mac=dev_mac, device_port=port, time=UNIX_TIMESTAMP();
        COMMIT;
        SELECT INET_NTOA(ip) INTO usr_ip FROM mac_uid
            WHERE mac=usr_mac AND device_mac=dev_mac AND device_port=port;
    END IF;
    SELECT NULL, login, 'Framed-IP-Address', usr_ip, '=';
    SELECT NULL, login, 'Session-Timeout', '600', '=';
END$$
DELIMITER ;

Также не помешает добавить индекс:

Код:

alter table mac_uid add index (oneconnect);

[fet4]

Efendy на этой неделе оттестирую и отпишусь. Спасибо.

Cell
У меня стоит 2 мака на порту свитча если "один на порту" и таких большинство, проблем нет. А зачем сбрасывать связку с "один на порту" там же мак не учитывается?!

Пришлось патчить dhcpd   чтобы он повторно выдавал адрес из занятого пула - иначе не красивенько вообще получалось

Я так понял это при статике? чтобы один и тот же адрес выдавался клиенту?

[fet4]

Efendy
Тестирую Вашу процедуру и есть парус вопросов.

Option82 передается в неизменном виде

Код:

[sql]   expand: call radcheck_ipoe('%{User-Name}') -> call radcheck_ipoe('ec:08:6b:d9:96:e7')
[sql] User found in radcheck table
[sql]   expand: call radreply_ipoe('%{User-Name}','%{DHCP-Agent-Remote-Id}','%{DHCP-Agent-Circuit-Id}','%{NAS-Identifier}') -> call radreply_ipoe('ec:08:6b:d9:96:e7','0x00060012cf7ef380','0x766c616e323030','accel-ppp-ipoe')

Получится ли в процедуре radreply разобрать эти опции? И что делать если разные коммутаторы будут присылать по-разному?
В accel-ppp есть возможность разбирать это все с помощью Lua для каждого интерфейса/vlan и формировать username например так agent_circuit_id:agent_remote_id:mac

Может так будет проще и лучше?

[Efendy]

Трудно переключать контекст и вникать о чем там речь была, попробую угадать, нужно распарсить строку '0x00060012cf7ef380' и выудить из нее мак и порт? Причем формат этой строки будет разный в зависимости от свича? Если тип свича присылать отдельным параметром, то в принципе можно распарсить, хоть mysql и тугой на строковые операции

[fet4]

Трудно переключать контекст и вникать о чем там речь была, попробую угадать, нужно распарсить строку '0x00060012cf7ef380' и выудить из нее мак и порт? Причем формат этой строки будет разный в зависимости от свича? Если тип свича присылать отдельным параметром, то в принципе можно распарсить, хоть mysql и тугой на строковые операции

Тип свича вряд ли получиться присылать отдельным атрибутом, так как список возможных отправляемых атрибутов ограничен.
А что если все-таки присылать в User-Name нужные данные в правильном формате c83a35d309e0:e067b318340a:1 = [mac]:[dev_mac]:[port] и в sql процедуре просто распарсить на части их. Тем более если такая возможность есть.

[fet4]

Трудно переключать контекст и вникать о чем там речь была, попробую угадать, нужно распарсить строку '0x00060012cf7ef380' и выудить из нее мак и порт? Причем формат этой строки будет разный в зависимости от свича? Если тип свича присылать отдельным параметром, то в принципе можно распарсить, хоть mysql и тугой на строковые операции

Хотелось бы закончить связку

распарсить строку  и выудить из нее мак и порт

Давайте сделаем как вы предложили.

Причем формат этой строки будет разный в зависимости от свича? Если тип свича присылать отдельным параметром, то в принципе можно распарсить

В основном прилетают данные со свичей в одном формате, имеется несколько штук которые отличаются.

Что вообще хотелось бы получить от связки.

-сохранить функционал модуля dhcp (Один на порту, Фиксированное подключение)
-выдавать статический ip если он есть  в учетке
-выдавать с пула по тэгу.

[fet4]

Efendy

Radius call radreply_ipoe шлет такую конструкцию

Код:

(14) sql: EXPAND call radreply_ipoe('%{User-Name}','%{NAS-Identifier}')
(14) sql:    --> call radreply_ipoe('ec086bd996e7-0012cf7ef380-21','accel-ppp-ipoe')

radreply_ipoe

Код:

DELIMITER $$
CREATE DEFINER=`nodeny`@`%` PROCEDURE `radreply_ipoe`(IN `login` VARCHAR(64), IN `tag` VARCHAR(64))
BEGIN
    DECLARE rad_mac VARCHAR(12);
    DECLARE rad_dev_mac VARCHAR(12);
    DECLARE rad_port VARCHAR(6);
    DECLARE usr_id INT;
    DECLARE usr_onecon INT;
    DECLARE usr_ip VARCHAR(15);
    
    SELECT SUBSTRING_INDEX(login, '-', 1) INTO rad_mac;
    SELECT SUBSTRING_INDEX(login, '-', -1) INTO rad_port;
    SELECT SUBSTRING_INDEX(SUBSTRING_INDEX(login, '-', 2), '-', -1) INTO rad_dev_mac;
    
    SELECT uid, oneconnect INTO usr_id, usr_onecon FROM mac_uid
		WHERE device_mac=rad_dev_mac AND device_port=rad_port
			AND (mac=rad_mac OR (oneconnect>0 AND device_mac<>''))
        		LIMIT 1;
				
	IF usr_id IS NOT NULL AND usr_id > 0 THEN
		SELECT get_ip_by_tag(usr_id, tag) INTO usr_ip;
		UPDATE mac_uid SET ip=0 WHERE ip=INET_ATON(usr_ip) AND uid<>usr_id;
		UPDATE mac_uid SET ip=INET_ATON(usr_ip), time=UNIX_TIMESTAMP() WHERE uid=usr_id;
		
        IF usr_onecon > 0 THEN
            UPDATE mac_uid SET mac=NULL WHERE mac=rad_mac AND oneconnect=0;
            UPDATE mac_uid SET mac=rad_mac WHERE device_mac=rad_dev_mac AND device_port=rad_port AND oneconnect>0;
        END IF;
		
    ELSE
        UPDATE mac_uid SET ip=0 WHERE uid=0 AND time<(UNIX_TIMESTAMP()-3600);
        UPDATE mac_uid SET mac=NULL WHERE mac=rad_mac AND oneconnect>0;
		
        START TRANSACTION;
        SELECT INET_NTOA(ip) INTO usr_ip FROM ip_pool p WHERE uid=0 AND type='dynamic'
			AND tags LIKE CONCAT('%,', tag ,',%')
			AND NOT EXISTS (SELECT ip FROM mac_uid WHERE ip=p.ip)
			ORDER BY RAND() LIMIT 1 FOR UPDATE;
			
        INSERT INTO mac_uid VALUES(
            NULL, rad_mac, INET_ATON(usr_ip), 0, UNIX_TIMESTAMP(), rad_dev_mac, rad_port, 0)
        ON DUPLICATE KEY
            UPDATE ip=IF(ip>0 AND device_mac=rad_dev_mac AND device_port=rad_port, ip, INET_ATON(usr_ip)),
	         uid=0, device_mac=rad_dev_mac, device_port=rad_port, time=UNIX_TIMESTAMP();
        COMMIT;
		
        SELECT INET_NTOA(ip) INTO usr_ip FROM mac_uid
			WHERE mac=rad_mac AND device_mac=rad_dev_mac AND device_port=rad_port;
			
    END IF;
	
    SELECT NULL, login, 'Framed-IP-Address', usr_ip, '=';
END$$
DELIMITER ;

ip получаю с пула по тегу все хорошо, функцию get_ip_by_tag использую от сюда

h//p://nodeny.com.ua/wiki/index.php/%D0%92%D1%8B%D0%B4%D0%B0%D1%87%D0%B0_ip_%D0%B2_%D0%B7%D0%B0%D0%B2%D0%B8%D1%81%D0%B8%D0%BC%D0%BE%D1%81%D1%82%D0%B8_%D0%BE%D1%82_%D1%82%D0%BE%D0%B3%D0%BE,_%D0%BA_%D0%BA%D0%B0%D0%BA%D0%BE%D0%BC%D1%83_NAS_%D0%BF%D0%BE%D0%B4%D0%BA%D0%BB%D1%8E%D1%87%D0%B5%D0%BD_%D0%B0%D0%B1%D0%BE%D0%BD%D0%B5%D0%BD%D1%82

Efendy можно в кратце логику работы radreply, поддерживающее "один на порту" последнее что вы дали, а то я не все понимаю и возможно что-то упущу при тестировании в сети, хотелось бы все ситуации проверить.

Radius call radupdate_ipoe

Код:

(28) sql: EXPAND call radupdate_ipoe('%{User-Name}','%{Framed-IP-Address}','nas=%{NAS-IP-Address}','%{NAS-Identifier}')
(28) sql:    --> call radupdate_ipoe('ec086bd996e7-0012cf7ef380-21','10.194.13.129','nas=172.19.0.12','accel-ppp-ipoe')

radupdate_ipoe

Код:

DELIMITER $$
CREATE DEFINER=`nodeny`@`%` PROCEDURE `radupdate_ipoe`(IN login VARCHAR(64), IN ipa VARCHAR(16),
    IN properties VARCHAR(255), tag VARCHAR(64))
BEGIN
	DECLARE rad_mac VARCHAR(12);
    DECLARE rad_dev_mac VARCHAR(12);
    DECLARE rad_port VARCHAR(6);
    DECLARE usr_id INT;
    DECLARE usr_ip VARCHAR(15);
    
    SELECT SUBSTRING_INDEX(login, '-', 1) INTO rad_mac;
    SELECT SUBSTRING_INDEX(login, '-', -1) INTO rad_port;
    SELECT SUBSTRING_INDEX(SUBSTRING_INDEX(login, '-', 2), '-', -1) INTO rad_dev_mac;
  
    SELECT uid INTO usr_id FROM mac_uid
		WHERE device_mac=rad_dev_mac AND device_port=rad_port
			AND (mac=rad_mac OR (oneconnect>0 AND device_mac<>''))
        	LIMIT 1;

    IF usr_id IS NULL
    THEN
        SELECT ip INTO usr_ip;
    ELSE
        SELECT get_ip_by_tag(usr_id, tag) INTO usr_ip;
    END IF;
	
    CALL set_auth(usr_ip, CONCAT('mod=dhcp;user=', rad_mac, ';', 'dev=', rad_dev_mac, ';', 'port=', rad_port, ';', REPLACE(properties,':','')));
	UPDATE mac_uid SET time=UNIX_TIMESTAMP() WHERE ip=INET_ATON(ipa) LIMIT 1;
END$$
DELIMITER ;

radupdate_ipoe отрабатывает успешно, но не уверен что сделана она по логике биллинга гляньте пожалуйста.

[Efendy]

Я бегло просмотрел твою radreply, вроде бы все норм. Ты же взял за основу http://forum.nodeny.com.ua/index.php?topic=3016.msg32154#msg32154 ?

"Один на порту" означает, что нам не важен мак абона, поскольку мы по маку свича и порту итак знаем кто он. Поэтому используется подобное условие:

Код:

WHERE device_mac=dev_mac AND device_port=port AND (mac=usr_mac OR (oneconnect>0 AND device_mac<>''))

означает: найти запись в которой мак свича такой-то, порт такой-то. При этом если мак абонента такой-же как и зарегистрирован, то это наш абон. Если это условие сработает, то неважно, что он еще и один на порту. Но допустим он сменил комп и тогда условие mac=usr_mac не сработает, но есть условие ИЛИ: если данный порт помечен как "один на порту" (oneconnect>0), то тоже считаем, что запись наша. При этом для подстраховки проверяется, что задан мак свича.

[fet4]

Efendy
Да это твоя процедура, дополненная нужным мне функционалом.

Если не сложно глянь пожалуйста еще radupdate_ipoe, а то я не уверен в правильности так как пока еще делаю на ощупь.

На dhcp сервере у меня установлены renew-time=150,lease-time=300,max-lease-time=300 относительно этих параметров в биллинге или radius нужно подгонять таймауты обновлений дабы авторизация работала правильно?