69587

ARP

Практическая работа

Информатика, кибернетика и программирование

Теоретическая возможность взаимодействия в составных сетях, как следует из рассмотренных ранее тем, существует. Для более детального изучения данного процесса необходимо перейти к изучению его отдельных составляющих. Последовательное рассмотрение этапов взаимодействия при передаче...

Русский

2014-10-07

2.54 MB

2 чел.

ARP

Теоретическая возможность взаимодействия в составных сетях, как следует из рассмотренных ранее тем, существует.  Для более детального изучения данного процесса необходимо перейти к изучению его отдельных составляющих. Последовательное рассмотрение этапов взаимодействия при передаче пакета в составных сетях указывает на наличие стандартных процедур сопровождающих данный процесс. Одной из них является выбор маршрута передачи пакета на роутере в зависимости от адреса получателя.

Для систематизации и упорядоченного рассмотрения типов процедур воспользуемся моделью OSI. С одной стороны известно, что сетевой уровень является сетенезависимым, т.е. его работа не контролируется и не зависит от канального уровня. С другой – продвижения пакета в составных сетях, при более детальном рассмотрении выглядит как постоянная передача пакета в какой либо канальной сети (физическом сегменте) в зависимости от выбора маршрута передачи на роутере. Другими словами – третий уровень OSI работает на маршрутизаторах, тогда как второй (канальный) уровень работает при передаче пакетов между этими же маршрутизаторами. Рассматривая вопрос о механизме взаимодействия между узлами в составной IP сети, выделим следующие разновидности взаимодействия:

  1.  Передача пакета в рамках одной канальной сети без применения масок
  2.  Передача пакета в рамках одной канальной сети при использовании масок
  3.  Передача пакета через составную сеть без применения масок
  4.  Передача пакета через составную сеть при использовании масок

Начнем с рассмотрения продвижения пакета в рамках одной сети без масок. В качестве примера сети используем схему:

 

Пусть два узла подключены к одному коммутатору. Для простоты дадим им адреса в сети класса С. Очевидно, что, судя по адресам, эти узлы находятся в одной IP сети, следовательно, логично ожидать, что они находятся в одной канальной сети, что и соответствует действительности (как видно из рисунка ), т.е. IP адреса заданы узлам правильно. Пусть узел A имеет пакет, предназначенный для узла B, т.е. пакет для узла 192.168.0.89. Для начала возникает вопрос, откуда берется такой пакет? Очевидно, это связано с работой приложений на узле А. Например, пользователь узла А запустил Internet Explorer и указал в адресной строке, что хочет посетить WEB сервер на узле 192.168.0.89. Т.е., узел, начинающий коммуникации в IP сети получает адрес того узла, с которым должен обменяться пакетами от пользователя. Возможны и другие сценарии, например, однажды настроив свою клиентскую почтовую программу на получение электронной почты с некоторого адреса, пользователь впоследствии не указывает адреса, а лишь просит доставить почту, но и в этом случае, по сути, адрес того узла, с которым необходимо осуществить взаимодействие  задается пользователем, а не определяется программным обеспечением стека TCP/IP. Возможен и такой вариант – установив программу ICQ, пользователь не вводит адрес того сервера, которому необходимо отправлять сообщения, но этот адрес изначально настроен в самом дистрибутиве ICQ клиента. В любом случае, стек узла, начинающего взаимодействие получает адрес того, кому передавать пакеты как некоторые исходные данные,  от пользователя ли непосредственно или из-за настройки пользовательского программного обеспечения, сделанной либо, снова таки, самим пользователем или производителем клиентского программного обеспечения. Адрес может быть задан пользователем не в явном виде, а например, в виде имени узла, например: www.yandex.ru. Это не принципиально отличается от предыдущих примеров, так как такое имя сначала с помощью специальных сетевых служб снова таки преобразуется к IP адресу, а затем начинается взаимодействие.

Т.е. к началу взаимодействия узел А знает IP адрес узла В. Например, IP адрес узла В известен пользователю узла А или помещен в переменную системного реестра ОС на узле А.

Теперь узел А должен решить, что делать с пакетом: может быть пакет можно доставить на канальном уровне непосредственно получателю, если получатель с ним в одной канальной сети, а возможно необходимо передать пакет маршрутизатору, если узел – получатель с отправителем разных канальных сетях. Как узнать узлу А в одной ли с ним канальной сети узел В? - С помощью IP адресов – их специально назначают таким образом, чтобы те, кто в одной канальной сети имели адреса в одной IP сети, и наоборот. Поэтому узел А поступает следующим образом: зная свой IP адрес, он может вычленить из него номер своей сети, пользуясь техникой классов: 192.168.0.0. Зная адрес получателя, узел А может из его адреса тоже вычленить номер его сети, пользуясь, опять таки, техникой классов: 192.168.0.0. Если эти номера сетей совпадают – отправитель и получатель в одной IP сети, следовательно, и в одной канальной сети, т.е. пакет можно передавать непосредственно получателю, с помощью кадров канального уровня, если номера сетей не совпадают – необходимо передавать пакет маршрутизатору.

В нашем случае номера сетей совпадают, следовательно, узел А может передать пакет узлу В, просто упаковав его в кадр канального уровня и адресовав кадр канального уровня узлу В.

Как сгенерировать подобный кадр? Для этого необходимо знать МАС адрес отправителя кадра, МАС адрес получателя кадра, и значение поля EtherType, зарезервированное для указания того, что в кадре канального уровня передается именно IP пакет. Перед тем как продолжить формирование кадра канального уровня прокомментируем форматы кадров Ethernet с точки зрения возможности инкапсуляции IP протокола.

Raw 802.3

6

6

2

46-1500

4

DA

SA

L

DATA

FCS

Тип кадра 802.3 Raw не используется для передачи IP датаграмм т.к. данный тип не позволяет указать протокол верхнего уровня в кадре ethernet  и поэтому его можно использовать только для передачи пакетов третьего уровня только одного, оговоренного типа – ipx,  для которого данный тип кадра и был разработан.

Ethernet DIX (Ethernet II)

6

6

2

46-1500

4

DA

SA

T

DATA

FCS

Тип кадра Ethernet II используется для передачи IP датаграмм в соответствии с RFC894: «IP datagrams are transmitted in standard Ethernet frames. The type field of the Ethernet frame must contain the value hexadecimal 0800. The data field contains the IP header followed immediately by the IP data.»

Т.е. поле «Type» кадра Ethernet должно содержать шестнадцатеричное значение 0800. Это указывает на то, что поле «Data» содержит IP заголовок и далее  данные IP пакета.

802.3/LLC

6

6

2

1

1

1(2)

46-1497

4

DA

SA

L

DSAP

SSAP

Control

DATA

FCS

Несколько позже появился RFC948, который позволял два метода упаковки IP пакета в кадр Ethernet: описанный выше и с применением обычного кадра 802.3/LLC, при этом должен использоваться LLC в режиме LLC1, а поля SSAP и DSAP должны быть равны  «96»:

 IP datagram’s are transmitted in standard 802.2/802.3 LLC Type 1 Unnumbered Information format with the DSAP and SSAP fields of the 802.2 header set to 96, the IEEE assigned global SAP value for IP.

Т.е. IP датаграмма передается в стандартном ненумерованном кадре LLC  Тип 1 802.2/802.3, с указанием в заголовке 802.2 (LLC) SSAP = 96, SSAP = 96. 96 это идентификатор для IP протокола присвоенный IEEE.

Ethernet SNAP (SubNetwork Access Protocol)

6

6

2

1

1

1

3

2

46-1492

4

DA

SA

L

DSAP

SSAP

Control

OUI

T

DATA

FCS

Далее появляется RFC1042, заменяющий собой RFC948, который определяет, что для всех сетей 802 необходимо пользоваться заголовком SNAP после заголовка LLC, его поле type должно быть равно 0800, а в Ethernet можно по прежнему пользоваться методом, описанным в RFC894.

Итак, как сформировать все поля кадра Ethernet мы знаем, но! Для генерации заголовка канального уровня, узел А должен знать аппаратный адрес узла В, а он его, разумеется, не знает, так как сверху (от пользователя) поступил IP адрес узла В, но не МАС адрес. Что же делать?

