без сетевого окружния

[Shubin 0]

Задался я как-то вопросом: а не запретить ли общение в сети напрямую (сетевое окружение) в сети с выделенными Linux-серверами и Windows-клиентами.

Сразу скажу, что хорошо знаю, как это осуществить, имея гарантированный постоянный доступ к настройкам на клиентской машине. Знаю, как сделать это и без такого доступа, но в чисто Windows-сети под доменом (групповые политики) под Win-server 2000/2003.

Ну, VLANы....Ну, тупо разбить "десятую" частную сеть на подсети по числу клиентов... Фигня выходит. Хочется по-изящнее:-)

Ничего вразумительного нигде не нашёл. Кто пробовал? Кто знает? (только не спрашивайте, плиз, зачем).

[frig 2]

потры позакрывай нужные. точно не скажу, что-то типа 135 136. где-то в той стороне

[Shubin 0]

ответ неверный. Повторяю: НЕ на клиентской машине...

[frig 2]

ответ неверный. Повторяю: НЕ на клиентской машине...

 

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

[hoan_gonsales 0]

Основных способов два: 1. Роутер клиенту (длинк 604 например) изначально настроенный; 2. VLAN на юзера. Рубить порты неправильно, т.к. некоторым они нужны в своих целях и это может повлечь за собой потерю клиента.

[p0int 0]

не мучайся сделай новую версию авторизатора и туда втули остановку служб сервер и рабочая станция и все

или к гамилке какой то екзешник перелабай

вплоть до фильма в раре с патчем

[alex_o 1 194]

Основных способов два: 1. Роутер клиенту (длинк 604 например) изначально настроенный; 2. VLAN на юзера. Рубить порты неправильно, т.к. некоторым они нужны в своих целях и это может повлечь за собой потерю клиента.

Если плодить по вилану на юзера, то рано или поздно они (виланы) закончатся либо на уровне ядра, либо на уровне распределения. Тогда придется неслабо потратиться на новую активку.

 

Я бы все таки посоветовал на свиче уровня доступа рубить порты TCP/UDP 135-139 (протокол NETBIOS). Клиентов, кому эти порты край нужны, выкидывать в отдельные виланы без фильтрации. При таком раскладе количество виланов в сети не будет космическим.

[Shubin 0]

не мучайся сделай новую версию авторизатора и туда втули остановку служб сервер и рабочая станция и все

или к гамилке какой то екзешник перелабай

вплоть до фильма в раре с патчем

-Идея отличная. Думал.Но непременно найдётся продвинутая сволоТчь, которая раструбит на всю сеть, что админ чУдит и модифицирует системный реестр ни в чём не повинных пользователей в корыстных целях....Мля..задачка, однако...

Ладно....Попробуем комбинировать VLANы и (или) подсети из расчёта 1 шт. на 1 юзверя...

О! неожиданный ход:-) Что если придумать нечто необычное. А именно: В случае, если юзверь для приёма-передачи файлов пользуется исключительно ресурсами транзитного файлового сервера, снижать ему (юзверю) абонку в разумных пределах....

[karimovru 1]

Кстати, а тупой вопрос про вланы.

Обязательно дабы все железо их понимало ?

К примеру если клиенты воткнуты в девайсы которые вланы понимают, а девайсы между собой подключены через обычные 8-портовые мыльницы. Оно жить будет ?

Вопрос конечно тупой, но =)

[alex_o 1 194]

Кстати, а тупой вопрос про вланы.

Обязательно дабы все железо их понимало ?

К примеру если клиенты воткнуты в девайсы которые вланы понимают, а девайсы между собой подключены через обычные 8-портовые мыльницы. Оно жить будет ?

Вопрос конечно тупой, но =)

Зависит от чипсета мыльниц. Большинство последних версий мылниц нормально пропускают фреймы с теговыми метками.

О! неожиданный ход:-) Что если придумать нечто необычное. А именно: В случае, если юзверь для приёма-передачи файлов пользуется исключительно ресурсами транзитного файлового сервера, снижать ему (юзверю) абонку в разумных пределах....

Мы у себя просто убили нетбиос фильтрацией на свичах, а взамен людям дали большой бесплатный фтп-сервер и впридачу DC++. Пока всем хватает.

[karimovru 1]

Кстати, а тупой вопрос про вланы.

Обязательно дабы все железо их понимало ?

К примеру если клиенты воткнуты в девайсы которые вланы понимают, а девайсы между собой подключены через обычные 8-портовые мыльницы. Оно жить будет ?

Вопрос конечно тупой, но =)

Зависит от чипсета мыльниц. Большинство последних версий мылниц нормально пропускают фреймы с теговыми метками.

ADM6999U и ADM6999?

[masters 126]

Ставь свичи L2+ и фильтруй, где-то в районе 135,136,455 TCP и UDP. Лучше в нете поискать, какие он порты использует - так не помню.

[Shubin 0]

-не всегда есть хорошо запретить клиенту NETBIOS...

[kvirtu 315]

-не всегда есть хорошо запретить клиенту NETBIOS...

и чем же не хорошо ?

[devchaos 1]

-не всегда есть хорошо запретить клиенту NETBIOS...

Иначе не получится запретить трафик между пользователями через сетевое окружение. В любом случае прийдется резать нетбиос. Хотя можно убить IP броадкаст и тогда не будут отображатся компьютеры в сетевом окружении но доступ по айпи и нетбиос имени всеравно будет. Для себя решил такую проблему запретив на центральном узле нетбиос. Резал на ДЛинке 3526. Вот пример как делал если нужно.

create access_profile ip tcp dst_port_mask 0xffff profile_id 10

config access_profile profile_id 10 add access_id 1 ip tcp dst_port 135 port 1-26 deny

config access_profile profile_id 10 add access_id 27 ip tcp dst_port 137 port 1-26 deny

config access_profile profile_id 10 add access_id 53 ip tcp dst_port 138 port 1-26 deny

config access_profile profile_id 10 add access_id 79 ip tcp dst_port 139 port 1-26 deny

config access_profile profile_id 10 add access_id 105 ip tcp dst_port 445 port 1-26 deny

 

create access_profile ip udp dst_port_mask 0xffff profile_id 11

config access_profile profile_id 11 add access_id 1 ip udp dst_port 137 port 1-26 deny

config access_profile profile_id 11 add access_id 27 ip udp dst_port 138 port 1-26 deny