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 адресов исчерпан. Посчитал по факту: 28 ноутбуков с Wi-Fi, плюс 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 недели — всё повторяется снова.

Я решил копнуть глубже. Открыл DHCP Manager на Windows Server, где был настроен DHCP, и стал смотреть резервации. Резервация для принтера, конечно, была создана, но MAC-адрес был записан как 00-1C-A8-3F-5B-22. А реальный MAC принтера был 00:1C:A8:3F:5B:22 — то есть, с двоеточиями вместо дефисов. Точнее, с двоеточиями он отображался только в выводе самого принтера, а 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 проходит

В другой раз звонит IT-директор торговой компании: у них 35 ПК, два этажа, между которыми стоит коммутатор Mikrotik CRS112. Проблема такая: «Один отдел никак не может подключиться к 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 руб. в зависимости от сложности инфраструктуры.