Очевидно, можно просто передать данный IP пакет в широковещательном кадре канального уровня. Но если все пакеты передавать в широковещательных кадрах, это плохо отразится на функционировании локальной сети, так как такие кадры затопляют сети на коммутаторах, во многом сводя на нет преимущества от их использования, кроме того, такие кадры нагружают процессор и память каждого узла обработкой заголовков третьего уровня.  Было бы полезно все же узнать МАС адрес станции В, а уже затем передавать кадры направленно на канальном уровне. Для выполнения этой задачи в стеке TCP/IP применяется специальный протокол: ARPAddress Resolution Protocol, протокол разрешения адресов, RFC826. С помощью этого протокола станция может, зная IP адрес узла в своей сети узнать аппаратный адрес этого узла.

Рассмотрим заголовок пакета ARP

2 байта

2 байта

Hardware Address Type

Protocol Type

Length of hardware address

Length of protocol address

Opcode 

Далее следуют: аппаратный адрес отправителя, сетевой адрес отправителя, аппаратный адрес получателя, сетевой адрес получателя, все эти поля имеют переменную длину, определяемую значениями полей Length of hardware address и Length of protocol address

Чтение пакета записанного в виде таблицы осуществляется следующим образом. Первая строка - это начало пакета, т.е. пакет начинается с двухбайтового поля «Hardware Type», следующие 2 байта пакета (или 3-й и 4-й байт с лева направо) это поле «Protocol Type». Вторая строка – это продолжение пакета, просто в виде строк формат пакета легче записывать на ограниченном в ширину пространстве, например листе А4 . Т.е. следующие поля в заголовке кадра ARP, это однобайтовое «Length of hardware address», или в общих координатах – это 5-й байт от начала заголовка. Далее идет однобайтовое поле «Length of protocol number»  – 6-й байт. Следующие поле длиной 2 байта называется «Opcode» – 7-й и 8-й байты. Теперь подробнее о каждом поле заголовка.

Hardware Address Typeтип аппаратного адреса. В этом поле указывается тот канальный протокол, для которого ARP производит разрешение аппаратного адреса в адрес третьего уровня. Наличие этого поля показывает, что ARP предназначен не только для решения описанной выше задачи в Ethernet или другой сети 802, но и вообще говоря, для выполнения преобразования адресов для любой сети канального уровня. За каждым канальным уровнем зарезервировано значение этого поля, в частности за Ethernet зарезервировано значение «1». Все зарезервированные значения можно получить в RFC1700 стр.163. RFC1700 - Assigned Numbers (назначенные константы) является универсального справочником по константам стека TCP/IP, в этом документе описаны идентификаторы (номера) протоколов, портов, требование по нумерациям бит в кадрах и т.п. Дальнейшее изучение  стека TCP/IP неразрывно связано с использованием данного RCF.

Вот эти значения:

 1 Ethernet (10Mb)     [JBP]

 2 Experimental Ethernet (3Mb)   [JBP]

 3 Amateur Radio AX.25    [PXK]

 4 Proteon ProNET Token Ring   [JBP]

5 Chaos      [GXP]

 6 IEEE 802 Networks    [JBP]

7 ARCNET      [JBP]

8 Hyperchannel     [JBP]

9 Lanstar     [TU]

 10 Autonet Short Address   [MXB1]

11 LocalTalk      [JKR1]

 12 LocalNet (IBM PCNet or SYTEK LocalNET)  [JXM]

 13 Ultra link     [RXD2]

14 SMDS      [GXC1]

 15 Frame Relay     [AGM]

16 Asynchronous Transmission Mode (ATM)  [JXB2]

17 HDLC      [JBP]

 18 Fiber Channel    [Yakov Rekhter]

 19 Asynchronous Transmission Mode (ATM)  [Mark Laubach]

 20 Serial Line     [JBP]

 21 Asynchronous Transmission Mode (ATM)  [MXB1]

 Protocol Type – тот протокол третьего уровня, для которого производит преобразование протокол ARP. Значения этого поля полностью соответствуют номерам протоколов третьего уровня, используемым в поле type кадра канального уровня IEEE 802 и описаны в RFC1700 p.168. использование этого поля подчеркивает тот факт, что протокол ARP может использоваться не только для преобразования IP адреса в адрес канального уровня, но и адреса любого сетевого протокола в адрес любого канального протокола, что подчеркивает универсальность протокола ARP.

 

Length of hardware address – длина аппаратного адреса в байтах. В случае применения ARP в сетях стандарта 802 значение этого поля очевидно равно «6», но возможно и использование МАС адресов длиной 2 байта. В других канальных сетях возможно будут применены аппаратные адреса другой длины. Зачем это поле необходимо? Очевидно, в поле данных пакета ARP будут фигурировать канальные адреса интерфейсов. Так как длина адреса может быть разной в разных базовых сетевых технологиях, то после передачи в поле данных ARP какого-то аппаратного адреса, пришлось бы использовать флаг окончания адреса (так как длина адреса заранее неизвестна). Существует ряд способов выставления подобных флагов (вспомнить все способы), но одним из наиболее простых способов показать окончание поля неизвестной длины является указывание заранее длины этого поля (так сделано в 802.3/LLC). Может показаться, что указание поля Hardware Address Type избавляет от необходимости указывать длину аппаратного адреса, так как тип канального протокола уже определен, а следовательно и длина адреса уже известна, но ведь возможны такие канальные протоколы, которые пользуются адресом не фиксированной длины (например IEEE 802), так что знание протокола канального уровня еще не означает автоматически знание длины аппаратного адреса. Применение этого поля еще раз подчеркивает универсальность ARP – этот протокол готов работать поверх тех канальных протоколов, которые имеют аппаратные адреса не фиксированной длины.

 

Length of protocol address – длина адреса третьего уровня в байтах. Полностью идентично по смыслу предыдущему полю. Так как возможно существуют протоколы третьего уровня, использующие адреса переменной длины, то для того, чтобы ARP работал с такими протоколами и в поле данных ARP не приходилось ставить флаги окончания адреса, используется поле Length of hardware address.

 

Opcode – тип проводимой операции. Определено несколько значений кодов, нас сейчас интересует два: 00 01 – запрос информации, 00 02 – ответ на запрос.

 Теперь об адресах: так как нас все же интересует нахождение МАС адресов в Ethernet на основании знания IP адресов, то формат пакета, записанный выше в общем случае, мы может переписать для нашего частного случая, когда известны длины адресов.  Вот что из этого получится:

2 байта

2 байта

Hardware Address Type (01)

Protocol Type (08 00)

Length of hardware addr (06)

Length of protocol addr (04)

Opcode

Sender Hardware Address

Sender Hardware Address (продолжение)

Sender Protocol Address

Sender Protocol Address (продолжение)

Target Hardware Address

Target Hardware Address (продолжение)

Target Protocol Address

или представим в виде инкапсуляции внутрь кадра Ethernet II:

Итак, формат кадра ARP известен. Изучим практическое применение каждого поля в пакете ARP. Для этого рассмотрим поэтапно работу протокола ARP.

Станция А, имеющая кадр для отправки станции В знает ее IP адрес и не знает ее МАС адреса. Станция А формирует ARP пакет, который на канальном уровне послан по широковещательному адресу от имени станции А, поле EtherType этого кадра равно 08 06 – зарезервировано за ARP. Станция А уверена, что такой кадр достигнет всех станций в своей сети, следовательно и искомую станцию, а то, что А и В в одной сети уже известно из анализа их IP адресов.

Внутри этого кадра канального уровня, как следует из значения поля TypeARP пакет. У него заполнены поля Hardware Address Type, Protocol Type, Length of Hardware Address, Length of Protocol  Address. Поле Opcode устанавливается равным 00 01, что означает, что данный пакет – ARP запрос. В поле Sender Hardware Address станция А указывает свой аппаратный адрес, в поле Sender Protocol Address – свой IP адрес, в поле Target Hardware Address необходимо указать аппаратный адрес станции В, так как станция А его не знает, то заполняет это поле нулями, подчеркивая, что это поле и есть собственно вопрос, из за которого послан ARP пакет, в поле Target Protocol Address указывается IP адрес станции В.

