Jump to content
Калькуляторы

ISC-DHCPd + Option82: У кого как работает эта связка?

Здравствуйте коллеги.

 

Я так понимаю связку ISC-DHCPd + Option82 тут используют многие. Стал тут тоже неё поглядывать, появились несколько вопросов.

 

Сейчас вся сеть работает на чистом PPPoE, по схеме VLAN на дом (группа коммутаторов). Планирую запустить пилот-сегмент с использованием DHCP Option82 + DHCP Snooping + IP Source Guard для маршрутизации локалки (терминация L3 интерфейсов на Cisco 3750G) но в то же время оставить PPPoE как дополнительную авторизацию для доступа в Интернет (да, иногда хочется странного). Как кто решает вопрос с блокировкой локалки для юзеров, не оплативших абонентку? Идея такая, что даже если юзер не оплатил локалку, у него должен быть доступ с билингу чтобы посмотреть что случилось, проверить баланс в личном кабинете, оплатить. Про Интернет речи не идет - его отрежет на граничном маршрутизаторе.

 

Пока видится все опции:

1) На Cisco 3750G формировать\изменять L3 ACL, привязанные к VLAN'ам, таким образом управляя пропуском трафика от отдельных абонентов к локалке. Периодически менять эти листы и заливать их на циски. Из минусов - если использовать "длинные" ACL (один на все VLAN'ы), в которых будет список всех абонентов в пределах данного узла агрегации; если использовать для каждого VLAN'а свой ACL, то становится мудренее управление и формирование этих ACL. Дополнительный минус - необходимо забрасывать измененные ACL на циски, возникает период обновления ACL равный интервалу заброски ACL - в итоге абонент получает сервис не мгновенно, что иногда вызывает ненужные вопросы в техподдержку.

2) На Cisco 3750G создать один короткий ACL, в котором описать две большие сети - например 10.0.0.0/8 и 192.168.0.0/16. Юзеров из 10.0.0.0/8 пускать всегда и везде (юзеры с оплаченной абоненткой). Юзерам не оплатившим абонентку выдавать по DHCP адрес из 192.168.0.0/16, для которой открыт доступ только на билинг. На Cisco 3750G на VLAN интерсейсах держать адреса из обоих сетей, с общим коротким ACL'ом. Управлять доступом к локалке путем изменения конфигурации ISC-DHCPd. Плюсы: конфигурация цисок статична, ничего не обновляется, короткие и эффективные ACL'ы.

 

И первый и второй варианты выглядят вполне рабочими. Только по второму варианту никак не могу понять как эффективно, быстро и красиво менять конфигурацию ISC-DHCPd в расчете что вся конфигурация должна быть per-user, т.е. абоненту выдается статический серый (или белый адрес), или даже подсеть, но всегда одна и та же. Насколько я понимаю, конфигурация ISC-DHCPd находится в текстовом файле, связку в внешней базой данных (MySQL например) этот софт не поддерживает (хотя может я плохо искал). Каким образом менять конфигурационный файл? Как я понял, по HUP серверу станет плохо и он как минимум выбросит все leases и будет их переподнимать минут 5 (при большом конфиге). Делать это каждый раз когда очередной абонент, которых не одна тысяча, оплатит абонентку и будет нуждаться в смене конфигурации на DHCP сервере - просто нереально, сервер будет только и делать что заниматься перечитками конфига каждые 5 минут. Дополнительный вопрос по схеме2: как досрочно "пнуть" юзера, чтобы он перезапросил DHCP параметры в случае если нужно выдать ему другой адрес, ведь если этого не сделать то он допустим не получит сервис при оплате если кабель не передернет, или наоборот будет пользоваться локалкой пока не кончится время lease.

 

Хотелось бы услышать каким образом у кого работает данная схема, услышать советы и ознакомиться с проверенными решениями, чтобы не наступать на грабли и не изобретать велосипед.

 

Заранее большое спасибо.

Edited by Sergey_Taurus

Share this post


Link to post
Share on other sites
Пока видится все опции:

