Tri-Edge Sep 13 2019 at 15:05

[Конспект админа] Как подружиться с DHCP и не бояться APIPA

10 min

113K

СЕРВЕР МОЛЛ corporate blogInformation Security*System administration*

+14

Comments 26

amarao Sep 13 2019 at 16:28

Я всё ещё считаю dhcp самым неприятным сетевым сервисом. Основная причина: большинство сетевых сервисов заканчивают свой эффект на сеть в момент своего выключения. Слал фигню по всем портам? Выключил, прошло. У dhcp всё наоборот — слать-то он особо не шлёт, а вот пост-эффекты от него остаются огромные (представьте себе lease в 365 дней), причём невоспроизводимые (железка получила адрес — железка счастлива и больше адрес просто так не просит до наступления T1). Т.е. вместо stateless network мы, внезапно, получаем stateful network. А что мы любим больше, чем state? Его наличие!

Mur81 Sep 13 2019 at 20:15

Поставьте lease time в пару минут.

selivanov_pavel Sep 13 2019 at 20:52

Имеются в виду проблемы после появления в сети некорректно настроенного или вообще левого сервера(воткнули не ту железку не туда). Понятно, что обычно lease time ставят не 365 дней.

Mur81 Sep 13 2019 at 20:59

Это конечно скорее сарказм был (но только от части).
Вот не знаю, никогда никакой проблемы в DHCP не видел. Я склонен так думать, что если что-то по неосторожности воткнули или не так настроили, то это и с кучей других технологий может случится с последствиями не менее неприятными. Ну а от злого умысла в сетях с оборудованием классом повыше SOHO всякие защиты есть. Тот же DHCP Snooping или алерты. Ну а в сетях с SOHO это просто никому не нужно/не интересно.

amarao Sep 16 2019 at 14:20

Просто признаемся, что dhcp оставляет state. После этого с ним надо работать как с распределённым stateful сервисом, а это совсем другой класс систем, чем (условный) http сервер или кривой роут на маршрутизаторе.

amarao Sep 16 2019 at 14:18

… И вот это как раз восторг. Вот у меня случилась фигня и я раздал lease'ы на 365 дней. Я спохватился и поставил 2 минуты.

Через какое время сеть придёт в себя?

Mur81 Sep 16 2019 at 18:27

Я в целом не спорю. Но, как я выше написал уже, это человеческий фактор. С ним можно много где наворотить. Скажем ткнуть патчкорд двумя концами в коммутатор. Веселья будет не меньше.

amarao Sep 16 2019 at 18:38

Смотрите за руками: патч-корд вынимается и всё проходит. Кривой dhcp выключается… и приключения в сети продолжаются.

alexanster Sep 13 2019 at 22:57

железка счастлива и больше адрес просто так не просит до наступления T1

справедливости ради — до наступления T1/2 или пока не перезагрузится, но тут уже на совести разработчиков — насколько точно реализовали IP стек.
А ещё есть экзотический DHCPFORCERENEW, только не знаю, насколько широко реализована его поддержка клиентами.

zurapa Jul 11 2021 at 11:10

Ещё мне интересно было бы узнать ваше мнение по поводу идущего дождя или дующего сильного ветра.

Mur81 Sep 13 2019 at 20:08

Можно еще добавить:
/ip dhcp-server option
add code=43 name=Disable-NetBIOS value=0x010400000002

Отключение NetBIOS. Для безопасности.

От случайно появившихся в сети левых DHCP-серверов в том же Микротике есть алерт:
/ip dhcp-server alert
add disabled=no interface=bridge-LAN

Tri-Edge Sep 13 2019 at 22:08

Спасибо, полезное дополнение!

Mur81 Sep 13 2019 at 20:12

Кстати пользуясь случаем хочу спросить. Может кто-нибудь знает почему микротиковский DHCP сервер вполне себе функционирует даже если в файрволе в цепочке input полностью закрыть протокол UDP?
Техподдержка ответила что-то в духе «это не баг, а фича».

avelor Sep 13 2019 at 22:25

