Ядро сети на базе SUSE

[g0a]

Недавно в голову пришла интересная мысль.

У меня сетка не очень большая, но очень тяжёлая, а тяжесть заключается в том, что отсутствует хотя бы скудный бюджет, а покупается все в ритме: «Шев, шиндец, сломалось то-то, то-то — нужно заменить». В свете этого, в сетки отсутствуют управляемые свичи, а про маршрутизаторы вообще молчу и т. п. Почесав репу и подумав, в голову пришла одна мысля, а заключается она в следующем:

1. Выдать юзверям айпишники следующего вида:
192.168.1.2/30
192.168.2.2/30
…..

2. На сервере, дать айпишники:
192.168.1.1/30
192.168.2.1/30
…..
3. У юзверей прописать шлюз сервера:
Если у юзера айпи: 192.168.1.2/30, то соответственно айпи шлюза будет 192.168.1.1/30, а если 192.168.2.2/30, то шлюз будет 192.168.2.1/30 и т. д.

Данная схема направит весь трафик через шлюз (ядро), а на самом шлюзе настроить уже непосредственно маршрутизацию с помощью suseFIREWALL.

Плюсы:
Можно контролировать все соединения пользователей, видить полную картину их трафика и т. д.

Минусы:
Случись что с серваком или с частью сети (порвут провод и т. д.), то будет по работе полный СТОП + трафик возрастет в разы.

Что скажите о такой схеме?

[patrius]

Спрошенная вами структура неплохо поднимается посредством PPPoE сервера.
в этом случае нет необходимость прописывать ip у "клиентов" вообще.

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

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

Кроме прочего g0a, ответь на такие вопросы:
1. что за сеть? задачи, кол-во участников, географическая распространенность
2. с какой целью вводиться тотальный мониторинг трафика?
3. QoS? что сделано или планируется.

[g0a]

Кроме прочего g0a, ответь на такие вопросы:
1. что за сеть? задачи, кол-во участников, географическая распространенность
2. с какой целью вводиться тотальный мониторинг трафика?
3. QoS? что сделано или планируется.

1. Обычная сетка из чуть более 30 компьютеров + 6 сереров (1С, Шлюз, DVR и ...). Огромная территория завода, по которому раскиданы свичи (более 8 штук). Сетка только локальная, ВПН и т.п. нету.

2. Писать долго Опишу картину:

Есть территория завода огромной площадью. По этому заводу идет локалка с обычными свичами, к которым могут все желающие подключиться. К свичам подключены компьютеры и с линукс и с виндовс и куча чего еще. За компьютерами с виндовс сидят приматы "турецкие граждане", которые говорят: нафиг антивирь, дай мне права админа и т.п. В результате чего по сетке гуляет всякая гадость. Дирик тоже примат, слушает только их, а на мое мнение плевать, говорит делать так, как они просят (права админа и т.д.) Результат, боты в сети и т.д.

Смешно звучит и не достоверно, но оно так и есть!!!!

3. QoS Нету такого и пока не планируется

[patrius]

к сожалению, не так уж и не достоверно

в этой ситуации можно применить dhcpd с привязкой по макам.
гуляющих по сети вирусов и ботов серверными мерами ты врятли эфективно остановишь... единственное, что: "пересадить" 1С и прочих за третью сетевую карту. Т.е. 1ая сетевая - пользователи, 2ая - инет, 3я - сервера. В таком контексте всех пользователей можно объединить в одну подсеть и тчательно фильтровать трафик в направлении серверов.
отсутствие антивирусов у пользователей легко лечиться вносом сеть "чего по крепче" и постоянным капанием на пользователей (раз дир слушает только их) информацией о культуре поведения в корпоративной сети.

[g0a]

к сожалению, не так уж и не достоверно

в этой ситуации можно применить dhcpd с привязкой по макам.
гуляющих по сети вирусов и ботов серверными мерами ты врятли эфективно остановишь... единственное, что: "пересадить" 1С и прочих за третью сетевую карту. Т.е. 1ая сетевая - пользователи, 2ая - инет, 3я - сервера. В таком контексте всех пользователей можно объединить в одну подсеть и тчательно фильтровать трафик в направлении серверов.
отсутствие антивирусов у пользователей легко лечиться вносом сеть "чего по крепче" и постоянным капанием на пользователей (раз дир слушает только их) информацией о культуре поведения в корпоративной сети.

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


[LocalNET]
|
[switch]
|
---------------
(eth0)
[шлюз](eth1)----[шлюз интернета]
(eth2)
---------------
|
[switsh]
|
[сервера]

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