1) На Cisco 3750G формировать\изменять L3 ACL, привязанные к VLAN'ам, таким образом управляя пропуском трафика от отдельных абонентов к локалке. Периодически менять эти листы и заливать их на циски. Из минусов - если использовать "длинные" ACL (один на все VLAN'ы), в которых будет список всех абонентов в пределах данного узла агрегации; если использовать для каждого VLAN'а свой ACL, то становится мудренее управление и формирование этих ACL. Дополнительный минус - необходимо забрасывать измененные ACL на циски, возникает период обновления ACL равный интервалу заброски ACL - в итоге абонент получает сервис не мгновенно, что иногда вызывает ненужные вопросы в техподдержку.

2) На Cisco 3750G создать один короткий ACL, в котором описать две большие сети - например 10.0.0.0/8 и 192.168.0.0/16. Юзеров из 10.0.0.0/8 пускать всегда и везде (юзеры с оплаченной абоненткой). Юзерам не оплатившим абонентку выдавать по DHCP адрес из 192.168.0.0/16, для которой открыт доступ только на билинг. На Cisco 3750G на VLAN интерсейсах держать адреса из обоих сетей, с общим коротким ACL'ом. Управлять доступом к локалке путем изменения конфигурации ISC-DHCPd. Плюсы: конфигурация цисок статична, ничего не обновляется, короткие и эффективные ACL'ы.

Нафик?

Читать лень?)

 

DHCP Option82 + DHCP Snooping + IP Source Guard
Позволяет жёстко закреплять за абонентом ИП, так что он если его сменит то коммутатор на доступе его никуда не пустит сам, без всяких доп ацл.

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

 

 

Только по второму варианту никак не могу понять как эффективно, быстро и красиво менять конфигурацию ISC-DHCPd в расчете что вся конфигурация должна быть per-user, т.е. абоненту выдается статический серый (или белый адрес), или даже подсеть, но всегда одна и та же.
Это значит вы не читали совсем.

ДХЦП не отдаёт подсети, там в заголовке поля по 4 байта для ипв4 адресов.

 

Есть дхцпд патченный до работы с SQL...

Есть фрирадиус 2х, в стадии развития, но в продакшен уже некоторые поставили. (Кстати, там совсем не обязательно перлом пользоваться для работы с бд)

Есть dhcpsql, вроде рабочий но заброшенный.

Есть самописные варианты.

 

дхцпд - просто держат два, пока один перезапускается другой работает.

Если долго пере запускается - сегментируют.

 

ipconfig /renew

Share this post


Link to post
Share on other sites
Нафик?

Читать лень?)

Сорри, но я не понял что это было. Что мне следовало читать и где?

 

DHCP Option82 + DHCP Snooping + IP Source Guard
Позволяет жёстко закреплять за абонентом ИП, так что он если его сменит то коммутатор на доступе его никуда не пустит сам, без всяких доп ацл.

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

Ну да, как раз вариант №2 о котором я прочитал на этом форуме. Что значит "без всяких доп ацл"? А кто же его тогда никуда не пустит, кроме билинга? Как я понимаю, для этого и нужен ACL на той железке (например на L3 агрегаторе, например на упомянутом мною Cisco 3750G, конечно же не на коммутаторе доступа), где "отдельная подсеть" будет резаться и пропускаться только на билинг, а "правильная" подсеть - пропускаться на локалку.

 

Только по второму варианту никак не могу понять как эффективно, быстро и красиво менять конфигурацию ISC-DHCPd в расчете что вся конфигурация должна быть per-user, т.е. абоненту выдается статический серый (или белый адрес), или даже подсеть, но всегда одна и та же.
Это значит вы не читали совсем.

ДХЦП не отдаёт подсети, там в заголовке поля по 4 байта для ипв4 адресов.

Наверное криво выразил свою мысль - здесь имелось ввиду, что за абонентом закреплен не конкретный статический адрес серый\белый, а динамический, из диапазона-подсети. Например, для тех абонентов, которым серая статика не нужна по разным причинам. Также я имел ввиду случай, когда через DHCP на конкретном порту (юрик) планируется выдавать например белую подсеть /29 через DHCP.

 

Есть дхцпд патченный до работы с SQL...

Есть фрирадиус 2х, в стадии развития, но в продакшен уже некоторые поставили. (Кстати, там совсем не обязательно перлом пользоваться для работы с бд)

