четверг, 30 марта 2017 г.

Fortigate Monitoring commands

Monitoring commands:

show
  • Show global or vdom config
sh system interface
  • Equivalent to show run interface
diagnose hardware deviceinfo nic
  • Equivalent to show interface
get system status
  • show version information
sh firewall policy 6
  • show firewall rule numer 6
sh router policy
  • Show Policy Routing rules
diagnose system session list
  • Show the excisting translations
diagnose system session clear
  • Clears all xlate/translations
diagnose ip arp list
  • Shows the arp table of connected hosts
get router info routing-table all
  • Equivalent to ‘show ip route’
diagnose system top
  • Show System Processes running with PIDs
diagnose system kill 9 <id>
  • Kill the specific PID
diag test auth ldap <server_name> <username> <password>
  • Ldap test query from the Forti to the AD

In order to see a tcp dump of information flowing through a fortigate, the diagnose sniffer command can be used from cli.   The command syntax:
diagnose sniffer packet {interface | all}  ‘net z.z.z.z/p and/or host x.x.x.x and/or port yyy’  [options]
You can narrow your search by filtering on any or the following:
net/prefix : print a whole netblock
host          : print only one host
port          : print only a specific port number
and/or      : allows additional options
The Options field at the end are as follow:
1: print header of packets
2: print header and data from ip of packets
3: print header and data from ethernet of packets (if available)
4: print header of packets with interface name
5: print header and data from ip of packets with interface name
6: print header and data from ethernet of packets (if available) with intf name
Option ‘4’ is particularly useful, in that it shows the associated interface for the directional traffic
Examples:
diagnose sniffer packet any ‘net 10.0.0.0/8 and host 172.16.16.14 and port 3389’

среда, 29 марта 2017 г.

ARP: Нюансы работы оборудования Cisco и интересные случаи.

В данной заметке я не буду подробно описывать принципы работы ARP и протоколов этого семейства (RARP, InARP, UnARP и т.д.). На эту тему уже существует уйма статей в Интернете (например, здесь не плохо описаны разновидности ARP). Единственный теоретический момент, на котором я заострю чуть больше внимания, – механизм Gratuitous ARP (GARP). 

Статья будет состоять из двух частей. В первой части будет немного теории и особенности работы ARP на маршрутизаторах Cisco, связанные с правилами NAT и с функцией Proxy ARP. Во второй части опишу отличия в работе ARP между маршрутизаторами Cisco и межсетевыми экранами Cisco ASA, а также поделюсь несколькими интересными случаями из практики, связанными с работой ARP.

Чуть-чуть теории

ARP-запрос/ARP-ответ

Ниже представлен пример обмена ARP-запросом/ARP-ответом в программе-сниффере Wireshark:





ARP-запрос отправляется на широковещательный MAC-адрес ff:ff:ff:ff:ff:ff. В теле ARP-запроса поле с неизвестным значением Target MAC Address заполняется нулями.

ARP-ответ отправляется на MAC-адрес получателя, отправившего ARP-запрос. В поле Sender MAC Address указывается запрашиваемый MAC-адрес устройства.

Поле opcode в заголовке ARP может принимает значение 1 для ARP-запроса и значение 2 для ARP-ответа.

Чтобы два устройства могли начать передавать трафика между собой, в их ARP-таблицах должна существовать соответствующая запись о соседнем устройстве. Логично предположить, чтобы ARP-запись появилась в таблицах, для каждого устройства должна отработать процедура ARP-запрос/ARP-ответ. То есть перед передачей трафика в сети должны пройти по два ARP-запроса и два ARP-ответа (ARP-запрос/ARP-ответ для первого компьютера и ARP-запрос/ARP-ответ для второго компьютера). Однако, данное предположение верно не для всех случаев. Сетевое оборудование Cisco добавляет новую запись в ARP-таблицу сразу по приходу ARP-запроса от удалённого устройства.

Рассмотрим пример. В широковещательный домен добавляется новое устройство с адресом 198.18.0.200. Запустим пинг с нового устройства и посмотрим debug arp на маршрутизаторе Cisco:

019383: Feb  4 10:38:55 UTC: IP ARP: rcvd req src 198.18.0.200 64e9.50c8.d6cd, dst 198.18.0.1 GigabitEthernet0/0/1.7
019384: Feb  4 10:38:55 UTC: IP ARP: creating entry for IP address: 198.18.0.200, hw: 64e9.50c8.d6cd
019385: Feb  4 10:38:55 UTC: IP ARP: sent rep src 198.18.0.1 d8b1.902e.e741,
                 dst 198.18.0.200 64e9.50c8.d6cd GigabitEthernet0/0/1.7

