Виявлено IP-конфлікт: швидко знайдіть винуватця

Що таке IP-конфлікт насправді (і чому він виглядає випадковим)

IP-конфлікт — це не «помилка мережі». Це помилка обліку. Два хости вважають, що володіють одним і тим же IP-адресом в одному L2 широкомовному домені (або в двох доменах, випадково з’єднаних бриджем). Мережа охоче доставляє пакети тому хосту, який нині «переміг» у відображенні між IP та канальним адресом (MAC для IPv4/ARP або канальна адреса для IPv6/NDP). Це відображення змінюється з часом, тому відмова виглядає періодичною і химерною.

Фактично змінюється запис у кеші сусідів на інших пристроях:

• В IPv4 ARP-кеші відображають IPv4 → MAC. Конфлікт викликає коливання ARP-кеша. Ви бачите логи на кшталт «duplicate address detected», «ARP flux» або «kernel: arp: duplicate address».
• В IPv6 NDP (Neighbor Discovery Protocol) відображає IPv6 → link-layer. Конфлікти IPv6 трапляються рідше, але можуть бути складнішими, бо у вас може бути кілька IPv6-адрес (SLAAC + DHCPv6 + статичні) та privacy-адреси, що ускладнює атрибуцію.

Конфлікти зазвичай проявляються в кількох сценаріях:

• Статичні IP всередині діапазону DHCP. Хтось жорстко задає 192.168.1.50 на принтері, бо «так зручніше», а потім DHCP роздає цю адресу.
• Клоновані ВМ або контейнери з збереженою мережею. Шаблон клоновано, MAC-адреса дубльована, або помилка в конфігурації змушує кілька вузлів використовувати один IP.
• Rogue DHCP сервер. Побутовий роутер, підключений до офісного порту, починає видавати оренди та неправильні шлюзи.
• Розширення рівня L2, якого ви не планували. Бридж, неправильно запущена вітка VLAN або розширена мережа змушують два сайти випадково спільно використовувати підмережу.
• Штормы gratuitous ARP. Деякі пристрої спамлять оголошеннями «я володію цією IP», і інші системи їм вірять.

Одна цитата, що переживає кожне розслідування, — це істина надійності від Richard Cook, яку часто перефразовують в операційних колах: перефразовано: «Системи успішні, бо люди постійно адаптуються; відмови відбуваються, коли ця адаптація не встигає». В IP-конфліктах «адаптація» — це постійне перевчивання ARP/NDP у мережі — доки воно не може встигнути.

Жарт #1: IP-конфлікт — це єдина ситуація, коли два комп’ютери згодні в чомусь, а всі інші страждають.

Швидкий план діагностики

Цю частину роздрукуйте (або хоча б запам’ятайте). Коли ви під тиском, не починайте з перезавантаження випадкових пристроїв. Перезапуски можуть тимчасово «вирішити» проблему, змінивши останньо бачену MAC-адресу, що знищує докази.

Перший крок: підтвердьте, що це реальний конфлікт, і визначте його межі

1. Визначте оспорюваний IP з логів/сповіщень/повідомлень користувачів.
2. Знайдіть щонайменше дві різні MAC-адреси, які претендують на цю адресу (свідчення ARP/NDP). Якщо є лише одна MAC, ви можете переслідувати проблему маршрутизації або фаєрвола.
3. Визначте широкомовний домен/VLAN, де живе конфлікт. «Та сама IP» — проблема тільки якщо це в одному L2 сегменті або в з’єднаних бриджем сегментах.

Другий крок: локалізуйте порушника фізично/логічно

1. З хоста в тому ж VLAN запросіть ARP для IP і запишіть MAC.
2. На комутаторі знайдіть цю MAC у таблиці переадресації, щоб отримати порт (або транк/аплінк).
3. Слідкуйте за MAC переходячи хоп за хопом, поки не дійдете до порту доступу. Якщо це бездротова мережа, ви потрапите у таблицю асоціацій WLC/AP.

Третій крок: вирішіть, чи це DHCP, статична конфігурація чи віртуалізація

1. Перевірте логи/оренди DHCP для цієї IP: чи була видана, якій MAC, коли?
2. Перевірте на наявність rogue DHCP-сервера, якщо клієнти отримують неправильний шлюз/DNS або оренди від дивного джерела.
3. Перевірте платформи віртуалізації на наявність дублікатів MAC або дубльованих статичних конфігурацій (VM-шаблони, cloud-init, netplan, systemd-networkd, Kubernetes CNI).