Рассмотрим, как будет передан и обработан такой пакет. Коммутаторы доставят этот кадр всем сетевым адаптерам, в сети, все адаптеры примут кадр, так как адрес получателя в нем широковещательный. На всех узлах сети содержимое кадра, т.е. ARP пакет будет передан программному модулю, обслуживающему ARP. Каждая станция посмотрит в поле Target Protocol Address, чтобы выяснить, не ей ли предназначен данный ARP пакет, и только та станция (В), которую спрашивают о ее МАС адресе продолжит обработку пакета, остальные его отбросят. Эта станция сгенерирует в ответ кадр канального уровня, в который вложит ARP ответ следующим образом: в поле DA кадра канального уровня поставит значение поля SA из принятого кадра с ARP запросом (т.е. ARP ответ уже не шлется широковещательно), в поле SA поставит свой МАС адрес, в поле Type установит 08 06, и начнет заполнять заголовок ARP пакета. Поля Hardware Address Type, Protocol Type (08 00), Length of hardware address, Length of protocol address берутся из запроса, так как два узла по определению находятся в одной сети и пользуются одним протоколом третьего уровня, в поле Opcode записывается 00 02 (Reply), в поле Sender Hardware Address записывается свой МАС адрес (станции В, это и есть собственно ответ на ARP запрос), в поле Sender Protocol Address записывается свой IP адрес (станции В, так как станция А могла послать много ARP запросов разным станциям, ей необходимо знать, станция с каким IP адресом ей ответила), в полях Target Hardware Address и Target Protocol Address записываются соответствующие адреса станции А.

Таким образом данный кадр канального уровня получит только станция А и узнает из принятого ARP ответа МАС адрес станции В, в свою очередь станция В из полученного ARP запроса узнает МАС адрес станции А (МАС адрес, соответствующий ее IP адресу) и таким образом станции В не придется в свою очередь слать ARP запрос станции А, чтобы передать ей IP пакеты в ответ на ее IP пакеты. После этого станция А может слать кадры канального уровня станции А, укладывая в них IP пакеты для станции В направлено, а не широковещательно, станция В в свою очередь может делать то же самое для станции А. 

Рассмотрим фрагмент трафика иллюстрирующего описанные выше этапы взаимодействия.

Расшифруем кадр выделенный курсором (Запись № 1) используя шестнадцатеричную форму представления и вышеприведенную схему инкапсуляции ARP протокола в кадры Ethernet II:

  1.  первые шесть байт это MAC адрес получателя, значение FF FF FF FF FF FF – говорит о том, что это широковещательный кадр канального уровня. Т.е. он посылается всем участникам канального сегмента сети. Это поле относится к кадру Ethernet II.
  2.  следующие шесть байт - это MAC адрес отправителя, его значение

00 02 44 08 EF 7E указывает на интерфейс (сетевую карту компьютера), отправивший данный пакет. Это поле также относится к кадру Ethernet

  1.  следующие 2 байта – это поле Type заголовка Ethernet II, указывает какой протокол инкапсулирован внутрь пакета. Значение 08 06 говорит о том, что это протокол ARP

Дальше начинается пакет ARP:

  1.  два байта 00 01 (поле Hardware Address Type)  показывают, что ARP работает внутри сети Ethernet
  2.  следующие два байта 08 00 (поле Protocol Type)  показывают, что ARP работает по разрешению адресов IP протокола
  3.  следующий байт 06 (поле Length of hardware address) показывает, что длина адреса канального уровня (MAC адреса) 6 байт.
  4.  следующий байт 04 (поле Length of protocol address) показывает, что длина адреса протокола для которого работает ARP (IP протокол) 6 байта.
  5.  следующие два байта 00 01 (поле Opcode)  показывают, что тип кадра ARP соответствует режиму «Запрос». Т.е. станция выясняет MAC адрес одного из участников канальной сети с известным IP адресом.
  6.  следующие шесть байт 00 02 44 08 EF 7E (поле Sender Hardware Address) указывают MAC адрес стации отправителя. С одной стороны MAC адрес отправителя указывается и в заголовке кадра Ethernet, но эти два поля могут не совпадать в случае использования технологии Прокси ARP (об этом позднее).
  7.  следующие четыре байта C0 A8 00 59 hex или в десятичной форме 192 168 00 89 (поле Sender Protocol Address) указывают IP адрес станции отправителя, эта информация нужна для того чтобы станция получатель пакета «ARP запрос» не дублировала операцию разрешения MAC адреса по известному IP адресу при формировании IP пакета в адрес станции 192.168.0.59.
  8.  следующие шесть байт 00 00 00 00 00 00 (поле Target Hardware Address) указывают MAC адрес стации получателя. Это пустые байты, т.к. адрес пока неизвестен, но исключить это поле из кадра нельзя – стандарт требует единообразия полей при любом типе операции.
  9.  следующие четыре байта C0 A8 00 01 hex или в десятичной форме 192 168 00 01 (поле Target Protocol Address) указывают IP адрес станции получателя, эта информация нужна для идентификации станции которой предназначается это запрос с точки зрения 3-го уровня. Дело в том, что рассматриваемый нами пакет имеет широковещательный MAC адрес получателя – т.е. это кадр примут все участники канального сегмента сети. Но отвечать на запрос будет только станция чей IP адрес совпадет со значением 192.168.0.1.
  10.  следующие восемнадцать байт с одинаковым значением 00 – это выравнивание, ли дополнение до минимального размера поля данных Ethernet II. Т.к. минимальное значение поля Data в Ethernet II составляет 46 байт, а мы использовали в предыдущих полях 28 байт = 2+2+1+1+2+6+4+6+4, следовательно, заполнение составит 46-28 = 18 байт.

Теперь декодируем ответ:

Расшифруем кадр выделенный курсором (Запись № 2) используя шестнадцатеричную форму представления и схему инкапсуляции ARP протокола в кадры Ethernet II:

  1.  первые шесть байт это MAC адрес получателя, значение 00 02 44 08 EF 7E – говорит о том, что кадр отправляется только в адрес одной станции, а именно – станции сформировавшей ARP-запрос из рассмотренного выше примера.
  2.  следующие шесть байт - это MAC адрес отправителя, его значение

00 03 47 EA 42 59 указывает на интерфейс (сетевую карту компьютера), отправивший данный пакет. Это поле также относится к кадру Ethernet

  1.  следующие 2 байта – это поле Type заголовка Ethernet II, указывает какой протокол инкапсулирован внутрь пакета. Значение 08 06 говорит о том, что это протокол ARP

Дальше начинается пакет ARP:

  1.  два байта 00 01 (поле Hardware Address Type)  показывают, что ARP работает внутри сети Ethernet
  2.  следующие два байта 08 00 (поле Protocol Type)  показывают, что ARP работает по разрешению адресов IP протокола
  3.  следующий байт 06 (поле Length of hardware address) показывает, что длина адреса канального уровня (MAC адреса) 6 байт.
  4.  следующий байт 04 (поле Length of protocol address) показывает, что длина адреса протокола для которого работает ARP (IP протокол) 6 байта.
  5.  следующие два байта 00 02 (поле Opcode)  показывают, что тип кадра ARP соответствует режиму «Ответ». Т.е. станция выясняет MAC адрес одного из участников канальной сети с известным IP адресом.
  6.  следующие шесть байт 00 03 47 EA 42 59 (поле Sender Hardware Address) указывают MAC адрес стации отправителя.
  7.  следующие четыре байта C0 A8 00 01 hex или в десятичной форме 192 168 00 01 (поле Sender Protocol Address) указывают IP адрес станции отправителя.
  8.  следующие шесть байт 00 02 44 08 EF 7E (поле Target Hardware Address) указывают MAC адрес стации получателя.
  9.  следующие четыре байта C0 A8 00 59 hex или в десятичной форме 192 168 00 89 (поле Target Protocol Address) указывают IP адрес станции получателя, эта информация нужна для идентификации IP интерфейса станции которой предназначается это ответ с точки зрения 3-го уровня.
  10.  следующие восемнадцать байт с одинаковым значением 20 – это выравнивание, ли дополнение до минимального размера поля данных Ethernet II. Т.к. минимальное значение поля Data в Ethernet II составляет 46 байт, а мы использовали в предыдущих полях 28 байт = 2+2+1+1+2+6+4+6+4, следовательно заполнение составит 46-28 = 18 байт.

Продолжим анализ трафика. Рассмотрим продолжение взаимодействия между станциями после работы ARP протокола.

 

Как видно из Записи № 3, дальнейшее взаимодействие выражается в отправке станцией 192.168.0.89 кадра имеющего IP заголовок в адрес станции 192.168.0.1. При этом в кадре канального уровня указываются соответствующие MAC адреса взаимодействующих станций. Это стало возможно благодаря, рассмотренной выше, успешной работе протокола ARP по разрешению известных IP адресов в MAC адреса взаимодействующих станций.

Приведенные выше примеры трафика можно получить при помощи специального ПО (в нашем случае это SniferPro), но существуют и другие способы наблюдения за работой протокола ARP. Речь идет об утилитах операционной системы. Рассмотрим программную реализацию протокола ARP в операционной системе Microsoft Windows XP/ Windows 2003 Server и познакомимся с работой системных утилит позволяющих контролировать и настраивать программный модуль  ARP протокола, выполняемый на узле.  В качестве примера возьмем взаимодействие двух станций A и B принадлежащих к одной IP сети.

