Доброго дня! Возможно кто-то сможет пояснить один момент. Есть следующая схема: R1—ASA—R2
За R2 находятся адреса 1.1.1.1 и 2.2.2.2. У R1 есть лупбэк с адресом 3.3.3.3.
Задача: R1 должен при обращении к адресу 192.168.3.1 отправляться на адрес 1.1.1.1, а при обращении к 192.168.3.2 на 2.2.2.2. На R1 настроен статический маршрут к сети 192.168.3.0/29 в сторону ASA. Source адрес R1 транслируется в адрес интерфейса ASA смотрящего в сторону R2.
Такая конструкция работает, но требует, чтобы на ASA был маршрут к 1.1.1.1 и 2.2.2.2 в сторону R2. Наличие маршрута к 192.168.3.0/24 на ASA никакого влияния не оказывает. Т.е. ASA сначала делает трансляцию, а затем маршрутизирует.
Без маршрута к 1.1.1.1 и 2.2.2.2 вижу: R1#ping 192.168.3.1 source 3.3.3.3
«192.168.3.1 отправляться на адрес 1.1.1.1, а при обращении к 192.168.3.2 на 2.2.2.2.»
А каким образом пакет с ASA дойдет к 1.1.1.1 или 2.2.2.2 если нет маршрута?:) это же CCNA R&S.
Problem: «%ASA-6-110003: Routing failed to locate next-hop for protocol from src interface» Error Message
ASA drops traffic with the error:%ASA-6-110003: Routing failed to locate next-hop for protocol from src interface:src IP/src port to dest interface:dest IP/dest port error message.
Solution This error occurs when the ASA tries to find the next hop on an interface routing table. Typically, this message is received when ASA has a translation (xlate) built to one interface and a route pointing out a different interface. Check for a misconfiguration on the NAT statements. Resolution of the misconfiguration may resolve the error.
Ну, транслировался исходящий пакет в пакет inside:192.168.2.2 to outside:1.1.1.1. А дальше его куда девать, если нет маршрута к 1.1.1.1?
Кроме того, если маршрут к сети 192.168.3.0/24 не нужен, то в чем смысл указания пары интерфейсов (inside, outside), если мы фактически узнаем пару интерфейсов только после трансляции?
Получается, что без маршрута к адресам после трансляции не обойтись.
Нда уж, такой базовой вещи как маршрутизация не понять =)))
Для 1 хоста сделай статик маршрут.
Смотрите пример с CCNP Security FIREWALL 642-618 Official Cert Guide стр. 370. Там пример с overlapping network. Возможно, Вам поможет.
Часовой пояс: UTC + 3 часа
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 23
MikroTik. Правильный dst nat при использовании 2-х и более провайдеров
Приступая к выполнению задачи я рассчитывал на легкую прогулку в тени дубового парка, созерцая природу и предаваясь размышлениям… Однако позже стало понятно, что это будет тернистый и сложный поход сквозь горные реки с подводными камнями, обледеневшими скалами и глубокими пещерами. Через медитации, борьбу со стихиями и собственной тупостью преодоление себя я, все таки, достиг желанной нирваны.
В этой статье я не только предоставлю готовый набор правил, но и постараюсь максимально доступно объяснить почему и как именно они работают.
Часть 1.
Для начала пробежимся по всем настройкам, дабы самые нетерпеливые могли скопипастить не читая.
Не помню начиная с какой версии RouterOS появилась эта фишка. Она позволяет группировать интерфейсы, что весьма удобно (например, в правилах /ip firewall). У меня создана группа из 3-х WAN-интерфейсов. AcidVenom подсказал, что в 6.36
IP-адреса (адреса, по понятным причинам, «левые»):
Для организации Failover’а я настроил рекурсивную маршрутизацию, подробнее расскажу в 2-ой части.
Firewall (для данной публикации я сознательно привожу правила, разрешающие все. Не делайте так!):
Часть 2.
Рассмотрим все подробнее.
/ip route В первых трех строчках мы указываем default gateway каждого из 3-х наших провайдеров. Маршруты имеют одинаковый вес (distance), но работают в разных таблицах маршрутизации.
Другими словами, эти маршруты работают для пакетов промаркированных соответствующим тегом (routing-mark). Теги пакетам мы будем навешивать в /ip firewall mangle (о чем я подобно расскажу ниже).
Следующие 3 строки — указание маршрутов по умолчанию в основной таблице маршрутизации.
Здесь стоит обратить внимание на:
ISP1 — основной, за ним ISP2 и ISP3 замыкает, т.е. при отказе провайдера ISP1 работать будем через ISP2, если и ISP2 почил в бозе, то за дело возьмется ISP3.
На самом деле трафик отправится активному провайдеру, а дальше тот отправит его в Интернет через свои аплинки.
Английский статьи http://wiki.mikrotik.com/wiki/Manual:IP/Route, на мой взгляд, слегка упорот. Это не Cisco CCNA Exploration, который читается на одном дыхании, но я постараюсь перевести ее отрывок максимально понятно. Если где-то увидите такую же упоротость, поправьте меня, пожалуйста.
Во-первых, определимся с некоторыми терминами. Nexthop — следующий прыжок, если дословно. Следующий шлюз/роутер/маршрутизатор на пути следования пакета из точки А(от моего роутера, например) в точку Б (допустим до гуглового DNS 8.8.8.8), т.е. следующий транзитный участок, на котором будет обрабатываться пакет. В переводе будет использоваться словосочетание “следующий хоп” (простите за англицизм).
Immediate nexthop — следующий шлюз/роутер/маршрутизатор на пути следования пакета из точки А в точку Б, доступный непосредственно. Для моего домашнего MikroTik, с маршрутом по-умолчанию:
89.189.163.1 — это и есть immediate nexthop, т.к. доступен он через ether1-gateway. В переводе будет использоваться словосочетание “непосредственно доступный следующий хоп”.
Connected route — связанный маршрут. Маршрут, шлюз которого доступен непосредственно.
Gateway — сетевой шлюз/роутер/маршрутизатор. Я буду пользоваться всеми тремя вариантами перевода.
scope — Используется в механизме поиска следующего хопа, т.е. решения какой же хоп станет следующим. Нужный маршрут может быть выбран только среди маршрутов, значения scope которых меньше либо равно значению target-scope. Значения по-умолчанию зависят от протокола:
Табличка значений обоих параметров.
Поиск следующего хопа. Поиск следующего хопа является частью процесса выбора маршрута.
Маршрутам, находящимся в FIB, нужен интерфейс, соответствующий каждому из адресов шлюзов. Адрес следующего хопа-шлюза должен быть непосредственно доступен через этот интерфейс. Интерфейс, который следует использовать для посылки исходящего пакета каждому из шлюзов, находится с помощью поиска следующего хопа.
Некоторые маршруты (например, iBGP), в качестве адреса шлюза, могут иметь адрес принадлежащий маршрутизатору, находящемуся через несколько прыжков-шлюзов от нашего MikroTik. Для установки таких маршрутов в FIB необходимо найти адрес шлюза, доступного непосредственно (an immediate nexthop), т.е. напрямую от нас, который и будет использоваться для достижения адреса шлюза в этом маршруте. Непосредственный адрес следующего хопа также может быть найден при помощи механизма поиска следующего хопа.
Поиск следующего хопа выполняется только в основной таблице маршрутизации main, даже для маршрутов, имеющих отличное значение параметра routing-mark. Это необходимо для ограничения установки маршрутов, которые могут быть использованы для поиска непосредственно доступных хопов (immediate nexthops). В маршрутах для протоколов RIP или OSPF предполагается, что следующий маршрутизатор доступен непосредственно и должен быть найдены используя только связанные маршруты(connected routes).
Маршруты с именем интерфейса в качестве шлюза не используются в поиске следующего хопа. Если есть маршрут с именем интерфейса, а также маршрут с активным IP-адресом, то маршрут с интерфейсом игнорируется.
Маршруты, имеющие значение параметра scope больше максимально допустимого не используются в поиске следующего хопа. В каждом маршруте указывается максимально допустимое значение параметра scope, для его следующего хопа, в параметре target-scope. Значение по-умолчанию для этого параметра позволяет выполнить поиск следующего хопа только через связанные маршруты (connected routes), за исключением iBGP-маршрутов, которые имеют большее значение по-умолчанию и могут выполнить поиск следующего хопа также через IGP и статические маршруты.
Интерфейс и адрес следующего непосредственно доступного маршрутизатора выбираются основываясь на результатах поиска следующего хопа:
Он и принимает, и таким образом маршруты по-умолчанию через:
Надеюсь мой перевод и объяснение будут вам полезны.
Пока самые охочие до знаний читают под спойлером, расскажу немого короче и проще. Когда мы указываем scope=10 в последних трех строках, мы даем понять MikroTik’у, что:
/ip firewall mangle
Для пояснения правил этого раздела пригласим несколько помощников.
Начем с первых двух. В первом мы сообщаем роутеру, что все входящие chain=input соединения на интерфейс ISP1 нужно маркировать action=mark-connection new-connection-mark=ISP1-conn, а так же указаваем passthrough=yes, чтобы пакет, после прохождения этого правила, не покинул таблицу и продолжил следование по правилам.
Все описанное выше справедливо и для ISP2 и для ISP3. Таким образом мы добились того, что роутер ответит именно с того интерфейса, на который к нему прийдет запрос.
Переходим к завершающим шести правилам. Уже понятно, они также разбиты на подгруппы по 2, для каждого из наших ISP. Первое из них поручает роутеру следить за цепочкой FORWARD и если происходит соединение через интерфейс ISP1, то оно маркируется action=mark-connection новым тегом new-connection-mark=ISP1-conn-f (обратите внимание! отличным от тега трафика самого маршрутизатора, в данном случае мы маркируем транзитный трафик). passthrough=no, т.к. мы не хотим, чтобы пакет, после попадания в это правило, обрабатывался в таблице как-то еще.
Второе навешивает нужную метку роутинга new-routing-mark=ISP1-route в цепочке PREROUTING, т.е. ДО принятия решения о маршрутизации, и отслеживает трафик пришедший к нам из локальной сети in-interface=bridge. Здесь нас выручает механизм CONNECTION TRACKING, позволяющий поймать промаркированные правилом выше соединения из локальной сети(от WEB-сервера) и навесить им необходимый тег роутинга.
Это позволяет транзитному трафику(здесь к/от web-сервера) идти именно тем путем, которым он и пришел, т.е. пришел через ISP1 — уходи через него же.
Заключение
Очень рад, если мои объяснения понятны, а данный труд станет полезен. Ушел медитировать, всем удачи!
ARP: Нюансы работы оборудования Cisco и интересные случаи. Часть 2
Привет, Habr! В предыдущей части статьи мы рассмотрели особенности работы ARP на маршрутизаторах Cisco, связанные с правилами NAT и с функцией Proxy ARP. В данном посте попробую разобрать отличия в работе ARP между маршрутизаторами Cisco и межсетевыми экранами Cisco ASA. В заключении статьи поделюсь несколькими интересными случаями из практики, связанными с работой ARP.
NAT и Proxy ARP на межсетевых экранах Cisco ASA
Рассмотрим примеры на основании следующей простейшей топологии:
Настройки интерфейсов Cisco ASA:
Настройки правила NAT и списка доступа на интерфейсе outside:
Как видно из представленных настроек мы публикуем порт tcp 3389 (RDP) под адресом 198.18.99.2, который не принадлежит IP-подсети интерфейса Cisco ASA.
Проверяем опцию sysopt noproxyarp:
Видно, что опция не выставлена (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 можно настроить следующим образом:
Представленная конфигурация указывает для 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. Например, nat (inside,outside) …
Случай №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.****.****:
Однако, через какое-то время заметили сообщение в debug arp на ASA:
Судя по данному сообщению 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:
Оказалось, что на интерфейсе провайдера адрес 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.
