RSS
 

Пример двойного NAT

02 Июл

NAT1Давайте рассмотрим пример следующий сети. У нас есть узел “INSIDE_HOST”, который подключен к пограничному маршрутизатору “NAT”. Этот узел не имеет шлюза по умолчанию. То есть, он видит только сеть, которая непосредственно подключена к его интерфейсу FastEthernet0/0 и интерфейсу FastEthernet0/1 маршрутизатора «NAT».

Есть удаленный узел “OUTSIDE_HOST”, который стоит за периметром нашей сети и не имеет маршрута к узлу “INSIDE_HOST”. Он находится в сети Интернет и имеет белые IP адреса. Узел “OUTSIDE_HOST” может быть как непосредственно подключен к роутеру “NAT”, так и где-то далее в сети. Но мы, для простоты эксперимента предположим, что он прямо подключен к нашему пограничному роутеру “NAT”. В нашем примере узел “OUTSIDE_HOST” интерфейсом FastEthernet0/0 подключен к интерфейсу FastEthernet0/0 роутера “NAT”.

Таким образом, роутер “NAT” видит оба хоста через свои интерфейсы и маршрутов никаких не требуется.

Адресация:

  • INSIDE_HOST – 192.168.0.1/24 (FastEthernet0/0)
  • NAT – 192.168.0.2/24 (FastEthernet0/1), 195.78.68.2/24 (FastEthernet0/0)
  • OUTSIDE_HOST – 195.78.68.1/24 (FastEthernet0/0)

 

NAT

Теперь, собственно, задача. Нужно, чтобы узлы “INSIDE_HOST” и “OUTSIDE_HOST” видели друг друга. Причем, ни на одном из них нет маршрута к другому – “INSIDE_HOST” не имеет шлюза по умолчанию вообще, а “OUTSIDE_HOST” не имеет маршрута внутрь сети “INSIDE_HOST”. Добиться решения мы должны только с помощью манипуляций на роутере “NAT”.

Разберем последовательно, что нужно сделать. Во-первых, чтобы узел “INSIDE_HOST” был виден за пределами роутера “NAT”, нужно транслировать его на адрес из сети между роутером “NAT” и узлом “OUTSIDE_HOST”, то есть, на один из адресов сети 195.78.68.0/24. Пусть это будет адрес 195.78.68.10.

Отлично. Теперь узел “OUTSIDE_HOST” должен видеть узел “INSIDE_HOST” как 195.78.68.10, а не 192.168.0.1. Но, что делать с ответом от узла “INSIDE_HOST”? Он отвечает пакетом с адресом назначения 195.78.68.1. Узел “INSIDE_HOST” не может отправить пакет на адрес 195.78.68.1. У него попросту нет шлюза по умолчанию. Нам нужно сделать так, чтобы узел “OUTSIDE_HOST” был виден для узла “INSIDE_HOST”. Например, транслировать его на один из адресов сети, которую узел “INSIDE_HOST” хорошо знает – ту, которой он подключен к роутеру “NAT”. Пусть это будет адрес 192.168.0.10.

С учетом того, что нам нужно промаркировать интерфейсы роутера “NAT” как inside (FastEthernet0/1) и outside (FastEthernet0/0), правила NAT-трансляции будут выглядеть соответственно ip nat inside source static… и ip nat outside source static…

Итоговая конфигурация роутера “NAT” будет выглядеть так:

  • interface FastEthernet0/0
  •  ip address 195.78.68.2 255.255.255.0
  •  ip nat outside
  •  ip virtual-reassembly
  •  duplex auto
  •  speed auto
  • !
  • interface FastEthernet0/1
  •  ip address 192.168.0.2 255.255.255.0
  •  ip nat inside
  •  ip virtual-reassembly
  •  duplex auto
  •  speed auto
  • !
  • ip nat inside source static 192.168.0.1 195.78.68.10
  • ip nat outside source static 195.78.68.1 192.168.0.10

 

Для полной картины, конфигурация узла “INSIDE_HOST”:

  • interface FastEthernet0/0
  •  ip address 192.168.0.1 255.255.255.0
  •  duplex auto
  •  speed auto

 

