Практические аспекты использования DHCP relay+option82

В этой статье я хотел бы осветить практические аспекты использования DHCP relay+option82 как возможность авторизации (в дальнейшем именно эта связка будет иметься ввиду), а так же привести примеры конфигурации свитча Dlink DES-3200-10 и isc-dhcp-server. Практически во всех статьях dhcp relay трактуют так: «можно вынести dhcp-сервер за пределы широковещательного домена». Однако почему-то не упоминают или почти не упоминают, что это хорошая возможность избавиться от широковешательных запросов в пределах того же самого широковешательного домена. И самое главное, на что акцентирую внимание — мы можем быть уверены, благодаря option82, что запрос пришёл именно со свитча с заданным маком и именно с порта с указанным номером, а следовательно — таким образом можно «авторизовать» пользователя.

Я немного позанудствую и напомню, как действует DHCP relay. Он перехватит широковещательный запрос (VLAN-а, на который он настроен), обернёт его в L3 и отправит unicast-ом указанному DHCP-серверу. Ну и не лишним будет напомнить, что делаетoption82. Она добавляет в DHCP-пакет два дополнительных параметра:

DHCP-Relay-Circuit-Id — номер порта с которого пришёл запрос.
DHCP-Relay-Remote-Id — (по умолчанию) макадрес свитча с которого пришёл запрос.


Ещё хочется сказать о методах внедрения этой опции в пакет.В оборудовании Dlink есть два способа:
dhcp_relay — добавляет Option82 и как писалось выше, обернёт его в L3 и отправит unicast-ом указанному DHCP-серверу
dhcp_local_relay (DHCP Snooping) — только добавляет Option82 и пересылает широковещательный пакет дальше.


Немного отклонюсь от темы. Дело в том что конструкцию dhcp_local_relay я нашёл только в оборудовании Dlink. Мне стало интересно, почему же другие производители не внедрили такую замечательную опцию? Оказывается, внедрили, и давно. Называется она DHCP Snooping.

Возможно, у кого-то возникнет вопрос: «зачем нам избавляться от широковещательного трафика»? Дело в том, что на практике я очень часто встречался с таким явлением, что при выходе из строя коммутатора, например, в результате грозы, возникают петли, что приводит к широковещательному шторму. Конечно, как вы уже догадались, от одного широковещательного трафика в IPv4 нам все равно не избавиться — это ARP-трафик. Именно он отвечает за построение таблиц MAC-IP. Конечно, можно это запретить и заполнить таблицы вручную. Но, боюсь что возникшие при этом неудобства сведут на нет все прелести от статических ARP-таблиц.


Во всех статьях указано, что DHCP-клиент и DHCP-сервер могут (должны) находиться в разных подсетях — это неправда. Вот наша схема:

image

Далее я приведу пример конфигураций:

DLINK DES-3200
config vlan default delete 1-10

 #Удаляем из дефолтного VLAN-а все порты
create vlan VLAN7 tag 7
 
#Создаем  VLAN в котором находиться наш DHCP-сервер
config vlan VLAN7 add tagged 9-10 
#Добавляем туда тегированные порты 9 и 10 (смотрят в сторону провайдера)

create vlan VLAN10 tag 10
 
#Создаем  VLAN 10 в котором у нас сидят абоненты
config vlan VLAN10 add tagged 9
-10 
#Добавляем туда тегированные порты 9 и 10 
config vlan VLAN10 add untagged 1-8 
# Добавляем туда не тегированные порты 1-8 (абонентские порты)

config ipif System ipaddress 10.90.90.90/8 
#Задаем IP-адрес свитча                                     

config ipif System vlan VLAN7
#Вешаем его на VLAN7

enable dhcp_relay
#Активируем опцию
config dhcp_relay option_82 policy replace
#Говорим что если информация в пакете уже есть то заменить
config dhcp_relay option_82 remote_id default

#Просто сохраняем параметры по умолчанию (мак)
config dhcp_relay option_82 circuit_id default

#Просто сохраняем параметры по умолчанию (№ порта)
config dhcp_relay add vlanid 10 10.90.90.92
#Говорим что весь трафик с VLAN10 перехватывать и отправлять его на DHCP-сервер с адресом 10.90.90.92
create iproute default 10.90.90.92
#Создаем дефолный маршрут, в данном примере не уверен что нужен вообще, но по феншую положено

Теперь конфиг isc-dhcp-server (isc-dhcpd-4.2.4 ) на
Linux big-A75F-M2 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:30:00 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux:

