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

[amarao]

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

[Mur81]

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

[selivanov_pavel]

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

[Mur81]

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

[amarao]

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

[amarao]

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

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

[Mur81]

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

[amarao]

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

[alexanster]

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

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

[zurapa]

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

[Mur81]

Можно еще добавить:
/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]

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

[Mur81]

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

[avelor]

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

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

[Mur81]

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

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

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

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

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

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

[avelor]

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

[remzalp]

Возможно, что микротик не блочит трафик, источником которого является он сам.
Например, 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]

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

[avelor]

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

[TaHKucT]

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

[martin74ua]

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

[Victor_koly]

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

[martin74ua]

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

[avelor]

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

[martin74ua]

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]

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