Привет, Habr! В предыдущей части статьи мы рассмотрели особенности работы ARP на маршрутизаторах Cisco, связанные с правилами NAT и с функцией Proxy ARP. В данном посте попробую разобрать отличия в работе ARP между маршрутизаторами Cisco и межсетевыми экранами Cisco ASA. В заключении статьи поделюсь несколькими интересными случаями из практики, связанными с работой ARP.
NAT и Proxy ARP на межсетевых экранах Cisco ASA
Поведение межсетевого экрана Cisco ASA в разрезе ARP для правил NAT и настроек Proxy ARP отличается от маршрутизаторов Cisco. По умолчанию при настройке правил NAT на Cisco ASA, устройство будет отвечать на ARP-запросы, соответствующие внутренним глобальным адресам правил 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.99.2, который не принадлежит IP-подсети интерфейса Cisco ASA.
Проверяем опцию sysopt noproxyarp:
asa# sh run all sysopt
. . .
no sysopt noproxyarp inside
no sysopt noproxyarp outside
Видно, что опция не выставлена (noproxyarp не включён). Попробуем открыть tcp-порт 3389 адреса 198.18.99.2 и одновременно посмотрим сниффер:
Успех: Cisco ASA отвечает на ARP-запрос и порт открывается.
Попробуем выставить опцию sysopt noproxyarp outside. Очищаем arc-cache на компьютере, подключенном к outside-интерфейсу, и пробуем открыть порт снова:
ASA более не отвечает на ARP-запросы к целевому IP-адресу. При этом, не имеет значения, находится ли целевой IP-адрес в IP-подсети интерфейса ASA. При выставленной опции sysopt noproxyarp ASA будет отвечать на ARP-запросы, адресованные исключительно IP-адресу интерфейса.
Не стоит сравнивать настройку ip proxy-arp интерфейса маршрутизатора с настройкой опции sysopt noproxyarp Cisco ASA. Опция Cisco ASA не включает проксирование любых ARP-запросов через межсетевой экран. Эта опция отвечает исключительно за обслуживание внутренних глобальных IP-адресов правил NAT и статических записей в ARP-таблице ASA, настроенных с ключевым словом alias.
В некоторых случаях функционал ARP-ответов необходимо отключать для конкретных правил NAT. Для этого служит ключевое слово no-proxy-arp в настройках NAT. Наиболее распространённый пример – настройка NAT-исключений при использовании VPN на Cisco ASA. Предположим, локальная сеть за Cisco ASA – 192.168.20.0/24, локальная сеть на удалённой стороне Site-to-Site VPN – 192.168.30.0/24. NAT-исключение для данного VPN можно настроить следующим образом:
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, что IP-подсеть local-LAN 192.168.20.0/24 целиком опубликована на каждом интерфейсе Cisco ASA (any,any в правиле NAT) под внутренними глобальными адресами той же IP-подсети local-LAN. Следовательно, при данной конфигурации Cisco ASA будет отвечать на любой ARP-запрос к целевому IP-адресу из IP-подсети 192.168.20.0/24, поступившему на любой интерфейс, включая inside интерфейс.
Представим ситуацию, хост с адресом 192.168.20.5 хочет обратиться к хосту из той же IP-подсети с адресом 192.168.20.6. Формируется ARP-запрос на целевой адрес 192.168.20.6. ARP-запрос рассылается широковещательно и достигает как целевой хост, так и inside интерфейс Cisco ASA. Настроенное правило NAT заставляет Cisco ASA ответить своим MAC-адресом на ARP-запрос. Если ARP-ответ от Cisco ASA поступит раньше ответа от целевого хоста, весь трафик, направленный к целевому хосту, пойдёт на Cisco ASA, где будет благополучно отброшен.
В представленном примере Cisco ASA будет работать как «black hole» для локальной IP-подсети, стремясь «засасывать» на себя весь трафик. При этом, элемент policy NAT (настройка NAT после ключевых слов destinations static) ситуацию не спасает. Если сравнивать с маршрутизатором, данная настройка на Cisco ASA по эффекту схожа с совместной настройкой ip proxy-arp и ip local-proxy-arp на интерфейсе маршрутизатора. Чтобы избежать описанного эффекта, в правиле NAT на Cisco ASA необходимо добавить ключевое слово no-proxy-arp:
nat (any,any) source static local-LAN local-LAN destination static remote-LAN remote-LAN no-proxy-arp
Примечание: описанный эффект можно избежать, указывая в настройках правила NAT точные интерфейсы, вместо ключевых слов any. Например, nat (inside,outside) …
Итоги
Прежде чем переходить к описанию случаев из практики, выделю основные моменты второй части статьи:
- Cisco ASA по умолчанию будет отвечать на ARP-запросы к внутреннему глобальному IP-адресу правила NAT, вне зависимости от принадлежности к IP-подсети интерфейса. Данное поведение регулируется настройкой опции sysopt noproxyarp <имя интерфейса>.
- Cisco ASA позволяет отключать ARP-ответы для конкретных правил NAT с помощью ключевого слова no-proxy-arp. В частности, для правил NAT-исключений необходимо отключать ARP-ответы, чтобы избежать проблем со связью в локальной сети.
- Функциональность Proxy ARP не настраивается в явном виде на Cisco ASA, однако необходимый эффект может быть достигнут с помощью правил NAT.
Итак, случаи из практики. Сразу отмечу, все описываемые проблемы происходили, когда я или мои коллеги подключали новое сетевое оборудование Cisco к Интернет-провайдерам. По нашему опыту, именно этот сценарий наиболее часто сопровождается проблемами с ARP.
Случай №1. Secondary IP-адрес у провайдера
Подключали к провайдеру межсетевой экран Cisco ASA. Подключение прошло успешно и все сервисы работали корректно. Однако через некоторое время связь пропадала. Детальный анализ показывал, что если инициировать исходящее соединение, то оно работает стабильно (трафик ходит в обе стороны). Проблема появляется только со входящими соединениями из сети Интернет (например, удалённое подключение к маршрутизатору). При этом прослеживается прямая зависимость входящих соединений от исходящих: если есть исходящие соединения, то и входящие соединения начинают корректно работать. Однако, по прошествии некоторого времени подключиться удалённо или «пропинговать» устройство из Интернета снова не удаётся.
Так как с физическим и канальным уровнем предположительно всё в порядке, мы стали проверять работу ARP. Запустили debug arp на ASA и попробовали очистить arp-cache. По debug-сообщениям увидели, что ASA корректно отправляет ARP-запрос и без проблем получает ARP-ответ от провайдера. В данном примере IP нашей ASA 80.X.X.4, её MAC-адрес a0ec.****.****, IP-шлюза провайдера 80.X.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
Однако, через какое-то время заметили сообщение в debug 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 получает ARP-запрос с верным Sender MAC Address aa43.****.**** но неверным Sender IP Address – 195.Y.Y.1. Данный некорректный ARP-запрос ASA отбрасывает и не отправляет ARP-ответ.
Таким образом, когда существует исходящий трафик, ASA отправляет ARP-запрос (при необходимости, когда соответствующая запись в ARP-таблице ASA требуется обновления) в сторону провайдера и получает ARP-ответ. Благодаря ARP-запросу от ASA оборудование провайдера также получает запись об ASA в своей ARP-таблице. Однако, когда исходящий трафик от ASA отсутствует продолжительное время и ASA не отправляет ARP-запрос, на оборудовании провайдера в ARP-таблице запись об ASA истекает. Оборудование провайдера пробует обновить запись, отправляя ARP-запрос, но ответ не получает. Отсюда и появляются «плавающие» проблемы со связью.
Осталось понять, почему оборудование провайдера отправляет ARP-запрос с неверным Sender IP Address. Позже провайдер проверил данную ситуацию со своей стороны и даже показал дамп ARP-трафика, который подтверждал debug-сообщения ASA:
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-запросе.
Случай №2. ARP-несовместимость
Перед нами была поставлена задача в одном из офисов заменить маршрутизатор Cisco ISR на межсетевой экран Cisco ASA. Межсетевой экран ASA предварительно был настроен и отправлен в точку установки. После подключения к провайдеру Cisco ASA оказался недоступным для удалённого подключения. На первый взгляд на устройстве всё работало корректно. Межсетевой экран ASA корректно определял MAC адрес маршрутизатора провайдера с помощью стандартной процедуры ARP-запрос/ARP-ответ. Пакеты уходили с внешнего интерфейса устройства в Интернет. При этом в обратную сторону на ASA ничего не приходило. Этот факт фиксировался встроенными средствами перехвата пакетов (packet capture).
После обращения к провайдеру было установлено, что пакеты от ASA успешно доставлялись на оборудование провайдера, также провайдер видел ответные пакеты, приходящие с вышестоящего оборудования. После того как был обратно подключен маршрутизатор, трафик снова начал ходить корректно в обе стороны. Это означало, что проблема где-то на стыке между провайдером и межсетевым экраном ASA. После повторного обращения к провайдеру с детальным описанием проблемы было определено, что оборудование провайдера не видит MAC адрес межсетевого экрана ASA. Собранный демо-стенд доказал корректность работы ASA (роль провайдера играл маршрутизатор Cisco). По какой-то причине устройство провайдера не заносило запись об ASA в ARP-таблицу после получения ARP-ответа от ASA. Самое интересное, что ARP-запрос, поступающий от Cisco ASA не отбрасывался. Оборудование провайдера корректно отвечало на ARP-запрос от ASA, но также, не заносило запись ASA в ARP-таблицу.
В итоге провайдеру было предложено сделать статическую привязку в таблице ARP. Данный случай показал несовместимость по ARP оборудования провайдера с межсетевым экраном Cisco ASA. К сожалению, провайдер не озвучил производителя своего оборудования.
Случай №3. Gratuitous ARP
И опять подключаем к провайдеру Cisco ASA. В этот раз вместо сервера MS TMG. Особенность данного случая в том, что MS TMG был подключен к устройству провайдера через L2-коммутатор. Предполагалось подключение ASA также через L2-коммутатор:
Итак, отключаем MS TMG и вместо него в тот же порт L2-коммутатора подключаем Cisco ASA. Видим стандартную ситуацию: с внешнего порт Cisco ASA трафик уходит, но ответные пакеты отсутствуют. После обращения к провайдеру выясняется, что оборудование провайдера по-прежнему видит MAC-адрес сервера MS TMG за IP-адресом, перешедшим на 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 в случаях использования трансляции сетевых адресов (NAT), а также функционал Proxy ARP. Разобрал отличия в работе ARP между маршрутизаторами Сisco и межсетевыми экранами Cisco ASA. В заключении статьи я рассмотрел проблемы, возникающие при подключении к Интернет-провайдеру, обусловленные работой ARP.
Описанные случаи показывают, на сколько важно помнить о необходимости проверки ARP в процессе решения и устранения сетевых проблем. Надеюсь, материал данной статьи станет полезным для более глубокого понимания работы ARP.
Жду комментарии. Может быть кто-то сможет рассказать собственные интересные случаи, связанные с работой ARP.
Автор: CBS
