сеть

часть 3. ADDRESS RESOLUTION PROTOCOL - ПРОТОКОЛ РАЗРЕШЕНИЯ IPV4-АДРЕСОВ

Thank you for reading this post, don't forget to subscribe!

Address Resolution Protocol IPv4 (ARP) явля­ет­ся одним из таких слу­ча­ев. ARP - это очень про­стой про­то­кол, исполь­зу­е­мый для реше­ния про­бле­мы меж­уров­не­во­го обна­ру­же­ния, не пола­га­ясь на сер­вер любо­го типа. Рису­нок ниже будет исполь­зо­ван для объ­яс­не­ния рабо­ты ARP.

Пред­по­ло­жим, A хочет отпра­вить пакет C. Зная IPv4-адрес C,

203.0.113.12 недо­ста­точ­но, что­бы A пра­виль­но сфор­ми­ро­вал пакет и поме­стил его на канал свя­зи по направ­ле­нию к C. Что­бы пра­виль­но постро­ить пакет, A так­же дол­жен знать:

  • Нахо­дит­ся ли C на том же кана­ле свя­зи, что и A
  • MAC или физи­че­ский адрес C

Без этих двух частей инфор­ма­ции A не зна­ет, как инкап­су­ли­ро­вать пакет в канал свя­зи, поэто­му C фак­ти­че­ски полу­чит пакет, а B про­игно­ри­ру­ет его. Как мож­но най­ти эту инфор­ма­цию? На пер­вый вопрос, нахо­дит­ся ли C на том же кана­ле вязи, что и A, мож­но отве­тить, рас­смот­рев IP-адрес локаль­но­го интер­фей­са, IP-адрес назна­че­ния и мас­ку подсети.

ARP реша­ет вто­рую про­бле­му, сопо­став­ляя IP-адрес назна­че­ния с MAC-адре­сом назна­че­ния, с помо­щью сле­ду­ю­ще­го процесса:

  • Хост A отправ­ля­ет широ­ко­ве­ща­тель­ный пакет каж­до­му устрой­ству в сети, содер­жа­ще­му адрес IPv4, но не MAC-адрес. Это запрос ARP; это запрос A на MAC-адрес, соот­вет­ству­ю­щий 203.0.113.12.
  • B и D полу­ча­ют этот пакет, но не отве­ча­ют, посколь­ку ни один из их локаль­ных интер­фей­сов не име­ет адре­са 203.0.113.12.
  • Хост C полу­ча­ет этот пакет и отве­ча­ет на запрос, сно­ва исполь­зуя unicast пакет. Этот ответ ARP содер­жит как IPv4-адрес, так и соот­вет­ству­ю­щий MAC-адрес, предо­став­ляя A инфор­ма­цию, необ­хо­ди­мую для созда­ния паке­тов в направ­ле­нии C.

Когда A полу­ча­ет этот ответ, он встав­ля­ет сопо­став­ле­ние меж­ду 203.0.113.12 и MAC-адре­сом, содер­жа­щим­ся в отве­те, в локаль­ном кэше ARP. Эта инфор­ма­ция будет хра­нить­ся до исте­че­ния вре­ме­ни ожи­да­ния; пра­ви­ла тайм-аута запи­си кэша ARP раз­ли­ча­ют­ся в зави­си­мо­сти от реа­ли­за­ции и часто могут быть настро­е­ны вруч­ную. Про­дол­жи­тель­ность кэши­ро­ва­ния запи­си ARP - это баланс меж­ду слиш­ком частым повто­ре­ни­ем одной и той же инфор­ма­ции в сети в слу­чае, когда сопо­став­ле­ние IPv4-адре­сов с MAC-адре­са­ми не меня­ет­ся очень часто, и отсле­жи­ва­ни­ем любых изме­не­ний в рас­по­ло­же­нии устрой­ство в слу­чае, когда кон­крет­ный адрес IPv4 может пере­ме­щать­ся меж­ду хостами.

