По просьбе коллеги (Fedia) я собрался с мыслями и решился написать статью про NAT NVI. Надо сказать, что вообще сама по себе трансляция адресов на роутере многократно рассматривалась, в т.ч. в статье «По просьбам трудящихся: Dual ISP на маршрутизаторах cisco без BGP». Тем не менее, описанный в ней механизм inside source и outside source NAT имеет некоторые ограничения.
Задача 1.
В частности, рассмотрим топологию:
Постановка задачи.
Требуется транслировать на R0:
Поскольку адрес интерфейса один, то естественно используется PAT.
Решение № 1.
Сами по себе трансляции пишутся для каждого случая довольно просто.
Теперь нам, требуется указать для каждого интерфейса, участвующего в трансляции, является он внутренним (inside) или внешним (outside) для трансляции. Вроде все просто но вот незадача: интерфейс fa 0/1 нужно будет сделать одновременно inside и outside. Что невозможно, поскольку каждый интерфейс может быть либо inside, либо outside.
Решить такую задачу с помощью классического NAT можно только с серьезными ухищрениями.
Первый способ решения состоит в применении технологии PBR (policy based routing). Идея состоит в следующем:
Граничные условия. Здесь позволю себе сделать несколько оговорок.
Во-первых, хотел бы обратить внимание, что такая хитрость возможно далеко не всегда. Дело в том, что PBR срабатывает раньше, чем inside-to-outside NAT (см. статью Cisco: Порядок обработки пакетов «в сложных конфигурациях»). В случае с outside-to-inside NAT это не верно, т.е. сначала проверяются правила NAT.
Во-вторых, мы создаем излишнюю нагрузку на роутер, т.к. отправка пакетов через PBR всегда нагружает процессор.
Т.е. решение, хотя и не выходит за рамки классического NAT, стоит на весьма хилых подпорках.
Решение № 2.
Теперь, собственно, давайте подойдем к тому варианту, из-за которого и писалась эта статья.
Технология Cisco NVI NAT (или ее еще часто называют ip nat enable) позволяет нам не заботиться о маркировании интерфейсов как inside или outside. Мы просто маркируем их, как включенные в NAT с помощью команды
И пишем унифицированные правила. В частности для нашего случая, эти правила будут отличаться только отсутствием слова inside:
А роутер сам разбирается, при получении на интерфейс пакета, подвергать этот пакет прямой или обратной трансляции, и какое у этой трансляции направление.
Естественно, такая «автоматика» требует гораздо более внимательного задания «интересного» трафика для трансляции, поскольку если описать его слишком поверхностно, можно получить непредсказуемое число трансляций в обе стороны.
Тем не менее, описанная топология достаточно редко встречается в реальных сетях. Как правило, она требуется мелким провайдерам. И поэтому, сейчас я хотел бы описать решение более жизненной задачи.
Задача 2.
Постановка задачи.
Часто бывает, что для некоторых запросов извне нам бы хотелось представить «запрашивающих» в качестве некоторого внутреннего адреса.
Рассмотрим топологию
Условия задачи:
Анализ.
Очевидно, что классический static PAT в данном случае не подходит, т.к. при запросе из интернета он изменит нам только адрес и порт назначения (c 172.16.1.5:22 на 192.168.1.2:22), оставив source (любой адрес из интернета) неизменным. Тогда ответ от SRV пойдет через шлюз по умолчанию, т.е. через R2 в интернет.
Нам же нужно, чтобы ответ возвращался тем же путем – через R1, т.е. чтобы клиент, подключившийся к серверу, получил ответ от того же глобального адреса, на который он обращался. Для этого хорошо бы представить обращающиеся к 172.16.1.5:22 хосты в качестве некоторого внутреннего адреса, например 192.168.0.201, тогда ответ на этот адрес пойдет по маршрутизации от R2 через локальную сеть к R1 и уже потом в Интернет.
Казалось бы, для этого можно использовать outside source NAT, но есть в cisco IOS одна загвоздка: outside source NAT не может быть PAT, т.е. работает на сетевом уровне и транслирует адрес в адрес. Это вынуждает нас делать трансляцию в некий пул. И число таких одновременных трансляций ограничено емкостью пула.
Поскольку количество адресов в интернете превышает любой наперед заданный пул, а сервер может быть очень посещаемый, то данное решение слабо нам подходит.
Решение.
Обратимся к Cisco NVI. Поскольку направление трансляции больше не задается на интерфейсах, мы можем сделать несколько прямых PAT-трансляций:
1. Трансляция для выхода в интернет наших хостов:
2. Трансляция для проброса порта:
Другими словами, мы совместили две динамических PAT-трансляции и одну статическую.
Конечно, данная статья не претендует на всевозможное раскрытие возможностей Cisco NVI NAT, тем не менее, она может быть полезна тем, кто часто использует NAT в своих топологиях и не хочет ограничивать себя возможностями классического NAT.
P.S. Спасибо Fedia за инвайт, приобщение к хабраобществу и просто за то, что сподвиг на написание сего опуса :)
Подкопаев Илья, инструктор
Задача 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 overloadRouter(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). Идея состоит в следующем:
- 1. Настроить fa 0/1 у R0 как outside.
- 2. Создать на R0 виртуальный интерфейс (loopback) lo0 с некоторым адресом и включить на нем ip nat inside.
- 3. Перенаправить трафик с fa 0/1 на lo0, если этот трафик требуется транслировать в интерфейс fa 0/0.
Граничные условия. Здесь позволю себе сделать несколько оговорок.
Во-первых, хотел бы обратить внимание, что такая хитрость возможно далеко не всегда. Дело в том, что PBR срабатывает раньше, чем inside-to-outside NAT (см. статью Cisco: Порядок обработки пакетов «в сложных конфигурациях»). В случае с outside-to-inside NAT это не верно, т.е. сначала проверяются правила NAT.
Во-вторых, мы создаем излишнюю нагрузку на роутер, т.к. отправка пакетов через PBR всегда нагружает процессор.
Т.е. решение, хотя и не выходит за рамки классического NAT, стоит на весьма хилых подпорках.
Решение № 2.
Теперь, собственно, давайте подойдем к тому варианту, из-за которого и писалась эта статья.
Технология Cisco NVI NAT (или ее еще часто называют ip nat enable) позволяет нам не заботиться о маркировании интерфейсов как inside или outside. Мы просто маркируем их, как включенные в NAT с помощью команды
Router(config-if)# ip nat enableИ пишем унифицированные правила. В частности для нашего случая, эти правила будут отличаться только отсутствием слова inside:
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)# 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 source list 101 interface fa 0/0 overload
Router(config)# ip nat source list 102 interface fa 0/1 overloadА роутер сам разбирается, при получении на интерфейс пакета, подвергать этот пакет прямой или обратной трансляции, и какое у этой трансляции направление.
Естественно, такая «автоматика» требует гораздо более внимательного задания «интересного» трафика для трансляции, поскольку если описать его слишком поверхностно, можно получить непредсказуемое число трансляций в обе стороны.
Тем не менее, описанная топология достаточно редко встречается в реальных сетях. Как правило, она требуется мелким провайдерам. И поэтому, сейчас я хотел бы описать решение более жизненной задачи.
Задача 2.
Постановка задачи.
Часто бывает, что для некоторых запросов извне нам бы хотелось представить «запрашивающих» в качестве некоторого внутреннего адреса.
Рассмотрим топологию
Условия задачи:
- 1. На R1 для хостов из 192.168.0.0/24 сети сконфигурирован PAT в адрес 172.16.1.5.
- 2. На SRV1 шлюзом по умолчанию выставлен R2.
- 3. Необходимо пробросить на R1 порт SSH (22) на сервер.
Анализ.
Очевидно, что классический static PAT в данном случае не подходит, т.к. при запросе из интернета он изменит нам только адрес и порт назначения (c 172.16.1.5:22 на 192.168.1.2:22), оставив source (любой адрес из интернета) неизменным. Тогда ответ от SRV пойдет через шлюз по умолчанию, т.е. через R2 в интернет.
Нам же нужно, чтобы ответ возвращался тем же путем – через R1, т.е. чтобы клиент, подключившийся к серверу, получил ответ от того же глобального адреса, на который он обращался. Для этого хорошо бы представить обращающиеся к 172.16.1.5:22 хосты в качестве некоторого внутреннего адреса, например 192.168.0.201, тогда ответ на этот адрес пойдет по маршрутизации от R2 через локальную сеть к R1 и уже потом в Интернет.
Казалось бы, для этого можно использовать outside source NAT, но есть в cisco IOS одна загвоздка: outside source NAT не может быть PAT, т.е. работает на сетевом уровне и транслирует адрес в адрес. Это вынуждает нас делать трансляцию в некий пул. И число таких одновременных трансляций ограничено емкостью пула.
Поскольку количество адресов в интернете превышает любой наперед заданный пул, а сервер может быть очень посещаемый, то данное решение слабо нам подходит.
Решение.
Обратимся к Cisco NVI. Поскольку направление трансляции больше не задается на интерфейсах, мы можем сделать несколько прямых PAT-трансляций:
1. Трансляция для выхода в интернет наших хостов:
Router(config)# access-list 100 permit ip 192.168.0.0 0.0.0.255 any
Router(config)# ip nat source list 100 interface fa0/0 overload2. Трансляция для проброса порта:
ip nat source static tcp 192.168.1.2 22 172.16.1.5 22 extendable
3. Трансляция адресов всевозможных запрашивающих хостов во внутренний адрес 192.168.0.201Router(config)# access-list 101 permit tcp any host 172.16.1.5 eq 22
Router(config)# ip nat pool SERV_PAT 192.168.0.201 192.168.0.201 prefix-length 24
Router(config)# ip nat source list 101 pool SERV_PAT overloadДругими словами, мы совместили две динамических PAT-трансляции и одну статическую.
Конечно, данная статья не претендует на всевозможное раскрытие возможностей Cisco NVI NAT, тем не менее, она может быть полезна тем, кто часто использует NAT в своих топологиях и не хочет ограничивать себя возможностями классического NAT.
P.S. Спасибо Fedia за инвайт, приобщение к хабраобществу и просто за то, что сподвиг на написание сего опуса :)
Подкопаев Илья, инструктор