Пусть станция А узнала МАС адрес станции В. Должна ли она в следующий раз, когда захочет передать ей IP пакет, снова посылать ARP запрос? Очевидно, что станции А (и В) имеет смысл запомнить полученную в ARP ответе информацию, а не повторять ARP запрос каждый раз. Информация, полученная из ARP ответов сохраняется в специальном кэше, называемом ARP-кэш. В Windows (а так же обычно и в других OC, поддерживающих TCP/IP) есть специальная утилита для работы с ARP кэшем, утилита называется ARP.exe.

Рассмотрим использование утилиты ARP.exe

Ключ –а показывает текущие записи в таблице ARPARP кэшэ).

Просмотр таблицы ARP выполняется для диагностики работы сети, например для сверки соответствия MAC адреса и IP адреса в таблице с фактическими значениями. Так же с помощью данного ключа можно оценить произошло ли взаимодействие по разрешению MAC адресов между узлами внутри сети, и если нет – начать поиск неисправности с помощью анализатора протокола.

Ключ –N позволяет уточнить интерфейс ARP таблица  которого интересует  в данный момент

Ключ –d удаляет все записи либо указанную запись из таблицы ARP 

 

Возможность редактирования таблицы ARP позволяет проверять надежность работы ARP по разрешению MAC адресов, кроме этого при создании статических записей в ARP таблице (ключ –s) таймаут не рассчитывается, т.е. статическая запись существует до перезагрузки системы, либо до выключения интерфейса – при этом удалить ее можно только ключом –d.

Ключ –s добавляет статическую запись в таблицу ARP

Возможность добавления записей в таблицу ARP используется при диагностике сети. Так же этот ключ применяется когда в сети блокируется широковещание на канальном уровне (по разного рода причинам), в этом случае взаимодействующие хосты оснащаются статическими ARP таблицами, загружаемыми при старте системы.

По умолчанию запись в таблице ARP сделанная самим протоколом ARP в результате взаимодействия с удаленным хостом является динамической, т.е. срок жизни такой записи (таймаут) ограничивается в настройках ОС (обычно минутами). Это делается на случай, если удаленный хост изменит свой IP адрес, либо произойдет замена сетевого адаптера. После истечения таймаута динамическая запись автоматически удаляется системой, и разрешение происходит по новой в случае обращения к данному хосту. В ОС MS Windows настройка таймаута для записей таблицы ARP осуществляется через системный реестр добавлением переменной ArpCaheLife типа REG_DWORD по адресу HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters. Значение переменной указывает время жизни записи в секундах. Максимальное значение достаточно велико – примерно 136 лет (и несколько месяцев).

Системное значение таймаута по умолчанию: 2 минуты для не используемых записей и 10 минут для используемых, т.е. тех записей, работа с которыми продолжается но ARP ответ был получен не далее чем 10 минут назад.

Статическая запись в таблицу ARP заносится либо из командной строки администратором ситемы, либо в результате выполнения сценария написанного администратором системы и запущенного от его имени. Таймаут в этом случае не действует. Запись удаляется администратором при помищи ключа –s, либо при перезагрузке системы либо интерфейса.

 Рассмотрим пример работы ARP протокола с динамическими записями. Проанализируем захват трафика между двумя узлами при условии, что запись в ARP кэше вызывающего узла сначала отсутствует, а затем присутствует.

Вот ARP кэш до нчала взаимодействия:

C:\arp -a

Не найдены записи в таблице ARP

Вот трафик между 192.168.0.89 и 192.168.0.1 (попытка зайти на WEB сервер):

Вот содержимое кэша ARP после взаимодействия:

C:\arp -a

Интерфейс: 192.168.0.89 --- 0x2

 Адрес IP              Физический адрес      Тип

 192.168.0.1           00-03-47-ea-42-59     динамический

Вот трафик попытки вновь после этого обратиться к тому же WEB серверу:

Обратите внимание, перед нами по сути тот же самый трафик прикладного протокола из 17 пакетов, но перед ним нет трафика ARP. (оба файла с трафиком прилагаются и называются WithARP.cap и WithoutARP.cap).

Подождем две минуты – убедимся, что кэш ARP снова пуст:

C:\arp -a

Не найдены записи в таблице ARP

 Теперь рассмотрим тот же пример с двумя станциями в одной сети но с использованием масок подсети.

Маски узлов одинаковы, так как они члены одной сети,  а маска по сути лишь показывает, как много узлов находятся вместе с данным в его подсети, поэтому все узлы одной подсети должны иметь идентичное представление о том, кто с ними находится в одной подсети.

Итак, пусть узел А (192.168.0.89/255.255.255.128) имеет пакет для отправки узлу В с IP адресом 192.168.0.1. Когда масок не было, узел А с помощью техники классов определял номер своей сети из своего IP адреса, номер сети получателя из его адреса и сравнивал эти номера сетей. Можно ли распространить ту же логику и на ситуацию с масками? Узел А знает свой IP адрес и свою маску подсети, на основании этого он определяет номер своей сети. Для этого нужно записать IP адрес в двоичной форме, маску в двоичной форме, все биты в адресе, которым соответствуют нулевые биты в маске положить равными нулю – в результате получим номер сети, в которой находится узел А:

Узел:  11000000.10101000.00000000.0|1011001

Маска  11111111.11111111.11111111.1|0000000

Номер сети: 11000000.10101000.00000000.0|0000000 – 192.168.0.0

Такой способ нахождения номера сети, зная IP и маску удобен человеку (насколько это вообще можно считать удобным), но совершенно не удобен для компьютера – слишком сложный и длинный алгоритм. Вместо этого можно поступить проще: номер сети есть произведение по модулю 2 адреса и маски.

Вспомним определение произведения по модулю 2:

, , ,

Если один из сомножителей (неважно какой, пусть для определенности первый) равен 1, то ответ равен второму сомножителю, а если один из сомножителей равен 0, то произведение по модулю 2 равно нулю не зависимо от значения второго сомножителя. Легко видеть, что именно так и работает маска: пока биты в маске равны 1 в номере сети биты совпадают с битами в IP адресе узла из этой сети, как только биты в маске равны 0, в номере сети биты равны нулю независимо от битов в IP адресе узла. Таким образом, станция для выяснения номера своей сети просто умножает по модулю два свой адрес на свою маску, находит таким образом свой номер сети и записывает его в память, чтобы не выполнять этой процедуры всякий раз перед началом взаимодействия.

Итак, номер своей сети известен, необходимо узнать номер сети получателя пакета чтобы сравнить эти номера сетей. IP адрес получателя станция знает (его сообщил пользователь, это уже обсуждалось), но станция не знает маски получателя! Действительно, откуда пользователь знает, как много узлов в одной сети с получателем, на сколько подсетей и с помощью какой маски администратор той сети, где находится узел получатель, разбил свою сеть на подсети ? Станция в принципе не может узнать маску получателя, и как следствие, в принципе не может узнать номер сети получателя чтобы сравнить его со своим номером сети ! Что же делать?

Суть в том, что станции отправителю и не нужно знать номер сети получателя, ей нужно лишь ответить на вопрос, в одной ли она с ней сети или в разных, и на этот вопрос ответить можно. В предыдущих уроках приведен пример решения аналогичной задачи. Задача состояла в нахождении первого и последнего узла некоторой сети, зная номер сети и маску. 

Так что, зная номер своей сети и маску подсети, станция отправитель может найти номера всех узлов своей сети и проверить присутствует ли среди них узел получатель. Или найти номер первого узла, последнего узла и проверить, попадает ли узел получатель в найденный диапазон узлов. Таким образом, задачу все же можно решить, даже при условии, что маску получателя мы не знаем, нам ведь нужно лишь ответить на вопрос в одной ли сети отправитель и получатель а не находить номер сети получателя. Однако предложенный алгоритм снова не слишком удобен для компьютера, рассмотрим более производительный алгоритм.

