Протокол ARP и его роль в современной сети

Мы с вами продолжаем говорить про то, что встречается в любых сетях, в том числе и небольших, в рамках курса ICN-D1. Мы с вами прошли работу протокола IP. Мы прошли перед этим работу протокола Ethernet. И мы говорили про то, что это два основных протокола, которые сегодня используются в современном мире. Ethernet используется для доставки данных внутри общей канальной среды, причём современная версия Ethernet — это на самом деле виртуализированный общий широковещательный канал, когда несколько разных доменов коллизии соединяются в один большой широковещательный домен. И есть ещё протокол IP, который отвечает за передачу данных между проводами. По большому счёту, что IP, что сегодняшний Ethernet — они занимаются одним и тем же. Они перекладывают данные между проводами. А Ethernet, когда перекладывает данные между проводами от коммутатора, он старается прикинуться шлангом, старается сделать вид, чтобы его никто не заметил. Поэтому мы не видим, как работает отдельный коммутатор.

Он максимально прозрачно для обычного абонента работает. Поэтому можно сказать, что он достаточно эффективно прикидывается общим проводом. И когда у нас идёт соединение разных доменов коллизии в один виртуальный широковещательный домен, можно сказать, что один коммутатор порождает один виртуальный провод. И когда IP работает с Ethernet, он берёт данные из этого виртуального провода и перекладывает эти данные в другой виртуальный провод, если мы говорим про перекладывание на IP-уровне пакетов между сетями Ethernet. Но возникает вопрос. Когда мы хотим отправить какой-то кадр в Ethernet роутеру, чтобы он его дальше переложил в какой-то другой провод, мы должны будем указать его адрес, канальный адрес. Мы с вами помним, в IP у нас взаимодействие всё ведётся так, что отправитель и все транзитные узлы, когда они принимают решение, куда отправить какой-то пакет дальше,

они должны принять решение, основываясь на двух моментах. Первый момент — какой интерфейс выбрать. Второй — какой канальный адрес выбрать для отправки данных в сеть назначения. И мы всё время опускали тонкий момент, как именно выбирается канальный адрес в сетях Ethernet, и сейчас пришла пора этот момент обсудить. Если у нас есть некий узел, например, слева некий компьютер с IP-шником 10.0.0.1, который хочет отправить IP-пакет на адрес 10.0.0.2, у него есть IP-шник получателя, например, ему пользователь сказал «пингани, пожалуйста, 10.0.0.2». IP-шник получателя он каким-то образом знает. Свой собственный IP-шник он тоже знает. Он может принять решение, что трафик отправляется либо с указанием явно заданного адреса источника, либо, если мы не специфицировали адрес источника, он может динамически подстроиться после того, как мы выберем интерфейс, с которого пакет должен уйти.

И на этом интерфейсе будет какой-то основной адрес. Этот основной адрес будет выбран в качестве адреса источника в пакете. Но этот IP-пакет надо упаковать в кадр. И в кадре мы можем взять MAC-адрес источника, свой собственный, мы его знаем. А MAC-адрес получателя нам надо каким-то образом заполнить. И возникает вопрос, как именно это сделать? У нас в среде, в широковещательном проводе, если хотите, виртуальном широковещательном домене, может быть много участников. Есть такой, есть сякой. И у них разные IP-шники, разные MAC-адреса. И как нам выбрать правильный MAC-адрес, правильно сформировать заголовок канального уровня и отправить IP-пакеты в среду. За это будет отвечать специальный протокол. Официальное название протокола — ARP, Address Resolution Protocol. Если посмотреть на подзаголовок RFC, это Ethernet Address Resolution Protocol. Не в любом протоколе он работает, а только в Ethernet. Авторы его позиционировали как протокол преобразования Ethernet-адресов,

то есть MAC-адресов во что-то там. Во что, например? В IP может преобразовывать. Если посмотреть на возможности работы протокола ARP, он достаточно тупой, но при этом достаточно мощный. И если у нас выполняются определённые требования к среде передачи данных, то он может преобразовать любые адреса в любые другие. У него есть так называемые аппаратные адреса — это MAC-адреса, то, что на канальном уровне работает. И протокольные адреса — это IP-адреса, с которыми мы и собираемся работать. У нас есть IP-адрес, мы должны его преобразовать в MAC. По большому счёту ARP может работать с абсолютно любым протоколом на канальном уровне, если в нём поддерживается широковещательная рассылка. Если вы можете отправить на канальном уровне какой-то кадр, и он дойдёт до всех получателей одновременно, чтобы кадр отправили один, а он дошёл до многих абонентов. В Ethernet такая возможность у нас есть. У нас broadcast там работает, мы можем отправить этот broadcast-кадр,

