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

Схема доступа optinon 82 + 802.1x + pppoe - что оптимально?

Доброго времени суток! Софтово-железячный вопрос, ткните ссылкой, если это уже спрашивали.

 

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

По железу все вписывается в схему вроде "des-3028 + dgs-3100-24tg + софт-роутер на freebsd" - вроде как достаточно стандартно.

Денег, разумеется, есть но мало.

 

Пожалуйста, посоветуйте схему доступа в сеть с наименьшим кол-м настроек с пользовательской стороны...

Ниже привожу несколько неупорядоченные мысли по этому поводу

 

Хочется удобной реализации для:

0) пускать\не пускать в локалку в зависимости от состояния баланса (это не вопрос )

1) default - просто пользователь "на почте и баше", которому безразлично, чем он натится (не пользуется файлообменниками\торрентами)

2) пользователь с несколькими компьютерами а) как на один порт, так и б) через роутер-железку (по 802.1x - дорого получается железка)

3) пользователь с белым ip, локалка не интересна (ну, во всяком случае, он так думает)

4) пользователь с белым ip + локалка

 

1-й Вопрос! Надо ли хотеть option 82?

Для значительной части пользователей компьютер статичен, поэтому прибивание ip-mac к порту IMHО! не должно мешать, но, разумеется, альтернативное подключение небоходимо.

Для тех, кто хочет сходить к соседу предполагаю применять хоть тот же 802.1х

 

2-й Вопрос! Есть ли те, кто успешно и красиво у себя запустились на option 82 с оборудованием dlink?

Если это решаемо, то хочется иметь альтернативу для подключения абонентов - хотя бы тот же 802.1x (еще варианты?)

 

Но я пока не представляю, как красиво отдавать пользователю (фиксированный?) белый ip, сохранив ему локалку.

Кроме pptp\pppoe сразу в голову ничего не приходит... (или делать что-то бесчеловечное с натом на гейте?) - но в сочетании со, скажем, 802x такое нагромождение меня не радует.

 

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

 

Спасибо.

Share this post


Link to post
Share on other sites

Правильно - влан на юзверя. Остальное - от лукавого. Возможно совмещение N юзеров в одном влане, где N - число портов на свиче агрегации.

По требуемому железу - отличия минимальны. Вместо dgs-3100-24tg - Л3 циска (35../36../37../45../65.. по вкусу).

А на доступ - можно и попроще чем 3028. Достаточно только поддержки 802.1q.

 

Всё естественно ИМХО, дабы не разжигать очередной холивар :)

Share this post


Link to post
Share on other sites
Для значительной части пользователей компьютер статичен, поэтому прибивание ip-mac к порту IMHО! не должно мешать, но, разумеется, альтернативное подключение небоходимо.

Для тех, кто хочет сходить к соседу предполагаю применять хоть тот же 802.1х

Прибивать IP к порту ACL'ями.

Share this post


Link to post
Share on other sites
Правильно - влан на юзверя. Остальное - от лукавого. Возможно совмещение N юзеров в одном влане, где N - число портов на свиче агрегации.

По требуемому железу - отличия минимальны. Вместо dgs-3100-24tg - Л3 циска (35../36../37../45../65.. по вкусу).

А на доступ - можно и попроще чем 3028. Достаточно только поддержки 802.1q.

 

Всё естественно ИМХО, дабы не разжигать очередной холивар :)

Да, это действительно хорошее техническое решение.

К сожалению, я не знаю, что в таком случае надо хотеть от биллинга...

 

Вот есть абон. отдел, в который пришел пользователь и заключил договор.

Я понимаю, что в идеале можно хотеть от биллинга настройки оборудования (на основе профиля?) порта, к которому пользователя подключат.

Т.е. приходят монтажники и втыкают пользовательский провод в 3-й порт и он уже настроен.

Что есть в реальности?

 