И конфигурация узла “OUTSIDE_HOST”:

  • interface FastEthernet0/0
  •  ip address 195.78.68.1 255.255.255.0
  •  duplex auto
  •  speed auto

 

Пробуем ping с узла “OUTSIDE_HOST” на “INSIDE_HOST”. При этом пингуем адрес 195.78.68.10. Именно под таким адресом узел “OUTSIDE_HOST” должен видеть узел “INSIDE_HOST”. Видим, что пинга нет.

  • OUTSIDE_HOST#ping 195.78.68.10
  • Type escape sequence to abort.
  • Sending 5, 100-byte ICMP Echos to 195.78.68.10, timeout is 2 seconds:
  • …..
  • Success rate is 0 percent (0/5)

 

Пробуем ping наоборот – с узла “INSIDE_HOST” узел “OUTSIDE_HOST”. При этом пингуем адрес 192.168.0.10. Именно под таким адресом узел “INSIDE_HOST” должен видеть узел “OUTSIDE_HOST”. Видим, что пинг, как ни странно, есть!

  • INSIDE_HOST#ping 192.168.0.10
  • Type escape sequence to abort.
  • Sending 5, 100-byte ICMP Echos to 192.168.0.10, timeout is 2 seconds:
  • !!!!!
  • Success rate is 100 percent (5/5), round-trip min/avg/max = 12/24/40 ms

 

Но как? Нет ни stateful filtering, ни других настроек роутеров. Для того, чтобы разобраться, нужно глубоко понимать особенности работы NAT-трансляций. Сейчас мы сделаем debug ip nat и посмотрим как, куда и откуда идут пакеты через наш роутер “NAT”.

  • NAT#debug ip nat detailed
  • IP NAT detailed debugging is on
  • NAT#debug ip packet detail
  • IP packet debugging is on (detailed)

 

Теперь сделаем ping 195.78.68.10 с узла “OUTSIDE_HOST”. Смотрим (на примере одного пакета):

  • *Mar  1 00:05:13.079: NAT*: o: icmp (195.78.68.1, 1) -> (195.78.68.10, 1) [5]
  • *Mar  1 00:05:13.079: NAT*: s=195.78.68.1->192.168.0.10, d=195.78.68.10 [5]
  • *Mar  1 00:05:13.083: NAT*: s=192.168.0.10, d=195.78.68.10->192.168.0.1 [5]
  • *Mar  1 00:05:13.135: IP: tableid=0, s=192.168.0.1 (FastEthernet0/1), d=192.168.0.10 (FastEthernet0/1), routed via RIB
  • *Mar  1 00:05:13.139: IP: s=192.168.0.1 (FastEthernet0/1), d=192.168.0.10 (FastEthernet0/1), len 100, rcvd 3
  • *Mar  1 00:05:13.143:     ICMP type=0, code=0

 

Здесь ‘o’ — пакет, который пришел на outside.

Теперь по порядку. При попадании пакета на outside интерфейс роутера “NAT” от узла “OUTSIDE_HOST” сначала происходит прямая трансляция источника по правилу ip nat outside source static 195.78.68.1 192.168.0.10. Почти так же, как и уже привычная трансляция ip nat inside…, но в другую сторону – от интерфейса outside к интерфейсу inside. Адрес назначения при этом остается неизменным — 195.78.68.10. Далее идет обратная трансляция адреса назначения (который раньше был адресом источника) по правилу ip nat inside source static 192.168.0.1 195.78.68.10. Тут адрес 195.78.68.10 стает адресом 192.168.0.1. Почему срабатывает обратная трансляция? Поскольку у нас есть прямая трансляция и параметры правила совпадают с данными пакета (ip адреса), то обязательно будет и обратная трансляция. При этом адрес источника, который уже подвергся трансляции, остается прежним — 192.168.0.10.

Далее пакет отправляется с интерфейса inside на узел “INSIDE_HOST”. ВНИМАНИЕ! Мы не видим до этого момента маршрутизации пакета. И только с 4-ой строчки видно, когда узел “INSIDE_HOST” пытается ответить на запрос, на роутере “NAT” сначала осуществляется маршрутизация пакета! Пакет получил адрес источника 192.168.0.1 и адрес назначения 192.168.0.10.

