Если бы министром интернета был я...

[taki_net]

Удивительно, но проблема множественных DHCP-серверов никем, похоже, никак не решается и никого не волнует.

Напомню, если ваш компьютер (на винде) имеет в настройках сети параметр "получать IP-адрес автоматически" (или такую настройку имеет ваш Ой-Фон, андроед и т.д. - а вот они так настроены просто всегда, у компьютеров есть хотя бы 1 процент исключений) - так вот, если так происходит, то после перезагрузки или подключения к новой сети устройство слушает рассылаемые по сети сигналы от так называемых DHCP-серверов, и поймав сигнал одного из них, соединяется с ним и получает от него данные этой сети: какой адрес свободен и его можно занять, и прочие параметры. После того как ваше устройство соглашается и занимает, по договоренности с DHCP-сервером, свободный адрес в данной сети, процесс подключения к сети заканчивается (именно этот процесс идет, когда после "обнаружены сети" начинает крутиться желтый кружок на индикаторе сети на экране - как видим, довольно длительный процесс и сложный).

Альтернативой является узнать (договориться с администратором) о заведомо свободном адресе, прописать его СТАТИЧЕСКИ в настройки устройства и всегда подключаться с этим адресом. Это крайне неудобно (функции компьютеров передаются людям), фактически ограничивает перечень возможных сетей подключения одной-двумя (то есть для публичных вайфай сетей вообще непригодно), а кроме того, на мобильных устройствах эта настройка часто вообще недоступна.

Так что же не так с прекрасным первым методом? Всё так. Кроме одного: что будет, если в сети окажутся два и более устройств, на которых запущена ПРОГРАММА (напомню, это просто программа) DHCP-сервер? "Правильный" при этом запущен на роутере, и именно пакеты с данными, поступающие от устройств, получивших правильный адрес от него (или статически, как описано выше, но согласованно с роутером) - будут пропускаться сквозь этот роутер наружу, в интернет и т.д. А компьютеры и другие устройства, которые получат от других DHCP-серверов неправильный адрес, будут видеть только друг друга, но не внешний мир или остальную сеть.

Откуда может взяться неправильный DHCP-сервер?

В сети могут быть устройства (например, дополнительные wifi роутеры), на которых DHCP-сервис запускается штатно по умолчанию. Администратор сети должен позаботиться, чтобы на всех, кроме одного, DHCP был отключен. При этом, при аварийном сбросе настроек в заводские легко в цейтноте забыть (при перенастройке такого роутера) о необходимости отключения DHCP. Кроме того, при наличии физического доступа к роутеру "лица с пониженной социальной ответственностью" могут за несколько секунд, простым нажатием спичкой на утопленную кнопочку, организовать сброс параметров роутера.

И, наконец, на любом компьютере под управлением Windows (и, конечно, Linux и, возможно, MacOS) лицо, имеющее права администратора, может запустить службу DHCP случайно или намеренно. И настроить любой пул раздаваемых адресов.

Внимание, ВОПРОС: что мешает за все десятилетия, которые проблема существует и не решается, модифицировать протокол, по которому работает DHCP, позволив включать в широковещательные пакеты, рассылаемые сервером, простой короткий идентификатор (пароль)? И позволить в настройках сети указывать этот пароль, так, чтобы устройство подключалось только к этому DHCP-серверу (а при отсутствии пароля - к любому)? Уже такое примитивное решение (даже без шифрования этих паролей - а можно сделать и это) полностью исключит случайные дублирования сервера и затруднит намеренные.

Comments

[nms]

Zeroconf.

[chabapok]

Это никому ненужно и беспокоит только вас

задача дхсп - чтобы было без кнопочек и без паролей и вообще максимально без ничего.

[ichthuss]

Неправильно. Задача DHCP - вынесение сетевой конфигурации клиентов с собственно клиентов в одну точку, удобную с точки зрения обслуживания сетевых настроек. Использование его "без руля и без ветрил" - лишь один, пусть и популярный, вариант его применения.

[chabapok]

Если придираться к словам.
Но вы тогда тоже путаете цели с средства достижения этих целей.

"Задача DHCP - вынесение сетевой конфигурации клиентов с собственно клиентов в одну точку"
это не задача, это способ достижения цели.
Цель - "удобную с точки зрения обслуживания сетевых настроек"

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

[strangerdiary.livejournal.com]

Какой-то переусложненный вариант решения не самой большой проблемы.

[a-yidisher-poet.livejournal.com]

А для кого существует эта проблема?

[konj-v-paljto.livejournal.com]

несколько лет в саппорте интернет-провайдера.
основные сегменты сети - подсети на 10-200 абонентов с единой ДХЦП-зоной.
Таких сегментов - несколько тысяч.

