Перейти к содержимому
Калькуляторы

G.Y.S.

Активный участник
  • Публикации

    141
  • Зарегистрирован

  • Посещение

Сообщения, опубликованные пользователем G.Y.S.


  1. в HP еще есть и web-base авторизация - клиент заходит на web сервер коммутатора, авторизируется без клиента, ручками набирая логин и пароль

     

    То что Вы увидели - скорее всего mac авторизация (на радиус в качестве логина и пароля шлеться mac )  

    на самом деле все равно что там шлется. Суть - чтобы коммутатор узнал - ага с этим маком на этом порту я могу работать! (это имхо и называется мак-based в отличии от порт-based)

  2. а как вам схема авторизации по 802.1x:

    упр свич (узел доступа) --- неупр. свич (на доме) -1 влан

     

    абоненты (дома где неупр свич) авторизуются на порту управляемого свича по 802.1x

     

    благо mac-based 802.1x позволяют задать

    до 16 маков на порт у длинка

    до 32 у хьюлетов

    до ?? у байстэков

  3. G.Y.S., активка это 5-10% от цены нормальной сети.

    А уж если говорить про полную стоимость (т.е. с учетом лет эдак 5-ти эксплуатации)...

    1. говорить о о конкретных ценах я не хочу. В любом случае с PPPoE и единственным неуправляемом свичем в доме (далее он подключен у упр-мому) будет дешевле

    ЗЫ

    через 5 лет - оборудование уже 1-2 раза придеться поменять.

    2. оптимизация саппорта мало зависит от кого упр ли в доме свич или нет.

    ЗЫ

    мне думается что Паше с такой жизненной позицией (к черту PPPoE) проще продавать упр. железо в бол. колчествах =)

  4. Повторяю в 10-й раз вводную.

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

    не в 10,а в первый ! -) - см. выше

    если каждый абонент воткнут в порт управляемого коммутатора - то проблемм нет. Но (как в рекламме): "нет сынок - это фантастика"

    +

    А внутренний трафик чтобы счтать - это коммутаторы с netflow покупай ? (иногда гигабитные)

    Дорого. Очень дорого.

  5. Вот. Смотри.

    Твоя схема: 1. используем DHCP - правильно ? (иначе работать с vlan практически невозможно).

    2. Ip addr -ss абоненту DHCP дает в зависимасти от мак (в твоей схеме).

    3. Абонент меняет мак. Все - он не авторизован. Можно настроить ДХЦП давать какой нить ip из "гостевого пула" вновь появившемуся маку в влане. Но это не спасет.

    Мониторить ? - ну отмониторил.... В доме стоит неупр свич. Дом подключен к порту упр свича. На упр. свиче появился новый мак. Что дальше ...?

    ПОВТОРЯЮ

    Если нет возможности дасть каждому юзеру влан (а ее нет у большинства ДС) - то нормально авторизировать юзера (без тунелей) и разделять ему локальные сервисы (например запретить доступ в др влан) от инернета просто нельзя. Если только не спашивать у него новый мак (а Паша не хочет!=)

  6. Прочитал.

    Других аргументов к сожалению не увидел.

    Vlan на юзера - идеально, быстро, контролируемо. Но дорого и трудоемко.

    Если нет возможности дасть каждому юзеру влан (а ее нет у большинства ДС) - то нормально авторизировать юзера (без тунелей) и разделять ему локальные сервисы (например запретить доступ в др влан) от инернета просто нельзя. Если только не спашивать у него новый мак (а Паша не хочет!=)

  7. Но... Приводить в порядок на управляемом и т.п. все равно придется. Так зачем громоздить одно на другое?

    а что приводить в порядок то? Ну пусть юзеры в пределах влана делют что хотят.

    Тарелочники? - не большой вред при разумной тарифной политике борльшого оператора.

    Вири? - лечаться асцессами портах l2 свичей

    Атаки соседа? - нет tcp/ip на интерфесе - нет атаки

    Что еще? У вас сот. телефон - но оператор не может заст-ть вас не уст gsm-шлюз или не пользоваться рацией . Это накем - проше надо отноститься к неуправляемому сегменту - ничего страшного внем нет. И не делать из мухи слона.

    Читай выше "низкоскоростные каналы". ;-)

    я бы не назвал бы adsl2 - низкоскоростным. Ладно ... не тема обсуждения.

  8. по существу - про proxy-arp - это имхо изврат.

    если денег хватило на упр железку в доме - узайте .1q на абонента или группу.

    Портовые vlan - тоже можно - тогда выдавайте /30 абонетам чтобы два соседа могли соединиться др с др-м.

    Если не хватает денег на .1q на абонента - тогда PPPoE.

    Другого решения я не вижу...?

  9. автору топика:

    А что собственно вы хотите контролировать в сегменте?

    Юзера отключить за неуплату: без упр. железок может только монтажник. Напр-ть через себя инет трафик на др-х юзеров - мало выгодно - при грамотной тариф политике. Вирусы можно порезать поставивь пару l2.

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

    PPPoE.

  10. 1. Решаемо, только дороговато пока.

    согласен. Но еще и трудоемко! (хотя работать мы не боимся=)

    2. Вы правда считаете, что PPPoE уменьшает число звноков в саппорт? :-)

    уверен! Особенно звонков из серии: я купил себе новый комп (ко мне пришел друг с ноутом) и проч - забейте пожалуйста мой новый мак

    3. Это куда легче контролировать без PPPoE, и дешевле к тому же

    Приведите пример. Будете по snmp рулить acl на l3 свичиках ? Или как ?

    В большом L2-сегменте плодятся вирусы, атаки, левые PPPoE - серваки, появляются тарелочники и т.д., и т.п. Все прелести неконтролируемого сегмента.

    -вирусы?

    плодятся везде (и в бол и в мал вланах). Согл-н что в бол. вланах чуть быстрее, НО фильтраваль порты можем и на l2 свичах внутри бол. влана.

    -атаки?

    абонент тебя атакуют внутри влана? Защитись! или удали протокол tcp/ip на интерфесе!

    - к тарелочникам у нас спокойной отношение. Опятьже мал влан тут мало поможет

    Лучше уж PPtP, хотя его и несколько труднее терминировать, но зато никто не мешает вам использовать L3-коммутацию в сегментах. Плюс ко всему он стандартный в винде, проще объяснять юзерам, как настроить, в отличие от PPPoE.

    Что есть в каждой винде - согласен.

    а) А как маршруты юзерам передовать на друг-ие подсети ? DHCP - можно только для XP. И то кривовато - масками /24. Просить запускать файлик - тоже можно - но эт не очень хорошо.

    б) как всеже контролировать доступ в другие подсети?

     

    Аргументы на самом деле хоршие. Жду еще...

  11. #----Краткое лирической отступление----

    Использовать ли 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 -- нельзя, - жадко полосы - гигабтного аплинка на этот микрорайон

     

    Нужна конструктивная критика.. =)

  12. Вариант 2 (Лепестки) -

    неп понимаю

    имхо

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

    если нет кольца (то что нарисовано пунктиром (а его нет и этим этот вариант отличается от вар-та "классика"):

    то надежности никак не прибавиться.

    поврежден приходящий кабель - узел не рабоатет

    пропало электропитание на узеле - узел тоже не работает

    или предусмотрены др варианты аварий ??

  13. возможноли запроектировать и получить РЭ ФСНСС на узел связи в состав которого входит одна железка сервер ТМС (ССС), к примеру inpro, на котором установлена ip-pbx Asterisk под open sourse OS

    и на котором оказываются услуги VOIP.

    Железка стыкуется e1-м c оператором и fastethernet-m с другим оператором.

  14. 2 Kuzmich

    1. Количество динамических правил - относиться ко всей системе сетевой защиты (ipfw)

    Too many dynamic rules возникает только тогда, когда флуд идет через keep-state правило БЕЗ limit'ов

    не-а. Too many dynamic rules возникает только тогда, когда флуд идет через любые динамические правила, к коим относится и limit.

    sysctl net.inet.ip.fw.не_помню_точно_как_называется ставим в ${лимит сессий на пользователя}*${количество пользователей}+небольшой запасик на всякий случай - и вот оно счастье.

    Кузмич, было бы очень интересно! Вспомни. Прошу. А так.. в счастье слабо пока вериться ))

     

     

    2. Конечно.

    Задача fw - фильтровать пакетики. А не следить за количество открытых соединений различных прикадных протоколов. Согласен? И те фичи которые суют в ipfw имхо бесполезны. А свид - хоть он и прокси, способен выполнять поставленную автором топика задачу.

  15. Kuzmich

    1. Что будет при флуде, пробовали смотреть? too many dynamic rules и ... все ост динамические правила "впролете", да их можно увеличить sysctl переменной, но это не спасет отца демократии. А флуда - хоть отбавляй: и вири и сетевые сканеры. Никуда от них не денешься.

    2. ограничивать количество сессий, имхо, отнють не задача фаервол. Это уже прикладной уровень. Надо юзать сквид. Он для этих целей и сделан. Подругому никак.

     

    ИМХО, способов борьбы с проксями в сети немного:  

    согласен