подскажите пожалуйста:
des-3526
Хочу что-бы пользователи не могли работать в сети с определёнными ip, например ip сервера.
делаю:
create access_profile ip source_ip_mask 255.255.255.255 profile_id 10
config access_profile profile_id 10 add access_id 1 ip source_ip 10.90.90.246 port 21 deny

Потом с ip 10.90.90.246 включаюсь в 21 порт , и продолжаю пинговать и заходить на сам коммутатор ( 10.90.90.90) , Хотя сеть за ним "видеть" перестаю...
А реально ли как-то закрыть на входе, ну так что-бы и на коммутатор пользователь не мог попасть...?

Почитайте вот это FAQ пожалуйста http://www.dlink.ru/technical/faq_hub_switch_115.php

Я читал, просто меня запутала необходимость разбирать арп-пакеты
Потому решил просто заблокировать нужные src ip и мак на всех портах кроме нужного. Я так понял отличие будет тольков том, что у клиента не будет периодически всплывают окна, предупреждающие о конфликте ip-адреса, он просто не будет видеть дальше порта.

Прочёл ещё раз
В итоге комутатор будет получать не правильный мак и путаться, а на сервере в лог это падать не будет:)
Но тут нам должен помочь цпу фильтеринг, с которым я что-то совсем запутался:)

Подскажите по цпу фильтеринг:
В примере, в факе:
create cpu access_profile ethernet source_mac FF-FF-FF-FF-FF-FF profile_id 1
config cpu access_profile profile_id 1 add access_id 1 ethernet source_mac 00-50-04-29-6E-C4 permit
разрешаем доступ к коммутатору с маком сервера
00-50-04-29-6E-C4 , но ведь остальные же не запрещаем?

А если вторым правилом запретить со всех остальных маков?
Мак совпал с 1 правилом - прошло. Не совпал - отрезали 2 правилом..

в самом начале тема была и поднята по этому поводу и подробно расписана:

create access_profile ip source_ip_mask 255.255.255.255 profile_id 10
config access_profile profile_id 10 add access_id 1 ip source_ip 192.168.1.1 port 5 permit (IP адрес, с которого можно выходить в сеть)
config access_profile profile_id 10 add access_id 2 ip source_ip 0.0.0.0 port 5 permit (тут мы разрешаем проходить запросам с нулевым IP, чтобы клиент мог получить IP от DHCP сервера)

# Настройте запрещающее правило для всех остальных IP-адресов
create access_profile ip source_ip_mask 0.0.0.0 profile_id 20
config access_profile profile_id 20 add access_id 2 ip source_ip 0.0.0.0 port 5 deny (а тут мы запрещаем проходить запросам со всех остальных IP)

Вы шутите?:)
Вы привели пример в котором мы разрешаем только определённым ай-пи, а остальным запрещаем. Я спрашивал "наоборот".
И насколько я понимаю в тех правилах, что вы привели в пример, коммутатор со стороны клиента всё равно будет пинговаться, и получать неправильный мак себе в таблицу.

В примере на который дал ссылку Иван Демин, эта прблема решается цпу фильтеринг, на как именно это работает, я так и не понял, поэтому на 2 поста выше, задал уточняющий вопрос:)


Если так сделать в цпу-фильтеринг, то получиться что НИКТО не сможет попасть на коммутатор КРОМЕ прописанного мака, если я верно понял...

здесь же как раз речь идет о том, чтобы клиент работал с определенным ему IP адресом и не мог подменить свой IP на адрес например сервера. Или я что-то не так понимаю?

Я спрашивал - что-бы могли работать с любым ай-пи, кроме ай-пи сервера..

ну попробуй подставить в запрещающий профиль ИП сервера

2 panic83: создаете аналогичные ACL и CPU профили и правила и все будет ок.

_________________
LiveComm

Уже реализованно в управлении бгбиллинга сея фича.Шлюз Длинк

Вот хочу уточнить - какие профили и правила?

Просто запретить "нежелательный" IP на порту с помощью обычного правила не помогает. Да, IP-пакеты перестают проходить, но отвечать на arp-запросы данный вредитель продолжает, ибо arp-запросы - это не IP-пакеты. Таким образом, пользователи теряют реальный сервер.

Static arp на свиче не помогает, ибо он, похоже, относится только к основному VLAN-у, в котором находится сам IP-интерфейс управления свича. То есть, если пользователи и сервер в других VLAN-ах, то статическую запись в arp-таблицу не сделать.

Видимо, вдобавок к простому ACL-правилу с IP и deny надо еще придумывать ACL-правило с битовой маской, запрещающей отвечать на arp-запросы с данным IP. Это надо анализировать arp-пакеты и придумывать маску...

Грустно. Может кто другой вариант посоветует?

На всякий случай, повторю проблему: запретить на нужных портах определенные адреса IP, включая и arp-ответы с этими адресами.

Перезвоните пожалуйста в офис по телефону 744-00-99 доб.390.

Да, спасибо, проблема действительно решается ACL с битовыми масками для arp-ответа. Все, как в 115-м FAQ, только в моем случае фильтруется arp-ответ, а не запрос (в offset_16-31 в 9-м байте вместо 1 пишем 2).

Рад слышать!