Умови зупинки (коли маєте достатньо)

• Ви називаєте дві MAC-адреси та зіставляєте кожну з пристроєм/портом.
• Знаєте, яка з них «легітимна» (інвентар, резерв DHCP, задокументована статична адресація).
• Розумієте механізм: статичне в DHCP, rogue DHCP, клон, неправильний VLAN, поведінка відмови.

Цікаві факти та історичний контекст

• ARP старший за більшість «сучасних» операційних практик. ARP було стандартизовано на початку 1980-х, коли мережі були меншими, і «дубльована IP» була в основному людською помилкою.
• Gratuitous ARP має два життя. Він використовується як для корисних оголошень (відкат, оновлення кешу), так і для зловживань (спуфінг/отруєння). Та сама механіка — різні наміри.
• Деякі ОС активно захищають свою IP. Багато стеків відправляють ARP-проби перед використанням адреси й можуть логувати «address conflict», якщо приходять відповіді.
• DHCP має механізми виявлення конфліктів, але це не магія. Багато DHCP-серверів можуть ARP-пінгувати адресу перед видачею оренди. Це зменшує конфлікти, але не запобігає статичним помилкам після видачі.
• Дубльовані MAC можуть маскуватися під IP-конфлікти. Якщо дві NIC мають однаковий MAC (погані клони, вручну заданий MAC), навчання на комутаторі стає нестабільним і трафік «відскакує» між портами.
• IPv6 намагався зробити це рідше. Duplicate Address Detection (DAD) вбудовано в IPv6 neighbor discovery. Це допомагає, але також створює власні режими відмов, коли L2 ненадійний.
• «ARP flux» — це реальне явище, а не страшний термін. Linux може відповідати на ARP «не на тому інтерфейсі», якщо налаштований вільно; мультиграндні хости можуть плутати пір.
• Висока доступність використовує ті ж трюки, що й зловмисники. VRRP, CARP та багато кластерних систем покладаються на швидке переміщення IP і оновлення кешів сусідів; при неправильній конфігурації вони виглядають як конфлікти.

Ваш набір інструментів: ARP, NDP, DHCP, комутатори та захоплення пакетів

Більшість IP-конфліктів ви вирішите чотирма інструментами: таблицями сусідів, логами DHCP, таблицями MAC комутаторів і захопленням пакетів. Хитрість — у послідовності, щоб кожна відповідь звужувала поле пошуку. Якщо ви одразу запускаєте tcpdump, не знаючи, що шукаєте, ви витратите годину на шум.

IPv4: ARP — це зал суду

Коли два пристрої претендують на IPv4-адресу, вони оголошують її ARP-відповідями (інколи непроханими). Усі інші оновлюють кеш. Ваше завдання — зловити ці оголошення й пов’язати їх з MAC та портами.

IPv6: NDP і DAD — та сама драма з довшими адресами

В IPv6 конфлікти часто виявляються під час DAD: хост пропонує адресу й слухає на заперечення. Заперечення — це NDP Neighbor Advertisement. Захват цього обміну — золото, бо він включає канальну адресу порушника.

DHCP: паперовий слід (коли він існує)

DHCP дає структуру: оренди, резерви, часові мітки. Він також породжує хаос, коли є більше одного DHCP-сервера або коли хтось використовує статичні IP всередині пулу. Логи DHCP відповідають на два важливі питання: чи була ця IP видана і кому?

Комутатори та контролери бездротової мережі: де поховано тіло

Коли у вас є MAC порушника, інфраструктура комутаторів зазвичай скаже порт (або пристрій вгору по ланцюжку). Це перетворює «невидимого мережевого привида» у конкретний тикет: «Port Gi1/0/17 має MAC aa:bb:cc:dd:ee:ff, підписаний ‘Conference Room’.»

Захоплення пакетів: сироватка правди

Коли логи брешуть, пакети не брешуть. Коротке захоплення, орієнтоване на ARP/NDP, покаже, хто претендує на адресу і як часто. Частота важлива: системи відмови вибухають і замовкають; поламані пристрої спамлять без упину; шкідливе ПЗ матиме дивні періодичні шаблони.

Жарт #2: ARP-таблиці — як офісні розсаджувальні списки: застарілі, інколи неправильні, але всі їм довіряють.