Когда A полу­ча­ет этот ответ, он встав­ля­ет сопо­став­ле­ние меж­ду 203.0.113.12 и MAC-адре­сом, содер­жа­щим­ся в отве­те, в локаль­ный кэш ARP. Эта инфор­ма­ция будет хра­нить­ся до тех пор, пока не исте­чет вре­мя ожи­да­ния; пра­ви­ла для тайм-аута запи­си кэша ARP варьи­ру­ют­ся в зави­си­мо­сти от реа­ли­за­ции и часто могут быть настро­е­ны вруч­ную. Про­дол­жи­тель­ность кэши­ро­ва­ния запи­си ARP - это баланс меж­ду тем, что­бы не повто­рять одну и ту же инфор­ма­цию слиш­ком часто в сети, в слу­чае, когда сопо­став­ле­ние IPv4-MAC-адре­сов меня­ет­ся не очень часто, и идти в ногу с любы­ми изме­не­ни­я­ми в место­по­ло­же­нии устрой­ства, в слу­чае, когда кон­крет­ный IPv4-адрес может пере­ме­щать­ся меж­ду хостами.

Любое устрой­ство, полу­ча­ю­щее ответ ARP, может при­нять пакет и кэши­ро­вать содер­жа­щу­ю­ся в нем инфор­ма­цию. Напри­мер, B, полу­чив ответ ARP от C, может вста­вить сопо­став­ле­ние меж­ду 203.0.113.12 и MAC-адре­сом C в свой кэш ARP. Фак­ти­че­ски, это свой­ство ARP часто исполь­зу­ет­ся для уско­ре­ния обна­ру­же­ния устройств, когда они под­клю­че­ны к сети. В спе­ци­фи­ка­ции ARP нет ниче­го, что тре­бо­ва­ло бы от хоста ожи­да­ния запро­са ARP для отправ­ки отве­та ARP. Когда устрой­ство под­клю­ча­ет­ся к сети, оно может про­сто отпра­вить ответ ARP с пра­виль­ной инфор­ма­ци­ей о сопо­став­ле­нии, что­бы уско­рить про­цесс началь­но­го под­клю­че­ния к дру­гим узлам на том же про­во­де; это назы­ва­ет­ся gratuitous ARP. Gratuitous ARP так­же полез­ны для Duplicate.

Gratuitous ARP так­же полез­ны для обна­ру­же­ния дуб­ли­ру­ю­щих­ся адре­сов (Duplicate Address Detection - DAD); если хост полу­ча­ет ответ ARP с адре­сом IPv4, кото­рый он исполь­зу­ет, он сооб­щит о дуб­ли­ро­ван­ном адре­се IPv4. Неко­то­рые реа­ли­за­ции так­же будут посы­лать серию gratuitous ARPs в этом слу­чае, что­бы предот­вра­тить исполь­зо­ва­ние адре­са или заста­вить дру­гой хост так­же сооб­щить о дуб­ли­ру­ю­щем­ся адресе.

Что про­изой­дет, если хост A запро­сит адрес, исполь­зуя ARP, кото­рый не нахо­дит­ся в том же сег­мен­те, напри­мер, 198.51.100.101 на рисун­ке 5? В этой ситу­а­ции есть две раз­ные возможности:

  • Если D настро­ен для отве­та как прок­си-ARP, он может отве­тить на запрос ARP с MAC-адре­сом, под­клю­чен­ным к сег­мен­ту. Затем A кэши­ру­ет этот ответ, отправ­ляя любой тра­фик, пред­на­зна­чен­ный для E, на MAC-адрес D, кото­рый затем может пере­на­пра­вить этот тра­фик на E. Наи­бо­лее широ­ко рас­про­стра­нен­ные реа­ли­за­ции по умол­ча­нию не вклю­ча­ют прокси-ARP.
  • A может отправ­лять тра­фик на свой шлюз по умол­ча­нию, кото­рый пред­став­ля­ет собой локаль­но под­клю­чен­ный марш­ру­ти­за­тор, кото­рый дол­жен знать путь к любо­му пунк­ту назна­че­ния в сети.

IPv4 ARP - это при­мер про­то­ко­ла, кото­рый отоб­ра­жа­ет interlayer иден­ти­фи­ка­то­ры путем вклю­че­ния обо­их иден­ти­фи­ка­то­ров в один протокол.

ОБНАРУЖЕНИЕ СОСЕДЕЙ IPV6

IPv6 заме­ня­ет более про­стой про­то­кол ARP сери­ей сооб­ще­ний Internet Control Message Protocol (ICMP) v6. Опре­де­ле­ны пять типов сооб­ще­ний ICMPv6:

  • Тип 133, запрос маршрутизатора
  • Тип 134, объ­яв­ле­ние маршрутизатора
  • Тип 135, запрос соседа
  • Тип 136, объ­яв­ле­ние соседа
  • Тип 137, перенаправление

