ARP Протокол Разрешения Адресов для чайников, как работает

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

N AT и Proxy ARP отображаются на экранах мобильных устройств Cisco ASA.

В чем отличие межсетевого экрана Cisco ASA от маршрутизаторов Telnet? По умолчанию при настройке правил NAT, устройство будет отвечать только по внутренним глобальным адресам. При этом, данное поведение не зависит от внутреннего глобального адреса IP-подсети интерфейса ASA. Данное поведение позволяет настроить опцию sysopt noproxyarp »имя интерфейса“.

Рассмотрим следующие простые примеры, основанные на топологии:

Настройки интерфейсов Cisco ASA:

interface Vlan1
 nameif inside
 security-level 100
 ip address 192.168.20.1 255.255.255.0
!
interface Vlan2
 nameif outside
 security-level 0
 ip address 198.18.0.1 255.255.255.0

Настройки правила NAT и списка доступа на интерфейсе outside:

object network TEST-PC-tcp3389
 host 192.168.20.5
 nat (inside,outside) static 198.18.99.2 service tcp 3389 3389
access-list acl-outside-in extended permit tcp any object TEST-PC-tcp3389 eq 3389
access-group acl-outside-in in interface outside

Настраиваем порт tcp 3389 (RDP) под адресом 198.18.199.2, который не принадлежит IP-подсети интерфейса Cisco ASA

Проверяем опцию sysopt noproxyarp:

asa# sh run all sysopt 
. . .
no sysopt noproxyarp inside
no sysopt noproxyarp outside

Noproxyarp отключен, поэтому вы можете видеть, что опция не отмечена. Давайте получим доступ к tcp-порту 3389 сервера 198.18.992 и одновременно запустим сниффер:

На запрос порта ARP отвечает Cisco ASA.

Попробуем выставить опцию sysopt noproxeyarp outside. Вычищаем arc-cache на компьютере, подключенном к outside интерфейсу

A RP-запросы к целевому IP больше не получают ответа от ASA. Точный адрес подсети IP интерфейса ASA не имеет значения. Когда выбрана опция noproxyarp, ASA будет отвечать на ARP-запросы, отправленные на IP-адрес интерфейса.

Опция Cisco ASA sysopt noproxyarps не имеет никакого отношения к настройке интерфейса ip proxy-arp маршрутизаторов. Конфигурация Cisco ASA предотвращает прохождение прокси ARP запросов через брандмауэр. Эта опция использует ключевое слово alias для обслуживания внешних общих IP-адресов в таблице ARP ASA.

В некоторых случаях ответы ARP могут потребовать отключения для определенных правил NAT. Ключевой фразой здесь является:

no-proxy-arp

N OT в настройках NAT. Настройка NAT-исключений при использовании VPN на Cisco ASA. Предположим, локальная сеть за Cisco ASA – 192.168.20.0/24 и удалённая сеть Site-toSite VPN — 193.168.10.0/128. NAT-исключение можно настроить следующим образом:

object network local-LAN
 subnet 192.168.20.0 255.255.255.0
object network remote-LAN
 subnet 192.168.30.0 255.255.255.0
nat (any,any) source static local-LAN local-LAN destination static remote-LAN remote-LAN

Отображаемая конфигурация показывает, что каждый интерфейс Cisco ASA (any или ani) публикует всю IP-подсеть локальной сети 192.168.20.0/24 под внутренними адресами той же IP-сети с именами NAT и PNC170xpcardonal LAN. При такой конфигурации любой ARP-запрос с адреса 192.168.20.0/24, поступающий в любую подсеть через внутренние интерфейсы, будет адресован Cisco ASA;

Предположим, что хост с адресом 192.168.206 хочет подключиться к другому хосту с адресом 192.168.206 в той же IP-подсети. Целевой узел и внутренний интерфейс Cisco ASA достигаются широковещательным ARP-запросом к целевому узлу 192.168.206. Cisco ASA отвечает на ARP-запрос своим MAC-адресом благодаря установленному правилу NAT. Весь трафик направляется на Cisco ASA, если его ARP-ответ приходит раньше, чем ответ целевого узла.

Для локальной IP-подсети в вышеупомянутом примере Cisco ASA будет действовать как “черная дыра”, в целом “засасывая” весь трафик. Ситуацию в данном случае не спасает элемент политики NAT (установка nat настроек после назначения статических ключевых слов). Настройка IP localproxy arpy и IP proxy-arp аналогична настройке маршрутизатора. Для предотвращения описанного выше эффекта NAT в Cisco ASA необходимо добавить ключевое слово no-proxy.