Предположим, что получатель с нами в одной сети, тогда его маска совпадает с нашей (об этом уже говорилось выше – каждый узел сети должен иметь идентичную информацию о том, с какими адресами он находится в одной сети, следовательно, маски на узлах в одной канальной/IP сети должны совпадать). А раз его маска совпадает с нашей, то умножив по модулю 2 IP адрес узла получателя на нашу маску мы получим предполагаемы номер сети получателя. Если этот номер совпадает с номером сети отправителя, то значит отправитель и получатель действительно в одной сети, если полученный предполагаемый номер сети получателя не совпадает с номером сети отправителя, то это значит, что отправитель и получатель находятся в разных сетях, а предполагаемый номер сети получателя в общем случае не имеет ничего общего с его истинным номером сети, что впрочем, не имеет ни малейшего значения, так как номер сети получателя мы и не собирались искать. Вот почему данный алгоритм дает правильный ответ, ведь по сути он полностью эквивалентен предложенному выше способу, но более приспособлен для вычисления компьютеру. 

Из вышеуказанного следует, что при старте стека TCP/IP в ОС станция умножает по модулю 2 адрес каждого интерфейса на его маску и записывает полученные результаты в памяти как номера сетей своих интерфейсов (пока для простоты положим, что интерфейс один). При необходимости передать пакет узлу с некоторым IP адресом, станция умножает его адрес на свою маску и сравнивает полученный результат с хранимым номером своей сети: если значения совпадают, значит получатель с нами в одной сети, если не совпадают – то получатель с нами не в одной сети.

Вернемся к нашему примеру:

Номер нашей сети:  

Действительно, 

Узел:  11000000.10101000.00000000.0|1011001

Маска  11111111.11111111.11111111.1|0000000

Номер сети: 11000000.10101000.00000000.0|0000000 – 192.168.0.0

Умножаем (по модулю 2) IP получателя на нашу маску: 

Действительно:

Узел:  11000000.10101000.00000000.0|0000001

Маска  11111111.11111111.11111111.1|0000000

Номер сети: 11000000.10101000.00000000.0|0000000 – 192.168.0.0

Т.е. отправитель и получатель находятся в одной сети. Что дальше? А дальше все то же самое – ARP запрос и ARP ответ – в дальнейшем маска не играет никакой роли во взаимодействии, так как нужна была лишь затем, чтобы определить, в одной ли сети находятся узлы или нет.

Описанные выше взаимодействия подтверждают положение о том, что адрес является уникальным самодостаточным идентификатором узла в IP сети, маска не является дополнительным идентификатором, маска лишь помогает узлу понять, кто с ним в одной сети, а кто – нет и соответственно перенаправлять ли пакеты непосредственно в кадрах канального уровня получателю или передавать их маршрутизатору.  Т.е. маска – не некое продолжение IP адреса.

Рассмотрим вопрос -  могут ли два узла иметь одинаковый адрес, при условии, что у них разные маски? Учитывая, что адрес есть уникальный идентификатор, сравним его с паспортом гражданина страны. Т.о. вопрос можно изменить в приложении к паспорту следующим образом:

- могут ли два человека иметь одинаковый номер паспорта, если у них в семье разное количество людей. Ответ однозначный – такого быть не может. С IP адресом – ситуация аналогична – хосты не могут иметь одинаковые IP адреса в т.ч. и в случае несовпадения масок, т.к. последние не влияют на значение ни одного из 32 бит входящих в состав IP адреса. 

Далее изучим логику работы IP и ARP протокола при взаимодействии с участием роутера. Для упрощения возьмем составную сеть с одним маршрутизатором.

Снова узел А имеет данные для отправки узлу В. Рассмотрим логику работы узла А. Начало «рассуждений» узла А нам известно: он находит на основании техники классов номер своей сети (192.168.0.0) и номер сети получателя (195.248.190.0), после чего сравнивает их. Эти номера различаются, следовательно отправитель и получатель находятся в разных сетях и отправитель должен передать пакеты для В на маршрутизатор, который будет «помогать» их передавать. Как это сделать? Для этого узел отправитель должен знать адрес маршрутизатора (разумеется, имеется ввиду адрес того интерфейса маршрутизатора, который в одной сети с отправителем пакета), которому передать пакет. Для того чтобы узел знал адрес маршрутизатора, его нужно в явном виде указать узлу, т.е. настроить на узле IP адрес, маску подсети и адрес маршрутизатора. Говорят, что узлу необходимо сообщить адрес «шлюза по умолчанию» (в RFC791 и др. маршрутизаторы принято называть шлюзами, gateway).

Вспомним конфигурирование IP адреса в Windows в графическом интерфейсе.

В нашем примере адресом шлюза по умолчанию для узла 192.168.0.89 является адрес 192.168.0.1. И это отражено в результате работы ipconfig.exe

C:\ipconfig

Настройка протокола IP для Windows

Подключение по локальной сети - Ethernet адаптер:

       DNS-суффикс этого подключения . . :

       IP-адрес  . . . . . . . . . . . . : 192.168.0.89

       Маска подсети . . . . . . . . . . : 255.255.255.0

       Основной шлюз . . . . . . . . . . : 192.168.0.1

Что будет делать узел, если ему нужно передать пакет в другую сеть, но адрес шлюза по умолчанию не указан в настройках узла, либо не существует соответствующей записи о сети назначения в таблице маршрутизации шлюза? В таком случае узел отбрасывает пакет немедленно, как только обнаружит, что его нужно передать маршрутизатору, адрес которого не указан. Выглядеть это будет так: пользователь указывает приложению адрес узла, с которым бы хотел иметь коммуникации, и практически мгновенно получает от приложения сообщение о невозможности коммуникаций.

При этом в сеть не посылается ни одного ARP запроса, и вообще при отсутствии взаимодействия протоколов вышележащих уровней, наш сетевой адаптер будет молчать. Но операционная система отреагирует на попытку взаимодействия – сообщением об ошибке.

 

 Пусть теперь на узле настроен адрес шлюза по умолчанию, как тогда осуществляются коммуникации?

Очевидно, узел А может передавать кадры канального уровня не получателю непосредственно, а лишь тому, кто с ним находится в одной канальной сети – порту маршрутизатора. При этом узел А знает IP адрес порта маршрутизатора. Тогда узел А должен передать кадр канального уровня порту маршрутизатора, но в этом кадре будет находиться IP пакет, предназначенный узлу В. Как узел может сформировать кадр канального уровня, предназначенный порту маршрутизатора? Для этого необходимо, чтобы, во-первых, порт маршрутизатора имел МАС адрес для того, чтобы ему можно было передать кадр канального уровня, а во-вторых, отправитель пакета должен знать этот МАС адрес для того, чтобы сгенерировать кадр порту маршрутизатора. МАС адрес есть у каждого порта маршрутизатора, как теперь узнать этот МАС адрес отправителю пакета? Очень просто – с помощью уже рассмотренного протокола ARP! С точки зрения протокола ARP нет никакой разницы, для чьего IP адреса искать соответствующий МАС адрес: узла или порта маршрутизатора. (Более того, порт маршрутизатора имеет МАС адрес и IP адрес, т.е. фактически является полноценным узлом IP сети, который может не только перенаправлять чужие пакеты, но и получать адресованные ему пакеты, так, например можно по IP сети осуществлять удаленное конфигурирование маршрутизатора). Таким образом узел, желающий передать пакет в другую сеть, должен знать IP адрес своего шлюза по умолчанию, после чего с помощью ARP запроса узел отправитель узнает МАС адрес соответствующего порта маршрутизатора, и формирует кадр канального уровня направленный на порт маршрутизатора, в котором лежит IP пакет, адресованный получателю.

Как тогда маршрутизатор будет обрабатывать полученный кадр?

Так как на канальном уровне данный кадр предназначен порту маршрутизатора, то он этот кадр принимает из сети (как и любой интерфейс локальной сети), после чего передает на обработку программному обеспечению. Программное обеспечение (модуль IP на маршрутизаторе) принимает извлеченный из кадра IP пакет и смотрит в его адрес получателя. Будь на месте маршрутизатора обычный узел, он бы обнаружил, что IP пакет предназначен не ему и отбросил бы его, но маршрутизатор как раз и является устройством, готовым обрабатывать IP пакеты, предназначенные не ему на третьем уровне. Поэтому маршрутизатор, получив кадр канального уровня, извлекает из него IP пакет, предназначенный не ему, на основании хранимой таблицы маршрутизации принимает решение о передаче пакета далее. Логику маршрутизаторов мы пока не рассматриваем, просто положим, что маршрутизатор принял правильное решение, а оно состоит в том, что пакет нужно передать через второй свой порт, причем получатель находится в подключенной сети, поэтому пакет необходимо передать в кадре канального уровня второй сети, причем получателем на канальном уровне должен служить истинный получатель IP пакета. Что для этого должен сделать маршрутизатор? Он знает, что получатель подключен к одному из его интерфейсов непосредственно, он знает IP адрес получателя, ему нужно узнать его МАС адрес для отправки ему кадра канального уровня. Так как порт маршрутизатора находится в одной сети с получателем, то маршрутизатор может послать во вторую сеть ARP запрос в поисках аппаратного адреса получателя. Получив ARP ответ маршрутизатор выдает получателю кадр канального уровня в котором находится IP пакет для получателя.