было предположение, что в микротах dhcp это некая отдельная сущность, которая (возможно) использует BPF (Berkley Packet Filter) — и запросы к нему идут в обход фаервола. а-ля как подключение винбоксом по маку, которое не заблочить фаерволом (только в /tool mac-server mac-winbox)

но заблокировать dchp-трафик можно — через bridge filter. только что сам проверил

Mur81 Sep 16 2019 at 18:35

было предположение, что в микротах dhcp это некая отдельная сущность...

Интересное предположение. Увидеть бы это на Traffic Flow…

а-ля как подключение винбоксом по маку

Это вроде как немного другое, т.к. в этом случае работа на L2 идёт.

но заблокировать dchp-трафик можно — через bridge filter

Вот про это не знал, спасибо.

avelor Sep 16 2019 at 18:39

>Увидеть бы это на Traffic Flow…
я тоже не нашёл(
>Это вроде как немного другое
ну тут они тоже говорят, что это не баг а фишка — чтоб ты не залочил себя. подозреваю что принцип схож — броадкастовый запрос\мультикастовый ответ — но я трафик не сниффал…

remzalp Sep 16 2019 at 08:20

Возможно, что микротик не блочит трафик, источником которого является он сам.
Например, ACL у Cisco не блокируют трафик, источником которого является сам роутер, потому что трафик является доверенным и сделано для увеличения производительности.

с форума: ...Traffic that is generated by the router/switch itself is trusted and is not subject to filtering by access lists on the interface…

Mur81 Sep 16 2019 at 18:40

На Микротике в принципе файрвол нормально открытый. Если ничего не трогать в цепочке output (это исходящий трафик как раз), то там ничего не блокируется, это да.
Но дело в том, что если в цепочке input (входящий трафик) заблокировать UDP протокол, то теоретически DHCP сервер не должен получать запросы и, соответственно, отвечать на них (раздавать адреса). Но нехитрый эксперимент показывает, что этот запрет ему побоку.

avelor Sep 16 2019 at 18:41

не вписывается — потому что в теории если мы блочим цепочку input, то не должны приходить запросы к DHCP. но раз он выдаёт ответы — то запросы проходят. интересно, что ip filter тут бессилен, в отличие от bridge filter.

TaHKucT Sep 16 2019 at 21:29

Если предположить что внутри живёт Linux ядро и что dhcp сервер реализован так же как в Linux через открытие raw сокета то все становится очевидно. В Linux тоже не фильтруется трафик, который идёт через raw сокет, потому что подсистема tcp/ip в этом процессе просто не участвует

martin74ua Sep 13 2019 at 22:32

вот только моим dhcp серверам не говорите, что просто два работающих dhcp сервера с идентичными настройками приведут к конфликту адресов. а то работают уже лет 15 и работают…

Victor_koly Sep 14 2019 at 00:04

Никак области не разделяли и все хорошо?

martin74ua Sep 14 2019 at 11:01

Никак не разделял.
Два идентичных конфига, около 2к сетей, 90% клиентов имеют фиксированный адрес, для остальных — в каждой сети имеется специальный диапазон. И никаких конфликтов.

avelor Sep 16 2019 at 18:43

>в каждой сети имеется специальный диапазон
а это не синоним разделения областей?

martin74ua Sep 17 2019 at 09:02

subnet 10.1.0.0 netmask 255.255.254.0 {
    option routers 10.1.0.1;
    option subnet-mask 255.255.254.0;

    range 10.1.0.232 10.1.0.248;

# clients

host ilon4ik {
        hardware ethernet 00:24:21:9F:D7:3C;
        fixed-address 10.1.0.2;
        }

host paprika {
        hardware ethernet 00:26:18:BE:46:D0;
        fixed-address 10.1.0.3;
        }
}

Вот такой конфиг загружен на два сервера. конфиг идентичен на обоих. Никаких проблем уже лет 15 как…

selivanov_pavel Sep 14 2019 at 17:34

Скорее всего настроено что-нибудь вроде ping-check, чтобы не выдавать уже существующие в сети адреса. В таком виде работать будет, по крайней мере если все клиенты отвечают на пинг.