Но, что же происходит в данный момент? На маршрутизации с интерфейса FastEthernet0/1 на самого себя же дело и заканчивается. Почему так? Дело в том, что для того, чтобы сработала трансляция адресов, пакет сначала должен попасть на outside интерфейс. И когда параметры правила трансляции совпадают с данными пакета, он транслируется. Если параметры не совпадают, то не транслируется. Но, как наш пакет попадет на outside интерфейс, если он туда не маршрутизируется?! А не маршрутизируется он потому, что адрес источника и адрес назначения (как было сказано выше) находятся в одной сети – в сети интерфейса inside.

Маленькое отступление. Теперь мы поняли, что если пакет попадает на inside интерфейс, он еще не транслируется, а помечается, как возможно транслируемый в будущем. И транслируется только если проходит через outside интерфейс. Чтобы попасть на этот интерфейс пакет сначала маршрутизируется на него. А если не маршрутизируется, то трансляция не происходит.

С другой стороны, если пакет попадает на outside интерфейс, он сначала подвергается трансляции. Так произошло в самом начале, когда узел “OUTSIDE_HOST” направил пакет узлу “INSIDE_HOST” и тот первым делом попал на интерфейс outside роутера “NAT”.

Продолжим разбор нашей задачи. И что же делать? Очень просто. Нужно маршрутизировать пакет на интерфейс outside. Для этого нужно прописать статический маршрут на роутере “NAT”. Но, перед этим посмотрим, почему же идет ping с INSIDE_HOST (один пакет).

  • *Mar  1 01:56:03.571: IP: tableid=0, s=192.168.0.1 (FastEthernet0/1), d=192.168.0.10 (FastEthernet0/1), routed via RIB
  • *Mar  1 01:56:03.575: IP: s=192.168.0.1 (FastEthernet0/1), d=192.168.0.10 (FastEthernet0/1), len 100, rcvd 3
  • *Mar  1 01:56:03.579:     ICMP type=8, code=0
  • *Mar  1 01:56:03.583: IP: tableid=0, s=192.168.0.10 (local), d=192.168.0.1 (FastEthernet0/1), routed via FIB
  • *Mar  1 01:56:03.583: IP: s=192.168.0.10 (local), d=192.168.0.1 (FastEthernet0/1), len 100, sending
  • *Mar  1 01:56:03.587:     ICMP type=0, code=0

 

Как видим, сначала, пришедший на inside интерфейс пакет, подвергается маршрутизации. Причем, как и в первом примере – безрезультатно. Адрес источника и адрес назначения находятся в одной подсети. Пакет не попадает на outside интерфейс и трансляции по правилу ip nat inside source static 192.168.0.1 195.78.68.10 не происходит. С 4-ой строчки видно, что ответ идет от адреса 192.168.0.10 (local), который создался на роутере “NAT” при трансляции по второму правилу.

То есть, это локальный интерфейс роутера, созданный на время трансляции, и это он отвечает нам на запросы от узла “INSIDE_HOST”. Пакет даже не доходит до outside интерфейса роутера “NAT”. В этом можно убедиться, если потушить интерфейс FastEthernet0/0 узла “OUTSIDE_HOST”. Ping все равно проходит, потому что не узел “OUTSIDE_HOST” нам отвечает а локальный интерфейс роутера “NAT”.

Как и в случае с узлом “OUTSIDE_HOST”, ping с узла “INSIDE_HOST” не работает (вернее, не корректный) по той же причине – нет маршрутизации на outside интерфейс роутера “NAT”. Пропишем статическую маршрутизацию:

  • NAT(config)#ip route 192.168.0.10 255.255.255.255 FastEthernet0/0

 

