Ситуация следующая. На железяках DES-3028 (fw: 2.41.B03) включёны DHCP Relay + DHCP Snooping на портах 1-24 (пример конфигурации ниже). Обе функции отрабатывают как положено. Но есть неприятный момент - при обнаружении MAC-адреса шлюза на клиентском порту, свитч добавляет в блоклист запись: LVAN - MAC шлюза - порт. Порт соответственно клиентский (1-24), но пакеты с МАС-адресом шлюза отбрасываются со всех портов. В резултате все абоненты на этом свитче не могут получить доступ к сервисам.
Пример конфигурации:
Код:
# dhcp replay
enable dhcp_relay
config dhcp_relay hops 4 time 0
config dhcp_relay option_82 state enable
config dhcp_relay option_82 check enable
config dhcp_relay option_82 policy keep
config dhcp_relay option_82 remote_id default
config dhcp_relay add ipif System 192.168.241.1
# dhcp snooping
enable address_binding dhcp_snoop
config address_binding ip_mac ports 1-24 state enable strict allow_zeroip enable forward_dhcppkt enable
config address_binding ip_mac ports 25-28 state disable allow_zeroip disable forward_dhcppkt enable
config address_binding dhcp_snoop max_entry ports 1-28 limit no_limit
Задача: Предотвратить блокировку МАС-адреса шлюза.ACL правила добавляемые arp_spoofing_prevention желаемого результата не дают, т.к. срабатывают только на ARP пакеты в которых ARP->Sender IP = IP-адресу шлюза. Это препятствует спуфингу шлюза, но не предотвращает блокировку МАС-адреса шлюза IMPB.
Немного поэксперементировав с генератором пакетов, выяснил что IMPB проверяет:
а) Sender MAC + Sender IP в ARP-пакете
б) MAC-src в Ethernet (L1) заголовке + IP-src в IP (L2) заголовке пакета, если ethertype = 0x8000 и ip->version = 0x04;
Если полученая из фрейма пара MAC-IP, отсутствует в списке IMPB, MAC-адрес отправляется в блоклист.
Для предотвращения блокировки МАС-адреса шлюза в случаи б), достаточно было бы отбрасывать на клиентских портах все пакеты, в которых MAC-src = MAC-адресу шлюза:
Код:
create access_profile ethernet source_mac FF-FF-FF-FF-FF-FF profile_id 1
config access_profile profile_id 1 add access_id auto_assign ethernet source_mac 00-23-54-29-b5-3a port 25 permit
config access_profile profile_id 1 add access_id auto_assign ethernet source_mac 00-23-54-29-b5-3a port all deny
В случаи а) достаточно заблокировать на клиентских портах все ARP пакеты, в которых ARP->Sender MAC = MAC-адресу шлюза:
Код:
create access_profile packet_content offset_0-15 0x0 0x0 0x0 0xffff0000 offset_16-31 0x0 0xffff 0xffffffff 0x0 profile_id 2
config access_profile profile_id 2 add access_id auto_assign packet_content offset 12 0x8060000 offset 22 0x00235429 offset 26 0xb53a000 port 25 permit
config access_profile profile_id 2 add access_id auto_assign packet_content offset 12 0x8060000 offset 22 0x00235429 offset 26 0xb53a000 port all deny
Не тестовом стенде всё сработало на ура. Перепробывал все возможные варианты пакетов. На продакшене, не сработало, МАС-шлюза переодически банится:
Код:
Unauthenticated IP-MAC address and discarded by ip mac port binding (IP: 10.70.1.254, MAC: 00-23-54-29-B5-3A, Port: 6)
IP-адрес переодически отличается от IP-адреса шлюза. На какие ещё пакеты кроме ARP и IPv4 может возбуждаться IMPB ? =)
Вход
Регистрация
FAQ
Поиск
