DHCP в офисной сети до 50 рабочих мест: типовые проблемы и как их чинить

Меня зовут Семёнов Евгений Сергеевич, я директор АйТи Фреш. За 15 лет обслуживания офисов в Москве и Подмосковье я повидал примерно всё, что может пойти не так с DHCP в небольшой корпоративной сети. В этой статье — конкретные кейсы из практики обслуживания офисов от 10 до 50 рабочих мест, что именно ломается, как это диагностируется за 5 минут и как чинится так, чтобы больше не повторялось.

Почему DHCP-проблемы в офисе — частая причина простоев

В большинстве офисов на 10-50 ПК сетевая инфраструктура выглядит примерно одинаково: провайдерский ввод приходит на роутер уровня Mikrotik или Keenetic, дальше управляемый или неуправляемый коммутатор, дальше рабочие станции и принтеры. DHCP-сервер крутится либо прямо на роутере, либо на Windows Server, если есть домен Active Directory.

Проблема в том, что «работает — не трогай» — это плохая стратегия для DHCP. Конфигурация, написанная пять лет назад, может прекрасно работать ровно до того момента, пока в офисе не появится 35-й сотрудник, для которого в пуле уже не осталось адресов. Или пока кто-то не воткнёт второй роутер «для Wi-Fi гостям» и тот не начнёт раздавать свой DHCP параллельно. У меня в практике десятки таких историй, и ни одна из них не кончалась автоматически — всегда нужен инженер.

Случай первый: «у нас половина ПК не выходит в интернет с утра»

Звонок в 9:30 от клиента — юридическая фирма, 28 рабочих мест в офисе на Цветном бульваре. Утром половина сотрудников жалуется, что не работает 1С, не открывается почта, в браузере «нет подключения к сети». При этом другая половина работает нормально.

Подключаюсь удалённо к рабочей станции одного из жалующихся, открываю командную строку и сразу вижу диагноз:

C:\> ipconfig /all

Ethernet adapter Ethernet:
   IPv4-адрес. . . . . . . . . . . : 169.254.218.33
   Маска подсети . . . . . . . . . : 255.255.0.0
   Основной шлюз . . . . . . . . . :

Адрес 169.254.x.x — это APIPA (Automatic Private IP Addressing), Windows присваивает его, когда не получает ответ от DHCP-сервера. Сразу понятно: проблема в DHCP, а не в сети целиком. Дальше нужно разобраться, почему сервер не отвечает.

Подключаюсь к Mikrotik, который у этого клиента работает DHCP-сервером для всего офиса. В разделе IP → DHCP Server → Leases вижу 254 активные привязки. Лезу в настройки пула: range 192.168.1.50–192.168.1.250. То есть пул на 200 адресов исчерпан. Посчитал по факту: ноутбуков с Wi-Fi у сотрудников 28, плюс рабочие станции 28, плюс смартфоны личные 28, плюс принтеры, видеонаблюдение, IP-телефоны — суммарно за рабочий день в сети живёт 80-90 устройств. Lease time стоял 7 суток, и за неделю в пуле «застревают» в три раза больше адресов, чем нужно.

Решение заняло 10 минут:

• Расширил пул до 192.168.1.20–192.168.1.250 (добавил 30 адресов);
• Сократил lease time с 7 дней до 8 часов — за ночь пул полностью обновляется;
• Очистил вручную старые lease, чтобы освободить адреса немедленно;
• Все жалующиеся сотрудники перезапустили сетевой адаптер — заработало.

А потом я полчаса объяснял IT-директору, что в современном офисе на каждое рабочее место надо закладывать минимум 4 IP-адреса, а не 1.

Случай второй: «мы поставили Wi-Fi от Beeline, и упала вся сеть»

Производственная компания в Подольске, 22 рабочих места плюс цех с терминалами. Звонок: «Мы вчера попросили монтажников Билайна поставить нам гостевой Wi-Fi, они принесли свой роутер и подключили. Сегодня вся локалка валится, 1С не работает, принтеры не печатают.»

Приехал на место, подключился к одной из проблемных машин. Картина: ipconfig показывает IP 192.168.100.45 вместо привычного 10.0.10.x. То есть машина получила адрес от чужого DHCP-сервера, который раздаёт свой собственный диапазон. И таких машин — половина офиса.

Это классический случай «rogue DHCP» — несанкционированный DHCP-сервер в сети. Когда клиент посылает Discover-запрос (broadcast), отвечает тот сервер, чей ответ пришёл первым. Если в одной сети два DHCP-сервера, и они не согласованы — IP раздаются хаотично, пользователи получают шлюз и DNS из чужой подсети, доступ к корпоративным сервисам пропадает.