Практичні завдання: команди, виводи, рішення (12+)

Це реальні завдання, які ви можете виконати під час інциденту. Кожне включає: команду, приклад виводу, що це означає, і яке рішення прийняти далі. Запускайте їх з хоста в ураженому VLAN за можливості; запуск звідкись ще дасть застарілі або нерелевантні дані про сусідів.

Завдання 1: Підтвердити, що IP відповідає і побачити вирішення MAC (IPv4)

cr0x@server:~$ ping -c 2 10.20.30.40
PING 10.20.30.40 (10.20.30.40) 56(84) bytes of data.
64 bytes from 10.20.30.40: icmp_seq=1 ttl=64 time=0.412 ms
64 bytes from 10.20.30.40: icmp_seq=2 ttl=64 time=0.398 ms

--- 10.20.30.40 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 0.398/0.405/0.412/0.007 ms

Значення: IP живий (принаймні зараз). Це не доводить конфлікту, але готує ARP-кеш.

Рішення: Негайно перевірте запис сусіда; не чекайте, поки він пропаде.

Завдання 2: Переглянути запис ARP/сусідів (IPv4)

cr0x@server:~$ ip neigh show 10.20.30.40
10.20.30.40 dev eth0 lladdr 00:11:22:33:44:55 REACHABLE

Значення: Ваш хост наразі вважає, що 10.20.30.40 відповідає MAC 00:11:22:33:44:55.

Рішення: Запишіть MAC. Потім спостерігайте, чи зміниться; зміни — підпис конфлікту.

Завдання 3: Слідкувати за коливанням ARP-кеша в реальному часі

cr0x@server:~$ watch -n 1 "ip neigh show 10.20.30.40"
Every 1.0s: ip neigh show 10.20.30.40

10.20.30.40 dev eth0 lladdr 00:11:22:33:44:55 STALE
Every 1.0s: ip neigh show 10.20.30.40

10.20.30.40 dev eth0 lladdr aa:bb:cc:dd:ee:ff REACHABLE

Значення: MAC змінилась з 00:11:22:33:44:55 на aa:bb:cc:dd:ee:ff. Це ваш палкий доказ: два пристрої відповідають за одну IP.

Рішення: Тепер ви шукаєте обидві MAC по мережі. Не «ремонтуйте» одразу; спочатку ідентифікуйте обидва кінці.

Завдання 4: Захопити ARP-повідомлення (хто кричить «ця IP моя»)

cr0x@server:~$ sudo tcpdump -ni eth0 arp and host 10.20.30.40
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:01:10.102345 ARP, Reply 10.20.30.40 is-at 00:11:22:33:44:55, length 28
12:01:10.508901 ARP, Reply 10.20.30.40 is-at aa:bb:cc:dd:ee:ff, length 28

Значення: Дві різні MAC-адреси відправляють ARP-відповіді для тієї ж IP. Це остаточне свідчення.

Рішення: Перейдіть до пошуку по комутатору/WLC для кожної MAC. Якщо у вас немає доступу, передайте MAC тим, хто має.

Завдання 5: Перевірити, чи ваш Linux-хост не є порушником (не смійтеся)

cr0x@server:~$ ip -4 addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    inet 10.20.30.41/24 brd 10.20.30.255 scope global eth0
       valid_lft forever preferred_lft forever

Значення: Цей хост не налаштований з 10.20.30.40. Добре — варто перевіряти, бо «самозавдані» рани часті.

Рішення: Якщо б хост мав оминутий IP, зупиніться і виправте це перш ніж шукати по мережі.

Завдання 6: Перевірити повідомлення ядра про дубль-адреси (Linux)

cr0x@server:~$ sudo journalctl -k --since "1 hour ago" | egrep -i "duplicate|arp|conflict"
Feb 05 11:58:22 server kernel: arp: 10.20.30.40 is detected on eth0 with different hwaddr aa:bb:cc:dd:ee:ff

Значення: Ядро зафіксувало невідповідність IP/MAC. Це підтверджує проблему з боку ОС.

Рішення: Використайте часову мітку для кореляції з логами DHCP, flaps у CAM таблиці або перезавантаженням пристрою.

Завдання 7: Визначити «легітимного» власника через оренду DHCP (приклад ISC dhcpd)