и он разлетится на всех-всех-всех. Как мы помним, оригинальный Ethernet по коаксиальному проводу позволял отправить такой кадр, он просто отправлялся, и физически он доставлялся вообще до всех в любом случае. А дальше те, кому не надо было получать такой кадр, они бы зажмуривались. Но broadcast был нужен всем. И даже после того, как появились свитчи, любой свитч разбрасывает копии всех кадров на все порты, кроме некоторых. И broadcast не включает какие-то дополнительные ограничения, он разбрасывается действительно на все порты, которые подключены к нужному VLAN, за исключением каких-то очевидных вещей, типа никогда не отправлять broadcast обратно в тот порт, с которого он пришёл, не отправлять broadcast-кадры в те порты, которые заблокированы в Spanning Tree и так далее. В любом случае, в Ethernet у нас broadcast есть. Если есть какая-то другая канальная среда, в которой тоже есть адреса, и в ней поддерживается broadcast, то тоже там ARP можно использовать.

По факту из всех возможных вариантов, где вы сегодня ARP можете увидеть, остался в живых только Ethernet. Как ARP в Ethernet будет работать для преобразования IP-адресов в MAC-адреса? Очень просто. У нас есть некий отправитель. Он знает IP получателя, но он не знает MAC-адрес получателя. Он просто орёт на всю сеть. Мужики, у кого из вас такой IP-шник, скажите свой MAC. Он отправляет кадр, в котором буквально так и написано. У кого из вас такой IP-шник, скажите свой MAC. И все узлы в канале получают такой запрос. Те, у кого IP-шник какой-то другой, не тот, который написан в пакете, они этот кадр игнорируют. Те, у кого действительно такой IP-шник есть, они говорят: меня спросили, какой у меня MAC, я должен буду ответить.

Wi-Fi, кстати, тоже ARP использует. Спасибо, что подсказали. Там тоже широковещательный запрос можно отправить, и там тоже ARP. Так. Далее. Действительно, обладатель такого адреса отправляет ответ. Кто-то тут меня давеча спрашивал. Я отвечаю. Мой IP-шник 10.0.0.2, мой MAC-адрес — дальше показывает свой MAC-адрес. Отправляется сообщение не в виде ответа на то, что ты спрашивал, какой у меня IP-шник, ты задавал мне вопрос, я тебе отвечаю на твой вопрос таким ответом. Что вопросы, что ответы у ARP — они очень друг на друга похожи. Они такие, как бы выразиться, декларативные. Вопрос — у какого узла IP-шник такой-то, скажите свой MAC. Это на самом деле не совсем вопрос, это как бы утверждение.

Мне интересен MAC-адрес узла, у которого IP-шник такой. И, в кавычках, ответ — когда мы говорим, что посылается ARP-ответ, это на самом деле тоже не ответ, это просто утверждение. У меня IP-шник такой, мой MAC-адрес такой. Кому надо, тот услышит, тот отреагирует. Но это не «будьте так любезны, пожалуйста, в ответ на мой вопрос ответьте мне встречным сообщением чего-то там». Это декларативное. Меня интересует такой-то IP-шник. У меня IP-шник такой. И по большому счёту вопросы и ответы не сильно отличаются по формату. Они отличаются буквально одним битиком. И мы сейчас увидим формат, вы поймёте, как эта штука работает. Для того чтобы не посылать вопросы «у кого из вас такой IP-шник, скажите свой MAC» постоянно на каждый чих, когда нам нужно будет вести взаимодействие с каким-то другим узлом — например, у нас есть два узла, 10.0.0.1 и 10.0.0.2 — для того чтобы на каждый пакет, который нам нужно будет отправить в сторону 10.0.0.2,

не посылать отдельный запрос «какой у тебя MAC-адрес, скажи его срочно», ARP будет кэшировать ответы. Один раз вы спросили, и в течение некоторого времени вы исходите из логики, что MAC-адрес получателя не изменился. Один раз спросили 10.0.0.2, какой у него MAC-адрес, и дальше в течение, например, 5 минут или 4 часов или чего-то ещё, вы повторные запросы уже не посылаете. Логика будет вполне очевидная: что IP-адреса узлов, что MAC-адреса узлов, они меняются крайне редко. И в какой ситуации может поменяться, например, MAC-адрес при сохранении IP-шника? У нас там был сервер какой-то, он вышел из строя, и мы думаем, что бы нам делать с сервером, который сгорел. Давайте возьмём новый сервер, назначим ему такой же IP-шник, и у него MAC-адрес, естественно, будет другой. Вставим его в сеть. На эту операцию в любом случае потребуется какое-то время,

и время, которое вам необходимо для того, чтобы заменить сервер с сохранением IP-адреса — 5 минут, 10 минут, 20 минут, час. В течение этого времени имеет смысл кэшировать записи. Что если прямо сейчас какой-то узел живёт, и у него MAC-адрес определённый, и у него IP-шник тоже определённый, то, скорее всего, в ближайший, условно говоря, час этот самый IP-шник и этот самый MAC не изменятся. В какой ситуации может этот процесс пойти не по плану? Например, если вдруг вы внезапно поменяли MAC-адрес. Те узлы, которые закэшировали старый MAC, они будут пытаться отправлять пакеты на ваш IP-адрес на старый MAC. Через некоторое время всё равно запись в кэше протухнет, и они уже автоматически будут вынуждены повторить запрос «у кого из вас такой IP-шник, скажите свой MAC», и будут уже посылать пакеты на новый адрес. Поэтому если вдруг вы меняете MAC, например, на сетевой карте, то гипотетически может быть такое, что в течение некоторого времени