$sudo apt-get install vlan-tools isc-dhcp-server
$sudo vconfig add eth0 7
$sudo ifconfig eth0.7 10.90.90.92/8
#Создаем VLAN7 и назначаем адрес 10.90.90.92/8 на котором у нас будет висеть сервер DHCP


local-address 10.90.90.92;

#Теоретически это должно указывать где будет создаваться сокет для прослушки, но практически я понял что эта опция рудимент, я её пробовал изменять и комментировать ни чего не менялось, но как говорят по феншую положено :). Вообще надо сказать что сервер будет «плевать» на все ваши указания и будет автоматом вешаться на интерфейсы IP-которых попадают в подсеть описанную в subnet секции!

if exists agent.circuit-id
{
 log ( info, concat( "Lease for ", binary-to-ascii (10, 8, ".", leased-address),.

 " raw option-82 info is CID: ", binary-to-ascii (10, 8, ".", option agent.circuit-id), " AID: ",

 binary-to-ascii(16, 8, ".", option agent.remote-id)));
}
#Это просто выводит записи в наш лог файл если обнаруживается опция 82

subnet 10.0.0.0 netmask 255.0.0.0 {
    pool {
        range 10.0.0.155;
    }
}
#Задаем подсеть и пул 

Конечно, это только стендовый конфиг, но нам самое главное разобраться с принципом работы. Все же забегая в перед я могу сказать, что у меня работает биллинговая система с option82 и конструкцией dhcp_local_relay(dhcp snooping), а в качестве сервера используется freeradius2 с perl-выборкой IP-адресов из базы postgres. Но это уже выходит за рамки данной статьи.

На машине с сервером запускаем:
$sudo tcpdump -i eth0.7 -e -n -t

И если мы увидели что-то типа:
c0:a0:bb:48:e5:b0 > 00:15:17:db:e3:e0, ethertype IPv4 (0x0800), length 345: 10.90.90.90.68 > 10.90.90.92.67: BOOTP/DHCP, Request from 48:5b:39:43:78:e5, length 303

То есть нет ни каких броадкастов, значит, все идёт хорошо и настало время запускать наш DHCP-сервер.
В первый раз я рекомендую его запустить просто набрав в строке:
$sudo dhcpd

Тогда вы сразу увидите все ошибки, если они есть, и обязательно должна быть запись вида:
Listening on LPF/eth0.7/00:15:17:db:e3:e0/10.0.0.0/8
Sending on LPF/eth0.7/00:15:17:db:e3:e0/10.0.0.0/8

На всякий случай можно проверить спустя несколько секунд:
$pgrep dhcpd

Должен вернуть UID процесса, если ни чего не выведет, проверяйте конфигурацию.

Для чего нужна такая проверка? Я помню случаи, когда сервер стартовал, висел в памяти несколько секунд и вылетал. А я тщетно пытался получить получить IP-адрес.

Если все прошло удачно, в логах мы обнаружим что-то типа:
Dec 2 20:36:17 big-A75F-M2 dhcpd: DHCPREQUEST for 10.0.0.155 from 48:5b:39:43:78:e5 (big-1001PX) via 10.90.90.90

Dec 2 20:36:17 big-A75F-M2 dhcpd: DHCPACK on 10.0.0.155 to 48:5b:39:43:78:e5 (big-1001PX) via 10.90.90.90

Dec 2 20:38:06 big-A75F-M2 dhcpd: Lease for 10.0.0.155 raw option-82 info is CID: 0.4.0.10.0.3 AID: 0.6.c0.a0.bb.48.e5.b0


Теперь одна очень важная вещь, про неё нигде не написано, но я дошёл до неё экспериментальным путём. IP-адрес свитча должен находиться в той же подсети, что и адреса, выдаваемые абонентам. Ни при каких других комбинациях мне не удалось заставить работать связку Dlink DES-3200 (Boot PROM Version: Build 4.00.002 Firmware Version: Build 4.04.004 Hardware Version: C1) и isc-dhcp-server 4.2.4.

И еще не большой бонус, как не погибнуть от броадкастов. Конфиг для Dlink DES-3200 С1:

config safeguard_engine state enable
config safeguard_engine utilization rising 90 falling 30 state enable
#Это защита от перегрузки процессора
config traffic control 1-8 broadcast enable multicast enable unicast disable action drop threshol
d 64 countdown 5 time_interval 5
#Это спасет от множественных броадкастов, генерируемых клиентами
enable loopdetect
config loopdetect ports 1-8 state enable
config loopdetect recover_timer 1200 interval 10 mode port-based
#А это спасёт от петель если уж они образовались