Найти rogue-сервер в небольшой сети просто:

# С Windows-машины, которая получила «не тот» IP:
C:\> ipconfig /all | findstr "DHCP-сервер"
DHCP-сервер. . . . . . . . . . . : 192.168.100.1

# Этот IP ведёт на тот самый «лишний» роутер.
# Идём в серверную, ищем железку с этим адресом.

В нашем случае оказалось, что монтажники Билайна не настроили роутер в режиме «точка доступа», а воткнули его как обычный роутер с включенным DHCP. Решение — выключил DHCP на новом роутере, перевёл его в режим Access Point, всё сразу заработало. На объяснение IT-директору, что любое сетевое оборудование в офисе должно проходить через нас, ушло ещё час.

Случай третий: принтер «слетает» с резервации каждые две недели

Бухгалтерия одной из обслуживаемых компаний на Курской. Сетевой принтер Kyocera, на нём настроена прописка в 1С с фиксированным IP-адресом 10.0.10.50. Каждые 2-3 недели бухгалтер звонит: «Принтер не печатает!» Захожу — у принтера IP 10.0.10.187, а в 1С прописан 10.0.10.50. Меняю на принтере IP вручную, печатает. Через 2 недели — снова.

Полез разбираться. На Windows Server, где настроен DHCP, открыл DHCP Manager, посмотрел резервации. Резервация для принтера была создана, но MAC-адрес был записан как 00-1C-A8-3F-5B-22, а реальный MAC принтера — 00:1C:A8:3F:5B:22 (двоеточия вместо дефисов). Точнее, реальный MAC был с двоеточиями только в выводе принтера, а Windows Server резервации хранил с дефисами. Но в этой конкретной строке кто-то когда-то ввёл MAC с одним дефисом и одним двоеточием, и Windows воспринял её как невалидную, но не выдал ошибку, а просто проигнорировал.

Это типовая проблема: формат MAC-адреса. Разные системы используют разные разделители:

• Windows Server DHCP: 00-1C-A8-3F-5B-22 (дефисы);
• Mikrotik, большинство Linux: 00:1C:A8:3F:5B:22 (двоеточия);
• Cisco, некоторые принтеры: 001C.A83F.5B22 (точки);
• Принтеры HP в самодиагностике: 001CA83F5B22 (без разделителей).

Когда копируешь MAC из одной системы в другую, важно привести к нужному формату. Я для себя завёл шаблон-проверку: после создания резервации обязательно перезапускаю интерфейс на устройстве и смотрю, какой IP оно получило. Если не тот, который зарезервирован — значит, MAC написан неправильно.

Случай четвёртый: домен 1С не находит сервер, хотя ping проходит

Торговая компания, 35 ПК, два этажа, между этажами стоит коммутатор Mikrotik CRS112. Звонок от IT-директора: «Один отдел не может подключиться к 1С. Сервер пингуется по IP, но по имени не находится.» Запах DNS сразу, но я для надёжности проверяю DHCP — оказывается, сервер DHCP на одном из коммутаторов VLAN раздаёт неправильные DNS-серверы. В настройках указан старый адрес контроллера домена, который мы поменяли месяц назад при замене железа. На основной сетке всё было обновлено, а на этом VLAN-е — забыли.

Это типичная ловушка: в офисе с двумя или тремя VLAN-ами (например, основная сеть, гостевой Wi-Fi, видеонаблюдение) DHCP настроен в трёх местах. При замене сервера DNS обновили в двух из трёх. Третий VLAN живёт со старыми настройками неделями, пока кто-нибудь не подключится.

Чек-лист, который я теперь требую от всех клиентов с несколькими VLAN-ами: при изменении любого инфраструктурного сервиса (DC, DNS, шлюз) — обновить DHCP во всех точках, где он настроен. У нас в АйТи Фреш для этого ведётся таблица в Confluence, где для каждого клиента перечислены все DHCP-сервера и их параметры. Перед сдачей задачи инженер проходит по таблице галочками.

DHCP на Mikrotik vs Windows Server: что выбрать для офиса до 50 ПК

Часто слышу вопрос «А на чём лучше держать DHCP — на роутере или на сервере?». Ответ зависит от размера офиса и от того, есть ли у вас Active Directory.

Моя рекомендация для большинства клиентов: если в офисе до 20 ПК и нет домена — оставляем DHCP на роутере. Если есть Active Directory или больше 25 рабочих мест — переносим на сервер. Это делается за 1-2 часа: создаётся область DHCP, переносятся резервации, выключается DHCP на роутере.

