DHCP + static mapping



  • Давно обращал внимание что DHCP как-то глючно работает, поставил статический IP на клиентской машине и отмахнулся таким образом от решения проблемы. Но вот недавно обнаружил у себя на компе статические настройки сетевушки, возмутился, поставил "получать автоматически" после чего сеть пропала через некоторое время. Полез в логи, начал искать намёки на проблему методом тыка.
    В итоге обнаружил, что если удалить мапинг из таблицы static mapping, то сетевушка исправно получает очередной свободный адрес из заданного диапазона (.50-.100). Если в настройках DHCP задать для её мак-адреса конкретный ip-адрес (.10), то она уходит в задумчивость на несколько минут и в итоге остаётся со случайным мусорным адресом.
    Происходит это обычно так (заходим в сетевые подключения и вместо статического адреса выбираем "получать автоматически", или с включённым DHCP отключаем сетевушку и включаем снова - не помню точно к какому из этих двух случаев относится):

    (дельше повторяется DHCPINFORM-DHCPACK)
    Mar 21 22:26:42	dhcpd: DHCPACK to 192.168.1.10 (00:1b:fc:79:72:dc) via re0
    Mar 21 22:26:42	dhcpd: DHCPINFORM from 192.168.1.10 via re0
    Mar 21 22:26:37	dhcpd: DHCPACK to 192.168.1.10 (00:1b:fc:79:72:dc) via re0
    Mar 21 22:26:37	dhcpd: DHCPINFORM from 192.168.1.10 via re0
    Mar 21 22:26:33	dhcpd: DHCPACK to 192.168.1.10 (00:1b:fc:79:72:dc) via re0
    Mar 21 22:26:33	dhcpd: DHCPINFORM from 192.168.1.10 via re0
    Mar 21 22:26:31	dhcpd: DHCPACK on 192.168.1.10 to 00:1b:fc:79:72:dc via re0
    Mar 21 22:26:31	dhcpd: DHCPREQUEST for 192.168.1.10 (192.168.1.1) from 00:1b:fc:79:72:dc via re0
    Mar 21 22:26:31	dhcpd: DHCPOFFER on 192.168.1.10 to 00:1b:fc:79:72:dc via re0
    Mar 21 22:26:31	dhcpd: DHCPDISCOVER from 00:1b:fc:79:72:dc via re0
    Mar 21 22:26:25	dhcpd: DHCPACK on 192.168.1.10 to 00:1b:fc:79:72:dc via re0
    Mar 21 22:26:25	dhcpd: DHCPREQUEST for 192.168.1.10 from 00:1b:fc:79:72:dc via re0
    Mar 21 22:26:25	dhcpd: DHCPACK to 192.168.1.10 (00:1b:fc:79:72:dc) via re0
    Mar 21 22:26:25	dhcpd: DHCPINFORM from 192.168.1.10 via re0
    

    А так происходит если уже настроенную на DHCP сетевушку отключить, выдернуть провод, включить сетевушку, воткнуть провод:

    (адрес сетевушкой получен)
    Mar 21 23:43:32	dhcpd: DHCPACK on 192.168.1.10 to 00:1b:fc:79:72:dc via re0
    Mar 21 23:43:32	dhcpd: DHCPREQUEST for 192.168.1.10 from 00:1b:fc:79:72:dc via re0
    Mar 21 23:43:32	dhcpd: DHCPACK on 192.168.1.10 to 00:1b:fc:79:72:dc via re0
    Mar 21 23:43:32	dhcpd: DHCPREQUEST for 192.168.1.10 from 00:1b:fc:79:72:dc via re0
    Mar 21 23:40:19	dhcpd: DHCPACK on 192.168.1.10 to 00:1b:fc:79:72:dc via re0
    Mar 21 23:40:19	dhcpd: DHCPREQUEST for 192.168.1.10 (192.168.1.1) from 00:1b:fc:79:72:dc via re0
    Mar 21 23:40:19	dhcpd: DHCPOFFER on 192.168.1.10 to 00:1b:fc:79:72:dc via re0
    Mar 21 23:40:19	dhcpd: DHCPDISCOVER from 00:1b:fc:79:72:dc via re0
    
    

    Обращаю внимание: адрес получен спустя 3,5 минуты (!!!) после начала процедуры. Причем сетевушка адрес может и не получить!

    Примерно так же ведут себя другие компы с Win 7-8. Но роутер LinkSys, которому адрес тоже прописан в таблице, получает постоянно один и тот же адрес без лишних расшаркиваний в течении секунды(!!!):

    Mar 21 23:36:12	dhcpd: DHCPACK on 192.168.1.15 to 00:11:95:5c:49:57 via re0
    Mar 21 23:36:12	dhcpd: DHCPREQUEST for 192.168.1.15 (192.168.1.1) from 00:11:95:5c:49:57 via re0
    Mar 21 23:36:12	dhcpd: DHCPOFFER on 192.168.1.15 to 00:11:95:5c:49:57 via re0
    Mar 21 23:36:12	dhcpd: DHCPDISCOVER from 00:11:95:5c:49:57 via re0
    
    

    В чём проблема? Почему комп не может получить всё что надо от DHCP-сервера в течении секунды так же быстро, как это делает роутер LinkSys?



  • Я понял в чём дело. У меня на всех комах стоит Dr. Web с фаерволом. Несмотря на то что в фаерволе по-умолчанию стоит разрешение на 67 и 68 порты для svchost, он почему-то блокируется (выяснилось отключением фаервола). Разрешил для svchost любую сетевую активность и всё заработало на всех машинах.



  • Нет, разрешить любую активность для svchost было мало. Выдача параметров по DHCP как работала через раз, так и продолжила. Но открытие 67 удалённого порта и 68 локального в пакетном фильтре решило проблему. Даже с правилом по-умолчанию для svchost.
    Так что если у кого-то стоит Dr.Web с фаерволом и не работает DHCP - есть решение! Оно не лежит на поверхности, поэтому разжую подробно:
    1. брэндмауер - настройки - интерфейсы
    2. выбираем нужный нам (сетевую карту через которую подключаемся) и жмём "настроить"
    3. становимся на "defaul rule" и копируем его (на всякий случай, чтобы не править дефолтное)
    4. становимся на "defaul rule (1)" и жмём "изменить"
    5. в открывшемся окне жмём "создать"
    6. даём название правилу, например "DHCP". Действие - резрешать. Направление - любое. Журналирование - заголовки. Критерий - UDP, жмём "добавить". Локальный порт 68, удалённый порт - 67.
    7. Везде жмём "ОК".
    После этого для svchost можно вернуть разрешения "по умолчанию" (т.е. тип правила "особый") и будет работать - у меня уже несколько дней как полёт нормальный.



  • Всегда перед манипуляциями с сетью отключаю все брендмауэры - от родного микрософтовского до любых сторонних. Всегда.


Locked