antiCisco blogs » NAT

antiCisco blogs


блоги по технологиям и оборудованию cisco от инструкторов

Публикации помечены ‘NAT’

Опубликовано 5 Ноябрь , 2015

В своих статьях Сергей описал о том, как настроить НАТ на АСА в версиях 8.3 и выше. Однако, в статье не освещается вопрос о подробностях … Итак, заинтересованным велком! Читать продолжение записи »

 

Метки: ,
Опубликовано: Безопасность cisco | Нет комментариев »

Опубликовано 10 Декабрь , 2011

Вот мы и добрались до главного: а в какой же последовательности все это богатство трансляций обрабатывается?

Глобально всю последовательность можно разделить на 3 больших блока:
I – Twice NAT
II – Object NAT
III – Twice NAT (after-auto)

Да-да, именно так. И с до и после. По умолчанию трансляции Twice NAT добавляются в конец первой секции, но можно явно указать, в какое место их ставить (ура!) указав номер правила.
nat (INS,OUT) {НОМЕР} …
Логика здесь такая же, как у строк ACL — если пишем «номер 1», то добавляем самым первым правилом, а остальные сдвигаются ниже.

Это очень предусмотрительно со стороны циски 🙂 потому что сами правила в I и III секциях (там, где Twice NAT) обрабатываются по порядку, в котором они записаны в конфиге. Как только совпадение будет найдено, заголовок пакета сразу транслируется и новый пакет отправляется по назначению.

Мы можем принудительно записать трансляции Twice NAT и в третью секцию, указав ключевое слово after-auto. Такое правило вставится в конец третьей секции по умолчанию или в то место третьей секции, которое мы явно укажем при помощи номера строки.
Читать продолжение записи »

 

Метки: , ,
Опубликовано: Безопасность cisco | 2 комментария »

Опубликовано 9 Декабрь , 2011

Пришло время добавить destination, а именно тут и начинается самое интересное.

Рассмотрим для начала формат команды:
nat [(SOURCE_INT,DEST_INT)] source {dynamic|static} SOURCE MAPPED_SOURCE destination static MAPPED_DEST DEST

Где SOURCE, MAPPED_SOURCE, MAPPED_DEST, DEST соответствующие объекты. Я обращаю ваше внимание на то, что разработчики ASA OS остались верны своей логике хоть где-нибудь запутать – группы для адресов назначения имеют обратный порядок.
Читать это надо так: если пакет идет с интерфейса SOURCE_INT на интерфейс DEST_INT, адрес источника пакета из группы SOURCE, а адрес назначения из группы DEST, то адрес источника меняется с SOURCE на MAPPED_SOURCE, а адрес назначения меняется с MAPPED_DEST на DEST. Обратный пакет, обращенный на адрес MAPPED_SOURCE пройдет внутрь, его адрес назначения сменится обратно с MAPPED_SOURCE на SOURCE. Но такая трансляция будет выполнена только если адрес источника пакета из группы DEST, и в этом случае адрес источника сменится обратно на MAPPED_DEST.
В случае создания статической трансляции можно будет обращаться (инициировать сессию) снаружи внутрь, а в случае динамической – нет.
Читать продолжение записи »

 

Метки: , ,
Опубликовано: Безопасность cisco | 6 комментариев »

Опубликовано 9 Декабрь , 2011

С object NAT мы познакомились подробно в предыдущих статьях. Пришло время разобраться, что такое TWICE NAT и зачем он вообще нужен.

При помощи данной конструкции можно сделать две принципиальные вещи, которые нельзя сделать при помощи object NAT:
1. Сделать трансляции одной и той же сети в разные адреса в зависимости от того, в какую сеть идет пакет. Это необходимо, например, при построении IPSec – надо не транслировать адреса пакетов, если они направляются в туннель.
2. А еще (то, что нельзя было сделать в версии 8.2 вовсе) – статическая трансляция диапазона (или группы) портов кучкой. Например, пробросить целиком диапазон с 1024 по 65535.

Рассмотрим формат команды для динамических трансляций NAT пока без указания сети назначения:
nat [(SOURCE_INT,DEST_INT)] source dynamic SOURCE MAPPED_SOURCE [interface] [dns]
Читать продолжение записи »

 

Метки: , , , ,
Опубликовано: Безопасность cisco | 2 комментария »

Опубликовано 2 Декабрь , 2011

Наверняка многие уже столкнулись с большими изменениями в синтаксисе настройки NAT при переходе от линейки ASA ОС 8.2 к 8.3. Трудно сказать, с чем связано такое резкое изменение подхода, но одно можно сказать уверенно: настройка стала менее понятна и прозрачна. Но это не повод вовсе не использовать версии 8.3, 8.4 и далее (вряд ли разработчики вернут старый синтаксис :))

Предлагаю постепенно, от простого к сложному, освоить новый синтаксис, ибо по нему регулярно возникают вопросы в форуме и необходимость статьи назрела. Даже перезрела, я бы сказал 🙂

Итак, cisco ввела два новых понятия: Object NAT и Twice NAT, заменив ими все предыдущие типы (Regular, Policy, Identity NAT).
______________
UPD 10.12.11
А также попутно отменила понятие nat-control. Теперь у нас тотальный no nat-control что означает «нет правила НАТ — просто маршрутизировать».
______________

Для начала познакомимся с понятием object NAT, узнаем про последовательность обработки правил object NAT, потом познакомимся с TWICE NAT и в конце подведем черту: опишем всю последовательность правил NAT в новом синтаксисе. Планирую небольшой цикл статей — штуки 4, дабы не перегружать сразу читателей.

Работать будем вот с такой топологией