Есть dhcpsql, вроде рабочий но заброшенный.

Спасибо за наводки, погляжу. Просто после частого упоминания ISC-DHCPd думал что все работают в основном в связке с ним.

 

ipconfig /renew
Это бесспорно прекрасно, но вопрос был не об этом. Юзер забыл оплатить абонентку, он вечером пришел домой, включил ноутбук и ему выдался адрес из диапазона, где локалка зарезана. Юзер зашел в личный кабинет, оплатил в личном кабинете абонентку, тут же в конфигурации DHCP сервера для него прописался адрес из другого диапазона, для которого локалка разрешена. Как я представляю, этот новый адрес юзер получит если он перегрузит свой WindowsXP, выкл\вкл сетевой адаптер или дернет и воткнет обратно шнурок из компа (или роутера). Извините, но я не вижу здесь места, куда обычная среднестатистическая домохозяйка с виндой на ноуте может вбить ipconfig /renew Т.е. собственно вопрос в том как форсировать DHCP "сбросить" lease для этого юзера и заставить его сделать повторный DHCP запрос при котором уже выдать новый адрес.
Edited by Sergey_Taurus

Share this post


Link to post
Share on other sites
а вы lease time небольшим сделайте
:) Действительно, просто и железобетонно надежно. Спасибо за наводку. Задержкой в 10 минут, например, можно и пожертвовать, если вариантов больше нет.

Больше никаких именно server-side способов нет, чтобы минимизировать время между включением услуги в билинге и её фактическим включением у абонента?

 

Share this post


Link to post
Share on other sites

не менять клиенту ip адрес например ;)

 

вы приходите, я вам еще че нить придумаю ;)

Share this post


Link to post
Share on other sites
а вы lease time небольшим сделайте
:) Действительно, просто и железобетонно надежно. Спасибо за наводку. Задержкой в 10 минут, например, можно и пожертвовать, если вариантов больше нет.

Больше никаких именно server-side способов нет, чтобы минимизировать время между включением услуги в билинге и её фактическим включением у абонента?

Мне кажется это флуд тогда будет. Зачем вам резкр отключать пользователя тарифы не безлимитные или просто важно чтобы новый компьютер быстро подключался и получал айпи?

Есть вот это нестандартное решение. Здесь на форуме это обсуждалось. Тему поднимал dsk и решение было найдено http://forum.nag.ru/forum/index.php?showto...mp;#entry546934

Edited by Traskalata

Share this post


Link to post
Share on other sites
Сорри, но я не понял что это было. Что мне следовало читать и где?
Относилось к "DHCP Option82 + DHCP Snooping + IP Source Guard".

 

Ну да, как раз вариант №2 о котором я прочитал на этом форуме. Что значит "без всяких доп ацл"? А кто же его тогда никуда не пустит, кроме билинга? Как я понимаю, для этого и нужен ACL на той железке (например на L3 агрегаторе, например на упомянутом мною Cisco 3750G, конечно же не на коммутаторе доступа), где "отдельная подсеть" будет резаться и пропускаться только на билинг, а "правильная" подсеть - пропускаться на локалку.
Правила настраиваются один раз, чтобы изолировать подсеть с должниками.

Каждый раз их настраивать не нужно, тк дхцп сам отдаст нужный адрес.

Единственное, абонент может прописать себе полученный адрес статикой.

Я не знаю как в таких случаях будет действовать коммутатор: перестанет ли он пропускать трафик от абонента по истечению времени лизы или нет.

Если нет - придётся дополнительно в нём на каждый порт по правилу добавлять и динамически с биллинга их обновлять.

 

 

 

Также я имел ввиду случай, когда через DHCP на конкретном порту (юрик) планируется выдавать например белую подсеть /29 через DHCP.
Dynamic HosT Configuration Protocol.

Про хостЫ/подсети в названии ничего не сказано.

Я рфк читал бегло, и не увидел там возможности отдавать сразу подсети, вместо одного адреса.

Просветите?

 

Спасибо за наводки, погляжу. Просто после частого упоминания ISC-DHCPd думал что все работают в основном в связке с ним.
Ищите по форуму, здесь фрирадиус даже чаще упоминается, наверное потому что более загадочен :)

 

 