некоторые узлы этот момент не отследят. Через некоторое время, после того как привязка устареет, узлы смогут подстроиться под новые адреса. Если вы резолвите какой-то IP-адрес в MAC-адрес, то у вас результат попадает в этот самый кэш, и все пакеты, которые будут идти на этот IP-шник, они будут брать записи из кэша. Можно будет встретить в кэше записи динамические — те, которые у вас автоматически распознались с помощью протокола ARP, или в этот кэш можно пополнять вручную. Например, если вы хотите, чтобы у вас всегда на определённый IP-шник IP-пакеты отправлялись в кадрах на определённый MAC-адрес. В этом случае вы можете сказать: давайте мы сделаем запись, что 10.0.0.3 будет иметь какой-нибудь конкретный MAC-адрес. И ещё бывают такие штуки, что пока вы резолвите запись —

захотелось вам узнать, кто такой на картинке 10.0.0.3, вы отправили запрос, задали всем узлам в сети вопрос «у кого из вас такой IP-шник, скажите свой MAC», и вам пока никто не ответил. Нет смысла слишком часто повторять этот вопрос. Если вдруг вы хотите отправить 2, 3, 5, 10 запросов одновременно, то смысла в этом нет особого. Если вы один вопрос задали в сеть, то следующий, как минимум, через секунду есть смысл повторять, или через две. Для этого вы после того, как один запрос отправили, создаёте в кэше ARP всё равно запись, только временную, на MAC-адрес 00:00:00:00:00:00. И у неё будет специальный тип invalid. Это значит, что не надо повторно отправлять вопросы на этот IP-шник, мы уже занимаемся попыткой разрешения этого адреса в MAC. И если нам это удастся сделать, то через некоторое время эта запись обновится и будет стоять нормальный MAC-адрес, и тип у неё будет уже динамический. А если не получится, то такая запись-заглушка препятствует повторной отправке кадров с запросами ARP на тот же самый IP-шник. Естественно, у такой записи срок жизни будет существенно меньше, чем у обычной нормальной.

Что ещё здесь хочется сказать? Да, про broadcast-ы. Broadcast-ы, как вы видите, здесь именно происходит преобразование IP broadcast-а, directed broadcast-а в broadcast канальный. И здесь же можно будет сказать про то, как преобразуется multicast. Помните, я говорил про то, что в IP есть multicast 224.0.0.0 по /24 маске. Этот multicast немаршрутизируемый. И он работает только в пределах канала. Работает в пределах канала очень просто. Вы берёте в IPv4 01:00:5E, и дальше ещё один битовый нолик. Не спрашивайте, почему этот битовый нолик там есть, но это один битовый нолик, и можно его не писать. И дальше приклеиваете на оставшиеся 23 бита последние 23 бита вашего IP-адреса. Это последние три октета за минусом одного бита.

Если у нас есть адрес, например, 224.0.0.2, это все роутеры, то у него последние 23 бита — это 00:00:02. Такой MAC-адрес будет соответствовать multicast-у IPv4 224.0.0.2. Запоминать это не обязательно, но если вдруг к CCIE будете готовиться, то надо будет запомнить. А так просто любопытный факт, чтобы, если вы знали, что в IPv4 есть multicast, который немаршрутизируемый, как он работает в пределах канала. Вот так и работает. Далее. Когда мы отправляем что вопросы, что ответы, у них будет определённый формат. И этот формат запоминать не надо, но любопытно просто на него посмотреть, чтобы вы понимали, какие возможности у протокола ARP есть и каких нет. Если мы говорим про взаимодействие IP и Ethernet — это 100% случаев использования ARP сегодня,

за исключением Wi-Fi, у которого на самом деле всё то же самое. У него точно такие же IP-шники, точно такие же MAC-адреса, поэтому можно сказать, что Ethernet, что Wi-Fi, что любые другие 802-е сети — они подобным образом будут работать. Мы будем брать и упаковывать ARP в кадры напрямую. Отправляются не IP-пакеты, содержащие ARP-запросы, а кадры, в которых используется такой EtherType-2 вложения 0x0806. И сравните это, например, с IPv4. IPv4 — если мы говорим, что у нас IP-пакеты отправляются, они вкладываются в Ethernet с помощью EtherType-2 вложения 0x0800. Рядышком и IPv4, и ARP находятся в списке EtherType-ов. И дальше сразу — вот здесь идёт заголовок Ethernet,