Как видно, сразу по пришествии ARP-запроса от неизвестного IP-адреса (rcvd req src 198.18.0.200), маршрутизатор создаёт соответствующую запись в своей ARP-таблице (creating entry for IP address: 198.18.0.200, hw: 64e9.50c8.d6cd).

Для текущей статьи я не проводил подробного исследования по вопросу, какое именно сетевое оборудование добавляет ARP-запись по пришествии ARP-запроса. Однако, предполагаю, описанное поведение присуще не только сетевому оборудованию Cisco, но и сетевому оборудованию других производителей, так как данный механизм позволяет существенно сократить ARP-трафик в сети. 

ARP-запрос/ARP-ответ для конечного оборудования

Gratuitous ARP

Механизм Gratuitous ARP используется для оповещения устройств в рамках широковещательного домена о появлении новой привязки IP-адреса и MAC-адреса. Когда сетевой интерфейс устройства получает настройки IP (вручную или по DHCP), устройство отправляет Gratuitous ARP сообщение, чтобы уведомить соседей о своём присутствии. Gratuitous ARP сообщение представляет собой особый вид ARP-ответа. Поле opcode принимает значение 2 (ARP-ответ). MAC-адрес получается как в заголовке Ethernet, так и в теле ARP-ответа является широковещательным (ff:ff:ff:ff:ff:ff). Поле Target IP Address в теле ARP-ответа совпадает с полем Sender IP Address.

Механизм Gratuitous ARP используется для многих целей. Например, с помощью Gratuitous ARP можно уведомить о смене MAC-адреса или обнаружить конфликты IP-адресов. Другой пример — использование протоколов резервирования первого перехода (First Hop Redundancy Protocols), например, HSRP у Cisco. Напомню, HSRP позволяет иметь виртуальный IP-адрес, разделённый между двумя или более сетевыми устройствами. В нормальном режиме работы обслуживание виртуального IP-адреса (ответы на ARP-запросы и т.д.) обеспечивает основное устройство. При отказе основного устройства обслуживание виртуального IP-адреса переходит ко второму устройству. Чтобы уведомить о смене MAC-адреса ответственного устройства, как раз отправляется Gratuitous ARP-сообщения.

В примере ниже представлено Gratuitous ARP сообщение при включении сетевого интерфейса маршрутизатора с настроенным IP-адресов 198.18.0.1.



Если на маршрутизаторе настроен secondary IP-адрес, при переходе интерфейса в состояние UP будут отправлены Gratuitous ARP уведомления для каждого IP-адреса интерфейса. В примере ниже представлены Gratuitous ARP сообщения, отправляемые при включении интерфейса маршрутизатора с основным IP-адресом 198.18.0.1 и secondary IP-адресом 198.18.2.1.



Безусловно, маршрутизатор будет отвечать на ARP-запросы как для основного, так и для secondary IP-адреса. 

Логично предположить, что как только устройство получает Gratuitous ARP, сразу добавляется новая запись в ARP-таблицу. Однако это не так. Если в таблице устройства отсутствовала ARP-запись, связанная с IP-адресом из Gratuitous ARP сообщения, новая запись добавлена не будет. При необходимости отправить трафик будет сформирован ARP-запрос и получен ARP-ответ. Только после этой процедуры новая запись добавится в ARP-таблицу. 

Пример на маршрутизаторе Cisco. Включим debug arp и подключим в широковещательный домен новое устройство с адресом 198.18.0.200. До подключения нового устройства ARP-таблица маршрутизатора выглядит следующим образом:
cisco#sh arp | inc 198.18.0.200
<вывод пуст>

Включаем новое устройство с адресом 198.18.0.200. Получаем debug-сообщение о приходе Gratuitous ARP:
IP ARP: rcvd rep src 198.18.0.200 64e9.50c8.d6cd, dst 198.18.0.200 GigabitEthernet0/0/1

Проверяем ARP-таблицу:
cisco#sh arp | inc 198.18.0.200
<вывод пуст>

Новая запись не появилась. Делаем пинг до нового адреса:
cisco#ping 198.18.0.200
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 198.18.0.200, timeout is 2 seconds:

019275: Feb  4 10:23:06 UTC: IP ARP: creating incomplete entry for IP address: 198.18.0.200 interface GigabitEthernet0/0/1
019276: Feb  4 10:23:06 UTC: IP ARP: sent req src 198.18.0.1 d8b1.902e.e741,
                 dst 198.18.0.200 0000.0000.0000 GigabitEthernet0/0/1
019277: Feb  4 10:23:06 UTC: IP ARP: rcvd rep src 198.18.0.200 64e9.50c8.d6cd, dst 198.18.0.1 GigabitEthernet0/0/1

.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 2/2/3 ms

Debug-сообщения показывают, что прошла процедура ARP-запрос/ARP-ответ. Проверяем ARP-таблицу:
cisoc#sh arp | i 198.18.0.200
Internet  198.18.0.200            6   64e9.50c8.d6cd  ARPA   GigabitEthernet0/0/1

Новая запись появилась.

ARP и NAT на маршрутизаторах Cisco

Теперь рассмотрим, как обстоят дела с ARP, если на маршрутизаторе используются правила трансляции сетевых адресов – NAT или PAT. В этом случае, мы можем транслировать адрес или адреса локальной сети либо в адрес интерфейса маршрутизатора, либо в какой-либо другой адрес, который будет называться в терминологии NAT внутренним глобальным адресом (inside global или inside mapped). Если трансляция происходит в адрес интерфейса, с ARP вопросов нет. В случае трансляции в адрес, отличный от адреса интерфейса, действуют следующие правила:
  1. Если внутренний глобальный адрес находится в той же IP-подсети, что и адрес интерфейса маршрутизатора, маршрутизатор будет отвечать на ARP-запросы к этому адресу. При этом в собственной arp-таблице маршрутизатора создаётся статическая запись для внутреннего глобального адреса.
  2. Если внутренний глобальный адрес находится в IP-подсети, отличной от адреса интерфейса маршрутизатора, маршрутизатор не будет отвечать на ARP-запросы к этому адресу. В собственной arp-таблице статическая запись не создаётся. Чтобы связь с таким IP-адресом заработала, требуется дополнительная настройка. Мы рассмотрим данный случай более подробно далее в статье.

Отдельно следует упомянуть поведение Gratuitous ARP. Рассматривать варианты генерации Gratuitous ARP для различных случаев (переход интерфейса в состояние UP, изменение основного IP-адреса интерфейса, изменение Secondary IP-адреса и т.д.) не буду, так как получится слишком много вариантов. Хочу указать только два момента. Первый момент: настройка нового правила NAT не приводит к генерации Gratuitous ARP уведомления. Второй момент: с помощью команды clear arp-cache можно не только очистить все динамические записи arp в таблице маршрутизатора, но и заставить маршрутизатор отправить Gratuitous ARP для всех IP-адресов, на которые маршрутизатор должен отвечать, включая внутренние глобальные адреса из правил NAT.
Рассмотрим примеры на основании следующей простейшей топологии:



Примечание: для тестов использовался маршрутизатор C4321 с программным обеспечением 15.4(3)S3 и межсетевой экран Cisco ASA5505 c программным обеспечением 9.1(6)6.

Компьютер Wireshark с адресов 198.18.0.250 в нашем случае будет обозначать подключение к внешней сети (например, к Интернет-провайдеру). С помощью сниффера Wireshark будем просматривать обмен сообщениями ARP между маршрутизатором и компьютером.

Настройки интерфейсов маршрутизатора:
interface GigabitEthernet0/0/0
 description === inside ===
 ip address 192.168.20.1 255.255.255.0
 no ip proxy-arp
 ip nat inside
!
interface GigabitEthernet0/0/1.7
 description === outside ===
 ip address 198.18.0.1 255.255.255.0
 no ip proxy-arp
 ip nat outside

Добавим правило динамического NAT, чтобы транслировать адрес компьютера из LAN (192.168.20.5) во внутренний глобальный адрес 198.18.0.5 при обращении к компьютеру во вне (Wireshark). Добавим правило статического PAT для публикации TCP порта 3389 (RDP) компьютера из LAN под глобальным адресом 198.18.0.2.



ip access-list standard acl-test-arp
 permit 192.168.20.5
ip nat pool test-pool 198.18.0.5 198.18.0.5 netmask 255.255.255.252
ip nat inside source list acl-test-arp pool test-pool overload
ip nat inside source static tcp 192.168.20.5 3389 198.18.0.2 3389 extendable 