cr0x@server:~$ sudo grep -n "10.20.30.40" /var/lib/dhcp/dhcpd.leases | tail -n 12
1827:lease 10.20.30.40 {
1828:  starts 3 2026/02/05 11:30:01;
1829:  ends 3 2026/02/05 23:30:01;
1830:  cltt 3 2026/02/05 11:30:01;
1831:  binding state active;
1832:  hardware ethernet 00:11:22:33:44:55;
1833:  uid "\001\000\021\"3DU";
1834:  client-hostname "acct-laptop-17";
1835:}

Значення: DHCP вважає, що 10.20.30.40 належить MAC 00:11:22:33:44:55 (включно з іменем клієнта).

Рішення: Розглядайте 00:11:22:33:44:55 як ймовірного легітимного клієнта, якщо ваш DHCP-діапазон правильний і не піддається отруєнню. Тепер шукайте aa:bb:cc:dd:ee:ff як порушника.

Завдання 8: Перевірити логи DHCP-клієнта systemd-networkd (щоб побачити, який сервер відповів)

cr0x@server:~$ journalctl -u systemd-networkd --since "2 hours ago" | egrep -i "DHCPv4|lease|server"
Feb 05 11:31:04 server systemd-networkd[612]: eth0: DHCPv4 address 10.20.30.41/24 via 10.20.30.1
Feb 05 11:31:04 server systemd-networkd[612]: eth0: DHCPv4 server: 10.20.30.2

Значення: Ваш хост отримав оренду від DHCP-сервера 10.20.30.2. Якщо клієнти отримують оренди від різних серверів, можлива ситуація з rogue DHCP.

Рішення: Якщо IP «сервера» несподіваний, залучіть мережеву команду для пошуку rogue і увімкніть DHCP snooping/port security.

Завдання 9: Знайти порт комутатора за MAC (загальний підхід через ARP + робочий процес, дружній до SNMP)

cr0x@server:~$ arp -an | grep "10.20.30.40"
? (10.20.30.40) at aa:bb:cc:dd:ee:ff [ether] on eth0

Значення: У вас є MAC для пошуку в CAM-таблиці комутатора.

Рішення: На access-комутаторі запустіть пошук MAC у таблиці адрес (виробник-залежно). Якщо не можете — надішліть MAC тому, хто може.

Завдання 10: Виявити MAC-flapping на Linux bridge (іноді «комутатор» — це хост)

cr0x@server:~$ bridge fdb show br0 | head
00:11:22:33:44:55 dev vnet3 master br0
aa:bb:cc:dd:ee:ff dev vnet7 master br0

Значення: На хості віртуалізації ви бачите, які vNIC відповідають за кожну MAC. Часто це найшвидший шлях у середовищах з великою кількістю VM.

Рішення: Зіставте vnet3/vnet7 з іменами VM (libvirt, qemu тощо) і перевірте їхні IP-конфігурації або cloud-init.

Завдання 11: Перевірити дубльовану IP-конфігурацію в netplan (поширено при image-based provisioning)

cr0x@server:~$ sudo cat /etc/netplan/01-netcfg.yaml
network:
  version: 2
  ethernets:
    eth0:
      addresses: [10.20.30.40/24]
      gateway4: 10.20.30.1
      nameservers:
        addresses: [10.20.30.2,8.8.8.8]

Значення: Цей хост статично налаштований з оспорюваною IP. Якщо те саме бачите на кількох машинах через золотий образ, ви знайшли фабрику конфліктів.

Рішення: Виправте pipeline провізіонування: унікальна адресація через DHCP або шаблони статичного розподілу. Потім змініть IP проблемного хоста й очистіть кеші.

Завдання 12: Очистити кеш сусідів після виправлення (стабілізація на стороні клієнта)

cr0x@server:~$ sudo ip neigh flush 10.20.30.40

Значення: Ви видалили застаріле відображення, щоб хост швидко навчився правильної MAC.

Рішення: Робіть це на уражених серверах після усунення проблеми, особливо якщо вони закріпили «не ту» MAC і ще падають.

Завдання 13: Перевірка конфлікту IPv6: перегляд запису сусідів і підказки DAD

cr0x@server:~$ ip -6 neigh show dev eth0 | head
fe80::a00:27ff:fe12:3456 lladdr 08:00:27:12:34:56 router REACHABLE
2001:db8:20:30::40 lladdr 00:11:22:33:44:55 STALE

Значення: У вас є IPv6-співвідношення сусідів. Якщо воно перемикається між двома lladdr, це IPv6-версія проблеми.

Рішення: Захопіть NDP (наступне завдання) і шукайте Neighbor Advertisements з кількох джерел.

Завдання 14: Захопити IPv6 NDP для конкретної адреси

cr0x@server:~$ sudo tcpdump -ni eth0 "icmp6 and (ip6[40] == 135 or ip6[40] == 136)"
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:07:11.001122 IP6 fe80::1 > ff02::1:ff00:40: ICMP6, neighbor solicitation, who has 2001:db8:20:30::40, length 32
12:07:11.003210 IP6 fe80::a00:27ff:fe12:3456 > fe80::1: ICMP6, neighbor advertisement, tgt is 2001:db8:20:30::40, length 32
12:07:11.004001 IP6 fe80::b00:dead:beef:1 > fe80::1: ICMP6, neighbor advertisement, tgt is 2001:db8:20:30::40, length 32

Значення: Два різні лінк-локальні джерела рекламують володіння тією самою IPv6-адресою. Це конфлікт.

Рішення: Витягніть L2-адреси (за потреби використайте -e у tcpdump) і прослідуйте їх через комутатори/бездротову мережу так само, як для ARP.

Завдання 15: Виявити rogue DHCP-offers у мережі (аналіз DORA)

