Конфликт IP-адресов - "Несколько устройств используют один и тот же IP-адрес X.X.X.X."

Конфликт IP-адресов - "Несколько устройств используют один и тот же IP-адрес X.X.X.X.", UniFi Network

shamus_rask

Guest

29.10.2025 13:38:00

Шлюз: UDM-SEUniFi OS: 4.3.6Сеть: 9.5.21

Я управляю полностью сетью на базе UniFi в начальной школе, максимальное количество устройств около 170 (59 подключены по кабелю). Студенты в основном используют Chromebook'и, но есть также iPad'ы, MacBook'и и ноутбуки на Windows. Я создал отдельную VLAN для студентов с подсетью 10.3.0.0/20. Я включил функцию "Rogue DHCP Server Detection" на этой сети. Я не назначал никакие статические IP-адреса на этой сети.

В логах я заметил несколько записей вида: "Multiple devices are using the same 10.3.X.X IP address." Ссылка в CEF Log направляет меня на статью поддержки о "Duplicate IP Addresses and Rogue DHCP Servers".

Когда я смог поговорить с одним конкретным пользователем, который вызвал одну из этих записей в логе, оказалось, что он не может получить доступ в интернет. С его точки зрения, сигнал WiFi имеет полную мощность.

Как я упомянул, у меня нет никаких назначенных статических IP-адресов, и я включил DHCP guarding. Какие еще шаги я могу предпринять?

Спасибо,
S.

jw2k_fr

Guest

15.11.2025 00:03:00

Это исправление ошибки может быть, а может и не быть причиной этой проблемы. Мои ошибки в логах связаны с новой функцией, принятой в iOS и Android, подробнее описано здесь: https://community.ui.com/questions/IP-Address-Conflict-Multiple-devices-are-using-the-same-X-X-X-X-IP-address/23c93b4b-e87d-4e99-9b8a-4f35c465dab1#answer/7339c8a6-a0bc-401e-8f53-11ddc70f65e2

shamus_rask

Guest

22.01.2026 19:18:00

Обновление о текущей ситуации. Я продолжаю видеть ошибки в логах, но нашёл 2 способа смягчить проблему (подробности ниже). Я постоянно предоставляю обновления команде UI support и надеюсь получить чёткое объяснение или исправление. Во время зимних праздников я реализовал 2 обходных решения для проблемы дублирования IP-адресов. Каждое было применено к отдельной сети (у каждой сети свой WiFi), и оба, похоже, решили проблему.

Для сети факультета я назначил статические IP-адреса каждому устройству вне диапазона DHCP (но в пределах маски подсети). В основном все устройства теперь имеют стабильное соединение, когда они активны. Я по-прежнему вижу ошибки "дублирование IP" в логе, однако все они попадают в диапазон DHCP. Я назначил статические IP-адреса только ноутбукам и Chromecasts, а не личным устройствам (телефонам/планшетам/часам).

Для студенческой сети я настроил 802.1X с аутентификацией на основе MAC-адреса, используя встроенный RADIUS-сервер. С этой конфигурацией я вообще не вижу предупреждений "дублирование IP" в логе.

Моя теория остаётся той же: конфликт между встроенным DHCP-сервером UniFi и современными устройствами, использующими приватные ротирующиеся WiFi MAC-адреса. Для всех устройств, которым был назначен статический IP или использована аутентификация на основе MAC-адреса, мне пришлось вручную отключить ротацию WiFi MAC-адреса. Хотя это было выполнимо, отныне я должен отслеживать каждое устройство и его MAC-адрес. В долгосрочной перспективе это не устойчиво.

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

shamus_rask

Guest

24.11.2025 15:01:00

Быстрое обновление: Я сидю в школе и наблюдаю логи ошибок. Заметил ошибку "Duplicate IPs for 10.4.0.127" и сразу запустил команду arping. Она показала мне 2 MAC-адреса. Когда я посмотрел в список Client Device в интерфейсе UniFi, один MAC-адрес показывал 10.4.0.127, как и ожидалось, но второй показывал 10.4.0.125. Запустив arping ещё раз на обе IP, я обнаружил, что с первой всё ещё связаны 2 активных клиента, а со второй — только 1. Это заставляет меня задаться вопросом: может ли быть проблема с ARP-таблицей UniFi?