MAC-адрес получателя, MAC-адрес отправителя, что внутри лежит 0x0806, и сразу после этого идёт заголовок ARP. Первые два байта указывают на тип аппаратного адреса. Если мы говорим про Ethernet, то здесь лежит число 0x0001, это основной протокол, для которого ARP создавался. Если Wi-Fi, то же самое, там единичка. Там всё равно MAC-адрес, обычный стандартный IEEE-шный MAC-адрес. И указывается, какого типа другие адреса будут. Мы резолвим IP-шники в MAC-и, и вот MAC-и — это у нас 0x0001. А то, что IP-шники — это нам нужно указать тип протокольного адреса, P-Type, и здесь будет как раз 0x0800. Двухбайтовое число, которое указывает на то, что мы IPv4-адреса резолвим в Ethernet. Далее. Вот это однобайтовое поле H-LEN —

это длина аппаратного адреса, hardware length. У MAC-адреса у нас традиционно 6 байт, поэтому H-LEN у нас 6 байт. P-LEN — это длина протокольного адреса, 4 байта. IP-адреса у нас 4 байта. Код операции, двухбайтовое поле, от которого по факту вы можете встретить использование только полутора бит. Полутора, да, потому что это не совсем один битик, это скорее два битика, хотя на самом деле да. Количество энтропии, которое здесь можно встретить, оно всего однобитовое. Либо вы указываете там единичку, либо указываете двоечку. Если вы отправляете запрос — «я не знаю MAC-адрес того, кто меня интересует, но я хочу отправить такой запрос» — вы отправляете код операции единичку. Если вы хотите сказать, что вы отвечаете на чей-то запрос, то вы отправляете двоечку. В любом случае там ничего особенно не меняется, за исключением того, какие поля из следующих четырёх по факту будут заполнены,

на какие поля стоит обратить внимание получателю такого пакета. После того как вы первые 8 байт заголовка заполнили, дальше идут четыре поля переменного размера. Что было указано здесь и здесь, оно будет определять, какого размера будут эти поля. Если мы, опять же, говорим про Ethernet — 6-байтовые адреса и IPv4 4-байтовые адреса, то это будет 6 байт, это 4 байта, это снова 6 байт, это снова 4 байта. SHA, Sender Hardware Address — это ваш собственный MAC. Когда вы отправляете свой пакет, вы знаете свой MAC-адрес, и вы указываете свой MAC. SPA, Sender Protocol Address — это вы знаете свой IP-шник, поэтому вы указываете свой IP-адрес. Когда вы отправляете кому-нибудь, фактически вы представляетесь, вы говорите: я IP-шник такой-то,

MAC такой-то. хочу либо задать вопрос, либо ответить на чей-то вопрос. Когда вы будете говорить про то, что у меня такой IP-шник, тут меня кто-то спрашивал, фактически вы заполняете мой IP-шник и мой MAC. Тот, кто получит такой ответ, сможет на него отреагировать. И дальше Target Hardware Address, Target Protocol Address — это то, про что идёт речь. Если вы задаёте вопрос, то вы указываете MAC и IP-шник того, кто вас интересует. IP-шник вы, возможно, знаете, а вот MAC-адрес вы будете спрашивать. Если вы хотите спросить, у кого такой IP-шник, скажите свой MAC, то поле Target Hardware Address вы заполняете нулями. Вы не знаете, какой у него MAC, вы просите ответить на вопрос, какой у него MAC. И если вы хотите ответить на вопрос, что тут кто-то меня спрашивал, у кого такой IP-шник, у меня такой IP-шник, и, соответственно, MAC-адрес у меня вот такой.

Фактически в этом случае вы заполняете и Sender Hardware Address, и Target Hardware Address своим MAC, и Sender Protocol, Target Protocol своим IP-шником. Речь идёт про вас самих. Вы отправляете сообщение, что вы обладаете таким IP-шником. И Sender, и Target в этом случае будете вы сами. ARP позволяет работать в пределах одной среды. И, соответственно, если вы делаете всё по правилам, у вас работает правило: это один канал, один провод, это одна IP-сеть. Если вы нарушаете это правило, то ARP со стандартным своим поведением не позволит работать в такой сети корректно. Смотрите, что получится. Например, у нас есть один коаксиальный сегмент. Соответственно, в этом сегменте у нас 4 компьютера.

И другой сегмент. В нём, например, 3 компьютера. И давайте представим себе, что у нас используется сеть 10.0.0.0/24. И вы хотите эту сеть использовать в двух разных канальных средах. Что в этой ситуации получится? Вот здесь у нас IP-шник .1, здесь .2, здесь .3, здесь .4, здесь .5, здесь .6, здесь .7. И вы хотите связать между собой эти две сети через роутер. Получится ли у вас так сделать? Нет, не получится. Потому что эти узлы будут думать, что все, кто находится с ними в сети 10.0.0.0 по маске /24, находятся с ними в одном канале. Они будут пытаться резолвить их с помощью протокола ARP. ARP у нас в IP не вкладывается. Поэтому все узлы, которые находятся у нас в левой половине сетки 10.0.0.0 по маске /24, они будут пытаться нащупать всех,