За несколько лет в саппорте я могу вспомнить, наверное, 3 или 4 случая ДХЦП-флуда в сетях (таки да - просто кабель от провайдера включали в ЛАН-, а не в ВАН-порт роутера).

[konj-v-paljto.livejournal.com]

и, кстати.

в 95% случаев или больше топология сети, в которой работает DHCP-сервер - звезда, где центр зведы - этот сервер и есть.
DHCP-клиент откликается на первый DHCPOffer, пришедший после DHCPRequest.
При топологии "звезда" и сервере в центре звезды в общем-то очевидно, что первым придет оффер от центра звезды, а не от какого-либо другого узла, будь он даже этим узлом отправлен.

Сервер на компьютере с виндой отправит дхцп-оффер новому клиенту через роутер, а не напрямую.
И к моменту получения оффера от "левого" сервера, новый клиент уже получит (и примет) оффер от основного сервера - от роутера. Просто потому что он топологически ближе по сети.

[saccovanzetti.livejournal.com]

извиняюсь за оффтопик(?)

есть такая проблема: старый андроид (эклер) после "сна" в 9 случаях из 10 не может подсоединиться к вайфаю: пытается, но сбрасывает. бесконечно. "раньше такого не было", точка доступа вроде тоже не менялась. после перезагрузки устройства обычно соединяется гораздо веселее. Такое ощущение, что это как-то связано с количеством живых WiFi дивайсов в сети.

[konj-v-paljto.livejournal.com]

обычно лечится в настройках роутера. хотя по разному.
возможно, поможет уменьшение времени аренды айпи-адреса в настройке беспроводной сети, например. Чтобы роутер закреплял адрес за устройством на 3 часа, а не на 48, скажем.
Либо - именно лимиты на количество активных устройств в локальной сети и в вайфай-сети могут стоять на роутере.
Заочно бОльшего не скажу. гадание по юзерпику такое гадание по юзерпику :)

[ichthuss]

По-моему, без изменения сущестчующих протоколов удобнее а) сделать DHCP-клиент, способный принять несколько настроек от разных серверов и протестировать их на предмет наличия интернета, б) дать юзеру возможность выбрать один из полученных вариантов.

[taki-net.livejournal.com]

Тоже метод.

[01petr.livejournal.com]

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

[ichthuss]

К вопросу возможны два подхода: добиваться корректно ситуации, когда в каждом сегменте есть только один дхцп-сервер, либо же сделать так, чтобы работало даже в случае кривых роутеров. В первом случае моё предложение просто не нужно, во втором - ваше замечание не по делу.

[01petr.livejournal.com]

Перечитайте снова всю ветку пожалуйста.
Вы предлагаете тестировать на наличие Интернета и выбирать такие настройки, я же возражаю, что поддельный сервер может обеспечивать доступ в Интернет. Т.е. критерий выбора по наличию доступа в Интернет может быть обманчив.

[ichthuss]

Ну и то? Какой вред в этой ситуации может принести поддельный DHCP-сервер? Если в сетке такой бардак творится, её в любом случае нельзя считать безопасной, даже и через правильный шлюз. А через кого ходят https и vpn, в общем-то, безразлично. Юзеру что надо - чтобы вконтактег бегал, вот и ладушки.

[b0p0h0k.livejournal.com]

ЕМНИП, DHCP server по своей инициативе ничего бродкастом не рассылает.
Наоборот, клиент в поисках адреса шлёт DISCOVER пакет на адрес 255.255.255.255.
И вот тут-то все DHCP серверы на сегменте отвечают пакетом OFFER.
Ну а дальше - лотерея. Чей ответ будет получен раньше, того и тапки.
Да, тут только дисциплиной. Никаких самодеятельных раутеров.

[taki-net.livejournal.com]

Да похер, кто шлет пакет.

[b0p0h0k.livejournal.com]

Вот это посмотрите.
tl/dr: проблема признаётся, но в ближайшем будущем решение не ожидается.

[konj-v-paljto.livejournal.com]

При топологии "звезда" и правильном сервере в центре звезды ответ от правильного примерно всегда придет первым.
любая локалка "по умолчанию" на одном роутере - звезда.

[taki-net.livejournal.com]

Я вежливо не комментирую, но по-моему про звезду ты свистишь.

[kondybas.livejournal.com]

Поскольку DHCP-сервер - это софт, то время ответа этого софта зависит от скорости выполнения кода, каковое время на порядки превышает время свитчирования пакетов. Первым отправит оффер тот сервер, который шустрее, а не тот, который ближе к барицентру сети.