cr0x@server:~$ sudo tcpdump -ni eth0 -vvv "udp and (port 67 or port 68)" -c 20
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:10:01.100001 IP (tos 0x0, ttl 64, id 1001, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:11:22:33:44:55, length 300, xid 0x1a2b3c4d
12:10:01.101111 IP (tos 0x0, ttl 64, id 2001, offset 0, flags [none], proto UDP (17), length 342)
    10.20.30.2.67 > 10.20.30.41.68: BOOTP/DHCP, Reply, length 314, xid 0x1a2b3c4d, yiaddr 10.20.30.41
12:10:01.101999 IP (tos 0x0, ttl 255, id 3001, offset 0, flags [none], proto UDP (17), length 342)
    192.168.0.1.67 > 10.20.30.41.68: BOOTP/DHCP, Reply, length 314, xid 0x1a2b3c4d, yiaddr 10.20.30.99

Значення: Два різні DHCP-сервера відповіли: 10.20.30.2 (очікуваний) і 192.168.0.1 (дуже підозрілий у цій підмережі). Це rogue DHCP, що опосередковано може викликати IP-конфлікти й точно викликає неправильну маршрутизацію.

Рішення: Залучіть мережу/безпеку: закрийте порт, увімкніть DHCP snooping, знайдіть пристрій за MAC у DHCP-пакеті (-e) і зробіть lookup портів комутатора.

Три корпоративні міні-історії з практики

Історія 1: Інцидент через хибне припущення

Компанія була в процесі міграції зі старої офісної мережі на нову сегментовану архітектуру. Невелика команда підняла «тимчасову» підмережу для лабораторії: той самий RFC1918-діапазон, що й у продакшені, бо «вона ізольована». Вони були впевнені, бо лабораторний комутатор був в іншому шафі, а лабораторний роутер мав інший WAN-аплінк. Ізоляція — на відчуття.

Через два місяці підрядник потребував віддалений доступ до лабораторії. Хтось додав VPN-тунель і з’єднав лабораторний VLAN з ядром кампусу «тільки на тиждень». Ніхто не оновив мережеві діаграми. Ніхто не оновив записи в IPAM. Тунель залишився.

Потім почалося веселе: продакшн-ендпоінти почали періодично втрачати доступ до файлового сервісу. IP сервісу був стабільний; MAC — ні. Helpdesk звинувачував storage. Storage — firewall. Firewall — DNS, бо так буває, коли фаєрвол-команди нудьгують.

Прорив був болісно простим: захват ARP показав дві MAC, що претендують на IP файлового сервісу. Одна була реальним сервером. Інша — лабораторна VM, налаштована копіпастою netplan з віккі. «Ізольована» лабораторія стала частиною продакшн-широкомовного домену через помилку в бриджуванні.

Виправлення не було героїчним. Воно було акуратним: видалити бридж, провести аудит перетинів RFC1918 і ввести правило — ніякого перекриття адрес між середовищами, якщо ви не можете довести розділення L2 і L3. Постмортем не звучав як «люди все поламали». Він звучав як «ми припустили, що ізоляція є, не перевіривши шлях».

Історія 2: Оптимізація, що обернулась проти

Інша організація пишалася швидким провізіонуванням. У них був золотий образ VM, який швидко завантажувався і приєднувався до флоту з мінімальними зовнішніми залежностями. Щоб зменшити час завантаження, вони вирішили попередньо прописувати статичну адресу в образі для спеціального класу сервісів: менше DHCP-запитів, швидша готовність, менше рухомих частин. На папері — акуратно.

Образ містив /etc/netplan/01-netcfg.yaml зі статичною IP. План був: «ми перезапишемо її під час провізіонування». Але переписка залежала від кроку cloud-init, який іноді падав, коли metadata-сервіс був повільний. Ті машини все одно піднімалися з вмонтованою IP.

Це не вибухнуло відразу. Воно тліло. Лише під час масштабування — наприклад, вікон патчів або піку трафіку — кілька інстансів одночасно стартували й зіткнулися на одній IP. Моніторинг виглядав як серцебиття: працює, не працює, працює, не працює. Команда назвала це «флаппер».

Вони пробували заглушити: збільшити таймаути ARP, додати keepalive, «можливо це балансувальник». Все це — робота з симптомами. Справжня оптимізація — статичні IP у образі — була коренем хаосу.

Вирішення — перестати мудрувати: прибрати статичні адреси з базового образу, дозволити DHCP робити свою роботу і використовувати резерви там, де потрібні стабільні IP. Час завантаження трохи зріс. Кількість інцидентів впала значно. Це компроміс, з яким більшість бізнесів може жити.

Історія 3: Нудна, але правильна практика, що врятувала день

В суворо регульованому середовищі мережева команда дотримувалася нудної звички: для кожного VLAN задокументовані DHCP-діапазони, виключення та зарезервовані статичні піддіапазони. Вони також строго забороняли призначати «статичні» адреси за межами зарезервованого діапазону, ніяких винятків, ніяких «тільки для принтера», ніяких «тимчасово».

Одного ранку в сегменті клінічного додатку з’явилася хвиля повідомлень про IP-конфлікти. Тріаж почався: ARP-захвати показали дві MAC для однієї IP — одна належала відомій моделі thin client, інша була невідома. Команда витягнула оренду DHCP і відразу побачила легітимного власника. Це звузило підозру до «щось статичне або rogue», а не «DHCP рандомно збивається».

Далі вони зробили найбільш нудну річ: lookup MAC на комутаторі. Невідома MAC виявилася на порту доступу в переговорній, яка не мала бути в тому VLAN. Порт був підключений до маленького unmanaged switch. Звідти — побутовий Wi‑Fi роутер, який хтось приніс з дому. Він бриджував і видавав DHCP, і мав статичну IP з попереднього середовища, що зіткнулася з орендованою адресою.

Вирішення зайняло кілька хвилин: відключити порт, прибрати пристрій, очистити кеші сусідів на ключових серверах, підтвердити відсутність інших rogue DHCP. Звіт після інциденту був задовільно нудним: задокументовані діапазони та трасування портів спрацювали як і планувалося.

Нудьга перемагає. Це не лозунг; це операційна правда.

Поширені помилки: симптом → коренева причина → виправлення

1) Симптом: «Працює для деяких користувачів, але не для інших»

Корінь: ARP-кеші різняться між клієнтами; деякі мають MAC A для IP, інші — MAC B. Сервіс виглядає випадково доступним.

Виправлення: Захопіть ARP-відповіді, щоб підтвердити подвійних претендентів, а потім простежте MAC через таблиці комутаторів. Після усунення прочистіть кеші сусідів на критичних клієнтах/серверах.

2) Симптом: «Конфлікт відбувається лише після перезавантажень або відмови»

Корінь: Неправильна конфігурація HA-пари (VRRP/CARP/keepalived), де обидва вузли думають, що вони master, або процедура failover відправляє gratuitous ARP занадто агресивно й плутає пристрої нагору.

Виправлення: Перевірте state machine HA, налаштування преемпції та health checks. Переконайтесь, що тільки один вузол тримає VIP. Захопіть ARP під час відмови, щоб підтвердити поведінку.

3) Симптом: «Бачимо сповіщення про дубль-адреси, але IP не пінгується»