Рису­нок ниже исполь­зу­ет­ся для объ­яс­не­ния рабо­ты IPv6 ND. Что­бы понять рабо­ту IPv6 ND, луч­ше все­го про­сле­дить за одним хостом, посколь­ку он под­клю­чен к новой сети. Хост A на рисун­ке ниже исполь­зу­ет­ся в каче­стве примера.

A нач­нет с фор­ми­ро­ва­ния link local address, как опи­са­но ранее. Пред­по­ло­жим, A выби­ра­ет fe80 :: AAAA в каче­стве link local address.

  • Теперь A исполь­зу­ет этот link local address в каче­стве адре­са источ­ни­ка и отправ­ля­ет запрос марш­ру­ти­за­то­ру на link local multicast address (адрес мно­го­ад­рес­ной рас­сыл­ки для всех узлов). Это сооб­ще­ние ICMPv6 типа 133.
  • B и D полу­ча­ют этот запрос марш­ру­ти­за­то­ра и отве­ча­ют объ­яв­ле­ни­ем марш­ру­ти­за­то­ра, кото­рое явля­ет­ся сооб­ще­ни­ем ICMPv6 типа 134. Этот одно­ад­рес­ный пакет пере­да­ет­ся на локаль­ный адрес кана­ла A, исполь­зу­е­мый в каче­стве адре­са источ­ни­ка, fe80 :: AAAA. 
    • Объ­яв­ле­ние марш­ру­ти­за­то­ра содер­жит инфор­ма­цию о том, как вновь под­клю­чен­ный хост дол­жен опре­де­лять инфор­ма­цию о сво­ей локаль­ной кон­фи­гу­ра­ции в виде несколь­ких флагов.
    • Флаг M ука­зы­ва­ет, что хост дол­жен запро­сить адрес через DHCPv6, пото­му что это управ­ля­е­мый канал.
    • Флаг O ука­зы­ва­ет, что хост может полу­чать инфор­ма­цию, отлич­ную от адре­са, кото­рый он дол­жен исполь­зо­вать через DHCPv6. Напри­мер, DNS-сер­вер, кото­рый хост дол­жен исполь­зо­вать для раз­ре­ше­ния имен DNS, дол­жен быть полу­чен с помо­щью DHCPv6.
  • Если уста­нов­лен флаг O, а не флаг M, A дол­жен опре­де­лить свой соб­ствен­ный IPv6-адрес интер­фей­са. Для это­го он опре­де­ля­ет набор пре­фик­сов IPv6, исполь­зу­е­мых в этом сег­мен­те, иссле­дуя поле инфор­ма­ции о пре­фик­се в объ­яв­ле­нии марш­ру­ти­за­то­ра. Он выби­ра­ет один из этих пре­фик­сов и фор­ми­ру­ет IPv6-адрес, исполь­зуя тот же про­цесс, кото­рый он исполь­зо­вал для фор­ми­ро­ва­ния link local address: он добав­ля­ет локаль­ный MAC-адрес (EUI-48 или EUI-64) к ука­зан­но­му пре­фик­су. Этот про­цесс назы­ва­ет­ся SLAAC.
  • Теперь хост дол­жен убе­дить­ся, что он не выбрал адрес, кото­рый исполь­зу­ет дру­гой хост в той же сети; он дол­жен выпол­нять DAD. Что­бы выпол­нить обна­ру­же­ние повто­ря­ю­ще­го­ся адреса: 
    • Хост отправ­ля­ет серию сооб­ще­ний запро­са сосе­дей, исполь­зуя толь­ко что сфор­ми­ро­ван­ный IPv6-адрес и запра­ши­вая соот­вет­ству­ю­щий MAC-адрес (физи­че­ский). Это сооб­ще­ния ICMPv6 типа 135, пере­да­ва­е­мые с link local address, уже назна­чен­но­го интерфейсу.
    • Если хост полу­ча­ет объ­яв­ле­ние сосе­да или запрос сосе­да с исполь­зо­ва­ни­ем того же адре­са IPv6, он пред­по­ла­га­ет, что локаль­но сфор­ми­ро­ван­ный адрес явля­ет­ся дуб­ли­ка­том; в этом слу­чае он сфор­ми­ру­ет новый адрес, исполь­зуя дру­гой локаль­ный MAC-адрес, и попы­та­ет­ся снова.
    • Если хост не полу­ча­ет ни отве­та, ни запро­са сосе­да дру­го­го хоста, исполь­зу­ю­ще­го тот же адрес, он пред­по­ла­га­ет, что адрес уни­ка­лен, и назна­ча­ет вновь сфор­ми­ро­ван­ный адрес интерфейсу.