root@KBS:~# arping 10.4.0.125
ARPING 10.4.0.125
60 bytes from 4c:b0:4a:36:33:1e (10.4.0.125): index=0 time=1.289 msec
60 bytes from 4c:b0:4a:36:33:1e (10.4.0.125): index=1 time=1.439 msec
60 bytes from 4c:b0:4a:36:33:1e (10.4.0.125): index=2 time=1.395 msec
60 bytes from 4c:b0:4a:36:33:1e (10.4.0.125): index=3 time=166.464 msec
60 bytes from 4c:b0:4a:36:33:1e (10.4.0.125): index=4 time=1.282 msec
60 bytes from 4c:b0:4a:36:33:1e (10.4.0.125): index=5 time=1.482 msec
^C
--- 10.4.0.125 statistics ---
3 packets transmitted, 6 packets received, 0% unanswered (3 extra)
rtt min/avg/max/std-dev = 1.282/28.892/166.464/61.524 ms
root@KBS:~#
root@KBS:~#
root@KBS:~# arping 10.4.0.127
ARPING 10.4.0.127
60 bytes from 4c:b0:4a:36:33:1e (10.4.0.127): index=0 time=1.347 msec
60 bytes from 4c:b0:4a:36:33:1e (10.4.0.127): index=1 time=1.473 msec
60 bytes from 6c:99:9d:32:3e:95 (10.4.0.127): index=2 time=1.681 msec
60 bytes from 4c:b0:4a:36:33:1e (10.4.0.127): index=3 time=1.343 msec
60 bytes from 6c:99:9d:32:3e:95 (10.4.0.127): index=4 time=1.377 msec

shamus_rask

Guest

24.11.2025 14:11:00

Как и обещал, вот еще одно обновление. На прошлых выходных я удалил 2 сети, которые выдавали ошибки, и пересоздал их с другими номерами VLAN и диапазонами IP-адресов. По просьбе поддержки UniFi я изначально настроил их на использование UDM-SE в качестве DHCP-сервера. Несмотря на то, что это были выходные и в здании не было пользователей, я все равно видел ошибки. Я зафиксировал ошибки (arping), отправил их вместе с файлом поддержки в UniFi. Я не думаю, что это неправильно настроенное устройство со статическим IP-адресом, так как я полностью изменил подсеть, и в здании не было пользователей, которые могли бы переназначить свои статические IP-адреса. Теперь я переконфигурировал 2 новые сети для использования внешних PiHoles в качестве DHCP-серверов. Если я продолжу видеть эти ошибки, мой следующий шаг — внедрить список разрешений MAC-адресов в сетях WiFi. Я надеюсь избежать этого, так как это потребует много дополнительной работы по ведению учета.

sirket

Guest

20.11.2025 13:49:00

В своём первом посте ты сказал, что сидел с «одним конкретным пользователем, который создавал одну из этих записей в логе», но моя суть в том, что есть два устройства, использующих один IP-адрес, и тебе нужно найти оба. Одно может быть настроено на DHCP, а другое может иметь статически назначенный адрес. Или же ты можешь обнаружить, что у тебя есть группа устройств, такие как куча IoT-устройств от одного производителя, которые не соблюдают время истечения DHCP-лизов.

shamus_rask

Guest

20.11.2025 13:31:00

Я понимаю, о чём ты говоришь, но это же начальная школа. Я регулярно вижу в логах до 50 ошибок "duplicate IP" ежедневно. Я бы ещё согласился, что может быть 1-2 неправильно настроенных устройства, но столько??? Учти, что большинство беспроводных устройств — это Chromebooks или Chromecasts.

sirket

Guest

19.11.2025 21:55:00

Значит, у тебя есть два устройства с одним и тем же IP-адресом. Судя по MAC-адресам, одно устройство от Apple, а второе принадлежит компании "Fibocom Wireless Inc.", которая, похоже, производит чипы для IoT-устройств. Кто-то вручную назначил IP-адрес одному или обоим этим устройствам, поэтому теперь тебе нужно будет найти эти устройства.

shamus_rask

Guest

19.11.2025 21:25:00

Быстрое обновление, чтобы узнать, есть ли у кого-нибудь мысли по этому поводу. Работая с поддержкой UniFi, они попросили меня выполнить "arping" на IP-адресе, который указан как дубликат. Я это сделал, и результаты ниже:

root@KBS:~# arping 10.2.0.176
ARPING 10.2.0.176
60 bytes from 1c:57:dc:5d:50:94 (10.2.0.176): index=0 time=5.375 msec
60 bytes from 64:f6:bb:a7:b9:6c (10.2.0.176): index=1 time=5.408 msec
60 bytes from 1c:57:dc:5d:50:94 (10.2.0.176): index=2 time=5.607 msec
60 bytes from 64:f6:bb:a7:b9:6c (10.2.0.176): index=3 time=5.623 msec
60 bytes from 1c:57:dc:5d:50:94 (10.2.0.176): index=4 time=5.632 msec
60 bytes from 64:f6:bb:a7:b9:6c (10.2.0.176): index=5 time=5.640 msec
60 bytes from 1c:57:dc:5d:50:94 (10.2.0.176): index=6 time=1.011 msec
60 bytes from 64:f6:bb:a7:b9:6c (10.2.0.176): index=7 time=1.169 msec
60 bytes from 1c:57:dc:5d:50:94 (10.2.0.176): index=8 time=1.230 msec
60 bytes from 64:f6:bb:a7:b9:6c (10.2.0.176): index=9 time=1.239 msec
60 bytes from 1c:57:dc:5d:50:94 (10.2.0.176): index=10 time=1.248 msec
60 bytes from 64:f6:bb:a7:b9:6c (10.2.0.176): index=11 time=1.256 msec
60 bytes from 1c:57:dc:5d:50:94 (10.2.0.176): index=12 time=1.092 msec
60 bytes from 64:f6:bb:a7:b9:6c (10.2.0.176): index=13 time=1.124 msec
60 bytes from 64:f6:bb:a7:b9:6c (10.2.0.176): index=14 time=1.263 msec
60 bytes from 1c:57:dc:5d:50:94 (10.2.0.176): index=15 time=1.283 msec
60 bytes from 64:f6:bb:a7:b9:6c (10.2.0.176): index=16 time=1.291 msec
60 bytes from 1c:57:dc:5d:50:94 (10.2.0.176): index=17 time=1.298 msec
60 bytes from 1c:57:dc:5d:50:94 (10.2.0.176): index=18 time=9.794 msec
60 bytes from 64:f6:bb:a7:b9:6c (10.2.0.176): index=19 time=10.132 msec
60 bytes from 1c:57:dc:5d:50:94 (10.2.0.176): index=20 time=10.155 msec
60 bytes from 1c:57:dc:5d:50:94 (10.2.0.176): index=21 time=10.254 msec
60 bytes from 64:f6:bb:a7:b9:6c (10.2.0.176): index=22 time=10.269 msec
60 bytes from 64:f6:bb:a7:b9:6c (10.2.0.176): index=23 time=12.122 msec
^C
--- 10.2.0.176 statistics ---
4 packets transmitted, 24 packets received, 0% unanswered (20 extra)
rtt min/avg/max/std-dev = 1.011/4.605/12.122/3.833 ms

Поддержка ожидала, что только один из MAC-адресов будет в сети, однако похоже, что есть 2 устройства, которые оба отвечают на один и тот же IP-адрес???

shamus_rask

Guest

#10

17.11.2025 19:04:00

Вот обновление о моих выходных и работе...Я подготовил 2 Raspberry Pi с питанием через PoE (3b+ и 4b) с Ubuntu 25.10 server, Docker и официальным контейнером PiHole (режим host). Придя в школу, я установил статические IP-адреса для каждого Pi и подключил их напрямую к портам UDM SE, которые были правильно распределены между VLAN студентов и преподавателей. Решив подойти осторожно, я решил сначала попробовать сеть для студентов. Установил "DHCP Mode" на "None", запустил PiHole и попробовал подключиться к студенческому WiFi... ничего. Затем попробовал отключить "Isolate Network", снова ничего. Потом в настройках студенческого WiFi отключил "Client Device Isolation"... и снова ничего. После нескольких часов экспериментов я уже готов был сдаться.

Перед тем как всё бросить, я отчаянно решил попробовать сеть преподавателей. Те же действия: установил DHCP Mode, запустил PiHole... УСПЕХ!!! Как только я подключился к facultyWiFi, мне выдал IP, и я смог увидеть соответствующее назначение на PiHole. Это натолкнуло меня на мысль, что в сети студентов оставалось какое-то остаточное правило брандмауэра, которое не было очищено. Я полностью удалил сеть студентов, создал новую (новый VLAN) и всё сработало! Я думаю, это подтверждает мою теорию – не все настройки должным образом очищались, что не позволяло устройствам клиентов доступиться к DHCP серверу PiHole.