[b0p0h0k.livejournal.com]

TS явно пишет о "дополнительных wifi раутерах", что противоречит вашему умолчанию.
Так что не звезда, а дерево, в каждом нетерминальном узле которого можно ожидать наличие "мусорного" сервера.

Авторизация в Микрософтовских сетях

[vitovtas.livejournal.com]

Александр,

Если Вас интересует, как эта проблема решается на профессиональном уровне, то вот прямая ссылка объясняющая как этот протокол был модифицирован для защищенных сетей - https://technet.microsoft.com/en-us/library/dd296633(v=ws.10).aspx. А что касается публичных сетей - то Вы правы, там каждый действует на свой страх и риск - spoofing attack,DNS spoofing и все прочие прелести, не убавить, не прибавить

Уже придумывали такое. Не так все просто с этим.

[pargentum.livejournal.com]

https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol#Security

Another extension, Authentication for DHCP Messages (RFC 3118), provides a mechanism for authenticating DHCP messages. Unfortunately RFC 3118 has not seen (as of 2002) widespread adoption because of the problems of managing keys for large numbers of DHCP clients.[25] A 2007 book about DSL technologies remarked that "there were numerous security vulnerabilities identified against the security measures proposed by RFC 3118. This fact, combined with the introduction of 802.1x, slowed the deployment and take-rate of authenticated DHCP, and it has never been widely deployed."[26] A 2010 book notes that "[t]here have been very few implementations of DHCP Authentication. The challenges of key management and processing delays due to hash computation have been deemed too heavy a price to pay for the perceived benefits."[27]

More recent (2008) architectural proposals involve authenticating DHCP requests using 802.1x or PANA (both of which transport EAP).[28] An IETF proposal was made for including EAP in DHCP itself, the so-called EAPoDHCP;[29] this does not appear to have progressed beyond IETF draft level, the last of which dates to 2010.[30]

[kondybas.livejournal.com]

PPPoE

[Шаманов Алексей (from livejournal.com)]

1) DHCP - СТАРЫЙ протокол. Он пришел из тех времен, когда о "безопасности", "аутентификации" и прочем-разном никто, в общем-то, не думал. /Та же проблема (Только в куда более серьёзных масштабах) есть, например, у SMTP - ПОЛНОНОЕ отсутствие какой-либо защиты на уровне дизайна протокола - спам, вирусы - вот это все./
2) DHCP - простой и, что даже более важно - _удобный_ как на стороне администратора, так и на стороне пользователя протокол.
3) Как следствие из п.1 и п.2 - это весьма и весьма широко распространенный протокол с ОГРОМНЫМ грузом "обратной совместимости". Любые изменения, которые его затрагивают повлияют на ТАКОЕ количество устройств, что мамадорогаяродименяобратно - а если учесть, что часть этих устройств не поддерживаемые, но рабочие... в общем, "дорого и больно".
Более того, размер проблемы - при её фактическом наличии - "несколько" меньше, чем может показаться со стороны. Широковещательный DHCPDISCOVER распространяется в рамках одного broadcast domain'а который, в минимально спроектированных а не "само насралося"(ТМ) сетях не так уж велик - сеть сегментируется на VLAN'ы, на маршрутизаторах с помощью DHCP Relay настраивается проброс DISCOVER\REQUEST на вполне конкретный DHCP-сервер, там, где это требуется используется аутентификация устройства на порту с помощью 802.1x в проводных сетях и WEP\WPA\WPA2 в wi-fi, для параноиков есть IPSEC-шифрование трафика, провайдеры используют VPN (Хотя бы минимальный PPPoE) с соответствующей аутентификацией перед выдачей сетевых параметров для подключения к сетям передачи данных, у администраторов есть средства поиска "левых" DHCP-серверов.
Ну и да, при всей мнимой "очевидности" решение проблемы весьма и весьма сложно. Как передать пароль всем клиентам сети, которые должны в ней работать? Вместе с WPA2-psk выдавать ещё один "мамой клянус, секретный!" пароль? Что делать, если !внизапна! в сети появится ДВА DHCP-сервера с одинаковым (А мы его выдаем всем клиентам по умолчанию) паролем? Использовать криптографию с открытым ключом аналогично SSL\TLS? Так распространение корневого сертификата и\или хэша самоподписанного сертификата тоже нифига не просто с точки зрения конечного пользователя.
В результате вышло так, как вышло - размер проблемы не так велик, как может показаться, кому надо - эту проблему с той или иной степенью успеха обкостылили, а тратить огромные - действительно ОГРОМНЫЕ ресурсы на решение проблем оставшихся за счет всех остальных желания нет.