Это бесспорно прекрасно, но вопрос был не об этом. Юзер забыл оплатить абонентку, он вечером пришел домой, включил ноутбук и ему выдался адрес из диапазона, где локалка зарезана. Юзер зашел в личный кабинет, оплатил в личном кабинете абонентку, тут же в конфигурации DHCP сервера для него прописался адрес из другого диапазона, для которого локалка разрешена. Как я представляю, этот новый адрес юзер получит если он перегрузит свой WindowsXP, выкл\вкл сетевой адаптер или дернет и воткнет обратно шнурок из компа (или роутера). Извините, но я не вижу здесь места, куда обычная среднестатистическая домохозяйка с виндой на ноуте может вбить ipconfig /renew Т.е. собственно вопрос в том как форсировать DHCP "сбросить" lease для этого юзера и заставить его сделать повторный DHCP запрос при котором уже выдать новый адрес.
Либо делать время аренды, хотя бы подсети должников маленьким, либо почитать внимательно по значениям опции 53, а именно:

RFC 3203 DHCP reconfigure extension (FORCERENEW)

 

 

 

а вы lease time небольшим сделайте
С этим можно доиграться: получить слишком большое количество запросов в единицу времени.

Share this post


Link to post
Share on other sites

 

гостевой vlan, и не надо плясок с бубном

Share this post


Link to post
Share on other sites
а вы lease time небольшим сделайте
:) Действительно, просто и железобетонно надежно. Спасибо за наводку. Задержкой в 10 минут, например, можно и пожертвовать, если вариантов больше нет.

Больше никаких именно server-side способов нет, чтобы минимизировать время между включением услуги в билинге и её фактическим включением у абонента?

Мне кажется это флуд тогда будет. Зачем вам резкр отключать пользователя тарифы не безлимитные или просто важно чтобы новый компьютер быстро подключался и получал айпи?

Я просто как наяву вижу среднестатистическую домохозяйку, которая положила деньги через киоск оплаты, пришла домой, зашла (уже достижение иногда) в личный кабинет, оплатила локалку и сидит ждет когда же оно заработает. Ждет недолго, минуты 2-3, потом начинает звонить в суппорт, а на том конце провода ей начинают объяснять как сделать ipconfig /renew, т.е. сделать что-то с компом, чтобы он получил новый IP адрес (здесь на слове "IP адрес" мы просто пациента теряем). Тарифы на Инет тут не при чем - они режутся на граничном маршрутизаторе без вмешательства кого-либо. Мне нужно чтобы доступ к сервису "локальная сеть" открывался и закрывался оперативно и с минимальным участием абонента, чтобы он для этого не перегружал комп, не выключал сетевые карты которые потом он не сможет включить обратно, не дергал как попало первые попавшиеся под руку кабеля (монтажникам и без этого работы хватает) и прочее.

Share this post


Link to post
Share on other sites
Ну да, как раз вариант №2 о котором я прочитал на этом форуме. Что значит "без всяких доп ацл"? А кто же его тогда никуда не пустит, кроме билинга? Как я понимаю, для этого и нужен ACL на той железке (например на L3 агрегаторе, например на упомянутом мною Cisco 3750G, конечно же не на коммутаторе доступа), где "отдельная подсеть" будет резаться и пропускаться только на билинг, а "правильная" подсеть - пропускаться на локалку.
Правила настраиваются один раз, чтобы изолировать подсеть с должниками.

Каждый раз их настраивать не нужно, тк дхцп сам отдаст нужный адрес.

Да, с этим то все понятно... На ближайшем L3 агрегаторе нужны правила для пропуска куда угодно допустим 10.0.0.0/8 (диапазон хороших юзеров, с оплаченной абоненткой) и пропуском допустим 192.168.0.0/16 (должники) только на билинг. Здесь вопросов нет, все логично и понятно.

 

Также я имел ввиду случай, когда через DHCP на конкретном порту (юрик) планируется выдавать например белую подсеть /29 через DHCP.
Dynamic HosT Configuration Protocol.

Про хостЫ/подсети в названии ничего не сказано.

Я рфк читал бегло, и не увидел там возможности отдавать сразу подсети, вместо одного адреса.