включая и правую половину, по протоколу ARP. А ARP-запросы через роутер не проходят. Поэтому в такой ситуации, если вы берёте одну сеть и разделяете её на две части искусственно, нарушаете правило «одна канальная среда — одна IP-подсеть», у вас что-то перестанет работать. Какие-то узлы не смогут понять, что они по факту находятся в разных канальных средах друг с другом, и что им требуется пакеты отправлять на роутер, а не напрямую на получателя. Что делать в этом случае? Есть такой костыль, который называется proxy-ARP. На самом деле, в ситуации, если вы думаете, что вы с получателем находитесь в одной сети, но при этом физически находитесь в разных средах, вам не интересен его настоящий MAC. Вам на самом деле интересно получить MAC-адрес шлюза, чтобы отправить пакет на шлюз. Дальше он его переложит в сторону нужного провода,

и пакет по факту дойдёт до получателя. Представим себе, что у нас есть вот такая штука. У нас был один большой-большой-большой провод. Это был один настоящий большой коаксиал. Всё это дело было классовое когда-то давным-давно. У нас был узел 10.0.0.1, классовый. Он думал, что он находится в десятой сети. И, соответственно, другой узел — 10.0.0.2. Он тоже думал, что он находится в десятой сети. В классовом мире эти два узла работали нормально в общем проводе. Потом мы решили поставить в разрыв роутер и разорвали эту сеть на два отдельных широковещательных домена. Узлы 10.0.1.1 и 10.0.2.2 по-прежнему пытаются нащупать друг друга с помощью протокола ARP. И 10.0.1.1 пытается спросить: у какого узла IP-шник 10.0.0.2, скажите, пожалуйста, свой MAC. В этой ситуации неинтересно знать, какой у него на самом деле MAC. Он у него какой-то есть, но в любом случае кадр на этот MAC отправить будет нельзя. И даже если представить себе,

что MAC у него действительно есть, и даже если мы его знаем, всё равно мы никакой пользы от этого не получим. Более того, гипотетически может быть такое, что у него вообще MAC нету. Представим себе, что здесь какой-нибудь ADSL, и здесь вообще MAC-адресов нету на канальном уровне. Бывают среды, в которых MAC'ов не бывает. Может быть, здесь будет какой-нибудь point-to-point соединение. Здесь всё, что угодно может быть, и совершенно не факт, что тут есть MAC-адреса. Поэтому канальный адрес узла, который находится не в одном канале с нами, нам в принципе не интересен. Но если мы задаём вопрос, какой MAC-адрес у узла с IP-шником 10.0.2.2, мы предполагаем, что он находится с нами в одном канале, потому что мы считаем, что мы находимся всё ещё в классовом мире. И мы видим, что этот IP-шник должен быть с нами в одном канале, хоть по факту он и не находится там. И в этом случае роутер, который находится на границе между этими двумя средами, говорит: я вижу ARP-запрос, который приходит на мой интерфейс.

Это же широковещательный запрос. Я вижу запрос, и в этом запросе идёт вопрос про 10.0.2.2. Роутер, естественно, уже понимает, что он находится в бесклассовом мире. Более того, он понимает, что у него маски /24. Эти товарищи думают, что они по маске /8 работают, а роутер знает, что они по маске /24. И поэтому он видит, что запрос приходит на 10.0.2.2, а этот IP-шник 10.0.2.2 в левой части отсутствует, он вообще принадлежит какому-то другому широковещательному домену. Он вот здесь находится. Тут пришёл запрос, а ответ должен дать кто-то из другой сети. В этой ситуации роутер понимает, что даже если вдруг гипотетически этот ответ будет дан, он тому, кто спрашивает, не сильно поможет. Поэтому он говорит: посылай такие пакеты мне, а я разберусь дальше, что с ними делать. Он отвечает своим адресом.

на вопрос, у кого из вас такой IP-шник, скажите свой Mac. Он, хотя не обладает IP-шником 10.0.2.2, говорит, если вдруг тебя интересует 10.0.2.2, посылай на вот такой вот MAC-адрес и показывает свой собственный Mac. И таким образом получается, что вот этот узел, левый, он спросил, у кого из вас IP-шник 10.0.2.2. Хотя этот IP-шник с ним в одной сети не находится, этот узел получил в ответ какой-то MAC-адрес. И это тот самый MAC-адрес, на который надо отправлять кадры, содержащие пакеты до 10.0.2.2, чтобы эти пакеты роутер переложил в сторону действительного получателя. То есть логика здесь именно в том, что роутер, у которого включен прокси ARP, будет отправлять на запросы адресов, которые находятся в другой сети, ответы со своим MAC-ом, чтобы клиенты, которые хотят посылать пакеты, которые по факту должны уйти в другие сети, посылали такие пакеты

