информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Где водятся OGRыСетевые кракеры и правда о деле Левина
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Бэкдор в xz/liblzma, предназначенный... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / networking
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
3 вариант дорогой, но с другой стороны ИМХО верный 03.05.04 14:36  Число просмотров: 1545
Автор: DeZ Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Хм...
Так вот жил я был в одной кампусной сетке, да и сейчас живу да не об том разговор,
сначала они использовали твое 1 решение(не совсем такое но максимально близкое) инет юзали все кому не лень даже те кто не представляет откуда береться мак и ип, потом подняли VPN в связке с биллингом UTM сейчас это и работает. По работе можно сказать нормально ... смена ипа ни фига не дает в принципе, как впрочем и мака, кроме того зачем жетско привязывать мак ??? (в смысле через порты свитчей) я думаю достаточно поставить роутер через него гнать весь трафик левый обрубать на нем же а там разруливать уже через NAT/VPN одна дырка все равно останеться так как она была всегда это локальные машины юзерей на них и проксик повесить можно и все остальное (мы например нашли контору у которой стоял винт на 120 гиг откуда они юзали гиг 8, мы покумекали и сделали фтпщник для общего с кучей софта фильмов и музыки :) в принципе до сих пор пашет и админ там спит ;) ) так что думаю части реализации 3 решения хватит :) точнее это ближе ко второму если я еще не забыл что там написано, но трафик разруливать роутер ИМХО должен, лучше позаботиться о ИБ клиентов так как некоторые конторы только проверяя почту не больше 5 метров в день платят по 15000р в месяц и думают что так и надо... но не всегда же это контора :) в общем удешеви немного 3 вариант (то есть убери жесткую привязку по портам) а все остальное ок ....
<networking>
"Правильное" подключение ЛВС к интернету. 04.04.04 20:07  
Автор: nordeep Статус: Незарегистрированный пользователь
Отредактировано 04.04.04 20:15  Количество правок: 1
<"чистая" ссылка>
Нужна критика организации подключения ЛВС к интернету. С точки зрения безопасности, и надежности работы.
Что есть: С одной стороны оптика, с другой стороны 75 различных клиентов!
Задача: Разместить правильное оборудовани между оптикой и клиентами, и организовать подключение клиентов. У клиентов будут как реальные IP адреса, так и фейковые, и не исключено что придется маршрутизировать на них небольшие сети. Вести учет трафика.
Пойду, по моему мнению, от "неправильных" решений к "правильным", и постараюсь прокоментировать свои решения.
1. Решение: Ставим конвертер оптики в езернет, включаем конвертер в одну сетевую карту в компьютер под управлением unix-подобной ОС, из второй сетевой карты идет кабель в простые свичи, в которые в свою очередь воткнуты те самые 75 клиентов. На сервере ставим DHCP раздаем IP адреса, если реальный IP то форвардим его через сервер, если фэйковый NAT'им. Учет трафика ведем либо через libpcap, divert socket, утилит много(netams к примеру)
Проблемы: Все клиенты в одной сети, ничто не мешает изменить ip адрес клиенту, посложней немного изменить mac адрес. Поднятие своего DHCP сервера клиентом, грозит раздачей ip адресов клиента, и не работай сети в общем.
2. Решение: Так же конвертер, так же сервер, те же свичи как в решении 1. На сервере поднимам VPN сервер, всем клиентам выдаем персональные имя и пароль, и присваем ip адреса фейковой сети, которая не имеет выхода в интернет. Клиент настраивает VPN подключение, подключается к серверу, получает реальный IP и форвардим в интернет, или фэйковый, тогда его NAT'им. Учет трафика ведем все так же, или же при использовании radius-сервера, по сессиям, сколько байт за сессию передано клиенту.
Проблемы: Все клиенты так же в одной сети, но теперь смена IP или MAC адреса не дает никакого результата. Если у клиента работает какая то служба требующая реального IP адреса, к примеру веб сервер, то сначала ему нужно установить соединение VPN, а затем запустить службу веб. Для unix-подобных систем это делается не сложно, для windows же, встроеными средствами, по моему, проблематично. Так же под вопросом на сколько стабильна будет работа сервера при одновременном подключении 75 клиентов ? Есть у кого опыт, может кто ответить ?
3. Решение: Самой дорогое, но и самое правильное, по моему мнению. Оптика путем конвертирования подключаем к роутеру, с поддержкой NetFlow, свичи управляемые с поддержкой VLAN(тут же вопрос поддержка VLAN не означает поддержка стандарта 802.1Q ?)(и еще один вопрос, если свичи на разных этажах, достаточно ли будет 802.1Q, или нужно что бы свичи могли обьединяться в стэк через витую пару?) Каждому клиенты выделяем свой VLAN, в который кроме клиента включаем наш роутер, жестко привязываем MAC адрес клиента к порту в свиче. Выделяем IP адрес клиенту, пропускаем его через роутер, если фейковый то NAT'им средствами роутера. Учет трафика ведем на сервере заберая поток netflow с роутера, разберая его по IP адресам.
Проблемы: Нет самой главной проблемы, клиенты теперь в разных сетях на физическом уровне. Если же клиент подключает к порту разные компьютеры(ноутбуки) то нужно всегда менять связку MAC адрес порт.
Скорее всего скрыты еще какие то проблемы в данном 3 решении, я их просто не вижу. Скорее всего не плохо бы было объеденить решение 2 и 3.
Еще из минусов, во всех решениях не продумано ограничение полосы пропускания, думаю что в третьем решении, организация будет самая простая.

Просьба ко всем, покритекуйте мои решения, какие еще есть проблемы в данных решениях. Что вы можете посоветовать из своих решений, очень рад буду выслушать любые комментарии и предложения.
Решение 2 или 3 собераюсь внедрять, выбор зависит от финансирования, предпочтительным считаю третье решение.
3 вариант дорогой, но с другой стороны ИМХО верный 03.05.04 14:36  
Автор: DeZ Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Хм...
Так вот жил я был в одной кампусной сетке, да и сейчас живу да не об том разговор,
сначала они использовали твое 1 решение(не совсем такое но максимально близкое) инет юзали все кому не лень даже те кто не представляет откуда береться мак и ип, потом подняли VPN в связке с биллингом UTM сейчас это и работает. По работе можно сказать нормально ... смена ипа ни фига не дает в принципе, как впрочем и мака, кроме того зачем жетско привязывать мак ??? (в смысле через порты свитчей) я думаю достаточно поставить роутер через него гнать весь трафик левый обрубать на нем же а там разруливать уже через NAT/VPN одна дырка все равно останеться так как она была всегда это локальные машины юзерей на них и проксик повесить можно и все остальное (мы например нашли контору у которой стоял винт на 120 гиг откуда они юзали гиг 8, мы покумекали и сделали фтпщник для общего с кучей софта фильмов и музыки :) в принципе до сих пор пашет и админ там спит ;) ) так что думаю части реализации 3 решения хватит :) точнее это ближе ко второму если я еще не забыл что там написано, но трафик разруливать роутер ИМХО должен, лучше позаботиться о ИБ клиентов так как некоторые конторы только проверяя почту не больше 5 метров в день платят по 15000р в месяц и думают что так и надо... но не всегда же это контора :) в общем удешеви немного 3 вариант (то есть убери жесткую привязку по портам) а все остальное ок ....
1




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach