none
Проблема с DHCP сервером RRS feed

  • Вопрос

  • Доброго времени суток.

    Столкнулся со странной проблемой на DHCP сервере под управлением Windows server 2008 (этот же сервер одновременно и DNS-server и контроллер AD).

    Согласно данным статистики зоны Ipv4 из 34 существующих адресов (единственная зона, 192.168.1.176-192.168.1.209, без исключений) занято 34 (то есть 100%). Естественно, сервер отказывается выдавать новые ip адреса, это совершенно логично... НО! Арендовано только 24 адреса! Из них 23 - это активное резервирование (некоторые адреса резервирования вообще находятся вне зоны DHCP, например 192.168.1.5). 

    Вопрос: как такое может быть и куда делись еще 10 адресов?

Ответы

  • запускайте network monitor или другой сниффер и смотрите откуда и куда идут dhcp запросы содержащие эти адреса

    • Помечено в качестве ответа AndricoRusEditor 16 мая 2013 г. 10:29
    Модератор
  • Итак, проблема решилась.

    Проанализировав логи dhcp насчитал 544 уникальных IP-адреса, не принадлежащих моей подсети, которым было отказано в течение одного дня! На частные ноутбуки это не похоже. С помощью wireshark и какой-то матери определил, что сервер засыпают dhcp запросами из других подсетей. Внимательно глянув на MAC тех сетей и увидев, что они совершенно разнородны (в частности, глаз упал на MAC, принадлежащий apple, а ни одного apple-устройства у меня в сети нет) пришло в голову, что это может быть пробой периметра сети. Подумав и сопоставив время начала этой белиберды вспомнил, что где-то в это же время я ввел в строй новый филиал, связь с которым осуществляется по L2 VPN каналу от нового провайдера (раньше мы с ним не работали). Ради эксперимента отключил аплинк этого канала, и... О ЧУДО! Запросы прекратились, и всё нормализовалось. Однозначно ясно, что напортачил провайдер. Сейчас с ним разбираюсь. А DHCP, скорее всего, именно из-за чужого RRAS забивался.

    Огромное всем спасибо за участие и помощь, особенно Dmitry Nikitin, за его наводку прослушать тафик (почему сам сразу этого не сделал - ума не приложу, видимо переклинило).

Все ответы

  • Вопрос: как такое может быть и куда делись еще 10 адресов
    RRAS используете? (удалённый доступ)
    Отвечающий
  • При пинге пропавших адресов, какой ответ получаете ?
  • RRAS не используем, используем только PPTP на линуксовом сервере без авторизации в домене
  • Адреса не используются. На пинги не отзываются, в ARP таблицах коммутаторов и маршрутизаторов не засвечивались.
  • Вот PPTP у Вас и забрал 10 адресов для подключения удаленных VPN клиентов.
    One of the "unexpected" features of RRAS and DHCP occurs when the RRAS service
    is configured and started. Assuming the DHCP server is available, it reserves
    blocks of 10 IP's for the VPN clients, with the first IP being assigned to the
    RRAS server itself. If enough VPN clients connect simultaneously to exceed the
    10 reservations, another block of 10 IP's is added.

    http://msmvps.com/blogs/robwill/archive/2008/05/09/rras-dhcp-options.aspx

    Отвечающий
  • Еще раз повторюсь: PPTP организован на ЛИНУКСОВОМ сервере, авторизация на нем организована средствами демона pptpd, без использования домена вообще. IP адреса выдаются не по dhcp, а из отдельного пула (не пересекается с пулом DHCP). И клиентов pptp значительно больше, чем весь пул DHCP.
  • Вот PPTP у Вас и забрал 10 адресов для подключения удаленных VPN клиентов.
    One of the "unexpected" features of RRAS and DHCP occurs when the RRAS service
    is configured and started. Assuming the DHCP server is available, it reserves
    blocks of 10 IP's for the VPN clients, with the first IP being assigned to the
    RRAS server itself. If enough VPN clients connect simultaneously to exceed the
    10 reservations, another block of 10 IP's is added.

    http://msmvps.com/blogs/robwill/archive/2008/05/09/rras-dhcp-options.aspx

    Черт! Нашел, что второй админ на этом сервере начал настройку Radius и установил роль RRAS! Она недонастроена, VPN (как, собственно и RADIUS) не включен, однако именно он, по всей логике, 10 IP адресов резервирует. Попробую его отключить.
  • попробуйте сделать на скопе Reconcile...

    Модератор
  • попробуйте сделать на скопе Reconcile...

    После согласования появились 14 IP-адресов, которые зарезервированы неизвестно-кем (вместо MAC адреса стоит 3139322e3136382e312e32303#00 или 3139322e3136382e312e31393#00, где # - изменяющееся число). Удаляются, но тут же восстанавливаются
  • Удаление роли RRAS не помогло.

    И адресов стало уже 15! После согласования и удаления все они появляются снова, с обновленным сроком истечения аренды.

    • Изменено ReMaster 15 мая 2013 г. 19:16
  • audit logging на dhcp включен? если нет, то включите и посмотрите что происходит
    Модератор
  • audit logging на dhcp включен? если нет, то включите и посмотрите что происходит

    Включен. В DhcpSrvLog-###.log ничего такого не указано. Только очень большое количество отказов в выдаче и информация об удалении мной адресов, появившихся после согласования:

    16	15.05.2013	22:56:04	Удалена	192.168.1.196		3139322E3136382E312E31393600
    16	15.05.2013	22:56:04	Удалена	192.168.1.197		3139322E3136382E312E31393700
    16	15.05.2013	22:56:04	Удалена	192.168.1.198		3139322E3136382E312E31393800
    16	15.05.2013	22:56:04	Удалена	192.168.1.199		3139322E3136382E312E31393900
    16	15.05.2013	22:56:04	Удалена	192.168.1.200		3139322E3136382E312E32303000
    16	15.05.2013	22:56:04	Удалена	192.168.1.201		3139322E3136382E312E32303100
    16	15.05.2013	22:56:04	Удалена	192.168.1.202		3139322E3136382E312E32303200
    16	15.05.2013	22:56:04	Удалена	192.168.1.203		3139322E3136382E312E32303300
    16	15.05.2013	22:56:04	Удалена	192.168.1.204		3139322E3136382E312E32303400
    16	15.05.2013	22:56:04	Удалена	192.168.1.205		3139322E3136382E312E32303500
    16	15.05.2013	22:56:04	Удалена	192.168.1.206		3139322E3136382E312E32303600
    16	15.05.2013	22:56:04	Удалена	192.168.1.207		3139322E3136382E312E32303700
    16	15.05.2013	22:56:04	Удалена	192.168.1.208		3139322E3136382E312E32303800
    16	15.05.2013	22:56:04	Удалена	192.168.1.209		3139322E3136382E312E32303900
    16	15.05.2013	23:13:18	Удалена	192.168.1.189		3139322E3136382E312E31383900
    Кстати, эти безумные "уникальные коды" вместо mac адресов - это всего лишь hex ascii ip-адресов с двумя знаками вопроса на конце, то есть "3139322E3136382E312E31393600" - это "192.168.1.196??" 

    Правда, очень напрягает, что отказы в выдаче идут на ip адреса из подсетей, которых нет в моей организации. Но это тема другого поста.
    • Изменено ReMaster 16 мая 2013 г. 6:02
  • а чей это адрес?

    Модератор
  • Ничей, это те адреса, которые появляются в списке арендованных только после согласования. Они никому не выданы. В сети таких ip нет. 
  • Какие еще сервисы, кроме RRAS могут резервировать для себя адреса DHCP?
  • Неправославный демон pptpd ?

    Отвечающий
  • Исключено. Эта система в спарке работает уже больше трех лет, а глюки с ip адресами начались совсем недавно. Плюс настройки у pptpd идеальные, проверял несколько раз. Он вообще dhcp не использует.
  • запускайте network monitor или другой сниффер и смотрите откуда и куда идут dhcp запросы содержащие эти адреса

    • Помечено в качестве ответа AndricoRusEditor 16 мая 2013 г. 10:29
    Модератор
  • Кто-то у Вас в сети отвечает на запросыARP по этим адресам. Смотрите в таблице ARP (команда arp -a) на сервере c DHCP MAC-адрес этого компьютера/устройства.

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

    PS Отмеченный ответ явно не служит решением проблемы. Господа отвечающие, уберите свою отметку.


    Слава России!




    • Изменено M.V.V. _ 16 мая 2013 г. 9:42
  • Итак, проблема решилась.

    Проанализировав логи dhcp насчитал 544 уникальных IP-адреса, не принадлежащих моей подсети, которым было отказано в течение одного дня! На частные ноутбуки это не похоже. С помощью wireshark и какой-то матери определил, что сервер засыпают dhcp запросами из других подсетей. Внимательно глянув на MAC тех сетей и увидев, что они совершенно разнородны (в частности, глаз упал на MAC, принадлежащий apple, а ни одного apple-устройства у меня в сети нет) пришло в голову, что это может быть пробой периметра сети. Подумав и сопоставив время начала этой белиберды вспомнил, что где-то в это же время я ввел в строй новый филиал, связь с которым осуществляется по L2 VPN каналу от нового провайдера (раньше мы с ним не работали). Ради эксперимента отключил аплинк этого канала, и... О ЧУДО! Запросы прекратились, и всё нормализовалось. Однозначно ясно, что напортачил провайдер. Сейчас с ним разбираюсь. А DHCP, скорее всего, именно из-за чужого RRAS забивался.

    Огромное всем спасибо за участие и помощь, особенно Dmitry Nikitin, за его наводку прослушать тафик (почему сам сразу этого не сделал - ума не приложу, видимо переклинило).