DHCP + static mapping

AnDrEyKa

Давно обращал внимание что 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?

AnDrEyKa

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

AnDrEyKa

Нет, разрешить любую активность для 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 можно вернуть разрешения "по умолчанию" (т.е. тип правила "особый") и будет работать - у меня уже несколько дней как полёт нормальный.

werter

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