Короткий ответ

ARP связывает IPv4 в 10.0.10.0/24 с MAC. Если 10.0.10.1 в кеше — MAC самозванца, трафик шлюза украден (конфликт, stale после failover, spoof). Сбросьте одну запись, посмотрите, какой MAC вернётся, найдите его на порту коммутатора. Не размазывайте arp -d * по серверам и не ставьте static ARP «чтобы больше не врало» без инвентаризации.

Симптомы и как отличить

  • SSH host key вдруг чужой на том же IP;
  • интернет пропал, ARP 10.0.10.1 не совпадает с документированным MAC роутера;
  • Get-NetNeighbor State Stale/Unreachable, ping плавает.

Отличия: два стабильных MAC на один IP — конфликт. Нет ARP вообще — VLAN или APIPA. Маршрут L3 врёт при верном ARP — таблица, не ARP.

Возможные причины

  1. Конфликт IP / второй DHCP.
  2. Stale после VRRP/VM migrate: старый MAC до timeout.
  3. ARP spoof (атака или «сетевой сканер» в режиме mitm).
  4. Proxy ARP на шлюзе слишком широкий.
  5. Неверная статическая запись администратора.
  6. NIC teaming сменил MAC.
  7. Мост/гипервизор отвечает за VM.
  8. Одинаковый MAC на двух VM (клон).

Диагностика

1. Снять кеш и эталон

Эталон MAC шлюза — из паспорта/наклейки/ show interface на 10.0.10.1.

arp -a
Get-NetNeighbor -AddressFamily IPv4 | Format-Table IPAddress, LinkLayerAddress, State, InterfaceAlias
Get-NetIPConfiguration
ip neigh
ip -s neigh show 10.0.10.1

Запишите IP, MAC, State, интерфейс.

2. Сброс одной записи и кто ответит

Remove-NetNeighbor -IPAddress 10.0.10.1 -Confirm:$false
ping -n 2 10.0.10.1
Get-NetNeighbor -IPAddress 10.0.10.1
sudo ip neigh del 10.0.10.1 dev eth0
ping -c 2 10.0.10.1
ip neigh show 10.0.10.1

Сравните MAC с эталоном. Чужой — ищите порт.

3. Кто отвечает сейчас

sudo tcpdump -n -i eth0 arp and host 10.0.10.1

Два разных MAC в reply — конфликт или spoof. Один MAC не с того порта — смотрите CAM.

show mac address-table address <MAC>
show ip arp 10.0.10.1

4. Статика в кеше

Windows arp -s / сосед Permanent. Ubuntu: nud permanent. Если её не ставили вы — ищите скрипт/агент.

Get-NetNeighbor -IPAddress 10.0.10.1 | Format-List *

5. Не proxy ARP ли

Шлюз отвечает ARP на адреса вне 10.0.10.0/24. Клиенты с широкой маской это любят. Тогда «неверный ARP» на 10.0.20.10 — на самом деле MAC шлюза. Чините маску/маршруты, не ARP.

Решение

Сценарий A. Stale после failover

Сброс ARP на клиентах или gratuitous ARP с нового master (VRRP обычно шлёт). Не держите lease ARP 10 часов на файрволе, если VIP часто ездит.

Сценарий B. Конфликт

Выключите самозванца. См. статью про конфликт. После — сброс ARP на соседях.

Сценарий C. Spoof

Изолируйте порт, DAI/DHCP snooping, dynamic ARP inspection где умеете. Не лечите static ARP на 200 ПК.

Сценарий D. Клон VM с тем же MAC

Уникальный MAC в гипервизоре. Сброс neigh.

Сценарий E. Постоянная ошибка на одном ПК

Удалите ручной arp -s из старых инструкций, проверьте hosts не при чём (hosts не ARP).

netsh interface ip delete arpcache

На сервере лучше Remove-NetNeighbor точечно.

6. После сброса: кто отвечает повторно

Сброс ARP без поиска источника — ритуал. После Remove-NetNeighbor 10.0.10.1 сразу tcpdump arp. Если снова чужой MAC — он жив. Идите на CAM. Совпадение с эталоном шлюза — был stale (VRRP/миграция), достаточно gratuitous. Два MAC в pcap — конфликт или spoof; DAI/snooping, изоляция порта, не arp -s на сотне ПК.

Проверьте, не proxy ARP ли это: MAC шлюза на адреса вне 10.0.10.0/24. Тогда «неверный ARP» на 10.0.20.10 ожидаем при кривой маске. NLB unicast, bonding, live migration — легитимная смена MAC; смотрите гипервизор, не «атака» сразу. IPv6 ip -6 neigh отдельно. На сервере с множеством сессий удаляйте одну запись, не netsh delete arpcache. Заявка: эталон MAC, факт MAC, порт, действие, повторный neigh через пять минут. Permanent запись, которой никто не ставил — ищите login-скрипт и старые инструкции arp -s.

Windows Get-NetNeighbor точнее arp -a (состояние Reachable/Stale). Ubuntu FAILED после flush без ответа — L2/VLAN, не spoof. Не путайте incomplete и wrong MAC.

Рабочий порядок на смене: эталон MAC → neigh сейчас → pcap ARP → CAM/порт → действие на источнике → точечный flush у пострадавших → контроль через пять минут. Если источник — клон VM, уникальный MAC и IP в гипервизоре важнее, чем «прописать arp -s на шлюзе». Для VIP кластера смотрите, шлёт ли master gratuitous; если нет, клиенты Windows могут держать Stale минутами. Не путайте задачу с hairpin: к публичному IP ARP в LAN не строится, нужен маршрут/NAT. Мониторинг: алерт на смену MAC 10.0.10.1. Это ловит и конфликт шлюза, и «доброжелательный» домашний роутер. DAI требует DHCP snooping как базу — внедряйте парой, не DAI в пустоту. Пользовательский «сканер безопасности» в режиме mitm даёт ту же картину, что атака; изолируйте порт до разбора.

Как проверить, что проблема устранена

MAC 10.0.10.1 совпадает с эталоном на нескольких клиентах 5+ минут. ping/Test-NetConnection до шлюза и DNS 10.0.10.2. tcpdump: один MAC в ARP reply. CAM: MAC на ожидаемом порту.

Если не помогло

  • Только IPv6 neighbor врёт — NDP, не ARP (ip -6 neigh).
  • Hairpin путают с ARP: до публичного IP ARP нет, нужен маршрут.
  • Bonding: ARP идёт не с того slave.
  • Windows NLB в unicast — особая модель MAC, не «spoof» в бытовом смысле, но ломает свитчи.

Профилактика

  • DAI + DHCP snooping.
  • Документ MAC шлюза и VIP.
  • Алерт: смена MAC шлюза.
  • Запрет клонов с копированием MAC.

FAQ

arp -d * на DC?

Не надо. Снесёте кеш всех соседей, краткий шторм ARP. Только нужный IP.

Почему запись возвращается «неверной» сразу после ping?

Кто-то активнее отвечает. Это не баг кеша — живой источник. Ищите его.

Static ARP на шлюз — хорошая защита?

Хрупкая. При замене NIC/VRRP всё умрёт. Для хостов — DAI, не static.

incomplete не исчезает. Это неверный ARP?

Это нет ответа. VLAN, фильтр, хост выключен. Не путать с wrong MAC.

Get-NetNeighbor vs arp -a

Get-NetNeighbor точнее (IPv4+IPv6, состояние). arp -a привычнее. Смотрите оба при расхождении.