Корінь: Адреса претендується через ARP, але брандмауер хоста відкидає ICMP; або ви спостерігаєте ARP-спуфінг/сканування безпеки; або конфлікт у іншому VLAN, ніж ви тестуєте.

Виправлення: Не використовуйте ping як істину. Використовуйте ARP/NDP і місцезнаходження по порту комутатора. Перевірте контекст VLAN (trunk tagging, access VLAN).

4) Симптом: «Нові пристрої отримують неправильний шлюз/DNS»

Корінь: Rogue DHCP-сервер, часто побутовий роутер або неправильно налаштована VM з dnsmasq.

Виправлення: Ідентифікуйте джерела DHCP-offer за допомогою tcpdump, потім ізолюйте за MAC і портом комутатора. Увімкніть DHCP snooping і блокуйте порти DHCP-сервера на краю мережі.

5) Симптом: «Та сама MAC з’являється на двох портах комутатора»

Корінь: Дубльована MAC-адреса (клоновані VM, вручну заданий MAC, багова прошивка NIC) або петля/неуправляємий комутатор, що викликає нестабільність CAM.

Виправлення: Підтвердіть у інвентарі віртуалізації; забезпечте унікальне генерування MAC. Перевірте L2 петлі; увімкніть STP; розгляньте port security, щоб обмежити переміщення MAC.

6) Симптом: «IP-конфлікти тільки у Wi‑Fi»

Корінь: Особливості ізоляції клієнтів/роумінгу, кілька SSID, що бриджуються в той самий VLAN випадково, або неправильна конфігурація контролера, що передає DHCP неправильно.

Виправлення: Корелюйте по таблиці клієнтів WLC за MAC, перевірте відповідність SSID→VLAN і шукайте rogue AP, що бриджують мережі.

7) Симптом: «Ми виправили, але через день повернулося»

Корінь: Ви виправили симптом (змінили IP на одному хості), але не механізм (шаблон, перекриття DHCP, неуправляємий пристрій, що повертається).

Виправлення: Дисципліна пошуку кореневої причини: знайти джерело пристрою та причину, чому він мав ту IP. Оновіть IPAM, введіть виключення й додайте детектування.

Контрольні списки / покроковий план

Чеклист інциденту: 15 хвилин до ясності

1. Запишіть: оспорювану IP, уражений VLAN/підмережу, час першого виявлення, хто повідомив.
2. З хоста в тому ж VLAN: ip neigh show <IP> і запишіть MAC.
3. Запустіть: tcpdump -ni <if> arp and host <IP> на 30–60 секунд. Зафіксуйте всі побачені MAC.
4. Перевірте оренди/логи DHCP: чи IP була видана? якій MAC? Є незвичні IP серверів DHCP?
5. Трасуйте MAC на комутаторі: знайдіть порт доступу або upstream-посилання. Повторюйте hop-by-hop.
6. Ідентифікуйте пристрій: інвентар активів, OUI виробника, DHCP hostname, мапа віртуалізації, запис клієнта бездротової мережі.
7. Зупиніть кровотечу: відключіть offending порт, приберіть статичну конфігурацію або виправте стан HA. Уникайте «просто перезавантажити».
8. Стабілізуйте: прочистіть кеші сусідів на ключових серверах, перезапустіть потрібні сервіси за необхідності.
9. Запобігти повторенню: виправте перекриття DHCP-діапазонів, оновіть IPAM, додайте захисні механізми (snooping, резерви, виправлення шаблонів).

Чеклист запобігання: зробіть конфлікти знову нудними

• Підтримуйте зарезервований статичний діапазон для кожного VLAN і тримайте його поза DHCP-пулом.
• Увімкніть перевірку конфліктів DHCP на сервері, де це доступно (ARP-перевірка перед offer).
• Увімкніть DHCP snooping та Dynamic ARP Inspection (де підтримується) на access-комутаторах.
• Забезпечте унікальність MAC у VM-шаблонах; ніколи не вбудовуйте статичні IP у золоті образи, якщо не гарантується унікальність.
• Логуйте та сповіщайте про flaps MAC для одної і тієї ж IP (на фаєрволі, комутаторах або через пасивні сенсори).
• Тримайте мінімальний процес «whois для MAC»: пошук OUI + внутрішнє мапування в інвентарі.
• Документуйте поведінку HA virtual IP (VRRP/CARP/keepalived) і тестуйте сценарії split-brain.