Просветите?

Давайте не будем буквоедничать? Еще раз, бегло перефразирую\скопипастю то, что я уже приводил в пример:

1) В общем случае каждый клиент имеет в конфиге DHCP сервера конкретный, закрепленный за ним статический серый адрес, который выдается конкретному абоненту по конкретной паре RemoteID+CurcuitID.

2) Есть клиенты которым нужно более одного статического серого (или даже белого) адреса на порту, получаемых по DHCP. Для них в конфиге DHCP сервера выделена /29 и более подсеть, из которой они получают адреса. По одному. Для каждого хостА. Но по одному. Но из подсети, сконфигурированной в конфиге DHCP севрера. Но по одному, для каждого хостА.

 

Я не гуру в Option82, поэтому могу хотеть странного или невозможного. Если так, то поправьте плиз. Для конфигурации в варианте когда выдаются адреса куче юзеров на общем влане так все работает, проверял. Но будет ли это также работать если нужно выдавать адреса из диапазона заранее определенной подсети, для группы юзеров на определенном CurcuitID (порту узла доступа)?

 

Т.е. собственно вопрос в том как форсировать DHCP "сбросить" lease для этого юзера и заставить его сделать повторный DHCP запрос при котором уже выдать новый адрес.
Либо делать время аренды, хотя бы подсети должников маленьким, либо почитать внимательно по значениям опции 53, а именно:

RFC 3203 DHCP reconfigure extension (FORCERENEW)

Ок, спасибо за наводку, почитаю. Может это и есть, то что нужно.

 

гостевой vlan, и не надо плясок с бубном
Хотелось бы свести управление чем-либо на узлах доступа к нулю. Как я понимаю, порт в гостевой влан придется переносить скриптами управления, причем лазить напрямую на узел доступа, который может быть в дауне, т.е. придется это тоже отслеживать, "откладывать" на потом когда узел доступа оживет и т.д.

 

Как раз в обсуждаемой схеме даже на L3 агрегаторах никакого управления\переконфигурирования не происходит, даже ACL'ы не изменяются, что и привлекает, т.к. на первый взгляд это будет более стабильно.

Share this post


Link to post
Share on other sites
Хотелось бы свести управление чем-либо на узлах доступа к нулю. Как я понимаю, порт в гостевой влан придется переносить скриптами управления, причем лазить напрямую на узел доступа, который может быть в дауне, т.е. придется это тоже отслеживать, "откладывать" на потом когда узел доступа оживет и т.д.

Вот это как-раз мелочи. Подумаешь, юзер при дауне свича лишние 10 минут локалом попользуется...

Share this post


Link to post
Share on other sites
2) Есть клиенты которым нужно более одного статического серого (или даже белого) адреса на порту, получаемых по DHCP. Для них в конфиге DHCP сервера выделена /29 и более подсеть, из которой они получают адреса. По одному. Для каждого хостА. Но по одному. Но из подсети, сконфигурированной в конфиге DHCP севрера. Но по одному, для каждого хостА.
Это притянуто за уши.

Вы себе представляете как будут матерится админы, которым вместо того чтобы статикой прописать ип+шлюз нужно будет прыгать с дхцп клиентом?

Даже те которые с виндой - понавключают фаер и ничего у них не заработает.

Проще уж просто ацл на порт повесить, чтобы только эту подсетку пропускал через него.

 

Я не гуру в Option82, поэтому могу хотеть странного или невозможного. Если так, то поправьте плиз. Для конфигурации в варианте когда выдаются адреса куче юзеров на общем влане так все работает, проверял. Но будет ли это также работать если нужно выдавать адреса из диапазона заранее определенной подсети, для группы юзеров на определенном CurcuitID (порту узла доступа)?
Оптион 82 - это информация которую добавляет/обрабатывает дхцп прокси=релей агент.

Там порядка 10 под опций определено, обычно используется несколько.

Логику поведения задаёте сами, как напишите так и будет.

Share this post


