locked
2 DHCP в одной сети RRS feed

  • Общие обсуждения

  • Все знают про такую хорошую штуку как DHCP-сервер... Не надо бегать по клиентам и руками вводить на них адреса и все счастливы...

     

    Но что делать, если вдруг в сети появляется второй DHCP-сервер? Собственно, вопрос несколько в другом. Для полного счастья, можно предположить (грубо), что в один свитч воткнуты 2 сервера, раздающие адреса из разных подсетей и бедный-несчастный клиент.

    От какого из серверов будет получен адрес, как с этим бороться и вообще как рулить этим процессом?
    15 апреля 2008 г. 13:38

Все ответы

  •  Anton Kononov написано:

    Все знают про такую хорошую штуку как DHCP-сервер... Не надо бегать по клиентам и руками вводить на них адреса и все счастливы...

     

    Но что делать, если вдруг в сети появляется второй DHCP-сервер? Собственно, вопрос несколько в другом. Для полного счастья, можно предположить (грубо), что в один свитч воткнуты 2 сервера, раздающие адреса из разных подсетей и бедный-несчастный клиент.

    От какого из серверов будет получен адрес, как с этим бороться и вообще как рулить этим процессом?

     

    Если два DHCP сервера в одном немаршрутизируемом сегменте сети будут раздавать адреса из разных подсетей, ничего хорошего не получится, поверьте.  Делать так категорически нельзя, а "плохие" dhcp серверы надо выявлять и изничтожать. Smile

    15 апреля 2008 г. 13:45
  • Если оба сервера авторизованы в AD, то клиенту выдаст адрес первый ответивший сервер. Второй сервер "увидит" ответ первого сервера клиенту и не будет вмешиваться.
    Как бороться - размещать каждый dhcp-сервер в своей сети, т.к. бродкастный запрос на получение адреса от клиента не пройдёт через маршрутизатор (без доп.настройки)
    15 апреля 2008 г. 13:45
  •  dmirk написано:
    Если оба сервера авторизованы в AD, то клиенту выдаст адрес первый ответивший сервер. Второй сервер "увидит" ответ первого сервера клиенту и не будет вмешиваться.
    Как бороться - размещать каждый dhcp-сервер в своей сети, т.к. бродкастный запрос на получение адреса от клиента не пройдёт через маршрутизатор (без доп.настройки)

     

    Помню принес как-то один добрый человек ноутбук с VMWare и его DHCP. Минут двадцать ловили, кто клиентам дает "левые" адреса. И никакой авторизации в AD. :-)

    15 апреля 2008 г. 14:05
  •  Michael Gotch написано:

     dmirk написано:
    Если оба сервера авторизованы в AD, то клиенту выдаст адрес первый ответивший сервер. Второй сервер "увидит" ответ первого сервера клиенту и не будет вмешиваться.
    Как бороться - размещать каждый dhcp-сервер в своей сети, т.к. бродкастный запрос на получение адреса от клиента не пройдёт через маршрутизатор (без доп.настройки)

     

    Помню принес как-то один добрый человек ноутбук с VMWare и его DHCP. Минут двадцать ловили, кто клиентам дает "левые" адреса. И никакой авторизации в AD. :-)

    Вот про это и речь. К тому же DHCP не всегда бывают софтовые в том смысле, что можно поставить какой-нибудь точка доступа, которое то же DHCP умеет и понеслась...

    15 апреля 2008 г. 14:08
  • Угу. Именно поэтому в Windows и придумали авторизацию в AD. DHCP-сервер "знает" авторизован он или нет,и во втором случае по задумке не должен выдавать адреса.

    Если же dhcp на другой платформе (не windows), то и авторизация не поможет

    15 апреля 2008 г. 14:58
  • Клиент получит адрес от первого ответившего сервера.

    Если вопрос в отлове нехорошего DHCP. то для этого есть dhcploc.exe или банальные снифферы (ставим сниффер, сбрасываем на ближайшем клиенте адрес и смотрим кто ему будет отвечать).

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

     

     

    15 апреля 2008 г. 14:59
    Отвечающий
  •  dmirk написано:

    Если же dhcp на другой платформе (не windows), то и авторизация не поможет

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

    15 апреля 2008 г. 15:03
    Отвечающий
  •  

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

     

    >>во втором случае по задумке не должен выдавать адреса

    Smile в реальной ситуации ессно может быть иначе

    15 апреля 2008 г. 15:12
  •  G14 написано:

    Клиент получит адрес от первого ответившего сервера.

    Если вопрос в отлове нехорошего DHCP. то для этого есть dhcploc.exe или банальные снифферы (ставим сниффер, сбрасываем на ближайшем клиенте адрес и смотрим кто ему будет отвечать).

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

    То есть просто ждать... Способа выставить приоритет для одного из серверов не существует? Даже если они оба есть в AD...
    15 апреля 2008 г. 16:12
  • Нет. Никаких приоритетов нет.

    Авторизация в AD затем и придумана, чтобы "чужие" DHCP не запускались. Но это работает только на членах домена. Способ только один - не авторизовывать что попало (и не давать прав на авторизацию кому попало), ну и нормальный контроль за всем устанавливаемым ПО и, конечно, оборудованием. Под ПО я имею в виду не столько серверы-члены домена, сколько всяческое third-party ПО или виртуализацию (VMWare\VirtPC и т.п.). Ну и конечно Windows серверы, которые не входят в домен.

    15 апреля 2008 г. 16:21
    Отвечающий
  •  Anton Kononov написано:

     Для полного счастья, можно предположить (грубо), что в один свитч воткнуты 2 сервера, раздающие адреса из разных подсетей и бедный-несчастный клиент.

    От какого из серверов будет получен адрес, как с этим бороться и вообще как рулить этим процессом?

    Если свич умный (достаточно управляемый), то можнно настроить: релеить запросы DHCP, VLAN.

    16 апреля 2008 г. 4:43
  •  dmirk написано:
    Второй сервер "увидит" ответ первого сервера клиенту и не будет вмешиваться.

    Ну прямо. Smile Второму серверу больше делать нечего, как следить за тем, кто кому чего ответил. Учим матчасть, как происходит получение IP адреса по DHCP. Там всего-то 4 пакета ходит, протокол самый простейший, но знать полезно Smile

    Если клиент не принял предложение от второго сервера, а принял от первого, то и брак со вторым не состоится. Все как у людей Smile

    16 апреля 2008 г. 6:22
  •  Jоker написано:

     dmirk написано:
    Второй сервер "увидит" ответ первого сервера клиенту и не будет вмешиваться.

    Ну прямо. Второму серверу больше делать нечего, как следить за тем, кто кому чего ответил. Учим матчасть, как происходит получение IP адреса по DHCP. Там всего-то 4 пакета ходит, протокол самый простейший, но знать полезно

    Если клиент не принял предложение от второго сервера, а принял от первого, то и брак со вторым не состоится. Все как у людей



    Видимо разные "учебники" читаем Smile
    http://support.microsoft.com/kb/169289/ru
    DHCPREQUEST  ... Это сообщает остальным серверам DHCP, что они могут больше не удерживать свои адреса и вернуть их в имеющиеся пулы.
    16 апреля 2008 г. 6:27
  •  Anton Kononov написано:

    Для полного счастья, можно предположить (грубо), что в один свитч воткнуты 2 сервера, раздающие адреса из разных подсетей и бедный-несчастный клиент.

    От какого из серверов будет получен адрес, как с этим бороться и вообще как рулить этим процессом?

    Если сервера раздают адреса из разных подсетей, то они к разным подсетям и подсоединены, соответственно никакого конфликта нет. Если сервера в одной подсети, или стоит DHCP relay, или не дай Бог свитч пропускает броадкасты, то можно устроить себе подстраховку на случай выхода из строя одного из серверов. Для этого существует правило 80 / 20.

     

    http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/cnet/cncb_dhc_ogjw.mspx?mfr=true

     

    http://technet2.microsoft.com/WindowsServer/en/library/75cd0e1f-f464-40ea-ac88-2060e6769f331033.mspx?mfr=true

     

     

    16 апреля 2008 г. 6:28
  •  dmirk написано:

    Видимо разные "учебники" читаем

    Я-то читаю правильные, а вот какие читаете Вы - большой вопрос Wink

    ну ладно, будем считать, что проехали.

    16 апреля 2008 г. 6:30
  • см. выше
    вставил ссылку с цитатой
    16 апреля 2008 г. 6:34
  • Все правильно, Вы вставили сейчас правильную ссылку. Вот и заметьте, что сервера не следят за тем, что первый сервер ответил клиенту, а получают броадкастом информацию от самого клиента о том, что он принял другое предложение. Есть разница, согласны?

    Типа если я - жених, то я не буду следить за другими женихами, как они посылают предложения, я буду следить, что скажет невеста Smile

    16 апреля 2008 г. 6:47
  • Разница есть. Суть не меняется
    имелось ввиду,что серверы не говорят наперебой с клиентом,а всё равно смотрят за проходящими пакетами и ведут себя в зависимости от них
    16 апреля 2008 г. 6:50
  •  Jоker написано:
     Anton Kononov написано:

    Для полного счастья, можно предположить (грубо), что в один свитч воткнуты 2 сервера, раздающие адреса из разных подсетей и бедный-несчастный клиент.

    От какого из серверов будет получен адрес, как с этим бороться и вообще как рулить этим процессом?

    Если сервера раздают адреса из разных подсетей, то они к разным подсетям и подсоединены, соответственно никакого конфликта нет. Если сервера в одной подсети, или стоит DHCP relay, или не дай Бог свитч пропускает броадкасты, то можно устроить себе подстраховку на случай выхода из строя одного из серверов. Для этого существует правило 80 / 20.

    http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/cnet/cncb_dhc_ogjw.mspx?mfr=true

    http://technet2.microsoft.com/WindowsServer/en/library/75cd0e1f-f464-40ea-ac88-2060e6769f331033.mspx?mfr=true

    Внимательно читаем ветку. Речь о "левых" DHCP, которые злые враги могут физически воткнуть в тот же свитч, что и нормальный сервер. К примеру, сервер раздает адреса вида 192.168.0.0 а враги подсовывают 192.168.100.0 При всем при этом воткнуты в одну физическую сеть
    20 апреля 2008 г. 14:33
  • Так в чем Ваш вопрос-то?

    Если в том, как правильно организовать работу нескольких DHCP серверов, чтобы они "подстраховывали" друг друга, то Вам это объяснили.

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

    20 апреля 2008 г. 17:13