none
DHCP-сервер ведёт себя ненормально RRS feed

  • Вопрос

  • Привет тебе, о неустрашимый All!

    Хочу поделиться одной проблемой, которая меня просто задолбала. Речь идёт о DHCP-сервере в Windows Server 2003. Как известно, помимо собственно IP-адресов, он может раздавать клиентам всякие полезные параметры. В частности, он может выдавать адрес шлюза, адреса DNS-серверов и целую пропасть всякой всячины.
    Мой DHCP-сервер настроен выдавать адреса DNS-серверов (параметр 006, настроен на уровне сервера). Обычно там 2-3 адреса.
    Так вот. Ещё с самого начала эксплуатации сервера я столкнулся с тем, что DHCP-сервер периодически не выдаёт адреса DNS-серверов. Вот адрес шлюза выдаёт всегда железно, адрес WINS-сервера и ещё какую-нибудь лабуду - тоже. А вместо адресов DNS - пусто.
    Проверял я это просто - последовательностью команд по сбросу и запросу аренды на IP со стороны клиента:
    Код
    ipconfig /release
    ipconfig /renew
    ipconfig /all

    В результате вижу, что адресов DNS-серверов не выдано. Повторяю эту операцию несколько раз (примерно так от 3 до 9, я не считал), и на какой-то раз DHCP-сервер вдруг нормально выдаёт адреса DNS. Если продолжить сбрасывать и заново получать аренду на IP, то вся эта хренотень может повториться снова.

    Обнаружена и ещё одна проблема. К примеру, в списке DNS-серверов на выдачу - три адреса. Первым (верхним) стоит наш внутренний DNS-сервер, который обслуживает запросы интранета, а запросы на разрешение имён из интернета перенаправляет серверам провайдера. Следующие два адреса - как раз серверы провайдера, чисто для страховки. В силу этого я рассчитываю, что все DNS-запросы пойдут на мой сервер.
    Предположим, что клиент удачно получил от DHCP-сервера список DNS-серверов. Разумеется, в нужном порядке. Что же происходит на деле? Я вижу, что клиентская машина за разрешением имён обращается не к первому серверу (нашему локальному), а ко второму (серверу провайдера). Пока нужно разрешение интернет-имён, проблем не возникает. Когда нужно разрешить интранет-имя, сервер провайдера, разумеется, не в курсе этих имён и даёт отлуп. После чего клиентская машина никуда уже не обращается и возвращает ошибку "Сервер не найден".

    Вот такая хренотень. Почему так происходит и как с этим бороться, я не понимаю.
    Система - без сервис-паков, без обновлений.
    На всякий случай, вот дамп всех установленных параметров DHCP-сервера:
    Dhcp Server 127.0.0.1 set optionvalue 3 IPADDRESS "192.168.0.1"
    Dhcp Server 127.0.0.1 set optionvalue 44 IPADDRESS "192.168.0.1"
    Dhcp Server 127.0.0.1 set optionvalue 46 BYTE "8"
    Dhcp Server 127.0.0.1 set optionvalue 6 IPADDRESS "192.168.0.1" "xxx.xxx.xx.xx"

    где "xxx.xxx.xx.xx" - DNS-сервер провайдера (сейчас он один, но была конфигурация, когда их было и два)
    Особых параметров области и т.п. не устанавливалось, все параметры заданы именно на уровне сервера.

    ...А теперь часть вторая этой истории.
    Народ просветил меня, что надо накатить последние обновления и изучать вопрос сетевым монитором. Так я и сделал. Во-первых, обновился до Windows Server 2003 R2, во-вторых, поставил MS Network Monitor 3.2 и продолжил свои изыскания.
    В общем, пока что проблема сохраняется, и я не могу однозначно ответить на вопрос, где собака порылась. Скорее всего, всё же в сервере.
    Результаты по-прежнему не воспроизводятся, разве что, случаев успешного получения адресов DNS-серверов стало ещё меньше.
    Мониторингом трафика по протоколу DHCP с обеих сторон (как клиента, так и сервера) установлена следующая последовательность событий:

    1. Клиент отправляет серверу запрос DISCOVER.

    2. Сервер отвечает клиенту двумя предложениями OFFER. Эти предложения идут либо одновременно, либо с небольшим (~0,01 с) лагом. При этом первый OFFER содержит все необходимые данные, в т.ч. адреса DNS-серверов, адрес WINS-сервера. Второй OFFER не содержит адресов ни DNS, ни WINS, а остальные параметры расположены в ином порядке, чем в первом предложении.

    3. Клиент соглашается с предоставляемым адресом (REQUEST).

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

    Насколько я понимаю, двойной ответ от DHCP-сервера - это ненормально. Для надёжности я смоделировал эту ситуацию (в качестве подопытных кроликов использовал три DHCP-сервера - dhcpd на FreeBSD, VMware-DHCP-сервер и, собственно, DHCP-сервер на другой копии Windows Server). Везде DHCP-сервер отвечал на запросы единожды.

    Мне кажется, что возникли какие-то нелады с привязкой сервера к интерфейсам. Хотя формально привязан он к правильному интерфейсу, мне очень не по душе, что дамп настроек DHCP-сервера выдаёт его адрес 127.0.0.1, хотя по идее это должен быть адрес внутреннего адаптера.

    Дамп мониторинга я снял как на сервере, так и на клиенте. Дамп настроек сервера также имеется.

    Пытался снести и заново поставить DHCP-сервер, но пока что это не увенчалось успехом. Возможно, не совсем чисто переставлял.
    10 ноября 2008 г. 0:45

Ответы

  • И снова здравствуйте! Smile

    Мне, кажется, удалось найти разгадку.

    Конечно, DHCP-релея у меня нету. Его надо было явно устанавливать в оснастке маршрутизации, и это сразу бросилось бы в глаза. VMware у меня тоже не установлен на сервере. Кстати, как и домен AD Smile
    Но эксперимент с остановом DHCP-сервера действительно толковая идея, за что выражаю всем благодарность Smile Он-то и привёл, в конце концов, к прояснению ситуации.

    Итак, я заглушил DHCP-сервер. К своему удивлению, я обнаружил, что сервер продолжает обрабатывать запросы DHCP-клиентов, только на сей раз ответы от него не двойные, а одинарные, как и должно быть. Адресов DNS-серверов в них не содержалось.
    Сетевой монитор недвусмысленно показывал, что запросы обслуживает именно этот сервер, а не какой-нибудь притаившийся в сети другой DHCP-сервер.
    То есть, напрашивался вывод, что на сервере размещена ещё какая-то служба, которая дублирует работу DHCP-сервера и обрабатывает запросы даже при остановленном DHCP-сервере.
    Я решил просмотреть детальную информацию об открытых портах с помощью команды netstat -a -b -n. Как известно, DHCP-сервер висит на порту UDP 67.
    Так вот, при включённом DHCP-сервере на внутреннем интерфейсе я увидел две службы: tcpsvcs.exe (это сам
    DHCP-сервер) и svchost.exe, при этом было подписано название стоящей за этим процессом службы - RemoteAccess. То есть, в переводе на русский, служба маршрутизации и удалённого доступа к сети (RRAS). Когда я глушил DHCP-сервер и снимал информацию по открытым портам, то на 67-м порту оставался только svchost.exe. Очевидно, он и обрабатывал запросы.
    Таким образом, становилось ясно, что параллельно с
    DHCP-сервером его роль выполняет также служба RRAS. Оставалось выяснить, какая именно подсистема службы отвечает за это, и отключить её.
    Рысканье по оснастке ничего не дало (как выяснилось потом, я плохо искал), поэтому я перешёл в командную строку и сделал дамп настроек службы: netsh routing ip dump. Внимательно изучив результат, я обратил внимание на последнюю секцию дампа, касающуюся некоего "DHCP-распределителя". Там были выставлены некоторые настройки, т.е. этот самый распределитель был включён. Я его заглушил: netsh routing ip autodhcp uninstall. Уже после этого я нашёл соответствующее место в GUI-оснастке.
    После останова DHCP-распределителя службы RRAS DHCP-сервер стал монопольно обслуживать запросы от клиентов. "Конкурент" пропал, 67-й порт перешёл в безраздельное пользование tcpsvcs.exe, ответы стали одинарными, клиенты стали нормально получать адреса DNS-сервера.

    Вот такая история... Для меня осталось не вполне выясненным, что такое этот DHCP-распределитель в службе RRAS. Надо книжки прочитать Smile Вероятно, это специальный суррогатный DHCP-сервер в составе службы для тех, кому не нужно досконально контролировать выдачу IP-адресов и не хочется ставить полноценный DHCP-сервер. Ошибка в настройке привела к тому, что этот суррогат работал параллельно с полноценным сервером.
    12 ноября 2008 г. 9:05

Все ответы

  • Куда воткнут сервер ? В хаб, свитч или ещё что-то ?

    Нужно попробовать заменить последовательно: порт, кабель, сетевую плату.
    10 ноября 2008 г. 6:20
  •  

    Проверьте, возможно в сети два сервера DHCP отвечают.

    Один раздает верные настройки, второй - неполные..

     

    Проверить можно утилитой dhcploc.exe из состава Support Tools.

     

    10 ноября 2008 г. 7:13
  • cognize@, сервер воткнут в свитч. Мысль насчёт замены понял, но мне кажется, что проблема совсем на другом уровне - на уровне логики настройки, а не на уровне железа.

    Ilgiz Mamyshev, ручаюсь, что двойной ответ исходит от одного и того же сервера. Данные MS Network Monitor'а свидетельствуют об этом недвусмысленно, ведь там и IP-адреса видны, и MAC-адреса. К тому же, я проводил испытания в воскресенье, когда никаких лишних машин в сети нет.
    10 ноября 2008 г. 7:42
  • У меня есть такое смешное теоретическое предположение, что на одном из сетевых подключений может быть включен Internet Connection Sharing.

    10 ноября 2008 г. 8:38
  • Двойные ответы DHCP это почти 100% второй сервер. У Michael Gotch отличная идея о ICS

     

    По DNS. Вы должны предлагать равноценные DNS серверы, т.к. клиент берет не первый по списку, а использует более изощренный алгоритм распознавания имен.

     

     

    10 ноября 2008 г. 9:01
    Модератор
  • Нет, никакого ICS ни на одном интерфейсе нет. Мне бы и в голову не пришло пользоваться ICS, ведь есть маршрутизация.

    Вот диалог сервера и клиента, отслеженный Network Monitor'ом. Слежение проводилось на внутреннем интерфейсе сервера:

    1    0.000000                    NetmonFilter    NetmonFilter:Updated Capture Filter: Protocol.DHCP==True
    2    0.000000                    NetworkInfoEx    NetworkInfoEx:Network info for , Network Adapter Count = 1
    3    5.795899    tcpsvcs.exe    {DHCP:3, UDP:5, IPv4:4}    0.0.0.0    255.255.255.255    DHCP    DHCP:Request, MsgType = DISCOVER, TransactionID = 0x371B079B
    4    5.797852    tcpsvcs.exe    {DHCP:3, UDP:5, IPv4:4}    192.168.0.1    255.255.255.255    DHCP    DHCP:Reply, MsgType = OFFER, TransactionID = 0x371B079B
    5    5.798828    tcpsvcs.exe    {DHCP:3, UDP:5, IPv4:4}    192.168.0.1    255.255.255.255    DHCP    DHCP:Reply, MsgType = OFFER, TransactionID = 0x371B079B
    6    5.798828    tcpsvcs.exe    {DHCP:3, UDP:5, IPv4:4}    0.0.0.0    255.255.255.255    DHCP    DHCP:Request, MsgType = REQUEST, TransactionID = 0x371B079B
    7    5.800781    tcpsvcs.exe    {DHCP:3, UDP:5, IPv4:4}    192.168.0.1    255.255.255.255    DHCP    DHCP:Reply, MsgType = ACK, TransactionID = 0x371B079B
    8    5.801758    tcpsvcs.exe    {DHCP:3, UDP:5, IPv4:4}    192.168.0.1    255.255.255.255    DHCP    DHCP:Reply, MsgType = ACK, TransactionID = 0x371B079B

    По-моему, вполне ясно видно, что речь не может идти о каких-то посторонних серверах. Сервер один-единственный, и на каждый запрос клиента он отвечает дважды.
    Сравнение деталированной информации о пакетах 4 и 5 между собой, а также 7 и 8, показало бы, что содержащаяся в них информация различна. Первый пакет содержит DHCP-информацию в таком порядке:

    - Dhcp: Reply, MsgType = OFFER, TransactionID =
    0x371B079B
    < . . . >
      - MessageType: OFFER - Type 53
      - SubnetMask: 255.255.0.0 - Type 1
      - RenewTimeValue: Subnet Mask: 3 day(s),12 hour(s) 0 minute(s) 0 second(s) - Type 58
      - RebindingTimeValue: Subnet Mask: 6 day(s),3 hour(s) 0 minute(s) 0 second(s) - Type 59
      - IPAddressLeaseTime: Subnet Mask: 7 day(s),0 hour(s) 0 minute(s) 0 second(s) - Type 51
      - ServerIdentifier: 192.168.0.1 - Type 54
      - Router: 192.168.0.1 - Type 3
      - DomainNameServer: 0.3650491412.3650488852.3232235521 - Type 6
      - NBOverTCPIPNameServer: 192.168.0.1 - Type 44
      - NodeType: H-node (8) - Type 46
      - End:

    Второй же - такую:

    - Dhcp: Reply, MsgType = OFFER, TransactionID =
    0x371B079B
    < . . . >
      - MessageType: OFFER - Type 53
      - ServerIdentifier: 192.168.0.1 - Type 54
       - IpAddress:
      - SubnetMask: 255.255.0.0 - Type 1
      - Router: 192.168.0.1 - Type 3
      - RenewTimeValue: Subnet Mask: 0 day(s),0 hour(s) 5 minute(s) 0 second(s) - Type 58
      - RebindingTimeValue: Subnet Mask: 5 day(s),6 hour(s) 0 minute(s) 0 second(s) - Type 59
      - IPAddressLeaseTime: Subnet Mask: 7 day(s),0 hour(s) 0 minute(s) 0 second(s) - Type 51
      - NodeType: H-node (8) - Type 46
      - End:

    10 ноября 2008 г. 11:48
  •  Ilgiz Mamyshev написано:

     

    Проверьте, возможно в сети два сервера DHCP отвечают.

    Один раздает верные настройки, второй - неполные..

     

    Проверить можно утилитой dhcploc.exe из состава Support Tools.

     

    Загасите свой DHCP сервер (деактивируйте или остановите службу) и послушайте в сети ответы DHCP сервера утилитой dhcploc.

    Если ваш сервер как вы говорите по 2 раза отвечает - то ответов больше не будет. Значит ваша правда и проблема в нем.

    А если ответы будут продолжаться.. - здешние парни еще раз пораскинут мозгами.. Smile

    10 ноября 2008 г. 16:19
  • Ну то что ответ идет с одного сервера может и не значить, что отвечает именно один и тот же DHCP. Сервер может, например, ретранслировать ответ некого иного dhcp из другой подсети, теоретически. Или, как однажды у меня было, на сервере может стоять, к примеру, VmWare, со встроенного dhcp раздающая адреса.

     

    Вы действительно, как советуют выше, остановите _только_ службу dhcp, и посмотрите - пропадут оба offer, или только один.

    10 ноября 2008 г. 18:58
  • Michael Gotch

    Это возможно если второй DHCP был авторизован в AD.

    Хотя всякое бывает и не известно что у автора темы на самом деле

    -)
    11 ноября 2008 г. 6:33
  • И снова здравствуйте! Smile

    Мне, кажется, удалось найти разгадку.

    Конечно, DHCP-релея у меня нету. Его надо было явно устанавливать в оснастке маршрутизации, и это сразу бросилось бы в глаза. VMware у меня тоже не установлен на сервере. Кстати, как и домен AD Smile
    Но эксперимент с остановом DHCP-сервера действительно толковая идея, за что выражаю всем благодарность Smile Он-то и привёл, в конце концов, к прояснению ситуации.

    Итак, я заглушил DHCP-сервер. К своему удивлению, я обнаружил, что сервер продолжает обрабатывать запросы DHCP-клиентов, только на сей раз ответы от него не двойные, а одинарные, как и должно быть. Адресов DNS-серверов в них не содержалось.
    Сетевой монитор недвусмысленно показывал, что запросы обслуживает именно этот сервер, а не какой-нибудь притаившийся в сети другой DHCP-сервер.
    То есть, напрашивался вывод, что на сервере размещена ещё какая-то служба, которая дублирует работу DHCP-сервера и обрабатывает запросы даже при остановленном DHCP-сервере.
    Я решил просмотреть детальную информацию об открытых портах с помощью команды netstat -a -b -n. Как известно, DHCP-сервер висит на порту UDP 67.
    Так вот, при включённом DHCP-сервере на внутреннем интерфейсе я увидел две службы: tcpsvcs.exe (это сам
    DHCP-сервер) и svchost.exe, при этом было подписано название стоящей за этим процессом службы - RemoteAccess. То есть, в переводе на русский, служба маршрутизации и удалённого доступа к сети (RRAS). Когда я глушил DHCP-сервер и снимал информацию по открытым портам, то на 67-м порту оставался только svchost.exe. Очевидно, он и обрабатывал запросы.
    Таким образом, становилось ясно, что параллельно с
    DHCP-сервером его роль выполняет также служба RRAS. Оставалось выяснить, какая именно подсистема службы отвечает за это, и отключить её.
    Рысканье по оснастке ничего не дало (как выяснилось потом, я плохо искал), поэтому я перешёл в командную строку и сделал дамп настроек службы: netsh routing ip dump. Внимательно изучив результат, я обратил внимание на последнюю секцию дампа, касающуюся некоего "DHCP-распределителя". Там были выставлены некоторые настройки, т.е. этот самый распределитель был включён. Я его заглушил: netsh routing ip autodhcp uninstall. Уже после этого я нашёл соответствующее место в GUI-оснастке.
    После останова DHCP-распределителя службы RRAS DHCP-сервер стал монопольно обслуживать запросы от клиентов. "Конкурент" пропал, 67-й порт перешёл в безраздельное пользование tcpsvcs.exe, ответы стали одинарными, клиенты стали нормально получать адреса DNS-сервера.

    Вот такая история... Для меня осталось не вполне выясненным, что такое этот DHCP-распределитель в службе RRAS. Надо книжки прочитать Smile Вероятно, это специальный суррогатный DHCP-сервер в составе службы для тех, кому не нужно досконально контролировать выдачу IP-адресов и не хочется ставить полноценный DHCP-сервер. Ошибка в настройке привела к тому, что этот суррогат работал параллельно с полноценным сервером.
    12 ноября 2008 г. 9:05
  • А это по-моему как раз призрак вашего DHCP сервера из ICS. Или NAT'а RRAS. 

    Адреса у вас раздавались его "любимые" - 192.168.0.XXX.

    15 ноября 2008 г. 8:06