Чеклист перевірки після інциденту

1. Підтвердіть, що ARP/NDP для IP резольвиться в точно одну MAC протягом 5–10 хвилин спостереження.
2. Підтвердіть, що DHCP не має активної оренди для тієї IP, прив’язаної до «неправильної» MAC (або очистіть її).
3. Підтвердіть, що CAM-таблиця комутатора показує MAC на очікуваному порту і вона стабільна.
4. Підтвердіть, що уражені додатки стабільні: немає скидань з’єднань, немає періодичних таймаутів.
5. Запишіть кореневу причину одним реченням, яке включає механізм (не тільки пристрій-порушник).

Питання й відповіді

1) Як зрозуміти, що це IP-конфлікт, а не DNS?

Проблеми з DNS не змінюють MAC-адрес. Якщо ip neigh (або ARP-захвати) показують кілька MAC для тієї самої IP, це конфлікт. DNS теж може бути зламаний, але має інший підпис відмови.

2) Чому проблема приходить і йде?

Бо кеші ARP/NDP старіють і оновлюються. Той, хто останнім оголосив володіння, «перемагає», поки щось не спровокує оновлення (трафік, закінчення кешу, gratuitous ARP, neighbor solicitation).

3) Чи можна просто очистити ARP-таблицю, щоб вирішити це?

Очищення кешів сусідів може тимчасово відновити підключення, але не видаляє другого претендента. Це крок стабілізації після виправлення причини, а не лікування.

4) Що робити, якщо обидва пристрої «легітимні», як у HA-парі?

Тоді тільки один з них має бути master для VIP у будь-який момент. Якщо обидва претендують — у вас split-brain або неправильне налаштування відмови. Захопіть ARP під час події і перевірте переходи станів HA.

5) Як знайти пристрій, якщо у мене є лише IP і немає доступу до комутаторів?

Використайте ARP-захват, щоб отримати MAC. Далі скористайтеся інвентарем: DHCP-оренда з hostname, таблиці bridge хостів віртуалізації, списки клієнтів WLC або записи EDR/MDM, що індексують за MAC.

6) Чи трапляються IP-конфлікти в IPv6?

Так, але вони часто виявляються раніше завдяки Duplicate Address Detection. Проте неправильно з’єднані сегменти, ручні статичні IPv6 або клоновані образи можуть створювати дубль. Використовуйте NDP-захвати та таблиці сусідів так само, як з ARP.

7) Який найшвидший спосіб довести, що є два пристрої?

tcpdump на ARP (або NDP для IPv6) і watch цикл на ip neigh show. Якщо MAC чергується, у вас доказ, з яким важко посперечатися.

8) Чому принтери та IoT-пристрої так часто фігурують у таких інцидентах?

Їх тимчасово часто налаштовують статично, переміщують між мережами і рідко оновлюють. Вони часто стоять під столами або в шафах, що робить їх ідеальними підозрюваними.

9) Чи треба ставити все на DHCP, щоб уникнути конфліктів?

Для більшості кінцевих пристроїв і звичайних серверів — так. Для інфраструктури, якій потрібні стабільні адреси, використовуйте резерви DHCP або документований статичний діапазон поза пулом. «Частково статично, частково DHCP, без документації» — вхідна квиток для конфліктів.

Висновок: наступні кроки для запобігання повторення

Коли трапляється IP-конфлікт, найкращий хід — припинити гадати і почати збирати дві ідентифікації: оспорювана IP і MAC-адреси претендентів. Далі — чиста механіка: зіставити MAC з портом (або vNIC VM, або асоціацією Wi‑Fi), підтвердити намір DHCP і видалити надлишкового претендента.

Ваші практичні наступні кроки:

1. Прийміть швидкий план і вимагайте ARP/NDP-докази перед «ремонтом».
2. Очистіть адресацію: тримайте статичні IP поза DHCP-пулом і документуйте зарезервовані діапазони.
3. Закріпіть край мережі: DHCP snooping, ARP inspection і розумні політики портів там, де обладнання це підтримує.
4. Виправте шаблони: ніяких вбудованих статичних IP, ніяких дубльованих MAC і ніяких «тимчасових» конфігурацій, що стають постійними.

Якщо ви виконаєте ці чотири кроки, повідомлення «IP conflict detected» знову стане рідкісною цікавістю, а не постійним героєм у вашому черговому списку інцидентів.