[Alex2ndr]

Данная схема направит весь трафик через шлюз (ядро), а на самом шлюзе настроить уже непосредственно маршрутизацию с помощью suseFIREWALL.
Плюсы:
Можно контролировать все соединения пользователей, видить полную картину их трафика и т. д.
Минусы:
Случись что с серваком или с частью сети (порвут провод и т. д.), то будет по работе полный СТОП + трафик возрастет в разы.
Что скажите о такой схеме?

Вот вам еще минус - кто-то качает файл с одного компа на другой и таких случаев пять. Они вполне себе забьют весь канал так, что даже инет у остальных будет тормозить. Так что о QoS вам тут не зря говорили.

Кроме того кто помещает им, имея права админа установить себе адреса 1.1.1.1 и 1.1.1.2 и качать от одного к другому все что хочется? Это же вы никак не сможете ограничить.

Имхо так как вы хотите без управляемых свитчей и vlanов делать смысла нет. Достаточно привязать адреса к макам на уровне фаера и не морочится со всем остальным. Таким образом вы проконтролируете доступ к серверам и в инет, а трафик между компами пусть себе идет - все равно вы на него повлиять не сможете. Да и так ли он страшен? И самое главное - так ли контроль за ним нужен?(лично я в своей практике не припомню такого случая). Зато подумайте сколько вы проблем избежите

Вообще советую начать с того, чтобы по пунктам написать что именно хочется, посмотреть на аппаратное обеспечение и привести пункты хотелок к реальному виду Думаю в вопросе приведения мы сможем вам помочь

[g0a]

проблема в том, что на одном проводе весят "приматы" и несколько отделов:

Отдел бухгалтерия.
Отдел сбыта.

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

Пример:
Если просто выдать IP следующего вида:

Бухгалтерия: 192.168.1.0/24
Сбыт: 192.168.2.0/24
Приматы: 192.168.3.0/24

То какой неть "примат" сменит ip с 192.168.3.0/24 на 192.168.1.0/24, то он окажется в сети бухгалтерии и с его "раковой" машины начнутся чудеса на виражах, да и он быть может будет чудить умышленно.

Физически протянуть отдельно провод не получится до этих отделов. Управляемые свичи тоже не позволят закупить («зачем что то покупать и так все работает» — слова шефа).

[drBatty]

То какой неть "примат" сменит ip с 192.168.3.0/24 на 192.168.1.0/24, то он окажется в сети бухгалтерии и с его "раковой" машины начнутся чудеса на виражах, да и он быть может будет чудить умышленно.

я вот не знаю, но что, если организовать VPN для отделов? (с адресами 10.0.0/24), а приматы пускай болтаются на 192.168/16
вот тут доку нашёл: http://linuxopen.ru/2007/12/14/nastrojjka-...s-nulja-na.html
Отделы будут вводить свой пароль, и будут вполне огорожены. А интернет будет у всех. Причём приматам даже проще, используя свои "админские" адреса, они смогут входить в Сеть "напрямую", без всяких паролей.

[g0a]

То какой неть "примат" сменит ip с 192.168.3.0/24 на 192.168.1.0/24, то он окажется в сети бухгалтерии и с его "раковой" машины начнутся чудеса на виражах, да и он быть может будет чудить умышленно.

я вот не знаю, но что, если организовать VPN для отделов? (с адресами 10.0.0/24), а приматы пускай болтаются на 192.168/16
вот тут доку нашёл: http://linuxopen.ru/2007/12/14/nastrojjka-...s-nulja-na.html
Отделы будут вводить свой пароль, и будут вполне огорожены. А интернет будет у всех. Причём приматам даже проще, используя свои "админские" адреса, они смогут входить в Сеть "напрямую", без всяких паролей.

это не то, Тут задача основная не об ограждении серверов (они и так за "стеной"), а о защите самих сеток этих двух отделов (сетку отделов узнать не составит труда у них).

Основной гвоздь в данном деле это увелечение трафика (если делать по моей схеме). Думаю, может шейпером нарезать отдельно каждого.

По факту сетку только грузят DVRы, с которых идет видео поток, а остальные только и работают с 1С да инетом. Фильмы тут не качают и т.п. друг у друга.

[Alex2ndr]

проблема в том, что на одном проводе весят "приматы" и несколько отделов:

Отдел бухгалтерия.
Отдел сбыта.

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

Пример:
Если просто выдать IP следующего вида:

Бухгалтерия: 192.168.1.0/24
Сбыт: 192.168.2.0/24
Приматы: 192.168.3.0/24

То какой неть "примат" сменит ip с 192.168.3.0/24 на 192.168.1.0/24, то он окажется в сети бухгалтерии и с его "раковой" машины начнутся чудеса на виражах, да и он быть может будет чудить умышленно.

Физически протянуть отдельно провод не получится до этих отделов. Управляемые свичи тоже не позволят закупить («зачем что то покупать и так все работает» — слова шефа).

Теперь я наконец то понял вашу идею. Вы хотите выдать такие маски, чтобы машины этих отделов могли общаться только с сервером. Даже если им придет пакет из 192.168.1.0/24 имея маску 30 они будут все равно отправлять его на сервер. Тогда предлагаю немного модернизировать идею и сделать подсеть строго по кол-ву адресов каждого отдела. Т е 27,28 и тд - смотря сколько машин. Получите то же самое, только без гемора с маршрутизацией и ходьбой межкомпьютерного трафика в этих отделах через сервер.

Но может можно поставить в эти отделы какой-нить шлюз, от которого можно будет кинуть впн? Самая захудалая машинка на P2 с 256Мб ОЗУ и хардом на 2 гига. Собрать ее из старого железа в конце концов. Это будет гораздо более грамотным вариантом.

[offtop]
А вообще противостояние "админ vs много юзеров" заканчивается обычно уходом админа. Рано или поздно, так или иначе. Если в дуэльном противостоянии еще есть какой-то шанс, то против толпы... имхо бесполезно.
[offtop]

[g0a]

[offtop]
А вообще противостояние "админ vs много юзеров" заканчивается обычно уходом админа. Рано или поздно, так или иначе. Если в дуэльном противостоянии еще есть какой-то шанс, то против толпы... имхо бесполезно.
[offtop]

Тут этих приматов скоро не станет (надеюсь). Нас должна купить европейская фирма, а у них то все как надо будет
Уходил я уже от сех, но вернули

Дело в том, что просто хочется миминизировать вероятный ущерб, в следствии ранее изложенных обстоятельств. Можно в принципе все оставить как и есть, но совесть мучает

[Alex2ndr]

Дело в том, что просто хочется миминизировать вероятный ущерб, в следствии ранее изложенных обстоятельств. Можно в принципе все оставить как и есть, но совесть мучает

Правильно хочется. Админ должен заботится о сети, иначе это не админ. К тому же кто проблемы, ежели что случится, будет расхлебывать - админ конечно. Логичнее обезопасить себя от этих проблем. Одна эпидемия KIDO таких нервов стоить будет....

[patrius]

g0a, вспомнилась инфа старого плана..
есть демон (для linux) который проверяет соответствие IP - MAC, в противном случае дает конфликт ip адресов. название вспомнить не могу, давно не пользуюсь... Может кто подскажет.
используя выше приведенного демона можно наглухо зафиксировать IP.
я не использую ибо мак можно подменить, и я как правило обхожусь административными мерами.

[g0a]

g0a, вспомнилась инфа старого плана..
есть демон (для linux) который проверяет соответствие IP - MAC, в противном случае дает конфликт ip адресов. название вспомнить не могу, давно не пользуюсь... Может кто подскажет.
используя выше приведенного демона можно наглухо зафиксировать IP.
я не использую ибо мак можно подменить, и я как правило обхожусь административными мерами.

arpwatch?

[Alex2ndr]

aptitude show arpwatch

Пакет: arpwatch
Состояние: не установлен
Версия: 2.1a13-2.1
Приоритет: необязательный
Раздел: admin
Сопровождающий: KELEMEN Péter <fuji@debian.org>
Размер в распакованном виде: 467k
Зависимости: adduser, debianutils, libc6 (>= 2.7-1), libpcap0.8 (>= 0.9.3-1)
Рекомендуются: mail-transport-agent
Предлагаются: snmp
Описание: программа мониторинга компьютеров в сетях Ethernet/FDDI
Arpwatch ведёт запись Ethernet MAC-адресов, наличествующих в сети и IP-адресов связанных с ними. При обнаружении изменений, таких как появление новых
компьютеров в сети, совпадение адресов, изменение и использование старых адресов, уведомляет системного администратора по электронной почте.

Можно конечно по ip банить, только пользователям работать надо. Поэтому они сразу позвонят и скажут "А у меня не пашет". И админу в данной ситации придется разбанить.

[Goodvin]

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

В каком-таком "следствии"?
В расследовании уголовного дела?
Вы о чём?