на канальный адрес маршрутизатора. Эта штука, она позволяет обойти проблемы, вызываемые вот этим вот правилом. Если вдруг вы это правило нарушаете, то есть у этого механизма есть ряд очень больших недостатков. То есть, во-первых, в этой ситуации у вас должен работать прокси ARP. Во-вторых, у вас вот этот вот узел, он, соответственно, на все узлы, которые он будет пытаться резолвить, будет пытаться сохранить результаты в кэше. Если вы будете неаккуратно использовать этот механизм, у вас этот кэш разрастется до совершенно неприличных значений. В нормальной ситуации, когда мы используем сравнительно небольшого размера сети, там, слэш 24, к примеру, кэш ARP не бывает очень большой. То есть, ну, сколько у вас узлов может быть в 24 сети? 254 штуки. Вот 254 адреса вам придется запомнить максимум. Если же вы будете, там, вот, например, слэш 8 сетку пытаться таким образом резолвить, то у вас

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

я сейчас описал, что вообще кто может в здравом уме такое придумать, на самом деле это встречается существенно чаще, чем вы можете подумать. И не столько потому, что кто-то подумал, а давайте присоединим вообще все сети в мире умышленно к своему интерфейсу. На самом деле, если вы делаете команду IP ROUT 0.0.0.0.0.0.0.0.0.0.0, и дальше указываете интерфейс, там, допустим, Ethernet 0.0.0, не указывая шлюз, но указывая только интерфейс. Вы ровно это и делаете. То есть вот такая вот команда, она именно такое поведение будет вызывать, что роутер, на котором вы прописываете шлюз по умолчанию без указания IP-шника, шлюза, с указанием только интерфейса, на котором вы резолвите канальные адреса, и резолвятся они вот с помощью ProxyArp. Вот он, соответственно, так и будет делать. Он будет запоминать вообще все API-шники в мире в CacheArp. У вас какой-нибудь клиент запустил торрент,

прекрасно, ваш роутер упал по недостатку памяти, потому что у него CacheArp выжрал. Сколько вот места у вас есть в оперативке, столько и выжрал. Так, я так понимаю, данная топология является примером плохого дизайна, в жизни такого бардака лучше не допускать. Да, вы правильно понимаете. Но иногда бывают сценарии, когда очень хочется так сделать. Я вам показал примеры, когда, скажем, это образцово-показательно неправильно выглядит, когда, ну, вот прям видно глазками, что это бардак, что делать так плохо. Но представьте себе, например, сценарий, когда у вас есть роутер, и у вас есть, соответственно, вот здесь какой-то, не знаю, свитчик. И на этом свитчике у вас сидят юзеры. Раз юзер, два юзер, три юзер, четыре юзер, пять юзер. И у вас тут сеточка есть, там 10, 0, 0, 0, 24. Вот здесь айпишник, точка первая, здесь точка вторая, здесь точка третья, точка четвертая, точка пятая. И к вам приходит запрос сделать так, чтобы компьютер, некоторый компьютер мог

подключиться по VPN на ваш роутер и получить айпишник 10, точка 0, точка 0, точка 6. Вот пользователь говорит, вот я хочу, чтобы так и было, чтобы айпишник у меня был из точно той же самой сети, что и вот тут. Вы можете ему, конечно, попытаться объяснить, что это неправильно. По правилам надо вот на вот этот вот пул VPN адресов сделать отдельную сеть, которая не будет пересекаться с локальной сетью. Но бывают такие пользователи, которые говорят, а нам надо. Вот у нас есть какая-то приложенька, и эта приложенька работает только так, что вот она работает в пределах канальной среды. И ничего вы с этим не сделаете. И действительно бывают такие приложения, то есть они там бывают даже иногда вполне как бы достойно написанные приложения, которые, тем не менее, используют автоматическое обнаружение соседних хостов, и они не умеют работать через маршрутизируемые сети. Они вот умеют работать как бы только в пределах своей айпи-сети. И вот в такой

ситуации вам придется городить огород с прокси-арпом. Что вы должны будете сделать? Вы должны будете сказать, что окей, мы создаем вот здесь вот пул VPN подключений. Мы даем всем VPN подключениям айпишники из той же самой сети 10.0.0.0, какая у нас используется в локальной сети. Давайте нарисую здесь LAN. Дальше. Когда вы создаете VPN подключение, оно имеет, как правило, point-to-point природа. Поэтому у вас вот этот вот компьютер, он просто говорит, все в мире доступно через этот провод, и у него никаких канальных адресов там нет. Более того, когда вы создаете такое VPN подключение, как правило, на роутере создается маршрут до вот этого вот айпишника по 32-й маске, который будет смотреть в сторону вашего вот этого вот VPN подключения. Если вдруг вы будете пытаться с роутера пингать 10.0.0.1, он будет пингаться. 10.0.0.2 будет пингаться. 10.0.0.6 тоже будет пингаться, просто в другую сторону. Но если вы попытаетесь с 10.0.0.1 попингать 10.0.0.6,

