ARP: Нюанси роботи обладнання Cisco та цікаві випадки. Частина 2



Привіт, 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:
network object 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 local network-LAN
subnet 192.168.20.0 255.255.255.0
object remote network-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 local ip-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 from outside 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 from outside 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.1 Q vlan#2 P0 arp who-has 80.X.X.4 tell 195.Y.Y.1
325: 22:03:41.937329 802.1 Q vlan#2 P0 arp who-has 80.X.X.4 tell 195.Y.Y.1
326: 22:03:42.822909 802.1 Q 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-адресу, ip address x.x.x.x y.y.y.y. Після цього ASA все ж відправила Gratuitous ARP, і все злетіло.

Висновок

У цій статті, що складається з двох частин, я постарався розглянути тонкощі роботи ARP на обладнанні Cisco у випадках використання трансляції мережевих адрес (NAT), а також функціонал Proxy ARP. Розібрав відмінності в роботі ARP між маршрутизаторами Сіѕсо і міжмережними екранами Cisco ASA. У висновку статті я розглянув проблеми, що виникають при підключенні до Інтернет-провайдера, обумовлені роботою ARP.

Описані випадки показують, на скільки важливо пам'ятати про необхідність перевірки ARP у процесі вирішення та усунення мережевих проблем. Сподіваюся, матеріал даної статті стане корисним для більш глибокого розуміння роботи ARP.

Чекаю на коментарі. Може бути хтось зможе розповісти власні цікаві випадки, пов'язані з роботою ARP.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.