Итого: отправитель ARP запросом узнает МАС адрес порта маршрутизатора, затем передает пакет в кадре для порта маршрутизатора, маршрутизатор (подключенный вторым интерфейсом к целевой сети) находит ARP запросом МАС адрес получателя, а затем передает ему кадр канального уровня с IP пакетом внутри. Видно, что протокол ARP играет важнейшую роль и в таких коммуникациях.

Теперь рассмотрим это на примере реального трафика.

Если не указывать узлу адрес маршрутизатора по умолчанию и обратится к web серверу 195.248.190.51 (www.alkar.net) то ответ о невозможности коммуникаций приходит немедленно, так как стек понимает, что в принципе не может передать пакет. Если же указать узлу адрес шлюза по умолчанию (192.168.0.1), то узел посылает ARP запрос порту маршрутизатора, а затем посылает кадры канального уровня на МАС адрес порта маршрутизатора, в то время как IP пакеты в этих кадрах посланы по IP адресу 195.248.190.51:

Видно, что взаимодействие начинается с посылки ARP запроса к маршрутизатору 192.168.0.1

Рассмотрим ARP ответ от порта маршрутизатора и выясняем его МАС адрес:

Этот МАС адрес: 00 03 47 EA 42 59. Следовательно, все остальные пакеты посылаются именно на этот МАС адрес, но IP адрес получателя в пакетах: 195.248.190.51

Таким образом логическая схема работы узла в случае взаимодействия с узлами из другой сети состоит из следующих этапов

  1.  узел отправитель, заранее зная адрес шлюза по умолчанию, выясняет его МАС адрес с помощью ARP запроса
  2.  затем передает кадры канального уровня маршрутизатору, в которых – IP пакеты истинному получателю.
  3.  маршрутизатор, подключенный к сети в которой находится получатель выясняет ARP запросом МАС адрес получателя и передает ему кадры канального уровня, в которых IP пакеты от отправителя к получателю. 

Изменится ли логика работы в случае, если между отправителем и получателем больше одного маршрутизатора?

Пусть станция А имеет данные для передачи станции В. Как мы уже выяснили, станция а определяет, что она находится в разных сетях со станцией В, после чего посылает ARP запрос своему шлюзу по умолчанию 192.168.0.1, после чего получив ARP ответ передает кадры канального уровня по МАС адресу порта маршрутизатора R1, в которых IP пакеты для станции В. Что делает маршрутизатор R1? В прошлом примере мы полагали для простоты, что этот маршрутизатор непосредственно подключен к той же сети, что и станция В. Теперь это не так, что же делать маршрутизатору R1? Как мы уже говорили, у маршрутизатора есть таблица маршрутизации, на основании анализа которой маршрутизатор выбирает, на какой порт следующего маршрутизатора передать пакет.

Мы пока не рассматриваем логику работы маршрутизатора, пусть пока для нас маршрутизатор остается черным ящиком, принимающим правильные решения (эту логику мы, разумеется, разберем позже), очевидно, что маршрутизатор на основании анализа своей таблицы маршрутизации принимает решение о передаче пакета на следующий порт 1.1.1.2, с которым маршрутизатор R1 в одной сети своим интерфейсом 1.1.1.1.

Итак, маршрутизатор выяснил, что передавать пакет от 192.168.0.89 к 195.248.190.51 нужно в кадре канального уровня на порт маршрутизатора R2 с адресом 1.1.1.2.  Но для того, чтобы сгенерировать такой кадр канального уровня, маршрутизатор R1 должен знать МАС адрес порта 1.1.1.2, разумеется, он узнает его с помощью протокола ARP. После выяснения МАС адреса порта 1.1.1.2 ему генерируется кадр канального уровня в котором исходный пакет. Затем тоже самое повторяется для маршрутизатора R2 – он принимает решение о передаче пакета на порт 2.1.1.2 с которым находится в одной сети интерфейсом 2.1.1.1, для передачи пакета в кадре канального уровня необходимо выяснить МАС адрес порта 2.1.1.2, что делается ARP запросом, а затем соответствующая задача передачи пакета стоит переда маршрутизатором R3, логику такого маршрутизатора мы уже рассматривали: видя, что он в одной сети с получателем, он посылает APR запрос в поисках МАС адреса истинного получателя, а узнав этот МАС адрес передает исходный IP пакет в кадре канального уровня истинному получателю.

Видно, что протокол ARP играет в IP коммуникациях важнейшую роль: с его помощью узлы узнают МАС адреса узлов в своей сети, узлы узнают МАС адреса портов своих маршрутизаторов, маршрутизаторы узнают МАС адреса портов следующих маршрутизаторов, маршрутизаторы узнают МАС адреса узлов получателей.

 Однако использование протокола ARP не всегда необходимо. В случае, если связь между портами маршрутизаторов, например, PPP или HDLC, в которых понятия канальных адресов просто нет, то кадр передается в таких сетях разумеется без предварительно выполненного ARP запроса. Так же протокол ARP в таком виде не может быть использован в NBMA (Non Broadcast Multiple Access) сетях, так как там нет возможности послать широковещательный ARP запрос. В этом случае применяется NBMA Address Resolution Protocol (NARP) – RFC 1735.

 Введении в рассмотренную выше схему масок IP адресов  принципиально не меняет логики узла: узел выясняет, в одной ли он сети с получателем, и если нет, то с помощью ARP запроса находит МАС адрес своего маршрутизатора по умолчанию, маршрутизаторы, в свою очередь, знают маски всех сетей, в которые имеют маршруты, что позволяет им правильно находить адреса следующих маршрутизаторов для правильной передачи пакетов, а после того, как маршрутизатор нашел адрес следующего маршрутизатора, снова таки применяя ARP он выясняет МАС адрес следующего маршрутизатора, и взаимодействие происходит так как было рассмотрено выше.

 

 

Proxy ARP

Представим себе ситуацию, когда некоторые узлы составной сети, в которой применяются маски подсети, не поддерживают данную технологию. Рассмотрим простейший пример взаимодействия:

  1. операционная система, установленная на компьютеры в левой части сети в т.ч. и на   Станции 1 поддерживает RFC 950;
  2. операционная система, установленная в правой части сети в т.ч. и на Станции 2 поддерживает только RFC 761;

Данные по интерфейсам

Станция 1

Маршрутизатор

Станция 2

IP адрес

192.168.12.18

192.168.12.17

192.168.12.4

Маска /Класс

255.255.255.240

255.255.255.240

Класс С

MAC

00:30:4F:14:0E:AB

00:02:44:7E:5B:28

00:0E:A6:33:51:2A

IP адрес

192.168.12.3

Маска /Класс

255.255.255.240

MAC

00:0E:A6:33:52:92

Взаимодействие происходит между Станцией 1 и Станцией 2. Проанализируем логику работы протокола IP на каждой из станций при отправке пакета в адрес партнера по взаимодействию.

Станция 1 при формировании пакета в адрес Станции 2, анализирует IP адрес получателя и по средствам маски сети сравнивает адрес сети получателя и собственный адрес сети:

Шаг 1. Собственный адрес  192.168.12.18

Маска сети     255.255.255.240

Значит адрес своей сети   192.168.12.16

Шаг 2. Адрес получателя   192.168.12.4

Значит адрес сети получателя  192.168.12.0

Шаг 3. Т.к. сеть назначения и своя сеть имеют разные значения – значит нужно использовать ARP для выяснения МАС адреса шлюза, и далее пересылать пакет на шлюз.

После чего пакет отправляется на шлюз 192.168.12.17, и далее к получателю.

Станция 2 при формировании пакета в адрес Станции 1, анализирует IP адрес получателя и на основании принадлежности к классу, сравнивает адрес сети получателя и собственный адрес сети:

Шаг 1. Собственный адрес  192.168.12.4

Принадлежность к классу  Класс С

Значит адрес своей сети   192.168.12.0

Шаг 2. Адрес получателя   192.168.12.18

Принадлежность к классу  Класс С

Значит адрес сети получателя  192.168.12.0

Шаг 3. Т.к. сеть назначения и своя сеть совпадают – значит нужно использовать ARP для выяснения MAC адреса получателя и формирования пакета канального уровня в адрес Станции 1.