Мы показываем, что адрес 192.168.0.10 находится за интерфейсом outside. Пробуем еще раз ping 195.78.68.10 с узла “OUTSIDE_HOST”. Видим:

  • OUTSIDE_HOST#ping 195.78.68.10
  • Type escape sequence to abort.
  • Sending 5, 100-byte ICMP Echos to 195.78.68.10, timeout is 2 seconds:
  • !!!!!
  • Success rate is 100 percent (5/5), round-trip min/avg/max = 52/80/120 ms

 

Ping проходит нормально. На роутере “NAT”:

  • *Mar  1 02:33:42.871: NAT*: o: icmp (195.78.68.1, 4) -> (195.78.68.10, 4) [24]
  • *Mar  1 02:33:42.875: NAT*: s=195.78.68.1->192.168.0.10, d=195.78.68.10 [24]
  • *Mar  1 02:33:42.879: NAT*: s=192.168.0.10, d=195.78.68.10->192.168.0.1 [24]
  • *Mar  1 02:33:42.903: IP: tableid=0, s=192.168.0.1 (FastEthernet0/1), d=192.168.0.10 (FastEthernet0/0), routed via RIB
  • *Mar  1 02:33:42.907: NAT: i: icmp (192.168.0.1, 4) -> (192.168.0.10, 4) [24]
  • *Mar  1 02:33:42.907: NAT: s=192.168.0.1->195.78.68.10, d=192.168.0.10 [24]
  • *Mar  1 02:33:42.911: NAT: s=195.78.68.10, d=192.168.0.10->195.78.68.1 [24]
  • *Mar  1 02:33:42.915: IP: s=195.78.68.10 (FastEthernet0/1), d=195.78.68.1 (FastEthernet0/0), g=195.78.68.1, len 100, forward
  • *Mar  1 02:33:42.919:     ICMP type=0, code=0

 

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

Аналогичная ситуация складывается и при ping с узла “INSIDE_HOST”.

  • *Mar  1 02:42:18.567: IP: tableid=0, s=192.168.0.1 (FastEthernet0/1), d=192.168.0.10 (FastEthernet0/0), routed via RIB
  • *Mar  1 02:42:18.571: NAT: i: icmp (192.168.0.1, 1) -> (192.168.0.10, 1) [5]
  • *Mar  1 02:42:18.575: NAT: s=192.168.0.1->195.78.68.10, d=192.168.0.10 [5]
  • *Mar  1 02:42:18.575: NAT: s=195.78.68.10, d=192.168.0.10->195.78.68.1 [5]
  • *Mar  1 02:42:18.579: IP: s=195.78.68.10 (FastEthernet0/1), d=195.78.68.1 (FastEthernet0/0), g=195.78.68.1, len 100, forward
  • *Mar  1 02:42:18.583:     ICMP type=8, code=0
  • *Mar  1 02:42:18.631: NAT*: o: icmp (195.78.68.1, 1) -> (195.78.68.10, 1) [5]
  • *Mar  1 02:42:18.631: NAT*: s=195.78.68.1->192.168.0.10, d=195.78.68.10 [5]
  • *Mar  1 02:42:18.635: NAT*: s=192.168.0.10, d=195.78.68.10->192.168.0.1 [5]

 

Видим сначала маршрутизацию (по статическому маршруту, который мы прописали) пакета с одного интерфейса на другой, потом трансляцию в соответствии с обеими правилами. Обратный ход пакета проходит уже наоборот – сначала трансляция на outside интерфейсе. В данном случае ответ идет уже от узла “OUTSIDE_HOST”, а не от локального интерфейса роутера “NAT” (как это было до конфигурации статического маршрута).

Все как-то сложно, скажете вы. Действительно, довольно сложно, если учесть, что nat outside используется редко. Поэтому, компания Cisco предусмотрела у версиях IOS 12.3Т и выше интересную технологию — NAT Virtual Interface, кототко — NVI. Конфигурируется она на интерфейсах как ip nat enable. Причем, уже не нужно указывать где inside, а где outside как на самих интерфейсах, так и в правилах трансляции. Эта технология создает виртуальный интерфейс, через который пропускается и симетрично транслируется трафик. Кроме того, уже не нужен статический маршрут, который перенапрявлял трафик для трансляции. IOS автоматически маршрутизирует трафик на NVI, на котором осуществляется симетричная трансляция трафика. Таким образом, нам не нужно думать, какой у нас входной, а какой выходной интерфейс, не нужно беспокоится попал ли трафик на нужный интерфейс или нет. Технология NVI решает это сама.

