G.Y.S.
-
Публикации
141 -
Зарегистрирован
-
Посещение
Сообщения, опубликованные пользователем G.Y.S.
-
-
а как вам схема авторизации по 802.1x:
упр свич (узел доступа) --- неупр. свич (на доме) -1 влан
абоненты (дома где неупр свич) авторизуются на порту управляемого свича по 802.1x
благо mac-based 802.1x позволяют задать
до 16 маков на порт у длинка
до 32 у хьюлетов
до ?? у байстэков
-
Попробуйте все-таки подсчитать, во сколько вам станет настройка PPPoE...
без комментариев. Во всем виноват Чубайс...
-
не заметил ответ.
1. Потрясающе. На дня обязательно сам проверю.
Спасибо.
-
G.Y.S., активка это 5-10% от цены нормальной сети.
А уж если говорить про полную стоимость (т.е. с учетом лет эдак 5-ти эксплуатации)...
1. говорить о о конкретных ценах я не хочу. В любом случае с PPPoE и единственным неуправляемом свичем в доме (далее он подключен у упр-мому) будет дешевле
ЗЫ
через 5 лет - оборудование уже 1-2 раза придеться поменять.
2. оптимизация саппорта мало зависит от кого упр ли в доме свич или нет.
ЗЫ
мне думается что Паше с такой жизненной позицией (к черту PPPoE) проще продавать упр. железо в бол. колчествах =)
-
Повторяю в 10-й раз вводную.
В доме стоит управляемый свитч, абонент включен на управляемый порт.
не в 10,а в первый ! -) - см. выше
если каждый абонент воткнут в порт управляемого коммутатора - то проблемм нет. Но (как в рекламме): "нет сынок - это фантастика"
+
А внутренний трафик чтобы счтать - это коммутаторы с netflow покупай ? (иногда гигабитные)
Дорого. Очень дорого.
-
Вот. Смотри.
Твоя схема: 1. используем DHCP - правильно ? (иначе работать с vlan практически невозможно).
2. Ip addr -ss абоненту DHCP дает в зависимасти от мак (в твоей схеме).
3. Абонент меняет мак. Все - он не авторизован. Можно настроить ДХЦП давать какой нить ip из "гостевого пула" вновь появившемуся маку в влане. Но это не спасет.
Мониторить ? - ну отмониторил.... В доме стоит неупр свич. Дом подключен к порту упр свича. На упр. свиче появился новый мак. Что дальше ...?
ПОВТОРЯЮ
Если нет возможности дасть каждому юзеру влан (а ее нет у большинства ДС) - то нормально авторизировать юзера (без тунелей) и разделять ему локальные сервисы (например запретить доступ в др влан) от инернета просто нельзя. Если только не спашивать у него новый мак (а Паша не хочет!=)
-
Прочитал.
Других аргументов к сожалению не увидел.
Vlan на юзера - идеально, быстро, контролируемо. Но дорого и трудоемко.
Если нет возможности дасть каждому юзеру влан (а ее нет у большинства ДС) - то нормально авторизировать юзера (без тунелей) и разделять ему локальные сервисы (например запретить доступ в др влан) от инернета просто нельзя. Если только не спашивать у него новый мак (а Паша не хочет!=)
-
предлагаю провести грань между маленьким и большим?
продавцам левого дешевого траффика развернутся будет негдедешевле чем мы - не продает никто =) Про вири уже писал
-
Но... Приводить в порядок на управляемом и т.п. все равно придется. Так зачем громоздить одно на другое?
а что приводить в порядок то? Ну пусть юзеры в пределах влана делют что хотят.
Тарелочники? - не большой вред при разумной тарифной политике борльшого оператора.
Вири? - лечаться асцессами портах l2 свичей
Атаки соседа? - нет tcp/ip на интерфесе - нет атаки
Что еще? У вас сот. телефон - но оператор не может заст-ть вас не уст gsm-шлюз или не пользоваться рацией . Это накем - проше надо отноститься к неуправляемому сегменту - ничего страшного внем нет. И не делать из мухи слона.
Читай выше "низкоскоростные каналы". ;-)я бы не назвал бы adsl2 - низкоскоростным. Ладно ... не тема обсуждения.
-
по существу - про proxy-arp - это имхо изврат.
если денег хватило на упр железку в доме - узайте .1q на абонента или группу.
Портовые vlan - тоже можно - тогда выдавайте /30 абонетам чтобы два соседа могли соединиться др с др-м.
Если не хватает денег на .1q на абонента - тогда PPPoE.
Другого решения я не вижу...?
-
автору топика:
А что собственно вы хотите контролировать в сегменте?
Юзера отключить за неуплату: без упр. железок может только монтажник. Напр-ть через себя инет трафик на др-х юзеров - мало выгодно - при грамотной тариф политике. Вирусы можно порезать поставивь пару l2.
+ пару гигабит линков - чтобы легче было жить с тунелями
PPPoE.
-
1. Решаемо, только дороговато пока.
согласен. Но еще и трудоемко! (хотя работать мы не боимся=)
2. Вы правда считаете, что PPPoE уменьшает число звноков в саппорт? :-)уверен! Особенно звонков из серии: я купил себе новый комп (ко мне пришел друг с ноутом) и проч - забейте пожалуйста мой новый мак
3. Это куда легче контролировать без PPPoE, и дешевле к тому жеПриведите пример. Будете по snmp рулить acl на l3 свичиках ? Или как ?
В большом L2-сегменте плодятся вирусы, атаки, левые PPPoE - серваки, появляются тарелочники и т.д., и т.п. Все прелести неконтролируемого сегмента.-вирусы?
плодятся везде (и в бол и в мал вланах). Согл-н что в бол. вланах чуть быстрее, НО фильтраваль порты можем и на l2 свичах внутри бол. влана.
-атаки?
абонент тебя атакуют внутри влана? Защитись! или удали протокол tcp/ip на интерфесе!
- к тарелочникам у нас спокойной отношение. Опятьже мал влан тут мало поможет
Лучше уж PPtP, хотя его и несколько труднее терминировать, но зато никто не мешает вам использовать L3-коммутацию в сегментах. Плюс ко всему он стандартный в винде, проще объяснять юзерам, как настроить, в отличие от PPPoE.Что есть в каждой винде - согласен.
а) А как маршруты юзерам передовать на друг-ие подсети ? DHCP - можно только для XP. И то кривовато - масками /24. Просить запускать файлик - тоже можно - но эт не очень хорошо.
б) как всеже контролировать доступ в другие подсети?
Аргументы на самом деле хоршие. Жду еще...
-
#----Краткое лирической отступление----
Использовать ли PPPoE ?
+
1) нет проблемм присущих "ip протоколу" в сети Ethernet: конфликты и подмена ip адресов. Необходимость их контроля.
2) прекрасная система авторизации. Нет необходимости контролировать абонентсикий порт, привязываться к макам и проч...
что экономит время, также уменьшает число звонков в саппорт.
3) можно контролировать не только доступ в Интрнет но и доступ к другим vlan-м (подсети, сервисы, пиринговые сети)
-:
1) оч. большой трафик через ядро сети.
2) стоимость машинок, которые терминируют pppoe
3)...не получается задействованы ресурсы L3 коммутации (l3 свичи) - а "мир" развивается в этом направлении
#----Итак схема-----
в core стоит гигабитный коммутатор (l2!), к нему подключены:
1. гигабитные линии на мирорайоны (к примеру штук 5-7)
2. 3-4 pppoe сервера, присоединены к коммутатору транковыми (taged) линкам - транком:2xгигабит etherchannel (простите за каламбул=)
Эти 3-4 машинки делют между собой лоад-банансинг +роутят между юзеров между vlan-ми.
На одной их них поднят DHCP, который раздает ip абонентам в VLAN-ы. Это нам нужно для того, чтобы абоненты внутри влана, могли гонять трафик между собой (а не через core, немного разгружая его)
Машинки с PPPoE мошут быть как PC-роутеры, так и аппаратные (cisco 3845)
3. центральный маршрутизатор (можно ether-channelx2GB)(между ним и pppoe серверами поднят ospf).
4. vlan серверов телематики (барахло больших объемов+web и проч)
5. бордерный роутер в интернет
----# дополнение
при разрастании vlan-а (микрорайона) более чем 500-1000 компов для того чтобы уменьшить кол-во броудкаста в нем --- машинка с пппое двигается в этот "большой влан", далее он делиться на 2-3 маленьких влана, которые роутятся этой машинкой. Роутить полученные 2-3 маленьких влана в core -- нельзя, - жадко полосы - гигабтного аплинка на этот микрорайон
Нужна конструктивная критика.. =)
-
ага точно - спать надо больше =))
-
PCI-X 133 при 64-bit девайсах около 1GBps
надо уточнить - имеется ввиду 1 Гигабайт! в секунду, т.е. 80Гигабит/c
-
Вариант 2 (Лепестки) -
неп понимаю
имхо
неправильное суждение что строить резервные связи по уходящему кабелю - поднимет надежность.
если нет кольца (то что нарисовано пунктиром (а его нет и этим этот вариант отличается от вар-та "классика"):
то надежности никак не прибавиться.
поврежден приходящий кабель - узел не рабоатет
пропало электропитание на узеле - узел тоже не работает
или предусмотрены др варианты аварий ??
-
возможноли запроектировать и получить РЭ ФСНСС на узел связи в состав которого входит одна железка сервер ТМС (ССС), к примеру inpro, на котором установлена ip-pbx Asterisk под open sourse OS
и на котором оказываются услуги VOIP.
Железка стыкуется e1-м c оператором и fastethernet-m с другим оператором.
-
Сегодня слышал что у людей заработало. Конвертеры Планет 100TX-100FX. Расстояние 1000 метров. Думаю тоже попробовать. У кого-нибудь есть опыт подобных экспериментов?
-
2 Kuzmich
1. Количество динамических правил - относиться ко всей системе сетевой защиты (ipfw)
Too many dynamic rules возникает только тогда, когда флуд идет через keep-state правило БЕЗ limit'овне-а. Too many dynamic rules возникает только тогда, когда флуд идет через любые динамические правила, к коим относится и limit.
sysctl net.inet.ip.fw.не_помню_точно_как_называется ставим в ${лимит сессий на пользователя}*${количество пользователей}+небольшой запасик на всякий случай - и вот оно счастье.Кузмич, было бы очень интересно! Вспомни. Прошу. А так.. в счастье слабо пока вериться ))
2. Конечно.
Задача fw - фильтровать пакетики. А не следить за количество открытых соединений различных прикадных протоколов. Согласен? И те фичи которые суют в ipfw имхо бесполезны. А свид - хоть он и прокси, способен выполнять поставленную автором топика задачу.
-
Kuzmich
1. Что будет при флуде, пробовали смотреть? too many dynamic rules и ... все ост динамические правила "впролете", да их можно увеличить sysctl переменной, но это не спасет отца демократии. А флуда - хоть отбавляй: и вири и сетевые сканеры. Никуда от них не денешься.
2. ограничивать количество сессий, имхо, отнють не задача фаервол. Это уже прикладной уровень. Надо юзать сквид. Он для этих целей и сделан. Подругому никак.
ИМХО, способов борьбы с проксями в сети немного:согласен
-
-
-
2flashwolf - не годиться.
2vic~ - только на прикладном уровне. Например сквид.
-
меня интересует сколько ip адресов нужно для того чтобы пропускать через (ipnat) НАТ определенное количество юзеров?
соотношение, скажет 1/20 или 1/100 ?
про 802.1x
в Активное оборудование Ethernet, IP, MPLS, SDN/NFV...
Опубликовано · Жалоба на ответ
в HP еще есть и web-base авторизация - клиент заходит на web сервер коммутатора, авторизируется без клиента, ручками набирая логин и пароль
на самом деле все равно что там шлется. Суть - чтобы коммутатор узнал - ага с этим маком на этом порту я могу работать! (это имхо и называется мак-based в отличии от порт-based)