После чего происходит посылка широковещательного ARP запроса в правом сегменте сети, для поиска обладателя адреса 192.168.12.18. Как видно из приведенной схемы, такой поиск завершится неудачей, т.к. правый сегмент не содержит станций, имеющих требуемый IP адрес.

Для решения проблемы, возникающей в подобных случаях взаимодействия, было предложено использовать специальную службу, дополняющую работу протокола ARP. Результатом, стало принятие в октябре 1987 г RFC 1027 “Using ARP to Implement Transparent Subnet Gateways” (Использование ARP для обеспечения прозрачности сетевых шлюзов”). Речь шла, конечно же, об обеспечении прозрачности на канальном уровне для широковещательных ARP запросов.

Дальнейшее воплощение рекомендаций данного RFC в операционных системах серверов и шлюзов рассмотрим на приведенной выше схеме.

Прежде всего, операционная система шлюза работает в соответствии с RFC 950 и поддерживает RFC 1027. Настройки протокола IP шлюза следующие:

Интерфейс 1

IP адрес

192.168.12.17

Маска /Класс

255.255.255.240

MAC

00:02:44:7E:5B:28

Интерфейс 2

IP адрес

192.168.12.3

Маска /Класс

255.255.255.240

MAC

00:0E:A6:33:52:92

ProxyARP Вкл

Для запросов по адресам, принадлежащим,  сети 192.16.12.16

Интерфейс 2, подключенный в правый сегмент сети, слушает широковещательные ARP запросы и его логика работы следующая:

  1. Если ARP запрос ищет IP адрес лежащий в сети 192.16.12.16, то ответом на этот запрос будет ответ, указывающий МАС адрес Интерфейса 2 шлюза, подключенного в правый сегмент, т.е. 00:0E:A6:33:52:92 .

В результате, Станция 2 получает ARP ответ якобы от Станции 1 и формирует пакет канального уровня, оправляя его по указанному адресу. На самом деле, пакет, как и требуется в данной ситуации попадает на шлюз, и далее обрабатывается в соответствии установленного прядка. Шлюз, определяет, что пакет адресуется в левый сегмент, далее происходит известная процедура определения МАС адреса получателя и отправка пакета в адрес Станции 1. Станция 1 отправляет пакет в адрес Станции 2 по уже известному сценарию рассмотренному выше.

Для полноты описания механизма проксирования ARP запросов рассмотрим трафик в каждом из сегментов.

Левый сегмент

Краткий анализ:

  1. Широковещательный ARP запрос от Станции 1 для выяснения МАС адреса шлюза 192.168.12.17. После этого шлюз знает что 192.168.12.18 = 00:30:4F:14:0E:AB.
  2.  ARP ответ шлюза к Станции 1 имеет смысл 192.168.12.17 = 00:02:44:7E:5B:28
  3. Отправка сообщения Станцией 1 в адрес 192.168.12.4 используя канальный адрес получателя пакета 00:02:44:7E:5B:28 и свой МАС адрес отправителя.
  4. Отправка ответа от 192.168.12.4 в адрес 192.168.12.18 с МАС адресом 00:30:4F:14:0E:AB

Правый сегмент

Краткий анализ:

  1. Широковещательный ARP запрос от Интерфейса 2 для выяснения МАС адреса получателя 192.168.12.4. После этого Станция 2 знает, что 192.168.12.3 = 00:0E:A6:33:52:92
  2.  ARP ответ Станции 2 имеет смысл 192.168.12.4 = 00:0E:A6:33:51:2A
  3. Отправка сообщения шлюзом в адрес 192.168.12.4 используя канальный адрес получателя пакета 00:0E:A6:33:51:2A.
  4. Когда Станция 2 формирует ответ на адрес 192.168.12.18 в ARP таблице отсутствует соответствующая запись. Поэтому Станция 2 посылает широковещательный ARP запрос в адрес 192.168.12.18
  5. На запрос отвечает Интерфейс 2, выдавая свой МАС адрес за МАС адрес обладателя 192.168.12.18. И это не противоречит логике IP, так как один физический интерфейс может обладать несколькими IP адресами.
  6. Станция 2 посылает ответ в адрес 192.168.12.18 на МАС адрес Интерфейса 2 шлюза, что и требовалось.

Шлюз, определяет, что пакет адресуется в левый сегмент, далее происходит известная процедура определения МАС адреса получателя и отправка пакета в адрес Станции 1. Станция 1 отправляет пакет в адрес Станции 2 по уже известному сценарию рассмотренному выше.

Вот как выглядит взаимодействие для двух интерфейсов шлюза

Краткий анализ:

  1. Станция 1 разрешает МАС адрес Интерфейса 1 шлюза.
  2. Шлюз отвечает Станции 1
  3. Станция один посылает на шлюз пакет для 192.168.12.4
  4. Шлюз разрешает МАС адрес обладателя 192.168.12.4 т.е. Станции 2
  5. Станция 2 отвечает Интерфейсу 2 шлюза
  6. Шлюз посылает Станции 2 пакет от 192.168.12.18
  7. Станция 2 разрешает МАС адрес обладателя 192.168.12.18 т.е. Станции 1
  8. Интерфейс 2 шлюза отвечает своим МАС адресом.
  9. Станция 2 посылает пакет в адрес 192.168.12.18 на МАС адрес Интерфейса 2 шлюза.
  10. Шлюза посылает ответ Станции 2 на известный МАС адрес Станции 1 обладателя 192.168.12.18.

Таким образом, “Using ARP to Implement Transparent Subnet Gateways” (Использование ARP для обеспечения прозрачности сетевых шлюзов”), заключается в псевдопрозрачном режиме работы интерфейса шлюза для ARP запросов, адресованных в чужую сеть с похожим префиксом. Т.е.  подстановки в ARP ответы МАС адреса интерфейса шлюза для правильного функционирования IP протокола.

RARP

 Еще одна технология, касающаяся ARP – технология RARPReverse ARP (обратный ARP). Алгоритм обратного ARP позволяет выяснять IP адрес  станции по известному МАС адресу интерфейса. При этом узлы, не имеющие IP адреса, имеют возможность послать обратный ARP запрос: узел знает свой МАС адрес и ищет соответствующий IP адрес широковещательным сообщением. Тогда, если в сети есть специальный RARP сервер, он может отвечать на такие запросы, назначая узлам IP адреса. Такой механизм удобен для автоматической конфигурации узлов, но есть и недостаток – низкая информативность RARP ответов – только IP адрес. Маска,  адрес шлюза и другие параметры, в этом случае не назначаются. Для сообщения маски подсети и адреса шлюза можно использовать дополнительно протокол стека TCP/IP, называемый  ICMP (Internet Control Message Protocol), но в настоящее время такая «связка» считается устаревшей и не используется.

RARP описан в RFC903, где можно уточнить особенности применения данного протокола.

Итоги

Протокол ARP используется операционной системой узла или шлюза для обеспечения взаимодействия на канальном уровне при передаче пакета по средствам IP протокола. Работа ARP протокола заключается в установлении соответствия между IP адресом узла подключенного в данный широковещательный сегмент и МАС адресом интерфейса по средствам которого подключение произведено.

Данные,  полученные в результате работы ARP хранятся в виде специальной таблицы соответствия. Записи в таблице могут быть динамическими и статическими. Динамические записи – результат работы ARP - хранятся заданное время после чего уничтожаются. Статические записи создаются в ручную администратором либо при помощи скриптов, и сохраняются до выключения интерфейса (например при перезагрузке операционной системы).

При взаимодействии между узлами одной IP сети, протокол ARP используется станцией отправителем для разрешения МАС адреса станции получателя IP пакета. При взаимодействии между узлами в разных IP сетях, протокол ARP используется станцией отправителем для разрешения МАС адреса интерфейса шлюза. Далее пакет сетевого уровня инкапсулируется в кадр канального уровня с МАС адресом получателя, соответствующим МАС адресу интерфейса шлюза и отправляется в соответствии с заголовком. Шлюз, анализируя IP адрес получателя, передает кадр на следующий шлюз, либо в подключенную сеть. При этом ARP работает в любом случае: при передаче на следующий шлюз – для разрешения МАС адреса интерфейса следующего шлюза; при передаче адресату – для разрешения МАС адреса станции получателя.

Таким образом операционная система решает о цели ARP запроса (шлюз или конечный получатель) после анализа IP адреса получателя. Для решения проблем возникающих в IP сетях содержащих станции «не понимающие» масок, используется технология ProxyARP, маскирующая интерфейс шлюза под станцию получателя IP пакета. Кроме того, существует, хотя и не используется) технология RARP, позволяющая конфигурировать IP адрес узлов по МАС адресам их интерфейсов.