Посмотрим ARP-таблицу на маршрутизаторе:
cisco#sh arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
. . .
Internet  198.18.0.1              -   d8b1.902e.e741  ARPA   GigabitEthernet0/0/1.7
Internet  198.18.0.2              -   d8b1.902e.e741  ARPA   GigabitEthernet0/0/1.7
Internet  198.18.0.5              -   d8b1.902e.e741  ARPA   GigabitEthernet0/0/1.7
. . .

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

Сделаем clear arp-cache на маршрутизаторе и посмотрим в Wireshark, какие Gratuitous ARP уведомления будут отправлены с внешнего интерфейса:



Как видно, маршрутизатор уведомил о готовности обслуживать адрес интерфейса, адрес из правила динамического NAT и адрес из правила статического NAT.

А теперь представим ситуацию, когда провайдер расширяет пул публичных адресов, выданных клиенту, за счёт другой подсети. Предположим, дополнительно к IP-подсети 198.18.0.0/24 на внешнем интерфейсе маршрутизатора мы получаем от провайдера новый пул 198.18.99.0/24 и хотим публиковать наши внутренние сервисы под новыми IP-адресами. Для наглядности приведу схему с провайдером:



Добавим правило статического PAT для публикации TCP порта 3389 (RDP) компьютера из LAN под новым глобальным адресом 198.18.99.2:
ip nat inside source static tcp 192.168.20.5 3389 198.18.99.2 3389 extendable 

Если снова посмотреть ARP-таблицу маршрутизатора командой show arp, увидим, что статическая запись для IP-адреса 198.18.99.2 не добавилась. 

Чтобы иметь возможность отправлять ARP-запросы в новую сеть 198.18.99.0/24 с компьютера Wireshark, расширим маску его сетевых настроек до 255.255.0.0 (/16). Напомню, для нашего примера компьютер Wireshark выступает в роли маршрутизатора Интернет-провайдера.

После ввода clear arp-cache сниффер по-прежнему показывает Gratuitous ARP только для трёх IP-адресов: 198.18.0.1, 198.18.0.2, 198.18.0.5. Для нового адреса 198.18.99.2 Gratuitous ARP не срабатывает. Попробуем открыть tcp-порт 3389 адреса 198.18.99.2 и одновременно посмотреть сниффер:





Неуспех. Проверим ARP-таблицу:



ARP-запись для нового IP-адреса 198.18.99.2 не появилась. Причина – новый IP-адрес 198.18.99.2 находится в IP-подсети, отличной от адреса интерфейса маршрутизатора. Как же нам заставить работать новый пул выданных провайдером IP-адресов? Есть четыре варианта:
  1. Попросить провайдера прописать статические ARP-записи для каждого IP-адреса из нового диапазона. Это не очень удобно, если выдаётся широкий диапазон как в нашем примере.
  2. Попросить провайдера прописать статический маршрут. Часто, чтобы выдать дополнительный диапазон белых IP-адресов, провайдер прописывает на интерфейсе своего оборудования secondary IP-адрес. Вместо этого мы можем попросить провайдера прописать статический маршрут к новой IP-подсети через IP-адрес внешнего интерфейса маршрутизатора. В этом случае оборудование провайдера будет знать, что новая подсеть доступна через IP-адрес интерфейса маршрутизатора, а маршрутизатор, в свою очередь, будет отвечать на ARP-запросы, отправленные к собственному интерфейсу.
  3. Прописать secondary IP-адрес из нового диапазона на внешнем интерфейсе маршрутизатора. В этом случае любой IP-адрес нового диапазона будет принадлежать той же подсети, что и IP-адрес (пусть и secondary) интерфейса маршрутизатора. Маршрутизатор автоматически добавит статические записи в свою ARP-таблицу, будет слать Gratuitous ARP и отвечать на ARP-запросы.
  4. Использовать механизм Proxy Arp на маршрутизаторе. На этом варианте остановимся чуть более подробно.

Proxy ARP на маршрутизаторах Cisco

Функциональность Proxy ARP позволяет маршрутизатору отвечать на ARP-запросы при выполнении трёх следующих условий:
  1. Целевой IP-адрес ARP-запроса находится в IP-подсети, отличной от IP-подсети, в которой ARP-запрос получен;
  2. Маршрутизатор имеет один или несколько маршрутов к целевому IP-адресу ARP-запроса;
  3. Маршруты к целевому IP-адресу ARP-запроса указывают на исходящий интерфейс, отличный от интерфейса, на который ARP-запрос был получен.