Это статья не клон и не попытка переписать чужие статьи своими словами. Ниже список похожих публикаций и отличия от них. В своей статье я делал акцент на использование данной конструкции как метод авторизации, а не попытку вынести DHCP-сервер за пределы сети.

xgu.ru/wiki/%D0%9E%D0%BF%D1%86%D0%B8%D1%8F_82_DHCP — здесь присутствует ошибка, я потратил много времени, чтобы ее отыскать. Выше я писал о ней (ip-адрес свитча должен находиться в той же подсети, что и адреса, выдаваемые абонентам. Ни при каких других комбинациях мне не удалось заставить работать связку Dlink DES-3200 (Boot PROM Version: Build 4.00.002 Firmware Version: Build 4.04.004 Hardware Version: C1) и isc-dhcp-server 4.2.4.);
habrahabr.ru/post/143846 — здесь dhcp вынесен за пределы сети;
www.dlink.ru/ru/faq/62/228.html — здесь также dhcp вынесен за пределы сети.
Share post
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 49

    +2
    ip-адрес свитча должен находиться в той же подсети, что и адреса, выдаваемые абонентам.

    Не обязательно. Используйте shared-network:
    shared-network ISP {
    
    subnet 10.0.0.0 netmask 255.255.255.0 
    {
            #Сеть коммутаторов доступа
            range 10.0.0.2 10.0.0.10;
            option broadcast-address 10.0.0.255;
            option subnet-mask 255.255.255.0;
            option routers 10.0.0.1;
    
    }
    
    subnet 10.10.0.0 netmask 255.255.255.0 
    {
            #Сеть клиентов
            option broadcast-address 10.10.0.255;
            option subnet-mask 255.255.255.0;
            option domain-name-servers 10.10.0.1,8.8.8.8;
            option routers 10.10.0.1;
    class "p5" { 
     match if binary-to-ascii (10, 8, "", suffix( option agent.circuit-id, 1)) = "5"
     and binary-to-ascii(16, 8, ".", option agent.remote-id) = "0.6.c0.a0.bb.48.e5.b0";
        }
            # собственно выдаем IP классу
    
            pool {
                    range 10.10.0.5;
                    allow members of "p5";
            }
    
       } 
    }
    

      0
      Прошу прощения — спешил. Секция subnet 10.0.0.0 для свичей должна идти после всех клиентов.
      +2
      freeradius2 также умеет DHCP. Причём можно настройки клиента цеплять из mysql к примеру и не переделывать каждый раз dhcpd.conf и дёргать за ногу демона
        +1
        1. Начните с того, что обновите прошивку. Firmware Version: Build 4.04.004 — это ОЧЕНЬ старая прошивка. Свежие можно взять тут: forum.dlink.ru/viewtopic.php?f=2&t=92700. Текущая — v4.38.B012. Заводские прошивки глюкавые. Чего не отнять у D-Link, они хотя бы не забрасывают большую часть своих свитчей и продолжают дорабатывать прошивки.
        2. IP свитча в пользовательском VLAN — это даже не дыра, а дырища в безопасности.
        config dhcp_relay add ipif System xxx.xxx.xxx.xxx — и пакеты на DHCP сервер будут уходить в менеджмент vlan юникастом. Главное, что бы по маршрутизации DHCP-сервер и свитч друг-друга видили. Альтернатива — dhcp_local_relay. Он только добавляет в пакет option 82, пакет дальше идёт бродкастом. Т.е. DHCP-сервер должен быть в этом VLAN.
        3. isc-dhcp-server имеет один серьёзный недостаток — если у Вас много записей (а у нормального провайдера их много), то у Вас получится ОЧЕНЬ большой конфиг. Да, его можно формировать скриптом. Но при любом изменении придётся сервис дёргать. Не умеет isc-dhcp-server на лету перечитывать конфиг. Сейчас смотрю в сторону freeradius. Последние версии умеют работать как DHCP-сервер. Со всеми плюшками прямой работы с SQL серверами. (п.с. выше уже написали).
        П.С. По настройке — обратитесь в любое представительство D-Link. Благо их много. Консультанты там обычно толковые. Много чего рассказать могут. И семинары бесплатные :)
          0
          config traffic control 1-8 broadcast enable multicast enable unicast disable action drop threshold 64 countdown 5 time_interval 5
          #Это спасет от множественных броадкастов, генерируемых клиентами

          Хана вашей сетке :)
          Вы замеряли сколько в Вашей сети «нормально» бегает бродкаста? В большой сети до нескольких сотен пакетов в секунду. Вы же рубите порт на 64 пакетах за 5 секунд. И дропаете всё что выше. Причём свитч не будет разбираться, что он дропает, полезный бродкаст или нет. Даёте рекомендации без описания, почему и как работает. С этой функцией надо обращаться ОЧЕНЬ аккуратно.
          enable loopdetect
          config loopdetect ports 1-8 state enable
          config loopdetect recover_timer 1200 interval 10 mode port-based
          #А это спасёт от петель если уж они образовались

          Тут стоит добавить, что НЕ РЕКОМЕНДУЕТСЯ включать этот функционал на магистральных портах :) Только на пользовательских.

          Ещё раз о System интерфейса свитча. Он должен быть привязан к отдельному VLAN (в простонародье к менеджмент-VLAN) по 2 причинам:
          1. Безопасность. Незачем пользователю видеть IP-управление свитча. Иначе это всегда шанс: перехватить трафик управления, подобрать пароль к свитчу и т.д.
          2. Уменьшение нагрузки на CPU свитча. Весть трафик который ip-бродкаст — попадает на проц и обрабатывается им. Вынеся IP управления в другой VLAN — лишаете этот трафик шанса загрузить свитч.

          При включенном dhcp_relay и указанной мной выше команде (при правильных настройках), запрос юникастом прекрасно попадает на DHCP-сервер, возвращается и попадает к клиенту. Если у Вас не работало — то только из-за не правильных настроек или словили баг старой прошивки.

          В результате у Вас получилась ОЧЕНЬ спорная статься. Те статьи, на которые Вы же ссылаетесь, написаны более правильно, на мой взгляд. Меньше ошибок и глупостей.

            0
            Здесь я просто описал принцип на isc-сервере. На практике я писал что у меня freeradius с perl выборкой и snmp правилами для блокировки IP на порту. Где вы увидели у меня IP свитча в пользовательском VLAN? Там vlan c тегом 7 а пользовательский с тегом 10. А если еще и внимательно посмотрите тх свитча то увидите что порты 9-10 это sfp порты и ни как не могут быть пользовательскими.

            " Вы же рубите порт на 64 пакетах за 5 секунд" Один порт — один клиент. Вполне достаточно.

            «запрос юникастом прекрасно попадает на DHCP-сервер, возвращается и попадает к клиенту. Если у Вас не работало — то только из-за не правильных настроек или словили баг старой прошивки.» Вы напрактике это проверяли? Или это догадки?
              +1
              «Тут стоит добавить, что НЕ РЕКОМЕНДУЕТСЯ включать этот функционал на магистральных портах :) Только на пользовательских.»

              А вот это в конфиге по вашему тогда что

              config vlan VLAN10 add untagged 1-8
              # Добавляем туда не тегированные порты 1-8 (абонентские порты)
                0
                Кстати, делаете туже ошибку, что и я 1 раз сделал. Кнопка «Ответить» лучше под сообщение, а не глобально :)
                Написал большой комментарий и случайно затёр его :) Злой :) Повторюсь.

                С VLAN согласен, не доглядел. НО!
                IP-адрес свитча должен находиться в той же подсети, что и адреса, выдаваемые абонентам.

                Навивает именно на ту мысль, что у Вас менеджмент VLAN и пользовательский — это одно и то же. С учётом тяжело читаемости куска конфига свитча — легко запутаться.
                Вы напрактике это проверяли? Или это догадки?

                У меня сегмент сети прекрасно работает. Между свитчами и isc-сервером 2 шлюза. Ни каких нареканий. В начале была такая же проблема как и у Вас, но она была в неправильной настройке именно isc-сервера. А именно — использование shared-network. Кстати именно конфига ics Вы и не привели. В примере для Вас с shared-network класс описан так, что он привязывается к порту любого свитча. Приведу свой (маленький кусочек). Может понятнее кому-то будет.
                Заголовок спойлера
                default-lease-time 300;
                max-lease-time 600;
                authoritative;
                ddns-update-style none;
                ddns-updates off;
                log-facility local7;
                deny unknown-clients;
                deny bootp;
                local-address 172.17.255.99;
                option ms-classless-static-routes code 249 = array of integer 8;
                
                
                if exists agent.circuit-id {
                 log ( info, concat( " Lease for ", binary-to-ascii (10, 8, ".", leased-address),
                    " Switch port: ", binary-to-ascii (10, 8, ".", option agent.circuit-id),.
                    " Switch MAC: ", binary-to-ascii(16, 8, ".", option agent.remote-id)));
                }
                
                subnet 172.17.255.0 netmask 255.255.255.0 {
                 deny unknown-clients;
                 option routers 172.17.255.253;
                }
                shared-network "global_net" {
                
                 subnet 172.17.254.1 netmask 255.255.255.255 {} # Свитч 1
                 subnet 172.17.254.14 netmask 255.255.255.255 {} # Свитч 2
                 subnet 172.17.254.49 netmask 255.255.255.255 {} # и т.д.
                #Классы пользователей
                class "vishnya" {
                 match if binary-to-ascii(10, 16, "",  substring(option agent.circuit-id, 4, 2)) = "22"
                  and binary-to-ascii(10, 8, ".", packet(24, 4)) = "172.17.254.1"
                  and binary-to-ascii(16,  8, ":", substring(hardware,1, 6)) = "0:15:58:71:8f:7c"
                 ;
                }
                class "sogacheva" {
                 match if binary-to-ascii(10, 16, "",  substring(option agent.circuit-id, 4, 2)) = "23"
                  and binary-to-ascii(10, 8, ".", packet(24, 4)) = "172.17.254.1"
                  and binary-to-ascii(16,  8, ":", substring(hardware,1, 6)) = "0:25:22:e2:71:8d"
                 ;
                }
                class "ers0072" {
                 match if binary-to-ascii(10, 16, "",  substring(option agent.circuit-id, 4, 2)) = "4"
                  and binary-to-ascii(10, 8, ".", packet(24, 4)) = "172.17.254.14"
                  and binary-to-ascii(16,  8, ":", substring(hardware,1, 6)) = "f8:d1:11:2:e8:b2"
                 ;
                }
                
                #------------------Описания network для 172.17.1.0/24---------------------------
                 subnet 172.17.1.0 netmask 255.255.255.0 {
                  allow unknown-clients;
                  option routers 172.17.1.254;
                  option domain-name-servers 172.17.100.1, 172.17.100.2;
                  option ms-classless-static-routes 12, 172,16, 172,17,1,254;
                   pool{
                    allow members of "vishnya";
                    range 172.17.1.144;
                   }
                   pool{
                    allow members of "sogacheva";
                    range 172.17.1.158;
                   }
                   pool{
                    allow members of "ers0072";
                    range 172.17.1.48;
                   }
                 }
                }


                В данном конфиге каждый пользователь привязан к конкретному свитчу (его IP) и порту свитча.
                Вообще конфиг на 11 тысяч записей весит около 1 мегабайта. Формируется динамически перловым скриптом.
                " Вы же рубите порт на 64 пакетах за 5 секунд" Один порт — один клиент. Вполне достаточно.

                Готов долго и нудно спорить — но… Думаю бессмысленно. Каждый останется при своём мнении.

                Про абонентские порты — это было уже скорее не для Вас, а описание и рекомендация. Для Вас — Вы кинули строки конфигурации вообще фактически без комментариев, почему именно так. Новички воспользуются не задумываясь и наступят на грабли.

                Далее.
                На практике я писал что у меня freeradius с perl выборкой и snmp правилами для блокировки IP на порту.

                А DHCP_snoop используете? Очень хорошая штука в паре с dhcp_relay options 82. Тогда ни какие snmp правила для блокировки не нужны :)
                Как я уже сказал — на мой взгляд ОЧЕНЬ спорная статья. Я бы сказал — первый блин комом… :)

                По поводу радиуса — было бы интересно посмотреть Ваши наработки — как раз этим направлением занимаюсь :)
                  0
                  В примере для Вас с shared-network класс описан так, что он привязывается к порту любого свитча.

                  Нет. Там всё же есть к мак свитча, но не читабельный. Почему через точку, а не через двоеточие? Зачем оставили первые 2 байта? :) Ладно. Не суть важно. В моём примере виден ещё 1 вариант — использование ip свитча.
                    0
                    Про IP свитча и клиента, я вроде не полный идиот что бы клиентам доступ давать в влан управления. :)

                    Я как раз DHCP_Snooping и использую у себя, для моих задачь DHCP в L3 не подходит. А правила нужны, можно ручками у себя прописать IP-соседа из одного влана и когда он выключает комп сидеть под его IP. Поэтому при первом запросе в свитче делается жесткая привязка IP+port и делается пометка в базе что правило прописано.

                    А что конкретно интересует по радиусу?
                      0
                      Мы наверное о разных DHCP_Snooping говорим. Он есть прямо на свитчах DLink. Пока пользователь не получит IP по DHCP, ни какой другой трафик, кроме DHCP-запросов от него не пройдёт (при максимальных настройках). Когда идёт ответ, свитч запомнит, какой ему ip выдало и привяжет пару mac+ip к порту. А уже DHCP сервер за счёт option 82 сделат, какой ip на какой порт выдать.
                      Попытка сменить себе после этого ip на какой-то другой — ничего не даст. Новый ip будет заблокирован. При всём желании
                      можно ручками у себя прописать IP-соседа из одного влана и когда он выключает комп сидеть под его IP.
                      не сделаешь. Даже попытка прописать себе свой IP статикой проживёт ровно до истечения lease dhcp-ответа. После этого свитч запомненную информацию скинет. Так что пользователь обязан юзать DHCP. И не пропишет своими кривыми ручками что-то не то.
                      В результате надобность в
                      config access_profile profile_id 4 add access_id 1 ip vlan_id $vlanid source_ip 10.5.0.88 port 1 permit
                      отпадает, т.к. это делается динамически.
                        0
                        Поподробнее на этом месте. Кончилась лиза, ну и что дальше. Причем здесь разрешающее правило? Ну не сделал он новго запроса и что измениться, у него IP есть, сеть физически состыкована у сервера тоже IP и кто ему запретит дальше сидеть в интете?
                          0
                          И так. Подробнее. Что делает DHCP_Snoop в связке с IMPB на свичах D-Link (у многих остальных есть аналоги, но тут всё достаточно хорошо отточено уже давно).
                          Когда эта петрушка включена на порту — от пользователя с порта могут уйти только DHCP-запросы. Любой другой трафик блокируется. Т.е. если пользователь попробовал прописать себе IP руками — он ничего не получит. (В том числе IP соседа).
                          Дальше. Он запросил IP по DHCP, ему сервер DHCP ответил. Свитч из ответа сервера выдернет для себя пару IP+mac и время на которое выдан, которые отданы этому клиенту и запомнит их для клиентского порта. Т.е. этот клиент сможет работать с этой парой. Начнёт ходит L2 трафик от этого mac и L3 трафик от пары IP+mac. Любые другие mac и ip+mac на клиентском порту будут продолжать блокироваться. Можно ограничить сколько одновременных пар можно будет выучить на порт.
                          В принципе на этой стадии клиент может попробовать прописать себе свой же IP руками. Но т.к. свитч запоминает, на сколько IP был выдан, то без повторных запросов DHCP со стороны клиента, свитч по истечении этого времени «забудет» пару IP+mac и клиент опять будет заблокирован.
                          Возможная махинация с прописыванием себе мака соседа блокируется использование option 82, т.е. ты клиента прибиваешь к порту.

                          Плюсы:
                          1. Глупости и не правильная настройка со стороны клиента блокируются на ходу. Даже роутер воткнутый в LAN, а не в WAN будет заблокирован, т.к. он не запрашивает DHCP.
                          2. Большинство атак, махинаций и попыток «воровать» интернет соседа так же заблокированы.
                          3. Динамическая привязка к твоему биллингу за счёт первоначальной настройки свитча, а дальше всё обслуживается 1 запросом DHCP. Тут надо только, что бы у тебя была привязка пользователя к порту. Кстати можно даже не привязываться к его маку, можно просто именно к порту.

                          Минусы:
                          1. Есть глючные клиентские устройства, которые криво работают с DHCP. Например роутеры, которые «забывают» уточнить данные по истечению времени аренды. Обычно (если это не полный китай) лечится обновлением прошивки.
                            0
                            Сейчас взяли на тест eltex MES1124, ковыряю как замену длинку. Попробовал настроить dhcp snooping c ip arp inspection. Да действительно работает. Весь трафик на порту блокируется пока dhcp-запрос не сделаешь.
                              0
                              Кстати прохождение трафика не зависит не от лизы не от арп таймаута. Прохождение сохраняется пока не погасишь порт.
                                0
                                У DLink отрабатывает чётко. Лиаза закончилась — иди лесом :)
                                  0
                                  Да, все верно. Почему то на стенде время лизы некоректно определял, сейчас на рабочий сервер свитч поставил, лизу стал правильно определять.
                                    0
                                    Ещё возможно ты на старой прошивке пробовал. Заводские лучше обновлять на свежие, за редким исключением. Иногда в процессе «починки» или добавления ломают что-нить. Тогда приходится откатываться на предыдущую. Но это редкость и обычно последняя — нормально рабочая.
                                      +1
                                      Продолжаю эпопею об елтексах.
                                      Как я уже говорил впечатление они производят крайне положительное.
                                      На сегодня удалось получить 100% работающий конфиг с авторизацией по opt82.
                                      Необходимо задействовать dhcp snooping + ip arp inspection + ip source guard. Причем обратите внимание что SG нужно включать не только глобально, но и на каждом клиентском интерфейсе.
                                      Отдельно хочется отметить их ТП, крайне адекватные ребята, отвечают быстро и по теме. Мне пока все у них нравиться.
                                0
                                mes1024 настраивал. работает
                                  0
                                  Вы давно елтекс-ы используете? Как себя зарекомендовали свитчи? Какой функционал на них используете.

                                  У меня пока первые впечатления положительные.
                                    0
                                    да в принципе только стенды пока, да тестовые подключения. Используем в качестве абонентских свитчей с поддержкой opt82
                            0
                            Вы вероятно вы путаете с авторизацией по протоколы 802.1X xgu.ru/wiki/802.1X_%D0%B8_RADIUS.
                              0
                              IMPB в свичах DLink знаете? Он заполняется в ручную или через SNMP. DHCP_Snoop обеспечивает его заполнение автоматически с использованием DHCP пакетов. С радиусом это ни как не связано.
                      0
                      Готов долго и нудно спорить — но… Думаю бессмысленно. Каждый останется при своём мнении.

                      И я даже более того скажу, я злой админ :) у меня еще и вот такие правила, клиентскому броадкасту не выжить:
                      Заголовок спойлера
                      expect "#$" { send «create access_profile profile_id 1 profile_name 1 ethernet ethernet_type\n»}
                      expect "#$" { send «config access_profile profile_id 1 add access_id auto_assign ethernet ethernet_type 0x86DD port all deny\
                      n»}

                      #Deny untrast dhcp-server
                      expect "#$" { send «create access_profile profile_id 2 profile_name 2 ip udp src_port_mask 0xFFFF \n»}
                      expect "#$" { send «config access_profile profile_id 2 add access_id 1 ip udp src_port 68 port $user_ports permit\n»}
                      expect "#$" { send «config access_profile profile_id 2 add access_id 2 ip udp src_port 67 port $user_ports deny\n»}

                      #Allow arp and deny broadcast
                      expect "#$" { send «create access_profile profile_id 3 profile_name 3 ethernet destination_mac ff-ff-ff-ff-ff-ff ethernet_typ
                      e\n»}
                      expect "#$" { send «config access_profile profile_id 3 add access_id 1 ethernet destination_mac ff-ff-ff-ff-ff-ff ethernet_ty
                      pe 0x806 port $user_ports permit\n»}
                      expect "#$" { send «config access_profile profile_id 3 add access_id 2 ethernet destination_mac ff-ff-ff-ff-ff-ff ethernet_ty
                      pe 0x800 port $user_ports deny\n»}

                      #
                      expect "#$" { send «create access_profile profile_id 4 profile_name 4 ip vlan 0xfff source_ip_mask 255.255.255.255 \n»}
                      #expect "#$" { send «config access_profile profile_id 4 add access_id 1 ip vlan_id $vlanid source_ip 10.5.0.88 port 1 permit\
                      n»}
                      expect "#$" { send «config access_profile profile_id 4 add access_id 25 ip vlan_id $vlanid port $user_ports deny\n»}

                        0
                        #Deny untrast dhcp-server
                        expect "#$" { send «create access_profile profile_id 2 profile_name 2 ip udp src_port_mask 0xFFFF \n»}
                        expect "#$" { send «config access_profile profile_id 2 add access_id 1 ip udp src_port 68 port $user_ports permit\n»}
                        expect "#$" { send «config access_profile profile_id 2 add access_id 2 ip udp src_port 67 port $user_ports deny\n»}


                        Это делает dhcp_server filtre
                        config filter dhcp_server ports 1-25 state enable
                        Немного проще. :)
                          0
                          В остальных бродкастах не разобрался. арп понял по коментарию, но вообще типы пакетов 0x806 0x800 0x86DD и т.д. не помню, а искать сейчас влому :) Так что ты имел в виду этими записями (что фильтровал, а что пропускал), пока что не понял :)
                            0
                            config filter dhcp_server ports 1-25 state enable

                            Нет такая запись не подходит, мне нужно разрешить прохождение на 67-port dhcp — запросов иначе на правиле config access_profile profile_id 3 add access_id 2 ethernet destination_mac ff-ff-ff-ff-ff-ff ethernet_ty
                            pe 0x800 port $user_ports deny весь этот траф погибнет.
                              0
                              Бррр. Тебе необходимо заблокировать «левые» DHCP сервера в своей сети. Именно это эта команда и делает. Блокируешь на пользовательских портах, оставляешь на магистральных. Что не так?
                                0
                                Всё. Понял наконец. Из-за твоего фильтра бродкаста получится умирают DHCP запросы от пользователей. Поэтому приходится их разрешать руками. Это ты имел в виду?
                                  0
                                  Правильно, именно так!
                          0
                          0x806 — это арп
                          0x800 — это обычный траф
                          0x86DD — это ipv6

                          Смысл там примерно такой, что убивать весь броадкаст, кроме арп и DHCP-запросов от клиентов. Весь броадкаст гаситься на уровне фреймов.
                          • UFO just landed and posted this here
                              0
                              Я видел ваш сервер и как вариант я его рассматривал, но с переписыванием на Си.
                              Потом я покрутил радиус, попробовал и 3 и 2 версии. 3 отмел сразу, как dhcp практически не работал вываливался. А двойка показал себя не плохо. И по сей день работает без нареканий. Буду признателен если просветите по поводу костыля :) Почему сложилось такое мнение?
                              • UFO just landed and posted this here
                                  0
                                  а чем перл-то не угодил? он только при старте интерпретируется и висит в памяти. тоже многопоточность умеет. Зато пиши что хочешь от управления файрволами до логирования и rrdb.
                                  • UFO just landed and posted this here
                                      +1
                                      Ну на самом деле в самописном сервере ты сам себе хозяин — в этом плане оно может и лучше. А на счет перла, он действительно интерпретируется при загрузке и работает очень быстро. На радиусе этот вопрос не однократно обсуждался. Я сначала как всегда в дебри полез и хотел написать бинарный модуль, потом почитав доки успокоился и оставил все на перле. Так что на перле дейсвительно все нормально работает. Плюсом в нем есть очень интересная функци connect_cached, которая очень помогает при постоянных коннектах к базе.
                                    0
                                    Что именно в 3 версии вываливалось, если не секрет? И какую именно тестил? Я сейчас 3.0.7 кручу. Достаточно свежая — но это пока что без нагрузки (1-10 клиентов) и с самыми простыми скриптами.

                                    Пока что смотрю на фрирадиус, т.к. он всё равно нужен для аутентификации юзеров. Смысл плодить сущности (отдельный DHCP, отдельный радиус и т.д.), если всё есть в одном.
                                      0
                                      Что именно в 3 версии вываливалось, если не секрет? И какую именно тестил? Я сейчас 3.0.7 кручу. Достаточно свежая — но это пока что без нагрузки (1-10 клиентов) и с самыми простыми скриптами.

                                      В домашних условиях работал, но как только я его попытался под нагрузкой запустить приблизительно 4000 юзеров онлайн, вывалился не отработав и часа. Что конкретно было в логах уже не помню. Версия была из гита, но какая точно не скажу, я эти эксперементы почти год назад делал.
                                      Если читали на сайте фрирадиуса, там есть фраза типа: 2-это стабильность, 3- это функционал. Поэтому я не стал упираться и перешел на 2-ую версию.
                                        0
                                        Это читал. Но взял для начала 3 версию. Посмотрю на сколько она стабильна стала :)
                                          0
                                          Почти год в продакшене 3й радиус, начинали с 3.0.1, стабильность подводит, зато настроить нужное поведение удалось достаточно быстро. После обновления до 3.0.3 «всё сломалось» — оказалось, что поменялось поведение, пришлось переписывать конфиги (так что больше не обновлялись). Стабильности добились балансировкой запросов на пул из 16 контейнеров с вочдогами.
                                          • UFO just landed and posted this here
                                              0
                                              А сколько у вас абонентов онлайн на один пул?
                                              • UFO just landed and posted this here
                                                0
                                                Если бы нужен был только DHCP — это да. Но нужен ещё и радиус. Так что вопрос стабильной работы именно радиуса в целом.
                                                0
                                                Ну сейчас 3.0.7 — интересно, на сколько стабильна она в разрезе до 4к пользователей.
                                      0
                                      А почему это в .NET?
                                        0
                                        Не расглядел, я думал там нписано *NET* а не *.NET*

                                      Only users with full accounts can post comments. Log in, please.