nat (any,any) source static local-LAN local-LAN destination static remote-LAN remote-LAN no-proxy-arp

Примечения

Правила NAT и ключевое слово any могут быть указаны в настройках для устранения описанного эффекта. Каково внутреннее/внешнее имя nat?

Итоги

В этом разделе статьи я кратко изложу основные идеи из второй главы:

1. По умолчанию Cisco ASA отвечает на ARP-запросы на внутренний глобальный IP-адрес правила NAT, независимо от принадлежности интерфейса к IP-подсети. Это поведение контролируется установкой опции sysopt noproxyarp <имя интерфейса>.
2. Cisco ASA позволяет отключить ARP-ответы для определенных правил NAT с помощью ключевого слова no-proxy-arp. Особенно для правил исключения NAT необходимо отключить ARP-ответ, чтобы избежать проблем с подключением в локальной сети.
3. Функциональность Proxy ARP не настраивается явно на Cisco ASA, но желаемый эффект может быть достигнут с помощью правил NAT.

Приведем пример из практики. В большинстве случаев я или мои коллеги сталкивались с проблемой подключения сетевого оборудования Cisco к Интернету. По нашим наблюдениям, именно этот сценарий наиболее часто сопровождается проблемами с ARP.

Cas № 1 вторичный IP-адрес провайдера

Провайдер был подключен к брандмауэру Cisco ASA. Каждая служба была использована должным образом, и соединение было успешным. Однако через некоторое время соединение разорвалось. Тщательный анализ показал, что оно функционирует правильно, если вы запускаете исходящее соединение (трафик идет в обоих направлениях). Одиночные интернет-соединения проявляются только при отключении от Интернета (например, при удаленном подключении к маршрутизатору). Входящие соединения могут функционировать правильно, если есть активные исходящие соединения. Однако через некоторое время попытка удаленного подключения или “пинга” устройства снова становится безуспешной.

Наши наблюдения привели к тому, что мы начали изучать работу ARP. На ASA мы попытались удалить все остатки, запустив debug arp. Отладочные сообщения показали, что ASA правильно отправляет запрос и успешно получает ответ. На этом рисунке IP-адрес нашего ASA – 80. X.14, а его MAC-адрес – a0ec****. IP-шлюз провайдера – 80. X.1, а MAC-шлюз – aa43.

arp-send: arp request built from 80.X.X.4 a0ec.****.**** for 80.X.X.1 at 978772020
arp-refresh: Trying to refresh ARP for outside 80.X.X.1
arp-in: response at outside from 80.X.X.1 aa43.****.**** for 80.X.X.4 a0ec.****.**** having smac aa43.****.**** dmac a0ec.****.****narp-set: added arp outside 80.X.X.1 aa43.****.**** and updating NPs at 978772020
arp-in: resp from 80.X.X.1 for 80.X.X.4 on outside at 978772020

Но через некоторое время мы заметили следующее сообщение в отладке arp на ASA:

arp-in: request at outside from 195.Y.Y.1 aa43.****.**** for 80.X.X.4 0000.0000.0000 having smac aa43.****.**** dmac ffff.ffff.ffffnarp-in: Arp packet received from 195.Y.Y.1 which is in different subnet than the connected interface 80.X.X.4/255.255.255.0

Это сообщение информирует ASA о MAC-адресе отправителя, который равен aa43. **** Неверный IP-адрес отправителя – 195.3. Некорректный ARP-запрос отклоняется ASA, и в ответ он получает только отказ.

Таким образом, когда существует исходящий трафик, ASA отправляет ARP-запрос (при необходимости, когда соответствующая запись в ARP-таблице ASA требуется обновления) в сторону провайдера и получает ARP-ответ. Благодаря ARP-запросу от ASA оборудование провайдера также получает запись об ASA в своей ARP-таблице. Однако, когда исходящий трафик от ASA отсутствует продолжительное время и ASA не отправляет ARP-запрос, на оборудовании провайдера в ARP-таблице запись об ASA истекает. Оборудование провайдера пробует обновить запись, отправляя ARP-запрос, но ответ не получает. Отсюда и появляются «плавающие» проблемы со связью.

Необходимо было определить, почему оборудование провайдера передавало запрос с неправильным IP-адресом отправителя. После этого провайдер проверил сообщения ASA debounce:

324: 22:03:41.056546       802.1Q vlan#2 P0 arp who-has 80.X.X.4 tell 195.Y.Y.1
325: 22:03:41.937329       802.1Q vlan#2 P0 arp who-has 80.X.X.4 tell 195.Y.Y.1
326: 22:03:42.822909       802.1Q vlan#2 P0 arp who-has 80.X.X.4 tell 195.Y.Y.1

Оказалось, что на интерфейсе провайдера адрес 195.Y.Y.1 был настроен как основной, а IP-адрес 80.X.X.4, который являлся для нас шлюзом по умолчанию, был настроен как secondary. Эта настройка полностью объясняла ситуацию. В данном случае проблема была решена добавлением статической ARP-записи на оборудовании провайдера.

Абсолютно аналогичная ситуация у нас возникала на другой площадке, когда мы использовали для подключения к провайдеру маршрутизатор Cisco. На оборудовании провайдера наш шлюз был также настроен как seconday IP-адрес. В этом случае, чтобы ускорить процесс решения проблемы, мы добавили на маршрутизаторе secondary IP-адрес из той же подсети, что и основной IP-адрес на интерфейсе провайдера. После этого наш маршрутизатор стал успешно отвечать на ARP-запросы со стороны провайдера, так как на нашем интерфейсе появился IP-адрес из той же подсети, что и адрес в ARP-запросе.

Случай No2. ARP-совместимость

Перед нами была поставлена задача установить брандмауэр Cisko ASA вместо маршрутизатора Cisco ISR в одном из наших офисов. Во время установки брандмауэр ASA был настроен и отправлен в точку назначения. После подключения к провайдеру Cisco ASA удаленное подключение оказалось невозможным. Поначалу казалось, что устройство работает нормально. MAC-адрес маршрутизатора провайдера был успешно идентифицирован брандмауэром ASA с помощью обычного метода ARP-запроса/ARP-ответа. Внешний интерфейс устройства отправлял пакеты в Интернет. Встроенные средства захвата пакетов смогли исправить этот факт.

Пакеты от ASA были успешно доставлены на оборудование оператора, это выяснилось после обращения к провайдеру. Затем маршрутизатор был переподключен, и трафик начал беспрепятственно проходить в обоих направлениях. Это указывало на проблему между брандмауэром ASA и провайдером. После повторного контакта с провайдером и подробного описания проблемы было обнаружено, что оборудование абонента не видит MAC-адрес брандмауэра ASA. Подготовка демонстрации включала рассмотрение маршрутизатора Cisco. По какой-то причине, получив ответ от ASA, устройство провайдера не добавило запись об ASA в ARP-таблицу. Тот факт, что ARP-запрос Cisco ASA не был отклонен, является наиболее интригующим. Несмотря на то, что все было совершенно правильно, оборудование ISP не ответило на ARP-запрос ASA.

У провайдера была запрошена привязка статических данных к ARP-таблице. Провайдер обнаружил проблему совместимости брандмауэра с оборудованием Cisco ASA. К сожалению, провайдер не упомянул, кто производит его оборудование.

Случай №3. Gratuitous ARP

Мы восстанавливаем связь с поставщиком Cisco ASA. Вместо сервера MSTMG на этот раз используется сервер Microsoft. В данном случае для соединения MSTMG с устройством провайдера использовался L2-коммутатор. L2-коммутатор должен был использоваться для подключения к ASA.

Итак, отключаем MSTMG и вместо него в порт L2-коммутатора подключаем Cisco ASA. Мы видим стандартную ситуацию: с внешнего порта Cisco ASA трафик уходит, но ответных пакетов нет. После обращения к провайдеру выясняется, что оборудование MSTMG не видит MAC-адрес сервера в Cisco ASA.

Дальнейшее разбирательство показало, что межсетевой экран Cisco ASA не шлёт Gratuitous ARP сообщение при переходе интерфейса из состояния DOWN в состояние UP. А так как оборудование провайдера подключено через L2-коммутатор, при смене устройства на нашей стороне канал до провайдера не падает, и интерфейс маршрутизатора провайдера всегда остаётся во включенном состоянии. Единственный способ своевременно оповестить провайдера о том, что на нашей стороне изменилось устройство и MAC-адрес, – Gratuitous ARP. В противном случае, придётся ждать таймаута ARP-записи у провайдера, а это как, как правило, 4 часа.
В данном случае мы сделали на интерфейсе Cisco ASA команды no ip address, ip address x.x.x.x y.y.y.y. После этого ASA всё же отправила Gratuitous ARP, и всё взлетело.

Заключение

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

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

Мне интересно услышать ваши мысли. Возможно, кто-то сможет поделиться своими собственными забавными случаями с ARP.