у вас ничего не выйдет. Не выйдет именно потому, что 10.0.0.1 будет пытаться резолвить MAC адрес 10.0.0.6, и у него, естественно, ничего не выйдет, потому что у 10.0.0.6 нет MAC вообще. В VPN-туннеле нет MAC адресов. Они там не нужны. И для того, чтобы у 10.0.0.1 было полное представление, что он знает, как добраться до 10.0.0.6 по Ethernet, чтобы он знал какой-то MAC адрес, который с ним будет проассоциирован, вам надо вот здесь вот включить ProxyR на вот этом LAN-интерфейсе. И тогда узел 10.0.0.1 будет орать на всю сеть, у кого из вас айпишник 10.0.0.6, скажите свой MAC. Роутер, у которого такого айпишника нету, будет понимать, что 10.0.0.6 сидит где-то в совсем другом проводе, потому что это виртуальный провод получается, виртуальный туннель. И он будет говорить, ходи через меня. Ты спрашивал, у кого айпишник 10.0.0.6, вот тебе мой MAC-адрес, и, соответственно, направляй трафик на мой MAC-адрес, а я дальше разберусь, что с этим делать. И в такой ситуации у вас получится,

что вы можете организовать одну сеть и использовать её в нескольких разных, назовём это, проводах. В том числе и объединить VPN-пользователей и пользователей локальной сети в одну IP-сеть. Делать так не всегда нужно, но иногда просто выхода нет, приходится делать такое. В целом, если у вас есть возможность не нарушать требования протокола IP, естественно, не надо их нарушать. Но иногда обстоятельства будут превыше вас. Так, что ещё можно хорошего про ARP рассказать? Он может использоваться для всяких служебных нужд. Самая популярная задача для него — это обнаружение конфликтов IP-адресов. Может быть, вы видели, что если вдруг вы берёте и назначаете на два компьютера одинаковый айпишник, на обоих выскакивает сообщение. В сети обнаружен конфликт адресов или повторяющиеся адреса, как-то там Windows это пишет. Такое жёлтенькое сообщение, мерзкое показывается в углу, бесит невозможно. И, соответственно, вы можете использовать ARP

как раз для решения задачи, как вам такое жёлтенькое сообщение показать. Есть два основных механизма, оба используют ARP, и механизмы различаются логикой работы. Первый механизм будет называться ARP probe, он же называется address conflict detection. И используется он в ситуации, когда вы хотите, перед повешением айпишника на интерфейс, убедиться, что он точно свободен. И, как правило, такое поведение предполагает, что если вдруг вы обнаруживаете, что адрес занят, вы просто отказываетесь от взятия этого айпишника. То есть по факту конфликта не произойдёт. Это не столько conflict detection, сколько предотвращение конфликта, если вы понимаете, о чём я. Вы вместо того, чтобы устроить конфликт, аккуратно проверяете, не занят ли адрес, если он занят, отказываетесь от его приобретения. Называется ACD, address conflict detection. Смысл заключается в том, что вы перед тем, как инициализировать адрес на вашем собственном интерфейсе,

у вас есть предположение, что не мешало бы айпишничек определённый хапнуть, и вы отправляете запрос. Запрос с кодом операции единичка. У кого из вас такой айпишник, скажите свой MAC. Source protocol address вы при этом ставите ноль, типа у вас никакого айпишника самостоятельного нету, и target protocol address вы интересуетесь тем айпишником, который вы хотите взять. Target hardware address при этом, естественно, нулевой, и source hardware address вы указываете свой собственный MAC. Если вдруг у кого-то такой айпишник есть, он ответит, он отправит свой собственный MAC в sender hardware address, и мы определим по наличию ответа на наш запрос, что кто-то этот ответ всё-таки отправил, у кого-то такой айпишник есть, и тем самым мы сможем избежать конфликта адресов, отказавшись от назначения айпишника на интерфейс. Это будет выглядеть как то, что вы в интерфейсе настройки IP-адреса вводите айпишник,

нажимаете применить, а система говорит, извините, этот адрес уже используется, выберите другой. Она отказалась от тех настроек, которые администратор ей выдал. Второй режим будет называться gratuitous ARP или ARP announcement. Он используется после инициализации адреса, он как раз нужен для того, чтобы обнаружить конфликт адресов, когда он уже произошёл, если вдруг он произошёл. И, соответственно, он может быть в режиме вопроса или ответа, но смысл будет заключаться в том, что вы отправляете сообщение и вы указываете, что source protocol address и target protocol address — это тот самый айпишник, который вы только что себе назначили. Target hardware address в случае запроса надо будет поставить нулевой, а если вы отправляете ответ, вы указываете target hardware address — это ваш собственный адрес. Смысл в любом случае будет такой, что вы отправляете сообщение: у меня такой айпишник и у меня такой MAC, знаете теперь, что так оно произошло. Если в сети

есть такой же обладатель адреса, он получит такой ARP и увидев, что кто-то внезапно от его айпишника отсылает уведомление, что у меня такой MAC и MAC этот не совпадает с его собственным, он в этом случае покажет коллизию, покажет то, что в сети обнаружены чужие MACи. И соответственно он вам в ответ тоже скорее всего отправит такое же сообщение, что нет, мама, это я, что на самом деле MAC другой, и у вас тогда тоже такое же сообщение выскочит, что в сети действительно уже тоже обнаружен конфликт адресов. Если конфликта не произошло, то отправив сообщение, что у вас такой айпишник и у вас такой MAC, вы его всё равно бродкастом отправляете. Оно всё равно дойдёт до всех участников. И в этом случае все участники смогут обновить свой кэш, несмотря на то, что вы не отвечаете ни на какой запрос, вы просто отправляете сообщение бродкастом, что у меня такой айпишник, у меня такой MAC.