Теперь сделаем изменения в конфигурации роутера «NAT».

  • NAT(config)#no ip route 192.168.0.10 255.255.255.255 FastEthernet0/0
  • NAT(config)#no ip nat inside source static 192.168.0.1 195.78.68.10
  • NAT(config)#no ip nat outside source static 195.78.68.1 192.168.0.10
  • NAT(config)#ip nat source static 195.78.68.1 192.168.0.10
  • NAT(config)#ip nat source static 192.168.0.1 195.78.68.10
  • NAT(config)#interface FastEthernet0/0
  • NAT(config-if)#no ip nat outside
  • NAT(config-if)#ip nat enable
  • NAT(config-if)#interface FastEthernet0/1
  • NAT(config-if)#no ip nat inside
  • NAT(config-if)#ip nat enable

 

Делаем ping 195.78.68.10 с узла “OUTSIDE_HOST”:

  • OUTSIDE_HOST#ping 195.78.68.10
  • Type escape sequence to abort.
  • Sending 5, 100-byte ICMP Echos to 195.78.68.10, timeout is 2 seconds:
  • !!!!!
  • Success rate is 100 percent (5/5), round-trip min/avg/max = 20/33/68 ms

 

Ping проходит без проблем. Теперь глянем на логи роутера «NAT»:

  • *Mar 1 00:16:00.419: IP: tableid=0, s=195.78.68.1 (FastEthernet0/0), d=195.78.68.10 (FastEthernet0/0), routed via RIB
  • *Mar 1 00:16:00.423: NAT: i: icmp (195.78.68.1, 4) -> (195.78.68.10, 4) [21]
  • *Mar 1 00:16:00.423: NAT: s=195.78.68.1->192.168.0.10, d=195.78.68.10 [21]
  • *Mar 1 00:16:00.427: NAT: s=192.168.0.10, d=195.78.68.10->192.168.0.1 [21]
  • *Mar 1 00:16:00.431: IP: tableid=0, s=192.168.0.10 (FastEthernet0/0), d=192.168.0.1 (FastEthernet0/1), routed via RIB
  • *Mar 1 00:16:00.431: IP: s=192.168.0.10 (FastEthernet0/0), d=192.168.0.1 (FastEthernet0/1), g=192.168.0.1, len 100, forward
  • *Mar 1 00:16:00.431: ICMP type=8, code=0
  • *Mar 1 00:16:00.443: IP: tableid=0, s=192.168.0.1 (FastEthernet0/1), d=192.168.0.10 (FastEthernet0/1), routed via RIB
  • *Mar 1 00:16:00.447: NAT: i: icmp (192.168.0.1, 4) -> (192.168.0.10, 4) [21]
  • *Mar 1 00:16:00.447: NAT: s=192.168.0.1->195.78.68.10, d=192.168.0.10 [21]
  • *Mar 1 00:16:00.447: NAT: s=195.78.68.10, d=192.168.0.10->195.78.68.1 [21]
  • *Mar 1 00:16:00.447: IP: tableid=0, s=195.78.68.10 (FastEthernet0/1), d=195.78.68.1 (FastEthernet0/0), routed via RIB
  • *Mar 1 00:16:00.447: IP: s=195.78.68.10 (FastEthernet0/1), d=195.78.68.1 (FastEthernet0/0), g=195.78.68.1, len 100, forward
  • *Mar 1 00:16:00.447: ICMP type=0, code=0

 

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

Согласитесь, технология NVI здорово упрощает работу с трансляцией адресов. Ну, а наша задача решена. И, хотя, такие задачи вряд ли практичны, они позволяют хорошо разобраться в тонкостях работы технологий, которые здесь задействованы.

На этом пока все.

 

Комментарии facebook

Комментарии vkontakte

Нет комментариев

Опубликовано в Сети

 

Теги: ,

Оставить комментарий