Link to post
Share on other sites
Я просто как наяву вижу среднестатистическую домохозяйку, которая положила деньги через киоск оплаты, пришла домой, зашла (уже достижение иногда) в личный кабинет, оплатила локалку и сидит ждет когда же оно заработает. Ждет недолго, минуты 2-3, потом начинает звонить в суппорт, а на том конце провода ей начинают объяснять как сделать ipconfig /renew, т.е. сделать что-то с компом, чтобы он получил новый IP адрес (здесь на слове "IP адрес" мы просто пациента теряем). Тарифы на Инет тут не при чем - они режутся на граничном маршрутизаторе без вмешательства кого-либо. Мне нужно чтобы доступ к сервису "локальная сеть" открывался и закрывался оперативно и с минимальным участием абонента, чтобы он для этого не перегружал комп, не выключал сетевые карты которые потом он не сможет включить обратно, не дергал как попало первые попавшиеся под руку кабеля (монтажникам и без этого работы хватает) и прочее.

По SNMP выключаем порт свитча, ждем 1-2 секунды, включаем порт свитча.

Пользователь получает новый адрес.

По образу и подобию кабельных модемов :)

 

Если узел в дауне, то уже и не важно, получил абонент новый адрес или нет. Всё равно никуда не пробьется, в том числе и в личный кабинет.

 

PS. Метод не сработает в случае EdgeCore - эти аппараты физически линк не тушат.

 

Вы себе представляете как будут матерится админы, которым вместо того чтобы статикой прописать ип+шлюз нужно будет прыгать с дхцп клиентом?

С этого момента поподробнее плз. Почему они должны материться?

Share this post


Link to post
Share on other sites
С этого момента поподробнее плз. Почему они должны материться?
Потому что:

- придётся держать BPF в ядре для работы дхцп

- лишнее барахло при запуске и работе

- лишние порты открыты в фаере

- возможность потерять аренду адреса в случае сбоев на линии (даже просто если провайдер идиот и неправильно настроил Т1 и Т2 да ещё и при маленьком времени аренды лизы)

- более длительное восстановление связи после сбоев в работе дхцп сервера/связи с ним (читай сети)

- возможность перехвата трафика, если провайдер не озаботится безопасностью дхцп

- дополнительный элемент для диагностики в случае когда сеть не работает

- усложняется конфиг фаера - нужно учитывать что адрес динамический и порты/адреса для дхцп открывать

- нет возможности получать на интерфейс больше 1 ИП адреса.

 

 

Статику прописал и забыл.

Не работает - всегда можно попингать шлюз, ибо вот он, тут же в текстовом конфиге прописан.

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

Для хомячка и мобильно юзера, и в ряде некоторых других случаев дхцп это ВСЁ, но для сколь нибудь понимающего админа скорее лишние головняки, чем радость.

Share this post


Link to post
Share on other sites

Ivan_83

Это эти админы еще не подозревают чем их IPv6 обрадует, особенно с двумя внешними каналами. Так что пусть привыкают 8)

 

Share this post


Link to post
Share on other sites
Хотелось бы свести управление чем-либо на узлах доступа к нулю. Как я понимаю, порт в гостевой влан придется переносить скриптами управления, причем лазить напрямую на узел доступа, который может быть в дауне, т.е. придется это тоже отслеживать, "откладывать" на потом когда узел доступа оживет и т.д.

Вот это как-раз мелочи. Подумаешь, юзер при дауне свича лишние 10 минут локалом попользуется...

 

В самом деле, это время можно сократить почти до нуля. Как правило, при загрузке свитч шлёт всякую фигню в syslog, шлёт trap (coldstart/warmstart) и при желании это дело можно отловить и не давать юзерам даже 10 минут халявы, но ИМХО возня на реализацию не стоит результата.Проще в cron поставить скрипт, который донастраивает ожившие свитчи и забыть про эту проблему.

Share this post


Link to post
Share on other sites

а на том конце провода ей начинают объяснять как сделать ipconfig /renew, т.е. сделать что-то с компом, чтобы он получил новый IP адрес (здесь на слове "IP адрес" мы просто пациента теряем).

Хомячкам нельзя так говорить. Нужно говорить "после оплаты Ваш компьютер должен подключиться к локальной сети. Самый просто способ это сделать - перезагрузить компьютер". Приучатся и будут перезагружать. Более умные спросят про сложный способ - тогда уже о renew обьяснять.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this