Cisco ASA - NAT Hairpin или Loopback NAT - как настроить и зачем это может понадобиться

   Решаем задачу, связанную с маршрутизацией трафика через ASA из внутренней сети на внешний интерфейс ASA. В чем смысл? Допустим, есть некоторый сервис, который доступен снаружи посредством проброса портов или IP-to-IP маппинга.  И вот по каким-то причинам внезапно требуется сделать так, чтобы трафик из внутренней сети шел не напрямую к серверу по внутренней сети, но через внешнюю сеть. Если пограничным оборудованием является ASA, то такой трафик заблокируется по умолчанию. С очень высокой долей вероятности такой трафик заблокируется любым пограничным устройством, которое может отслеживать состояние соединения или имеет функционал uRPF.

   Начальные условия:

• Сервер SRV с адресом A.A.A.1 находится во внутренней сети А.А.А.0/24.
• Клиент CL для простоты находится в той же сети, что и сервер. 
• Шлюзом для этой сети будет наша ASA, адрес внутреннего интерфейса - А.А.А.254, адрес внешнего - публичный адрес P.P.P.90.

 Схема топологии представлена ниже:

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

   Настраиваем NAT Hairpin. Для этого мы должны подменить адрес назначения в пакете на адрес, нужный нам. Т.е. до NAT:

    Source: A.A.A.100

    Destination: P.P.P.96

    Соответственно, после NAT:

    Source: A.A.A.100

    Destination: А.А.А.1

   Приступаем к настройке. Для начала и для простоты создаем объекты:

!

object network CLIENT
 host A.A.A.100
 description CLIENT HOST
 !

 object network SRV_INSIDE
 host A.A.A.1
 description SRV Inside Address
!

object network SRV_OUTSIDE
 host P.P.P.96
 description SRV outside

!

    Пока все просто и знакомо, ничего особо нового нет. Мы создали объекты для внутреннего адреса сервера, для внешнего адреса сервера (он же OUTSIDE) и для клиентского ПК.

   Логично, что нам необходимо далее применить правило NAT. И именно ради этой одной строки все и затевалось. Правило NAT будет применено для трафика, следующего из внутреннего интерфейса в этот же самый внутренний интерфейс:

!

nat (INSIDE,INSIDE) source static CLIENT CLIENT destination static SRV_OUTSIDE SRV_INSIDE

!

   Почему применяем таким образом? Разбор правила показывает, что изменения произойдут с трафиком, поступающим на интерфейс INSIDE. Как только пакет пройдет через интерфейс, сначала сработает правило NAT. После изменений пакет будет смаршрутизирован обратно в интерфейс INSIDE без прохождения внешнего интерфеса. Поэтому правило применяется для трафика INSIDE-TO-INSIDE и позволяет не дропать этот трафик. Таким образом в заголовке пакета происходят изменения адреса отправителя до того, как этот трафик попадет в процесс маршрутизации.

    Если нам нужно сделать доступ с большего количества клиентов, чем один, то конфигурация изменится следующим образом. Во-первых, стоит создать объект со всей сетью:

!

object network CLIENT_NET
 subnet A.A.A.0 255.255.255.0
 description CLIENT NET
!

    Во-вторых, меняем NAT на отправителя тоже.

!

nat (INSIDE,INSIDE) source dynamic CLIENT_NET interface destination static SRV_OUTSIDE SRV_INSIDE

!

     В этом случае часть с заменой адреса получателя происходит так же, как и в предыдущем случае, а адрес отправителя динамически NAT'ится в интерфейс INSIDE в соответствии с порядком обработки пакетов ASA. Наглядно этот процесс можно увидеть с помощью команды packet-tracer.

    

   Теперь самый главный вопрос. Зачем все это нужно? В каких случаях мы можем использовать эту конструкцию?

    По опыту могу сказать о двух случаях использования данной настройки. 

1) Настройка Cisco Meeting Server с использованием XMPP через Cisco ExpressWay. Сервер Expressway-E должен быть выпущен в интернет через loopback NAT.

2) Представим некую систему, развернутую внутри организации. К этой системе мобильный пользователь имеет доступ извне. Но приложение на смартфоне таково, что позволяет забить в настройки только один адрес. Естественно, адрес забивается внешний. Но этот пользователь может приходить в офис и подключаться к внутренней сети. Чтобы не заниматься перенастройкой приложения в зависимости от того, внутри сети или за её пределами находится пользователь системы, можно воспользоваться hairpin NAT.