Теория: ARP: как хосты находят друг друга
IP-адрес известен, а кадр отправить нельзя: нужен MAC. Как хост его спрашивает, что лежит в кеше и почему в кадре стоит MAC шлюза, а не сервера. Прочитайте материал, а затем пройдите тест — следующий пункт курса откроется после верных ответов.
Задача, которую решает ARP
Из темы про Ethernet известно: коммутатор доставляет кадр по MAC-адресу. Из темы про адресацию — что приложения и маршрутизация работают с IP-адресами. Между этими двумя фактами дыра: вы набираете
Эту дыру закрывает ARP (Address Resolution Protocol). Его работа ровно одна: по известному IPv4-адресу узнать MAC-адрес того, кому предназначен кадр. Ничего больше ARP не делает — ни маршрутизацией, ни проверкой доступности он не занимается.
ping 192.168.1.20, у вас есть IP, а положить кадр в провод без MAC получателя нельзя.Эту дыру закрывает ARP (Address Resolution Protocol). Его работа ровно одна: по известному IPv4-адресу узнать MAC-адрес того, кому предназначен кадр. Ничего больше ARP не делает — ни маршрутизацией, ни проверкой доступности он не занимается.
Как выглядит обмен: широковещательный вопрос, адресный ответ
Хост, которому нужен MAC, кричит на весь сегмент: кадр с MAC назначения
Все хосты сегмента этот вопрос получают и разбирают, но отвечает только один — тот, у кого действительно этот IP. Ответ уже не широковещательный: он адресован лично спросившему, потому что MAC спрашивавшего лежал прямо в вопросе. Остальные молча выбрасывают запрос — но заодно многие запоминают, кто спрашивал.
Отсюда важное следствие: ARP не выходит за пределы своего широковещательного домена. Маршрутизатор широковещательные кадры не пересылает, поэтому спросить MAC узла из чужой сети нельзя в принципе.
ff:ff:ff:ff:ff:ff — широковещательный, его получают все. Внутри вопрос: «у кого адрес 192.168.1.20? ответьте мне, 192.168.1.10 по адресу aa:bb:cc:11:22:33».Все хосты сегмента этот вопрос получают и разбирают, но отвечает только один — тот, у кого действительно этот IP. Ответ уже не широковещательный: он адресован лично спросившему, потому что MAC спрашивавшего лежал прямо в вопросе. Остальные молча выбрасывают запрос — но заодно многие запоминают, кто спрашивал.
Отсюда важное следствие: ARP не выходит за пределы своего широковещательного домена. Маршрутизатор широковещательные кадры не пересылает, поэтому спросить MAC узла из чужой сети нельзя в принципе.
ARP-таблица и время жизни записи
Спрашивать перед каждым пакетом было бы разорительно, поэтому ответ кладётся в ARP-таблицу (её же называют ARP-кешем) — соответствие «IP → MAC → интерфейс». Дальше кадры уходят сразу, без вопросов.
Запись живёт не вечно: в Linux она проходит через состояния
Отдельно стоит запись со словом
Запись живёт не вечно: в Linux она проходит через состояния
REACHABLE → STALE → и либо подтверждается, либо удаляется. Порядок величин — минуты. Это сделано намеренно: если устройство заменили и MAC изменился, сеть должна починиться сама, без администратора.Отдельно стоит запись со словом
PERMANENT — её создал человек руками, и сама она не исчезнет и не обновится никогда. Именно поэтому неверная статическая запись — диагностический тупик: все настройки выглядят правильными, а связи нет.Главное место, где ломается модель: MAC шлюза вместо MAC сервера
Вы открываете сайт, который живёт на другом континенте. В IP-пакете адрес назначения — адрес того самого сервера. А в Ethernet-кадре, который лежит в вашем проводе, MAC назначения — вашего домашнего роутера. Не сервера.
Так и должно быть. Хост сравнивает адрес назначения со своей сетью (той самой операцией AND из темы про подсети) и решает:
• адрес в моей сети — спрашиваю ARP-ом MAC самого получателя и отправляю кадр прямо ему;
• адрес в чужой сети — спрашиваю ARP-ом MAC шлюза и отдаю кадр ему, пусть разбирается дальше.
IP-адрес назначения при этом не меняется на всём пути от вас до сервера, а MAC-адреса в кадре меняются на каждом участке между маршрутизаторами. IP отвечает на вопрос «куда в итоге», MAC — «кому передать прямо сейчас». Это разные вопросы, и путать их — самая частая ошибка в понимании сети.
Так и должно быть. Хост сравнивает адрес назначения со своей сетью (той самой операцией AND из темы про подсети) и решает:
• адрес в моей сети — спрашиваю ARP-ом MAC самого получателя и отправляю кадр прямо ему;
• адрес в чужой сети — спрашиваю ARP-ом MAC шлюза и отдаю кадр ему, пусть разбирается дальше.
IP-адрес назначения при этом не меняется на всём пути от вас до сервера, а MAC-адреса в кадре меняются на каждом участке между маршрутизаторами. IP отвечает на вопрос «куда в итоге», MAC — «кому передать прямо сейчас». Это разные вопросы, и путать их — самая частая ошибка в понимании сети.
что стоит в заголовках кадра, который лежит в проводе у ПК-1
Обратите внимание на нижнюю строку: IP назначения не меняется никогда,
а MAC назначения меняется на каждом участке. IP отвечает на вопрос «куда в итоге»,
MAC — «кому передать прямо сейчас».
Gratuitous ARP — ответ, которого никто не спрашивал
Иногда хост рассылает ARP про самого себя, хотя его не спрашивали. Это gratuitous ARP, и у него две работы.
Первая: проверить, не занят ли адрес. Подняв интерфейс, хост спрашивает про свой же адрес — если кто-то ответил, в сети дубликат, и об этом надо кричать, а не работать дальше.
Вторая: обновить чужие таблицы. Так делает отказоустойчивый шлюз: когда резервный узел забирает адрес себе, он рассылает gratuitous ARP, и все хосты сегмента моментально переучиваются слать кадры на новый MAC. Без этого они продолжали бы отправлять их умершему узлу до истечения записи в кеше.
Первая: проверить, не занят ли адрес. Подняв интерфейс, хост спрашивает про свой же адрес — если кто-то ответил, в сети дубликат, и об этом надо кричать, а не работать дальше.
Вторая: обновить чужие таблицы. Так делает отказоустойчивый шлюз: когда резервный узел забирает адрес себе, он рассылает gratuitous ARP, и все хосты сегмента моментально переучиваются слать кадры на новый MAC. Без этого они продолжали бы отправлять их умершему узлу до истечения записи в кеше.
Proxy ARP — маршрутизатор отвечает за чужой адрес
Маршрутизатор может ответить на ARP-запрос про адрес, который ему не принадлежит, подставив свой MAC, — если знает, как до этого адреса добраться. Это proxy ARP: хост думает, что сосед рядом, и отдаёт кадр маршрутизатору, а тот пересылает дальше.
Механизм придуман для случаев, когда у хоста неправильно задана маска и он считает своей сетью больше, чем есть на самом деле. Сегодня это скорее костыль, который маскирует ошибку конфигурации: сеть работает, но не так, как написано в документации, и разбираться в этом потом будет очень неприятно. В большинстве современных сетей proxy ARP выключают.
Механизм придуман для случаев, когда у хоста неправильно задана маска и он считает своей сетью больше, чем есть на самом деле. Сегодня это скорее костыль, который маскирует ошибку конфигурации: сеть работает, но не так, как написано в документации, и разбираться в этом потом будет очень неприятно. В большинстве современных сетей proxy ARP выключают.
Что здесь ломается
Дубликат IP. Два устройства с одним адресом отвечают на один и тот же ARP-запрос. Чей ответ пришёл последним, тот и попал в кеш — связь начинает «плавать» и работать через раз, причём у разных хостов по-разному.
Застрявшая статическая запись. Оборудование заменили, MAC новый, а прописанная руками запись держит старый. Всё настроено верно, ping молчит.
ARP spoofing. В протоколе нет никакой проверки подлинности: кто ответил, тому и верят. Злоумышленник отвечает на чужие запросы своим MAC и оказывается посередине чужого разговора. Защита живёт на коммутаторе (Dynamic ARP Inspection), а не в самом ARP — починить протокол уже нельзя.
Тишина вместо ответа. Если у интерфейса снят ARP или хост в другом широковещательном домене, запросы уходят в пустоту. Симптом одинаковый — «ping не работает», причины совершенно разные.
Застрявшая статическая запись. Оборудование заменили, MAC новый, а прописанная руками запись держит старый. Всё настроено верно, ping молчит.
ARP spoofing. В протоколе нет никакой проверки подлинности: кто ответил, тому и верят. Злоумышленник отвечает на чужие запросы своим MAC и оказывается посередине чужого разговора. Защита живёт на коммутаторе (Dynamic ARP Inspection), а не в самом ARP — починить протокол уже нельзя.
Тишина вместо ответа. Если у интерфейса снят ARP или хост в другом широковещательном домене, запросы уходят в пустоту. Симптом одинаковый — «ping не работает», причины совершенно разные.
Как проверять
ip neigh show (или arp -n) — таблица целиком: какой MAC хост считает соседским и в каком состоянии запись. Первое место, куда стоит смотреть, когда «адреса верные, а связи нет».ip neigh flush dev eth0 — сбросить кеш и заставить хост спросить заново. Обратите внимание: записи PERMANENT эта команда не трогает, и это регулярно сбивает с толку.tcpdump -i eth0 -e arp — увидеть сам обмен. Флаг -e показывает Ethernet-заголовки, и в них хорошо видно главное: у запроса MAC назначения ff:ff:ff:ff:ff:ff, у ответа — конкретный адрес.Уходят запросы, а ответов нет — проблема на той стороне или между вами. Не уходит даже запрос — смотрите свой интерфейс и маршрут.
Команды — шпаргалка
# посмотреть и почистить
ip neigh show # вся таблица соседей: IP, MAC, интерфейс, состояние
ip neigh show dev eth0 # dev — сузить вывод до одного интерфейса
ip neigh flush dev eth0 # flush — стереть выученное на этом интерфейсе.
# Записи PERMANENT останутся
# добавить и удалить руками
ip neigh replace 192.168.1.20 lladdr aa:bb:cc:11:22:33 dev eth0
# replace — создать запись или переписать, если
# она уже есть. lladdr — «link layer
# address», то есть MAC-адрес соседа.
# dev — на каком интерфейсе он живёт
ip neigh del 192.168.1.20 dev eth0 # убрать одну запись
# поймать обмен
tcpdump -i eth0 -e arp # -i — на каком интерфейсе слушать;
# -e — показывать MAC-адреса кадра, без него их не
# видно; arp — фильтр: только ARP-пакеты
# выключить и включить ARP на интерфейсе
ip link set eth0 arp off # set — менять свойство; arp off — не рассылать
# запросы и не отвечать на них
ip link set eth0 arp on
# Cisco-подобный синтаксис
show arp # та же таблица на сетевом оборудовании
clear arp-cache # стереть выученное целикомТеория прочитана. Дальше — руками.
Личный стенд из настоящих роутеров разворачивается за секунды. Платформа проверяет не ответы на тесты, а состояние вашей сети: поднялись ли соседства, сошлись ли маршруты, ходит ли ping. Рядом — AI-наставник, который видит ваши конфиги и ведёт к решению, не выдавая готовое.
Начать бесплатно →
бета открыта, доступ бесплатный