Протокол ARP занимается простой и неблагодарной работой: он отвечает на вопрос, какому физическому интерфейсу в локальном сегменте принадлежит нужный IP-адрес. Без этого ответа кадр Ethernet просто некуда отправить, потому что коммутаторы оперируют MAC-адресами, а приложения думают в терминах IP. ARP появился в 1982 году, до сих пор работает на каждой точке доступа и в каждой домашней сети, и при этом остаётся одним из самых недооценённых протоколов: о нём вспоминают ровно тогда, когда сетевое соединение рушится по непонятной причине, а на самом деле кэш устаревших записей продолжает отправлять кадры на старый адрес шлюза. Эта статья разбирает, как устроены запрос и ответ, зачем кэшу время жизни, что делает gratuitous ARP, почему протокол не знает слова «аутентификация», и как извлечь из него пользу при диагностике.
Механика запроса и ответа через широковещание
Когда хост хочет отправить пакет соседу по локальной сети, он сначала заглядывает в свой кэш ARP. Если записи нет, хост собирает запрос: кадр с широковещательным MAC-адресом назначения ff:ff:ff:ff:ff:ff, внутри которого лежит вопрос «кто владеет таким-то IP, сообщите свой MAC». Кадр получает каждый узел сегмента, потому что коммутатор по определению рассылает broadcast во все порты. Адресат узнаёт свой IP в поле запроса и отвечает уже точечным кадром, указывая свой MAC в поле отправителя. Остальные узлы молча отбрасывают запрос, хотя многие реализации заодно обновляют свой кэш сведениями об адресе спрашивающего, чтобы не задавать встречный вопрос позже.
Важная деталь чистого сетевика: ARP не является протоколом IP-уровня. Он живёт прямо поверх канального, со своим EtherType 0x0806, и его кадры никогда не покидают локальный сегмент. Маршрутизатор ARP не пересылает, а завершает на своём интерфейсе. Поэтому, когда компьютер хочет поговорить с внешним миром, он ищет через ARP не адрес назначения, а адрес шлюза по умолчанию, и именно MAC шлюза попадает в заголовок кадра. Дальше кадр гуляет по сети от маршрутизатора к маршрутизатору, и на каждом новом участке заголовок канального уровня переписывается заново с новой парой адресов.
Кэш ARP и время жизни записей
Отвечать на каждый исходящий пакет широковещательным запросом было бы расточительно, поэтому результат сохраняется в кэше. Запись живёт ограниченное время: в разных операционных системах это от нескольких секунд для неподтверждённых записей до десятков минут для активно используемых. Живой протокол подстраивается: если по записи продолжают идти кадры, её срок продлевается, а если запись простаивает, она стареет и удаляется. Зачем вообще нужно старение? Потому что сеть меняется. Сетевая карта выходит из строя, ноутбук переезжает в другую подсеть, роутер заменяют на новый, и у нового устройства тот же IP, но другой MAC. Если бы записи были вечными, все соседи продолжали бы слать кадры на адрес покойника.
Практическая ловушка известна любому, кто менял домашний роутер. Провайдерский адрес шлюза остался прежним, настройки перенесены, но половина устройств в сети не видит интернет. Диагностика показывает: «шлюз не отвечает». Отвечает, ещё как, просто кадры летят на старый MAC из застрявшей записи кэша. Лечится очисткой кэша, переподключением или терпеливым ожиданием истечения срока. На серверных системах встречается и обратная беда: администраторы прописывают статические записи ARP ради мнимой надёжности, а потом забывают про них, и замена сетевой карты на сервере превращается в часовое расследование, потому что статика переживает любые реальные изменения. Динамический кэш сам себя лечит, статический требует памяти администратора, а она подводит чаще железа.
Gratuitous ARP как объявление о смене личности
Есть особая форма протокола, где хост ничего не спрашивает, а сам рассказывает миру о своей паре адресов. Такой кадр называется gratuitous ARP, и он рассылается широковещательно при загрузке интерфейса, при смене IP, при замене сетевой карты или при переезде виртуальной машины. Получатели, у которых есть запись об этом IP, молча обновляют её на новый MAC. Именно поэтому корректно настроенный переезд сервиса на резервный узел в кластере проходит почти незаметно: новый владелец адреса кричит о себе gratuitous ARP, и кэши соседей и коммутаторов перестраиваются за миллисекунды.
Есть и второе применение: обнаружение конфликтов адресов. Хост при назначении себе адреса может спросить сеть, не занят ли он, сформировав запрос с нулевым адресом отправителя. Если кто-то ответит, адрес уже занят, и вежливая система откажется его поднимать, выведя предупреждение. Грубая система поднимет всё равно, и соседи начнут получать противоречивые обновления, что превращается в мерцание связности, когда половина пакетов уходит одному владельцу адреса, а половина другому.
Домашняя сеть, коммутаторы и две таблицы, которые друг друга кормят
В типичной квартире стоит один роутер со встроенным коммутатором на четыре порта и точкой доступа, и вся внутренняя жизнь сети держится на двух таблицах. Первая - таблица CAM внутри коммутатора: какой MAC за каким портом находится. Вторая - кэши ARP на каждом устройстве: какой IP соответствует какому MAC. Эти таблицы заполняют друг друга, но вопреки распространённому заблуждению ARP не заполняет таблицу коммутатора напрямую. Коммутатор учится сам, глядя на адрес источника каждого проходящего кадра. ARP лишь провоцирует трафик: широковещательный запрос идёт во все порты, ответ возвращается точечным, и по этому ответу коммутатор впервые узнаёт, за каким портом прячется ранее молчавшее устройство. Дальше кадры между хостами уже не рассылаются повсюду, а идут точно в нужный порт.
У записей в таблице CAM тоже есть срок жизни, обычно около пяти минут без трафика. Отсюда диагностический вывод: если устройство долго молчало, первый кадр к нему может вылиться лавинной рассылкой во все порты, это нормальное поведение, а не поломка. Полезный рабочий порядок действий при разборе странностей выглядит так:
- Смотрим кэш на хосте командой arp -a и проверяем, совпадает ли MAC шлюза с реальным адресом роутера.
- Если есть доступ к управляемому коммутатору, смотрим его таблицу CAM и проверяем, на каком порту числится нужный MAC.
- Сверяем сроки старения: запись без трафика могла просто умереть.
- Проверяем наличие дублей IP, когда один адрес мелькает с разными MAC в соседних строках.
- При смене оборудования принудительно чистим кэш на ключевых узлах вместо ожидания.
Почему протокол не умеет проверять подлинность
ARP спроектирован в 1982 году как протокол локального доверия. Исходное допущение было простым: все участники сегмента свои, никто не врёт, а задача протокола - скорость и простота, а не проверка личности. В сообщении нет ни подписи, ни сеанса, ни подтверждения полномочий отвечающего: кто первым ответил, тот и прав, а более поздний ответ банально перезаписывает старый. Ретроспективно это выглядит наивно, но в контексте исследовательской сети начала восьмидесятых, где все узлы принадлежали горстке лабораторий, такая экономия была разумной инженерной сделкой.
Цена этой сделки - известный класс атак через подмену ответов, когда чужой узел убеждает соседей, что MAC шлюза принадлежит ему, и трафик начинает течь через руки злоумышленника. Здесь атака интересна лишь как повод для защиты, а защита живёт на управляемых коммутаторах: функция динамической инспекции ARP сверяет каждое сообщение с таблицей привязок адресов, собранной при выдаче настроек, и отбрасывает ответы, где связка IP и MAC не соответствует учёту. Дополняет её привязка портов к конкретным адресам и ограничение числа MAC на порт. Вывод практичный: доверие, которого нет в протоколе, восстанавливается железом и учётом на границе доступа.
ARP, IPv6 и диагностика поля зрения
В мире IPv6 протокола ARP нет вовсе. Его функции переняло семейство Neighbor Discovery поверх ICMPv6: запрос соседа и объявление соседа работают через мультикаст-группы вместо грубого широковещания, а обнаружение маршрутизаторов тоже встроено туда же. Замена вышла элегантнее и экономнее для среды передачи, но переход растянулся на десятилетия, потому что ARP слишком глубоко врос в практики эксплуатации. Сетевики привыкли, что правильная инвентаризация сегмента делается в два шага: сначала разведка всех адресов подсети методом перебора с проверкой отклика, а затем чтение собственного кэша, куда осели записи обо всех, кто ответил. Эта комбинация самодостаточна, не требует доступа к коммутаторам и работает независимо от того, молчат ли хосты на высоких уровнях.
Именно поэтому ARP выжил. Он мал, предсказуем, даёт наблюдаемый след в кэше на каждом конце, и его поведение десятилетиями одинаково на железе любого вендора. В Ethernet он был естественным дополнением, потому что Ethernet с детства был шиной с широковещанием, и протокол вопросов и ответов ложился на среду без трения. Диагностика, построенная на нём, остаётся первым инструментом, к которому тянется рука: одна команда arp -a рассказывает о сегменте больше, чем уровень сигнала на индикаторах. Сетевик, который умеет читать кэш, понимать старение и отличать gratuitous ARP от обычного ответа, видит локальную сеть не как туман, а как набор конкретных записей с конкретной историей, и это половина любого разбора инцидента.
Gratuitous ARP и объявление себя
Отдельного упоминания заслуживает самопровозглашённый ответ: узел посылает ARP-ответ, на который никто не спрашивал. Такая рассылка называется gratuitous ARP и выполняют её по трём понятным причинам: сообщить сети новый адрес при переезде виртуальной машины, расчистить чужие устаревшие записи после смены сетевой карты или адреса, сигнализировать о дублировании адресации, когда две машины попадаются на одном и том же IP. Коммутаторы наблюдают кадр и обновляют свои таблицы, сервера записывают отображение, а оборудование кластеров при переносе виртуального IP использует этот приём, чтобы клиенты узнали адрес у нового хозяина ещё до истечения сроков базовых записей. Из этой же логики вырастает предупреждение: группа пассивных прослушиваний ветеранского звена благополучно определяет перебор ошибок именно по серии таких ответов, потому что законная смена владельца редка, а массивные повторы - признак вмешательства.
Поведение записей и устаревание
Каждая запись обречена устаревать: когда карта образовывается динамически, операционная система вбрасывает ей время жизни, обычно измеряемое минутами, и повторное разрешение становится необходимым при следующем обращении. Именно поэтому статический занесённый маршрут выигрывает у динамического только там, где топология неизменна годами, а в прочих местах старение защищает от накопления фальшивых карт. Для диагностики важно соотнести задержку первой передачи после паузы с тратой времени на повторное разрешение адреса: если первый пакет к хосту каждый раз стартует медленно после длительного затишья, стоит проверить прожиточный путь обмена. Этот простейший приём экономит часы разбора на жалобах пользователей, почему печать «долго думала» по первому запросу.
ARP в эпоху современных сетей
С переходом к IPv6 протокол сменил облик: Neighbor Discovery Protocol через ICMPv6 исполняет те же обязанности, но с вложенной безопасностью (SEND с сертификатами) и без широковещания на уровне ethernet: запросы переведены на целевые multicast-группы, чтобы не утомлять всех подряд. Почему этот сдвиг был вынужденным, объясняется одним фактом структуры: широковещание не масштабируется, и сеть из тысячи станций получает шум на каждый запрос каждой из них, если все отклики идут через широковещательный сетевой радиоканал. Замена не обесценила ARP: он действует по сей день во всех сетях IPv4, а его учебное значение состоит в том, что самый прозрачный протокол даёт самый наглядный урок о том, почему доверие в сети нужно подтверждать наблюдением, а не предполагать даром.