В понедельник утром я был в школе, внимательно наблюдая и ходя по ней, чтобы увидеть результаты. Если раньше студенты и преподаватели постоянно сталкивались с проблемами "подключения к сети" (то есть получали дублирующийся IP, что блокировало передачу пакетов), то теперь они подключаются без проблем.

Любопытно, что я всё ещё вижу несколько сообщений об ошибке "Duplicate IP" в логе сети преподавателей. Если это станет проблемой, я применю то же решение: удалю и создам новую сеть. Это немного сложнее, так как мне придётся пересмотреть все映射порты, в то время как сеть студентов была только WiFi.

Теперь у меня осталась не совсем идеальная конфигурация, где я полагаюсь на 2 Raspberry Pi с питанием через PoE, каждый из которых работает как независимый DHCP сервер; это кажется очень хрупким решением. Я отправлю всю эту информацию в поддержку UniFi и продолжу делиться любыми дальнейшими разработками.

jw2k_fr

Guest

#11

15.11.2025 00:05:00

У меня время аренды DHCP установлено на уровне 300 секунд, что ПОЛНОСТЬЮ непрактично для большой сети и может перегрузить DHCP-сервер, но это единственный способ не исчерпать доступные адреса (я не могу изменить свою подсеть 192.168.x.x на класс A 10.x.x.x из-за устаревших устройств с фиксированными IP-адресами). Я ответил на твой пост на Reddit по этому поводу и выложил здесь копию того, что, по моему мнению, вызывает проблему, по крайней мере для меня.

jw2k_fr

Guest

#12

15.11.2025 00:01:00

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

В Android эта функция находится здесь:
Перейдите в Параметры > Подключения > Wi-Fi.
Нажмите на значок шестерёнки рядом с Wi-Fi сетью, к которой вы подключены.
Прокрутите вниз и нажмите Показать больше.
Нажмите на Тип MAC-адреса.
Выберите между Randomized MAC (по умолчанию) или Phone MAC (реальный MAC-адрес устройства).

В iOS это называется "Private WiFi Address":
Перейдите в Параметры > WiFi > Private Wi-Fi Address.
Установите значение Fixed или, что предпочтительнее, Off.

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

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

@UI-Team - Запрос функции

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

Люблю, когда постмиллениалы (или другие новички) в технологических компаниях придумывают "потрясающие новые идеи", которые нарушают стандарты, принятые в индустрии;)

shamus_rask

Guest

#13

13.11.2025 15:33:00

Именно этим я и займусь на выходных. У меня уже есть RaspberryPi 4 с запущенным PiHole, и я попытаюсь перенести DHCP-сервер одной из VLAN на него. Я понимаю, что это костыль, но моя цель — проверить, решит ли это проблему, и дать обратную связь команде поддержки UniFi. Мне удалось стабилизировать работу одного устройства, назначив ему статический IP (вне диапазона DHCP). Это наводит меня на мысль, что проблема именно во встроенном DHCP-сервере. Продолжение следует.

BrinRe Guest	#14 13.11.2025 13:57:00 А что если ты попробуешь использовать другой сторонний DHCP сервер и отключишь встроенный на UDM?

sirket Guest	#15 13.11.2025 13:43:00 Я просто в шоке (хотя удивляться не должен), что у Ubiquiti DHCP-сервер не может работать с подсетью больше /24. Это же DHCP, нужно же! Технология далеко не новая.

shamus_rask

Guest

#16

13.11.2025 13:10:00

Я успешно установил UniFi OS 4.4.6 за ночь. Сейчас чуть больше 8 утра по моему времени, и мне грустно сообщить, что я уже заметил 9 записей в логе, указывающих на дублирующиеся IP-адреса. Для справки: всё ещё использую /22.

shamus_rask Guest	#17 12.11.2025 17:53:00 Мне только что пришло уведомление о доступности UniFi OS 4.4.6 для моего сайта. Я написал в службу поддержки UniFi, чтобы узнать, стоит ли мне переходить на эту версию – я не думаю, что там есть какие-то конкретные исправления, которые помогли бы с этой проблемой.

Читают тему (гостей: 1)