Я к тому, что какая схема позволит абон. отделу (через только лишь морду биллинга) решать большинство вопросов, которые могут появиться у абона в процессе его жизнедеятельности?

Разумеется, если есть опыт работы на основе какого-то конкретного биллинга - назовите (с конкретикой всегда проще)

Просто я понимаю, что вопросы автоматической генерации логин-пароля для pppoe\pptp (с выдачей конверта с напечатанными данными) могут решаться куда проще, нежели чем изменение конфигурации оборудования на доме.

 

Сорри, ну не видел я схемы работы офиса "все по уму" :-( , поэтому не знаю, чего можно хотеть. Чего точно не хочется, так это в обязательном порядке залезания на железо и т.п.

Поэтому очень хочу совместить хорошее техническое решение с .... эргономикой :)

Edited by Donat

Share this post


Link to post
Share on other sites
Вот есть абон. отдел, в который пришел пользователь и заключил договор.

Я понимаю, что в идеале можно хотеть от биллинга настройки оборудования (на основе профиля?) порта, к которому пользователя подключат.

Т.е. приходят монтажники и втыкают пользовательский провод в 3-й порт и он уже настроен.

Что есть в реальности?

 

Я к тому, что какая схема позволит абон. отделу (через только лишь морду биллинга) решать большинство вопросов, которые могут появиться у абона в процессе его жизнедеятельности?

Разумеется, если есть опыт работы на основе какого-то конкретного биллинга - назовите (с конкретикой всегда проще)

Просто я понимаю, что вопросы автоматической генерации логин-пароля для pppoe\pptp (с выдачей конверта с напечатанными данными) могут решаться куда проще, нежели чем изменение конфигурации оборудования на доме.

 

Сорри, ну не видел я схемы работы офиса "все по уму" :-( , поэтому не знаю, чего можно хотеть. Чего точно не хочется, так это в обязательном порядке залезания на железо и т.п.

Поэтому очень хочу совместить хорошее техническое решение с .... эргономикой :)

 

Именно так и сделано, монтажник протягивает провод, звонит в абон отдел, называет порт юзера, абон отдел в базе нажимает кнопочку - всё, юзер работает (DHCP + Option 82 + NAT без VPN, всё с UTM в связке)

Share this post


Link to post
Share on other sites
Именно так и сделано, монтажник протягивает провод, звонит в абон отдел, называет порт юзера, абон отдел в базе нажимает кнопочку - всё, юзер работает (DHCP + Option 82 + NAT без VPN, всё с UTM в связке)
хммм... при этом самим биллингом 82 должно поддерживаться?

Был слух, что в самом UTM option 82 сильно-то не поддерживается... или враги все наврали?

- по форуму пробежался, кроме не очень понятной http://www.netup.ru/phpbb/viewtopic.php?t=...ighlight=option не встретилось...)

 

А что получает юзер по dhcp(насколько он произволен) и как абонент может получить белый ip? (и сильно ли надо кликать абон отделу для этого? :) )

Edited by Donat

Share this post


Link to post
Share on other sites
Был слух, что в самом UTM option 82 сильно-то не поддерживается... или враги все наврали?
UTM такая штука, что при применении к нему /dev/hands и наличия лицензии на urfa-client, к нему можно прикрутить что угодно, в т.ч. и 82ю опцию (такое св-во абонента, как id свича, вообще есть в стандартной поставке). Без написания собственных скриптов управления железом УТМ вообще мало что умеет...
А что получает юзер по dhcp(насколько он произволен) и как абонент может получить белый ip? (и сильно ли надо кликать абон отделу для этого? :) )
В чем проблема выдавать желающим белый адрес? Единственное, он должен быть статичен для абонента. На шлюзе реальник + алиасом виртуальник, конфиг дхцп генерится таким образом, чтоб при наличии у абонента 2 ip - серого и белого, выдавался именно белый.

А количество кликов абон. отдела в целом обратно пропорционально времени, потраченного сисадмином на написание системы управления сетью

 

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