Примеры работы с анализаторами трафика

Для диагностики работы сетевых служб и протоколов, а так же для их детального изучения используют специальное программное обеспечение – анализаторы сетевого трафика. Функции анализаторов заключается в прослушивании сетевого трафика через интерфейс компьютера, запись трафика в буфер и передача декодированной информации на устройство вывода, например экран монитора. Некоторые анализаторы позволяют, так же, конструировать пакеты в ручную с последующей отправкой созданных пакетов в сеть.

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

Microsoft Network Monitor

Установка возможна только на Windows Server 2000/2003, установка на клиентские операционные системы – только компиляцией из SDK (подробности на http://msdn.microsoft.com/library/en-us/netmon/netmon/installing_network_monitor_files.asp).

Установка на сервер выполняется из стандартной оснастки «Добавить/Удалить программы»

Запуск программы из меню «Пуск» - «Программы» - «Администрирование»

Включение режима отбора трафика осуществляется кнопкой «  »

Выключение режима отбора трафика осуществляется кнопкой «  »

Настройка видов просмотра трафика осуществляется дополнительной кнопкой

Верхний фрейм содержит хронологию собранных пакетов, средний – декодированный выбранный пакет, нижний фрейм – тот же самый пакет но в шестнадцатеричном коде.

CommView

 

Включение режима отбора трафика осуществляется кнопкой «  »

Выключение режима отбора трафика осуществляется кнопкой «  »

Переключение в режим просмотра собранного трафика осуществляется выбором закладки «Packets»

Sniffer Pro

Включение режима отбора трафика осуществляется кнопкой «  »

Выключение режима отбора трафика осуществляется кнопкой «  »

Переключение в режим просмотра собранного трафика осуществляется выбором закладки «Packets»

Ethereal

От предыдущих анализаторов кроме функциональных особенностей, отличается бесплатным распространением (http://www.ethereal.com/)

Включение режима отбора трафика осуществляется следующим образом

Далее выбираем какой интерфейс будем использовать для отбора трафика – кнопка «Capture»

Выключение режима отбора трафика осуществляется кнопкой «Stop»

Вывод результатов осуществляется в общепринятой форме

Каждый из рассмотренных анализаторов имеет функцию записи собранного трафика в файл. Обычно это стандартная опция в меню File. Так же, каждый анализатор может использоваться на компьютерах с несколькими сетевыми интерфейсами, а некоторые (например CommView) могут собирать модемный трафик.

Практическое задание

  1.  Работа со свойствами протокола IP 

  1.  Назначить узлу IP адрес и маску подсети.
  2.  Убедиться, что нельзя назначить узлу адрес из сети 0.0.0.0
  3.  Убедиться, что нельзя назначить узлу адрес из сети 127.0.0.0
  4.  Убедиться, что нельзя назначить узлу адрес из сети класса D
  5.  Убедиться, что нельзя назначить узлу адрес из сети класса E
  6.  Убедиться, что нельзя назначить узлу адрес, являющийся номером сети, примеры:
  7.  5.0.0.0/255.0.0.0 (классовая масками)  – привести свой пример
  8.  198.2.4.64/255.255.255.192 (подсеть)  – привести свой пример
  9.  но можно 198.2.4.64/255.255.255.128  – привести свой пример
  10.  Убедиться, что нельзя назначить узлу адрес, являющийся широковещательным, примеры:
  11.  150.150.255.255/255.255.0.0 (классовая маска) – привести свой пример
  12.  но можно 150.150.255.255/255.0.0.0 (с произвольной допустимой маской) – привести свой пример
  13.  198.2.4.63/255.255.255.192 (с подсетями) – привести свой пример
  14.  но можно 198.2.4.63/255.255.255.128 – привести свой пример
  15.  Убедится, что в качестве маски нельзя назначить число, не являющееся совокупностью непрерывной последовательности «1» а затем непрерывной последовательности «0»:
  16.  255.0.255.0
  17.  255.255.255.252
  18.  255.255.0.255
  19.  255.255.128.0
  20.  255.144.0.0
  21.  255.255.191.0
  22.  255.254.255.0
  23.  255.224.0.0
  24.  255.255.253.0
  25.  255.255.255.240
  26.  192.0.0.0
  27.  255.255.188.0
  28.  255.254.0.0
  29.  255.192.128.0
  30.  255.255.255.0
  31.  255.255.192.0
  32.  255.255.255.248

  1.  Практика по работе с ipconfig.exe

  1.  Из командной строки получить настройки IP протокола
    1.  Сравнить предыдущий результат и информацию полученную с ключом /all , записать МАС адреса интерфейсов подключеных в систему

3. Практика по ARP.

Часть 1. Настроить IP адреса двум узлам в одной канальной сети, осуществить взаимодействие между ними, обращаясь к Web серверу на одном из узлов. Необходимо осуществить захват трафика и идентифицировать ARP пакеты, которыми обменивались клиент и сервер.

Часть 2. С помощью утилиты arp.exe проверить содержимое ARP кэша на предмет наличия в нем записей о соответствиях МАС адресов и IP адресов на обоих узлах.

Часть 3. Повторно осуществить то же самое взаимодействие, пока записи в ARP кэше еще существуют, и убедиться, что взаимодействие возможно, хотя ARP пакетов в сети не было.

Часть 4. Стереть ARP кэш на обеих станциях, снова повторить взаимодействие, убедиться, что ARP запрос/ответ снова присутствуют перед началом коммуникаций

4. Практика по анализаторам

Необходимо провести захват ARP трафика каждым из следующих анализаторов протоколов:

  1.  NAI Sniffer Pro
  2.  MS Network Monitor
  3.  Commit View
  4.  Ether Real


 

А также другие работы, которые могут Вас заинтересовать

70226. Безопасность жизнедеятельности в медицинских организациях 364 KB
  Система здравоохранения сегодня - это более трех миллионов работающих, тысячи медицинских организаций (лечебно-профилактических, аптечных, санитарно-эпидемиологических учреждений) десятки научно-исследовательских институтов, центров, высших и средних учебных заведений...
70227. Национальная безопасность 307 KB
  Национальная безопасность - основы государственного устройства и управления, осуществляющие процесс переоценки национальных ценностей и согласования интересов личности, общества и государства, дальнейшее развития социально-экономических, политических, правовых, этнических связей и отношений.
70228. Расстройства восприятия, иллюзии, галлюцинации. Дереализация и деперсонализация 95 KB
  Показанием к срочной даже без согласия больного госпитализации являются: C 12. Психосенсорные расстройства обычно являются проявлением: D 14. В каком случае иллюзии являются безусловным признаком психоза C Галлюцинации относятся к расстройствам невротического уровня.
70230. Визвольні ідеї Г.Сковороди, Т.Шевченка, І.Франка 132 KB
  Національна природа інтелігента визначається не кількістю його декларацій про любов до Батьківщини а відповідністю власної духовної діяльності специфіці менталітету рідного народу і потребам його розвитку спричинених своєрідністю конкретної історичної ситуації.
70231. Соціально-політичні погляди М.Грушевського 49.5 KB
  Політична думка в Україні у XIX—XX ст. формувалася в умовах, коли зникав традиційний сільськогосподарський уклад життя і його змінювало індустріальне суспільство, коли відбувалися процеси національно-культурного й національно-політичного відродження України.
70232. Політична культура як засіб завоювання та здійснення влади 75.5 KB
  Політична психологія має певну структуру. Вона містить політичні потреби, інтереси, почуття, настрої, традиції тощо. Політичні потреби - це ті потреби, задоволення яких пов’язано зі здійсненням влади. Вони можуть лише тим чи іншим чином стосуватися влади, а можуть виявлятися безпосередньо...
70233. Критичний утопічний соціалізм 26.5 KB
  Вихідними пунктами його плану з одного боку стала переконаність у провідній ролі індустріалів у суспільному житті а з іншого його ставлення до організації промисловості як одного з найважливіших чинників досягнення суспільного блага. Мислитель розглядав державну владу як основний засіб...
70234. Розвиток і особливості політичної думки в Росії 51 KB
  Слов’янофільство - вияв приязні, симпатії до слов’янства, зацікавлення ним з боку різних громадсько-політичних та культурних діячів, які, виходячи з етнічної та мовної спорідненості слов’ян, підтримували ідею їхнього тісного єднання. Форми вияву слов’янофільства були найрізноманітнішими...