Недавно была поставлена задача: организовать L2L VPN между двумя Cisco PIX 8.0(3). Далее, к этой задаче «приросла» необходимость в поднятии DMZ и Remote access VPN (для удаленного доступа администратора) на одном из Cisco PIX. С одной стороны, задача типична и достаточно документации с сайта cisco.com. Но, начав настройку МСЭ, начали всплывать подводные камни, обойти которые удалось не так просто, по причине того, что описание появившихся проблем находились в неожиданных для меня местах. Собственно, хотелось бы поделиться с проблемами и их решениями, ну и помочь людям обойти грабли, на которые я наступил по глупости. Само собой, опытные специалисты по МСЭ Cisco могут закончить на этом абзаце…
PS: в написании статей я новичок, так что надеюсь на объективную критику.
PSS: статья написана немного академическим языком, если сравнивать с уже существующими статьями на этом сайте, но увы, иначе не получается. А также, здесь нету руководства к действию, а скорее раскрывается один частный случай, который, на мой взгляд, является не совсем тривиальным, и может помочь новичкам расширить свою видимость.
ЗАДАЧА:
Как уже говорилось выше, задача в организации VPN между двумя сетями, VPN удаленного доступа и демилитаризованной зоны.
Принципиальная схема сети выглядит следующим образом:
Адресация выглядит следующим образом:
Для внутренней сети всей организации выделены адреса 172.16.0.0/12. Наше структурное подразделение имеет сеть (если это так можно назвать) 172.16.9.0/0.15.0.255, которую мы и будем использовать как для внутренней сети, так и для удаленных пользователей и офисов. Из этой «сети» мы выделим 172.20.9.0/24 под демилитаризованную зону, и 172.25-26.9.0/24 под удаленные пользователи и офисы, причем, под офис выделим сети 172.25-26.9.0/26. У нас остается 3 подсети размером /26, одну из которых мы выделим под удаленный доступ, а оставшиеся 2 – под перспективу новых офисов.
Цель: организовать доступ из удаленного офиса (172.25.9.0/26 и 172.26.9.0/26) во внутреннюю сеть и в демилитаризованную зону. Также, необходимо организовать аналогичный доступ для удаленных пользователей. Доступ в демилитаризованную зону должен быть со всех внутренних адресов, но узлы демилитаризованной зоны не должны иметь доступ во внутреннюю сеть.
РЕШЕНИЕ ЗАДАЧИ:
Прежде чем пытаться конфигурировать Cisco PIX, необходимо понять, что это МСЭ, и все принципы настройки аналогичных сетей на базе маршрутизаторов не работают с данными устройствами.
Одни из первых граблей, на которые я наступил – это маршруты. Дело в том, что имея небольшой опыт конфигурирования маршрутизаторов, я рассчитывал на то, что при поднятии туннеля, в таблицу маршрутизации будет добавляться маршрут для этого туннеля. Рассчитывая на это, я, не долго думая, добавил маршрут во внутреннюю сеть в виде:
Код: Выделить всё
route inside 172.16.0.0 255.240.0.0 172.31.9.241 20Код: Выделить всё
route inside 172.16.0.0 255.255.0.0 172.31.9.241 1
route inside 172.17.0.0 255.255.0.0 172.31.9.241 1
route inside 172.18.0.0 255.255.0.0 172.31.9.241 1
route inside 172.19.0.0 255.255.0.0 172.31.9.241 1
route inside 172.21.0.0 255.255.0.0 172.31.9.241 1
route inside 172.22.0.0 255.255.0.0 172.31.9.241 1
route inside 172.23.0.0 255.255.0.0 172.31.9.241 1
route inside 172.24.0.0 255.255.0.0 172.31.9.241 1
route inside 172.27.0.0 255.255.0.0 172.31.9.241 1
route inside 172.28.0.0 255.255.0.0 172.31.9.241 1
route inside 172.29.0.0 255.255.0.0 172.31.9.241 1
route inside 172.30.0.0 255.255.0.0 172.31.9.241 1
route inside 172.31.0.0 255.255.0.0 172.31.9.241 1Вторые грабли, на которые наступил – это странная работа NAT на устройстве. Проблема заключалась в следующем: после настройки NAT при попытке отправки ICMP-пакета наружу, ответ не попадал вовнутрь, и это при том, что в таблицу трансляции этот пакет попадал. И самое что интересное, в документации по PIX не было упоминания этой проблемы, но оно было найдено в разделе траблшутинга, где было указано, что по умолчанию PIX отправляет наружу ICMP-пакеты, но ответы почему-то отбрасывает. Для PIX 8.0.3 эта проблема решается следующим образом:
Код: Выделить всё
policy-map global_policy
class inspection_default
…
inspect icmp
…
!Эта настройка работает с 7 версии PIX. Для более ранних версий можно повесить на внешний интерфейс следующий список доступа:
Код: Выделить всё
access-list ouside extended permit icmp any any echo-replyПервое, что необходимо сделать – определить пользователей, имеющих доступ во внешнюю сеть, и адрес, в который будут транслироваться внутренние адреса. Это делается следующим образом:
Код: Выделить всё
access-list pat-inside extended permit ip 172.16.9.0 255.255.255.128 any
global (outside) 1 1.1.1.2
nat-control
nat (inside) 1 access-list pat-insideСледущим шагом будет настройка L2L VPN на центральном Cisco PIX. Для этого необходимо:
1. Определить, какие пакеты необходимо шифровать и отправлять в туннель. Делается это с помощью ACL. В нашем случае он будет выглядеть следующим образом:
Код: Выделить всё
access-list ENC_BR1 extended permit ip 172.16.0.0 255.240.0.0 172.25.9.0 255.255.255.0
access-list ENC_BR1 extended permit ip 172.16.0.0 255.240.0.0 172.26.9.0 255.255.255.0
access-list ENC_BR1 extended permit ip 10.101.224.0 255.255.255.0 172.25.9.0 255.255.255.0
access-list ENC_BR1 extended permit ip 10.101.224.0 255.255.255.0 172.26.9.0 255.255.255.02. Для каких пакетов нужно запретить трансляцию адресов. Также, как и в предыдущем случае, нам необходимо использовать ACL для определения нужных адресов. Так как мы не должны транслировать адреса только для пакетов, направленных в удаленные офисы, то по сути данный ACL продублирует ACL ENC_BR1. Но при этом, желательно оформить это в виде отдельного списка доступа:
Код: Выделить всё
access-list nonat-inside extended permit ip 172.16.0.0 255.240.0.0 172.25.9.0 255.255.255.0
access-list nonat-inside extended permit ip 172.16.0.0 255.240.0.0 172.26.9.0 255.255.255.0
access-list nonat-inside extended permit ip 10.101.224.0 255.255.255.0 172.25.9.0 255.255.255.0
access-list nonat-inside extended permit ip 10.101.224.0 255.255.255.0 172.26.9.0 255.255.255.0
nat (inside) 0 access-list nonat-insideКод: Выделить всё
crypto ipsec transform-set TSET-VPN esp-des esp-md5-hmacКод: Выделить всё
crypto map CMAP-VPN 10 match address ENC_BR1
crypto map CMAP-VPN 10 set peer 2.2.2.2
crypto map CMAP-VPN 10 set transform-set TSET-VPNКод: Выделить всё
crypto isakmp policy 10
authentication pre-share
encryption des
hash md5
group 1
lifetime 1000
crypto isakmp identity address
crypto isakmp enable outsideКод: Выделить всё
tunnel-group 2.2.2.2 type ipsec-l2l
tunnel-group 2.2.2.2 ipsec-attributes
pre-shared-key *Код: Выделить всё
sysopt connection permit-vpnНа данном этапе мы имеем: выход пользователей во внешнюю сеть и связь между офисами.
Далее, необходимо настроить удаленный доступ с использованием Cisco VPN Client. Данная настройка несколько отличается от настройки L2L VPN. Главным отличием является поддержка динамических пиров. Порядок настройки выглядит следующим образом:
1. Настройка таблицы преобразований. В нашем случае она будет идентичная таблице преобразований для L2L VPN, но при этом, желательно сделать ее отдельно, что даст возможность в будущем менять ее лишь для этого типа VPN:
Код: Выделить всё
crypto ipsec transform-set TSET-RA esp-des esp-md5-hmacКод: Выделить всё
crypto dynamic-map DMAP-RA 1 set transform-set TSET-RA
crypto map CMAP-VPN 1 ipsec-isakmp dynamic DMAP-RAКод: Выделить всё
crypto isakmp policy 65535
authentication pre-share
encryption des
hash md5
group 2
lifetime 86400Далее, необходимо настроить аутентификацию пользователей и настройку их клиентов. Для начала определим адреса, которые будем выдавать удаленным пользователям:
Код: Выделить всё
ip local pool RAPool 172.25.9.240-172.25.9.254 mask 255.255.255.192Наиболее удобной схемой использования этих политик, с учетом масштабирования в будущем, будет следующая схема:
Создаем настройку туннеля, определяющую ключ и созданный ранее пул адресов. Далее, создаем групповую политику, в которой описываем выдаваемые клиентам DNS-сервера, определяем возможность сохранения пароля в клиенте, доступ к локальной сети удаленного пользователя и другие параметры, имеющие прямое или косвенное отношение к возможностям удаленного пользователя. Далее. Создаем пользователя и привязываем его к политике.
Пошагово это выглядит следующим образом:
1. Настраиваем туннельную группу. Указываем, что туннельная группа будет использоваться для удаленного доступа, определяем пул адресов и указываем ключ шифрования. Единственное, что нужно продумать – это на название туннельной группы, так как она будет использоваться для подключения в виде имени пользователя в паре с ключом шифрования на первой фазе установления соединения. Также, здесь можно указать групповую политику, используемую этой туннельной группой, но этого мы делать не будем, так как в нашем случае удобней привязать групповую политику непосредственно пользователю:
Код: Выделить всё
tunnel-group remote type remote-access
tunnel-group remote general-attributes
address-pool RAPool
tunnel-group remote ipsec-attributes
pre-shared-key *a. password-storage enable – разрешаем сохранение пароля в клиенте;
b. ipsec-udp enable – включаем инкапсуляцию IPSec в UDP дейтаграммы (нужно для клиентов, находящихся за NAT);
c. split-tunnel-policy tunnelspecified – определяем, каким образом будут настраиваться маршруты клиентов. В нашем случае, маршрут в сторону корпоративной сети будет включать только указанные соответствующей настройкой подсети;
d. split-tunnel-network-list value split-tunnel-ra – определяем, какие подсети будут маршрутизироваться через наш туннель. В качестве
Код: Выделить всё
split-tunnel-ra выступает Standart ACL.
access-list split-tunnel-ra standard permit 172.16.0.0 255.240.0.0
access-list split-tunnel-ra standard permit 10.101.224.0 255.255.255.0
group-policy RAdmin internal
group-policy RAdmin attributes
wins-server value 172.16.9.3
dns-server value 172.16.9.3 172.16.9.4
password-storage enable
ipsec-udp enable
split-tunnel-policy tunnelspecified
split-tunnel-network-list value split-tunnel-ra
default-domain value DOMAINКод: Выделить всё
username RAdmin password ENCRYPTED_PASSWORD encrypted
username RAdmin attributes
vpn-group-policy RAdmin
service-type remote-accessДалее, для проверки работы туннеля попробуем попинговать узлы корпоративной сети и удаленного офиса. Результат должен быть не совсем положительным. Узлы корпоративной сети, которые находятся за inside интерфейсом PIX будут пинговаться, а вот что касается узлов удаленного офиса – они пинговаться не будут. Это происходит по той причине, что удаленный пользователь находится за интерфейсом outside, также, как и удаленный офис, а стандартное поведение Cisco PIX запрещает выход сетевого пакета из интерфейса, в который этот пакет вошел. Для исправления этой ситуации необходимо разрешить прохождение таких пакетов следующей командой:
Код: Выделить всё
same-security-traffic permit intra-interfaceНастроив и проверив VPN, перейдем к настройке демилитаризованной зоны. Для этого назначим сетевому интерфейсу, подключенному к ней, адрес 172.20.9.1/24 и определим уровень безопасности между уровнями безопасности inside и outside, например, 50. Это даст нам возможность контролировать соединения из демилитаризованной зоны во внутреннюю сеть, запретив их. Для всех взаимодействий между внутренней и удаленной сетей, и DMZ будем использовать технологию NAT.
На данный момент трансляция адресов выглядит следующим образом:
Код: Выделить всё
access-list pat-inside extended permit ip 172.16.9.0 255.255.255.128 any
access-list nonat-inside extended permit ip 172.16.0.0 255.240.0.0 172.25.9.0 255.255.255.0
access-list nonat-inside extended permit ip 172.16.0.0 255.240.0.0 172.26.9.0 255.255.255.0
access-list nonat-inside extended permit ip 10.101.224.0 255.255.255.0 172.25.9.0 255.255.255.0
access-list nonat-inside extended permit ip 10.101.224.0 255.255.255.0 172.26.9.0 255.255.255.0
global (outside) 1 1.1.1.2
nat-control
nat (inside) 0 access-list nonat-inside
nat (inside) 1 access-list pat-insideДанные настройки не предполагают доступ в DMZ, так как трансляция для этой сети не настроена и включен nat-control, запрещающий форвардинг пакетов без настроенной трансляции адресов.
Казалось бы, настройка доступа в DMZ является тривиальной задачей, но и здесь есть свои подводные камни:
1. NAT Exception неприемлем, так как разрешает доступ в обе стороны;
2. Удаленные пользователи «приходят» с интерфейса outside, который имеет более низкий уровень безопасности, нежели DMZ, что позволит узлам из DMZ беспрепятственно слать пакеты в сторону удаленных офисов.
Для начала предоставим доступ внутренних узлов к DMZ. Оптимальным вариантов будет использование статической трансляции адресов внутренней сети (стоит обратить внимание на то, что используется вся подсеть 172.16.0.0/12, куда входят и удаленные пользователи). Данная настройка позволяет транслировать адреса внутренней сети в самих себя, что дает возможность производить подключения к узлам DMZ (ведь у нас включен nat-control, так что, трансляция в любом случае нужна):
Код: Выделить всё
static (inside,dmz) 172.16.0.0 172.16.0.0 netmask 255.240.0.0Далее, необходимо настроить трансляцию узлов DMZ для удаленного офиса. На первый взгляд можно использовать статическую трансляцию:
static (dmz,outside) 172.20.9.0 172.20.9.0 netmask 255.255.255.0
При использовании такой настройки доступ к DMZ из удаленного офиса появится, но доступ из внешней сети настроить не удастся, так как мы транслируем внутренние адреса в самих себя, а о них внешний мир ничего не знает. Это уже сводит смысл такого DMZ к нулю. Для решения данной проблемы необходим избирательный подход для трансляции, то есть, нам нужно транслировать локальный адрес в локальный только для узлов удаленных офисов, которые знают где искать эти адреса. Делается это с помощью static policy nat, настройка которого выглядит следующим образом:
1. Определяем ACL, в котором в виде источника указываем адрес, в который нам необходимо транслировать адреса, а в качестве получателя – удаленные сети, для взаимодействия с которыми будет работать эта трансляция:
Код: Выделить всё
access-list static-nat-dmz extended permit ip 172.20.9.0 255.255.255.0 172.25.9.0 255.255.255.0Код: Выделить всё
static (dmz,outside) 172.20.9.0 access-list static-nat-dmzДля верности проверим доступность узлов внутренней и удаленной сети со стороны узлов DMZ. Данные узлы не должны быть доступны. Ранее говорилось о проблеме уровня безопасности интерфейсов. Не смотря на теоретическое наличие этой проблемы, на практике ее не оказалось. Это связано с тем, что в трансляции адресов внутренней сети при подключении к DMZ мы указали всю сеть 172.16.0.0/12, в которые включаются также и адреса удаленных офисов. Таким образом, при попытке подключения из DMZ в подсеть удаленного офиса, PIX думает, что подключается к внутренней сети, и соответственно отбрасывает эти пакеты. Но при этом, когда пакет приходит с внешнего интерфейса (из удаленного офиса), он попадает в DMZ, так как подсеть DMZ транслируется наружу для подсети 172.25.9.0/24. В связи с этим получается, что мы добились нужного результата. Осталось раздать узлам DMZ интернет, если это необходимо и вывесить наружу необходимые службы:
1. Для раздачи интернета настроим динамический PAT, как и в случае с узлами внутренней сети, используя уже указанный ранее внешний адрес:
Код: Выделить всё
access-list pat-dmz extended permit ip 172.20.9.0 255.255.255.0 any
nat (dmz) 1 access-list pat-dmza. Настроим статическую трансляцию порта в адрес:
Код: Выделить всё
static (dmz,outside) udp 1.1.1.3 tftp 172.20.9.10 tftp netmask 255.255.255.255Код: Выделить всё
access-list outside extended permit udp any host 1.1.1.3 eq tftp
access-group outside in interface outsideКод: Выделить всё
access-list outside extended permit udp any host 1.1.1.3 eq tftp
access-list pat-dmz extended permit ip 172.20.9.0 255.255.255.0 any
access-list pat-inside extended permit ip 172.16.9.0 255.255.255.128 any
access-list nonat-inside extended permit ip 172.16.0.0 255.240.0.0 172.25.9.0 255.255.255.0
access-list nonat-inside extended permit ip 172.16.0.0 255.240.0.0 172.26.9.0 255.255.255.0
access-list nonat-inside extended permit ip 10.101.224.0 255.255.255.0 172.25.9.0 255.255.255.0
access-list nonat-inside extended permit ip 10.101.224.0 255.255.255.0 172.26.9.0 255.255.255.0
access-list pat-dmz extended permit ip 172.20.9.0 255.255.255.0 any
nat-control
global (outside) 1 1.1.1.2
nat (inside) 0 access-list nonat-inside
nat (inside) 1 access-list pat-inside
nat (dmz) 1 access-list pat-dmz
static (dmz,outside) 172.20.9.0 access-list static-nat-dmz
static (dmz,outside) udp 1.1.1.3 tftp 172.20.9.10 tftp netmask 255.255.255.255
static (inside,dmz) 172.16.0.0 172.16.0.0 netmask 255.240.0.0
access-group outside in interface outsideИспользованная литература:
Frahim J., Santos O. - Cisco ASA. All-in-One Firewall, IPS, Anti-X, and VPN Adaptive Security Appliance, 2nd Edition, 2010
http://www.cisco.com/en/US/products/hw/ ... 4e8a.shtml
http://www.cisco.com/en/US/docs/securit ... nf_gd.html
)