УСТРАНЕНИЕ ЛОЖНЫХ СРАБАТЫВАНИЙ ПРИ ОБНАРУЖЕНИИ ПОВТОРЯЮЩЕГОСЯ АДРЕСА

Про­цесс DAD, опи­сан­ный здесь, может при­ве­сти к лож­ным сра­ба­ты­ва­ни­ям. В част­но­сти, если какое-то дру­гое устрой­ство на кана­ле свя­зи пере­да­ет исход­ные паке­ты запро­са сосе­да обрат­но к A, оно будет счи­тать, что это от дру­го­го хоста, тре­бу­ю­ще­го тот же адрес, и, сле­до­ва­тель­но, объ­явит дуб­ли­кат и попы­та­ет­ся сфор­ми­ро­вать новый адрес. Если устрой­ство посто­ян­но повто­ря­ет все запро­сы сосе­дей, отправ­лен­ные A, A нико­гда не смо­жет сфор­ми­ро­вать адрес с помо­щью SLAAC.

Что­бы решить эту про­бле­му, RFC7527 опи­сы­ва­ет усо­вер­шен­ство­ван­ный про­цесс DAD. В этом про­цес­се A будет вычис­лять одно­ра­зо­вый номер, или, ско­рее, слу­чай­но выбран­ную серию чисел, и вклю­чать ее в запрос сосе­дей, исполь­зу­е­мый для про­вер­ки дуб­ли­ро­ва­ния адре­са. Этот одно­ра­зо­вый номер вклю­чен через рас­ши­ре­ния Secure Neighbor Discovery (SEND) для IPv6, опи­сан­ные в RFC3971.

Если A полу­ча­ет запрос сосе­да с тем же зна­че­ни­ем nonce, кото­рый он исполь­зо­вал для отправ­ки запро­са сосе­да вовре­мя DAD, он сфор­ми­ру­ет новый одно­ра­зо­вый номер и попы­та­ет­ся сно­ва. Если это про­изой­дет во вто­рой раз, хост будет счи­тать, что паке­ты зацик­ли­ва­ют­ся, и про­игно­ри­ру­ет любые даль­ней­шие запро­сы сосе­дей с соб­ствен­ным одно­ра­зо­вым номе­ром в них. Если полу­чен­ные запро­сы сосе­дей име­ют одно­ра­зо­вый номер, отлич­ный от того, кото­рый выбрал локаль­ный хост, хост будет пред­по­ла­гать, что на самом деле суще­ству­ет дру­гой хост, кото­рый выбрал тот же адрес IPv6, и затем сфор­ми­ру­ет новый адрес IPv6.

Как толь­ко у него есть адрес для пере­да­чи дан­ных, A теперь тре­бу­ет­ся еще одна часть инфор­ма­ции перед отправ­кой инфор­ма­ции дру­го­му хосту в том же сег­мен­те - MAC-адрес при­ни­ма­ю­ще­го хоста. Если A, напри­мер, хочет отпра­вить пакет в C, он нач­нет с отправ­ки multicast сооб­ще­ния запро­са сосе­да на C с запро­сом его MAC-адре­са; это сооб­ще­ние ICMPv6 типа 135. Когда C полу­ча­ет это сооб­ще­ние, он отве­тит с пра­виль­ным MAC-адре­сом для отправ­ки тра­фи­ка для запро­шен­но­го IPv6-адре­са; это сооб­ще­ние ICMPv6 типа 136.

В то вре­мя как преды­ду­щий про­цесс опи­сы­ва­ет объ­яв­ле­ния марш­ру­ти­за­то­ра, отправ­ля­е­мые в ответ на запрос марш­ру­ти­за­то­ра, каж­дый марш­ру­ти­за­тор будет пери­о­ди­че­ски отправ­лять объ­яв­ле­ния марш­ру­ти­за­то­ра на каж­дом под­клю­чен­ном интер­фей­се. Объ­яв­ле­ние марш­ру­ти­за­то­ра содер­жит поле lifetime, ука­зы­ва­ю­щее, как дол­го дей­ству­ет объ­яв­ле­ние маршрутизатора.