Рассмотрим простейшую задачу: выйти через ASA в интернет.
Для этого, как и ранее, надо определить, какие внутренние адреса мы собираемся транслировать в какой внешний пул адресов (NAT) или какой адрес (РАТ).
Читать продолжение записи »

 

Метки: , , ,
Опубликовано: Безопасность cisco | 7 комментариев »

Опубликовано 27 Февраль , 2010

Трансляция сетевых адресов не является защитной технологией, однако она настолько часто применяется, что пропускать её не стоит. Все возможности трансляции сетевых адресов здесь описывать не буду, коснусь лишь самых частоиспользуемых.

Трансляция сетевых адресов (Network Address Translation, NAT) как правило, требуется на границе между сетью компании и провайдером Интернет.

Обычно разделяют внутреннюю (inside) и внешнюю (outside) трансляции. Внутренняя трансляция подменяет адрес источника при выходе «наружу» маршрутизатора, а внешняя трансляция подменяет адрес источника при проходе «внутрь». Направление определяется при помощи меток, написанных на интерфейсе

ip nat {inside|outside}

Читать продолжение записи »

 

Метки: , ,
Опубликовано: Маршрутизаторы и коммутаторы | 9 комментариев »

Опубликовано 17 Февраль , 2010

Кроме вышеперечисленных типичных трансляций встречаются еще и необычные задачи. Рассмотрим два случая, не перечисленных в предыдущих частях

1. Трансляция адресов между интерфейсами с одинаковым уровнем безопасности.
Напомню, что по умолчанию передача пакетов между такими интерфейсами запрещена, однако если разрешить, то между такими интерфейсами возникает обычная маршрутизация. Даже если включено строгое правило nat-conrol. Однако, это не значит, что между такими интерфейсами нельзя транслировать адреса. Для этого мы используем обычный формат внутренних (inside) динамических и статических трансляций
Читать продолжение записи »

 

Метки: , ,
Опубликовано: Безопасность cisco | 2 комментария »

Опубликовано 15 Февраль , 2010

Статические трансляции, в отличие от динамических, жестко связывают адреса (или адреса с портами). Именно эта их особенность позволяет инициировать сессии как изнутри, так и снаружи МСЭ. Но для того, чтобы раз и навсегда не путаться в написании статических трансляций, я научу вас их «читать» правильно. Итак, формат команды довольно прост:

static ({source_int},{dest_int}) {translated_address} {real_addess}

где

source_int – интерфейс на который приходит пакет
dest_int – интерфейс, с которого пакет пойдёт дальше
real_address – реальный адрес хоста
translated_address – странслированный адрес хоста

И читается трансляция так:
Когда пакет бежит с интерфейса source_int на интерфейс dest_int его адрес ИСТОЧНИКА подменяется с real_address на translated_address.
Когда же пакет бежит в обратном направлении, т.е. приходит на интерфейс dest_int и идет далее через интерфейс source_int его адрес НАЗНАЧЕНИЯ меняется с translated_address на real_address
Читать продолжение записи »

 

Метки: , , ,
Опубликовано: Безопасность cisco | 4 комментария »

Опубликовано 14 Февраль , 2010

Трансляция сетевых адресов (Network Address Translation, NAT), как правило, требуется на границе между сетью компании и провайдером Интернет. Однако, это далеко не единственная задача. Рассмотрим несколько типичных задач и способы решения при помощи межсетевого экрана ASA.

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

Обычно разделяют внутреннюю (inside) и внешнюю (outside) трансляции. Внутренняя трансляция подменяет адрес источника при выходе «наружу» межсетевого экрана, а внешняя трансляция подменяет адрес источника при проходе «внутрь» МСЭ.
Читать продолжение записи »

 

Метки: , , ,
Опубликовано: Безопасность cisco | 4 комментария »

Опубликовано 13 Февраль , 2010

Наконец я собрался с мыслями и решился написать статью про NAT NVI. Надо сказать, что вообще сама по себе трансляция адресов на роутере многократно рассматривалась, в т.ч. в статье «По просьбам трудящихся: Dual ISP на маршрутизаторах cisco без BGP». Тем не менее, описанный в ней механизм inside source и outside source NAT имеет некоторые ограничения.

Задача 1.
В частности, рассмотрим топологию:

Постановка задачи.

Требуется транслировать на R0:

  • 1. адреса за R2 (10.0.2.0/24) – в интерфейс fa 0/0, при обращении к R1
  • 2. адреса за R3 (10.0.3.0/24) – в интерфейс fa 0/1, при обращении к R2

Поскольку адрес интерфейса один, то естественно используется PAT.
Решение № 1.
Сами по себе трансляции пишутся для каждого случая довольно просто.
Router(config)# access-list 101 permit ip 10.0.2.0 0.0.0.255 10.0.1.0 0.0.0.255
Router(config)# ip nat inside source list 101 interface fa 0/0 overload

Router(config)# access-list 102 permit ip 10.0.3.0 0.0.0.255 10.0.2.0 0.0.0.255
Router(config)# ip nat inside source list 102 interface fa 0/1 overload

Теперь нам, требуется указать для каждого интерфейса, участвующего в трансляции, является он внутренним (inside) или внешним (outside) для трансляции. Вроде все просто но вот незадача: интерфейс fa 0/1 нужно будет сделать одновременно inside и outside. Что невозможно, поскольку каждый интерфейс может быть либо inside, либо outside.
Решить такую задачу с помощью классического NAT можно только с серьезными ухищрениями.
Первый способ решения состоит в применении технологии PBR (policy based routing). Идея состоит в следующем:
Читать продолжение записи »

 

Метки: , , ,
Опубликовано: Маршрутизаторы и коммутаторы | 2 комментария »