Чек-лист правильно настроенного DHCP в офисе

На основе своего опыта собрал список того, что должно быть настроено в DHCP в офисе до 50 рабочих мест, чтобы потом не было сюрпризов:

1. Пул адресов с запасом 50%. Если у вас 30 ПК, в пуле должно быть минимум 60 адресов — учитывайте смартфоны, ноутбуки, принтеры, гостевые подключения.
2. Lease time 8-12 часов. Сутки и больше — лишнее, адреса застревают за уволенными сотрудниками. Меньше 4 часов — лишняя нагрузка на DHCP, особенно если у вас Wi-Fi с роумингом.
3. Резервации для всего ключевого. Принтеры, NAS, IP-камеры, VoIP-телефоны, серверы — у всего должны быть фиксированные IP по MAC. Не статика на устройстве, а именно резервация в DHCP.
4. Правильный DNS. Если есть AD — DNS-серверы это контроллеры домена. Если нет AD — Яндекс DNS 77.88.8.8 / 77.88.8.1 или провайдерские. Никогда не Google 8.8.8.8 для корпоративной сети — это подсветит вас в логах провайдера.
5. Опция 6 (DNS) и опция 15 (domain name). domain name = имя AD-домена, чтобы клиенты могли резолвить короткие имена.
6. Запрет неавторизованных DHCP в сети. На управляемых коммутаторах включается DHCP Snooping — все DHCP-ответы блокируются на портах, кроме того, где стоит «правильный» сервер.
7. Бэкап конфигурации DHCP. На Mikrotik — еженедельный экспорт /ip dhcp-server export в Git. На Windows Server — резервная копия базы DHCP (%SystemRoot%\System32\dhcp\backup) в составе бэкапа.
8. Документация в Confluence или в Excel. Какие пулы, какие резервации, какие опции — всё это должно быть записано, иначе через год никто не вспомнит.

Как мы в АйТи Фреш предотвращаем DHCP-инциденты у клиентов

За 15 лет работы я понял, что 90% DHCP-проблем у клиентов решается не реактивно (когда позвонили и плачут), а проактивно — мониторингом и правильной первоначальной настройкой. У нас в АйТи Фреш для каждого клиента на абонентском обслуживании настроены три уровня защиты:

• Мониторинг загрузки пула. Через Zabbix снимаем метрику «свободных адресов в пуле» каждые 5 минут. Если пул заполнен более чем на 80% — алерт инженеру в Telegram.
• Аудит rogue DHCP. Скрипт раз в час сканирует сеть с тестовой машины, отправляет DHCP Discover и проверяет, отвечает ли только наш сервер. Если приходит ответ от чужого DHCP — сразу алерт.
• Документация в актуальном состоянии. При любом изменении DHCP инженер обязан обновить запись в Confluence. На сдаче задачи это проверяется руководителем смены.

Стоит это для клиента ровно ноль рублей сверху — всё включено в стандартную абонентку. Зато количество ночных звонков «у нас встала сеть» снижается до одного-двух в год вместо одного-двух в месяц.

FAQ — частые вопросы по DHCP в офисе

Почему компьютер не получает IP-адрес от DHCP?

Чаще всего причины три: пул адресов исчерпан, провод не подключён к нужному VLAN-у, или роутер выдаёт DHCP-ответ медленнее, чем Windows ждёт. Проверяется через ipconfig /all и логи DHCP-сервера на роутере или Windows Server.

Можно ли держать два DHCP-сервера в офисе?

Можно, но только в режиме failover (Windows Server 2012+) или split-scope. Если просто включить два DHCP без согласования — будут выдаваться конфликтующие адреса, и часть устройств перестанет работать в сети.

Что лучше — DHCP на роутере или на Windows Server?

До 30 ПК достаточно DHCP на роутере уровня Mikrotik или Keenetic. От 30 рабочих мест и выше, особенно при наличии Active Directory, лучше переносить DHCP на Windows Server — это даёт интеграцию с DNS, аудит, удобные резервации по MAC.

Почему IP, выданный по резервации, не применяется?

Чаще всего опечатка в MAC-адресе резервации (формат с дефисами вместо двоеточий или наоборот) или старая lease у клиента. Решение: проверьте формат MAC, выполните ipconfig /release && ipconfig /renew на клиенте.

Сколько стоит настройка DHCP в офисе под ключ?

В рамках абонентского обслуживания АйТи Фреш — бесплатно. Разовая настройка DHCP на Windows Server с резервациями для 30-50 устройств обходится в 8 000-15 000 руб. в зависимости от сложности инфраструктуры.