По умолчанию Proxy ARP включен на всех интерфейсах маршрутизатора. Однако использование механизма Proxy ARP имеет несколько недостатков. В первую очередь Proxy ARP вносит потенциальную уязвимость к атакам типа Man-in-the-middle, когда злоумышленник получит возможность перехватывать сетевой трафик. Поэтому, рекомендуется отключать Proxy ARP как минимум на интерфейсах, к которым подключены внешние сети.

Настройка Proxy ARP на интерфейсе маршрутизатора:
interface GigabitEthernet0/0/1.7
 ip proxy-arp

Отключить Proxy ARP на всех интерфейсах маршрутизатора можно глобально:
ip arp proxy disable

Данная настройка имеет приоритет над настройками Proxy ARP, применёнными на интерфейсах.
Помимо команды ip proxy arp в настройках интерфейса существует команда ip local-proxy-arp. Данная команда работает только когда ip proxy arp включён на интерфейсе и позволяет маршрутизатору отвечать на ARP-запросы, даже если целевой IP-адрес находится в той же IP-подсети, откуда ARP-запрос поступил. Пример настройки:
no ip arp proxy disable
interface GigabitEthernet0/0/1.7
 ip proxy-arp
 ip local-proxy-arp

Данная настройка может пригодится, если мы хотим, чтобы трафик в рамках одного широковещательного домена шёл через интерфейс нашего маршрутизатора. Данную задачу можно реализовать с использованием Protected port (PVLAN edge) настроек на L2-коммутаторе (switchport protected).

Включение Proxy ARP на внешнем интерфейсе маршрутизаторе позволит решить проблему с новым пулом адресов, выданных провайдером. Попробуем открыть tcp-порт 3389 адреса 198.18.99.2 после включения Proxy ARP на интерфейсе маршрутизатора и одновременно посмотреть сниффер:



Успех. Маршрутизатор отвечает на ARP-запрос и порт открывается. Таким образом, функциональность Proxy ARP также можно использовать при необходимости трансляции адресов в новый пул.

Итоги

Попробую тезисно обобщить основные моменты первой части статьи:
  1. Сетевое оборудование Cisco добавляет ARP-запись о новом удалённом устройстве в ARP-таблицу сразу по приходу ARP-запроса от удалённого устройства. Данное поведение позволяет сократить ARP-трафик в сети.
  2. Маршрутизатор Cisco будет отвечать на ARP-запросы к внутреннему глобальному IP-адресу правила NAT, если данный IP-адрес принадлежит той же IP-подсети, что и интерфейс маршрутизатора. Дополнительные настройки для работы ARP не требуются.
  3. Если внутренний глобальный IP-адрес правила NAT маршрутизатора не принадлежит IP-подсети интерфейса маршрутизатора, требуются дополнительные настройки. Существуют четыре варианта:
    1. Статические ARP-записи на внешнем оборудовании;
    2. Статический маршрут на внешнем оборудовании;
    3. Настройка secondary IP-адреса на интерфейсе маршрутизатора;
    4. Использование Proxy ARP.
      Первый и второй вариант подразумевают изменение настроек на «чужом» сетевом оборудовании и не всегда может быть приемлем.
      Третий вариант является наиболее предпочтительным.
      Четвёртый вариант может быть использован, но открывает уязвимость с точки зрения сетевой безопасности.
  4. Функциональность Proxy ARP включена на интерфейсах маршрутизатора по умолчанию. Рекомендуется отключать Proxy ARP как минимум на интерфейсах, подключаемых к Интернет-провайдерам.
Source: https://habrahabr.ru/company/cbs/blog/276863/

NAT и Proxy ARP на межсетевых экранах Cisco ASA

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.

Secondary IP-адрес на ASA
Настройка статической записи в ARP-таблице ASA с ключевым словом alias позволяет реализовать на ASA аналог secondary IP-адреса. Здесь описан пример настройки.

В некоторых случаях функционал 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) …

Итоги

Прежде чем переходить к описанию случаев из практики, выделю основные моменты второй части статьи:
  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.

Случай №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.ffff\narp-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. 

Source:https://habrahabr.ru/company/cbs/blog/277251/