Но, учитывая, что это сообщение идёт бродкастом, оно в любом случае дойдёт до всех-всех-всех участников, и все-все-все участники могут обновить свой кэш ARP. То есть вы бесплатно им послали информацию про то, что такому-то айпишнику соответствует такой-то MAC. Почему бы эту информацию не сохранить? Собственно, отсюда и растёт название. Gratuitous ARP — это бесплатный ARP-ответ, или ARP announcement — это оповещение ARP. Такой замечательный механизм. Также на ARP будут основаны некоторые другие протоколы. В частности, есть протокол RARP — Reverse ARP, который имеет тот же самый формат сообщения, но он делает немножко другую вещь. Само название Reverse ARP намекает на то, что там что-то сделано задом наперёд. И, соответственно, Reverse ARP работает следующим образом. Вы посылаете сообщение, и вы отправляете

сообщение: у кого из вас известен айпишник, соответствующий определённому MACу. То есть я не знаю MAC, но я знаю айпишник. Это нормальный режим. А у RARP наоборот. Я знаю MAC, но я не знаю айпишник. Запрос вида «Скажите мне айпишник, соответствующий определённому MACу», в нормальной ситуации мы не отправляем, потому что это совершенно бесполезное поведение. Однако, когда-то давным-давно этот протокол предлагалось использовать для автоматического назначения IP-адресов. То есть у вас компьютер, он был выключен, и он включился. И вот, соответственно, ему надо каким-то образом IP-шник назначить самому себе. Можно IP-шник и ручками назначить, а можно автоматически с помощью какого-то протокола автоматической настройки сделать это. И вот RARP, это была первая попытка сделать автоматическую настройку хостов. Узел

отправлял свой собственный MAC и спрашивал, не знает ли кто-нибудь, какой IP-шник мне следует назначить. И был какой-то центральный RARP-сервер, у которого была база всех MAC-адресов, и, соответственно, этот сервер рассказывал каждому хосту, какой IP-шник следует ему назначить. Естественно, что эта штука была довольно ненадежная, неудобная в использовании, поэтому очень скоро ее заменил другой протокол BootP, а потом уже и BootP заменил другой протокол, который мы сегодня знаем как DHCP. Не то, чтобы прям заменил, скажем, дополнил. Есть еще и другой протокол, который называется InARP. Если вдруг вы потом, когда-нибудь потом, посмотрите дополнительно наш ролик по Frame Relay, который выложен на нашем сайте, то вы поймете, зачем этот протокол будет нужен. У него тоже какое-то странное название InverseARP. То есть есть ReverseARP, а есть InverseARP. Он тоже заданно наперед работает. Нормальный ARP, он нужен для того, чтобы резолвить MAC-адреса

по известному IP-шнику. И когда нам нужно зарезолвить IP-шник в MAC, мы, соответственно, орем на всю сеть. Мужики, у кого из вас такой IP-шник, скажите свой MAC. InARP работает заданно наперед. Он резолвит IP-шник в MAC не тогда, когда вам это нужно, а до того. Ну, соответственно, возникает вопрос, да, до того, как мы узнаем, что оно нам нужно. Ну, вот InARP работает в таких средах, где нет браткаста. То есть обычный ARP работает в среде, где браткаст есть. Он орет на всю сеть. У кого из вас такой IP-шник, скажите свой MAC тогда, когда это нужно. А InARP работает в ситуации, когда у вас нету браткаста, но есть список всех живых канальных адресов, которые в сети могут быть. То есть во FrameRelay как раз такая ситуация чаще всего и есть. У вас там есть такая штука, как сигнализация, которая притаскивает вам список всех живых соседей на порту с канальными адресами. И вот вы каждому из них отправляете. У меня вот такой IP-шник, у меня вот такой IP-шник.

И, соответственно, вот InARP, он ловит сообщение. У меня вот такой IP-шник и вот такой канальный адрес и складывает их, опять же, в кэш. Ну, логика, да, чем-то похожа на обычный ARP, но обычный ARP работает по браткасту и отправляются сообщения о MAC-адресах тогда, когда это понадобилось, ну, после того, как понадобилось. А в InARP до того, как понадобилось. Есть еще и другие протоколы, которые похожи на ARP, но используют уже другой формат сообщения. Если мы говорим про, например, IPv6, то там ARP нету. Вообще, в IPv6 нет браткастов. И, как следствие, с работой ARP тоже некоторые сложности возникли. Но там за обнаружение канальных адресов из известных IP-шников будет отвечать специальный служебный протокол, который называется NDP. Это подножество протокола ICMPv6. И мы обязательно, конечно же, этот протокол будем изучать. Так, это вот все то,

что хотелось рассказать теоретического про ARP. Давайте посмотрим на то, как это все работает на практике.