Настойка можжевельника: готовим Juniper SRX. Часть 2: IPSec

July 18, 2014 by snakeslair

Не так давно мы пощупали немножко Juniper SRX, настроили его , и собрали отказоустойчивый кластер. Теперь начнем поднимать на нем “боевые” схемы, ради которых все и затевалось.
Например, соберем мысленно вот такую схему:

На схеме видим центральный офис и подключенную к нему ноду – это может быть как филиал, так и какой-то удаленный заказчик/клиент, для связи с которыми требуется защищенное соединение. Разумеется, их может быть несколько (об этом ниже). Способ связи при этом нам абсолютно не важен: хоть Интернет, хоть “темное волокно” – данные все равно нужно шифровать, чтобы свести к нулюминимуму риск их утечки. И чем выше стойкость шифра и совершенней способ фильтрации, тем целее будут нервы администратора (как вы, наверное, знаете, сисадмин, как и любая замкнутая система, всегда стремится к состоянию покоя).

Сегодня мы будем поднимать IPSec-туннели.

Главным отличием ipsec от того же шифрованного ovpn или pptp является гораздо более высокая степень устойчивости ко взлому, а также гораздо более широкая степень унификации и распространенности. Связать две железки site-to-site, если нужен канал с шифрованием, через ipsec гораздо проще, нежели поднимать между ними ppp-соединение. Потому что ipsec умеют почти все роутеры умнее домашней мыльницы (есть и специальные VPN-шлюзы), а вот с ppp-соединениями всегда возможны нюансы. А для подключения удаленных сотрудников можно применить комбинацию этих решений, типа Cisco Anyconnect или L2tp/ipsec – с их помощью можно создать защищенное соединение непосредственно с клиентского устройства, а не с роутера.

Процесс установления защищенного туннеля состоит из двух фаз: сначала устройства “узнают” друг друга с помощью IKE и договариваются об используемом типе шифрования, контроле целостности и аутентификации, после чего переходят ко второй фазе.
На втором этапе строится основной туннель для данных (при этом соединение, поднятое в первой фазе, используется для обновления SA).
Подробнее про IPSec можно прочитать, например в седьмом выпуске СДСМ, мы же займемся практикой.

IPSec VPN (в нашем случае мы рассматриваем только туннельный режим site-to-site) в Juniper SRX бывает двух видов: Policy based и Routed based. Отличия между ними можно почитать в официальной Juniper KB на английском.

Я буду использовать в своем примере свою HA-пару Juniper SRX, про которую можно почитать вот тут. Там же есть конфигурация интерфейсов (на схеме интерфейсы тоже подписаны).

1. Policy based VPN
Проще всего в конфигурации, и нужен, когда, например, требуется связать две сети друг с другом. При этом нет перекрытия сетей друг с другом и не используется NAT.
Настраивается, в общем-то, элементарно (комментарии в самом конфиге). Я подразумеваю, что читатель представляет, что такое IPSec, и хотя бы раз его настраивал.

edit security address-book
set global address 192.168.100.0/24 192.168.100.0/24
set global address 10.0.0.10/32 10.0.0.10/32
       #Сначала прописываем phase1-proposal.        
       #В цисках можно просто сделать десяток политик с самыми 
       #распространенными настройками, и при подключении применится первая подходящая 
       #В отличие от Cisco, здесь isakmp policy, для каждого пира нужно явное указание proposals.
       #При этом несколько пиров вполне могут использовать один и тот же proposal
top
edit security ike
set proposal ike_prop_1 description "ike proposal"
set proposal ike_prop_1 authentication-method pre-shared-keys
set proposal ike_prop_1 dh-group group5
set proposal ike_prop_1 authentication-algorithm sha1
set proposal ike_prop_1 encryption-algorithm 3des-cbc
set proposal ike_prop_1 lifetime-seconds 86400
        #Штука уже "индивидуальная". Здесь мы прописываем пиру подходящий proposal, 
        #режим работы туннеля и psk.
        #Оговорюсь сразу, что режим во всех примерах выбран туннельный
set policy ike_policy_1 mode main
set policy ike_policy_1 description "ike policy"
set policy ike_policy_1 proposals ike_prop_1
        #Если в ключе есть спецсимволы, лучше взять его в двойные кавычки. 
        #Соответственно, использовать двойные кавычки в самом psk нельзя
set policy ike_policy_1 ike pre-shared-key ascii-text XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
        #IKE gw это тоже отдельная сущность. 
        #У пира, например, может быть несколько gw (основной и резервный). 
        #При этом они могут пользовать одну ike policy
set gateway ike_gateway_1 ike-policy ike_policy_1
            #Это адрес криптошлюза, с которым мы будем дружить
set gateway ike_gateway_1 address 2.2.2.2
            #Тут можно задать параметры проверки работы туннеля и доступности пира
set gateway ike_gateway_1 dead-peer-detection interval 10
set gateway ike_gateway_1 dead-peer-detection threshold 5
            #А это "выходящий" интерфейс, через который мы общаемся с пиром.
set gateway ike_gateway_1 external-interface reth2.10;
        #А это уже вторая фаза
        #Тут все тоже довольно стандартно, и набор proposal-policy 
        #может использоваться для нескольких пиров
top
edit security ipsec 
set proposal ipsec_prop_1 description "ipsec proposal"
set proposal ipsec_prop_1 protocol esp
set proposal ipsec_prop_1 authentication-algorithm hmac-sha1-96
set proposal ipsec_prop_1 encryption-algorithm 3des-cbc
set proposal ipsec_prop_1 lifetime-seconds 3600

set policy ipsec_policy_1 description "ipsec policy"
set policy ipsec_policy_1 perfect-forward-secrecy keys group5
set policy ipsec_policy_1 proposals ipsec_prop_1;
        #Сам vpn instance. Соответственно, для одного пира их может быть больше одного
set vpn vpn_1 df-bit clear
set vpn vpn_1 ike gateway ike_gateway_1
set vpn vpn_1 ike ipsec-policy ipsec_policy_1
            #Очень полезная опция - устанавливать туннель сразу, 
            #или только при появлении трафика
set vpn_1 establish-tunnels on-traffic

top
edit security 
set policies from-zone trust to-zone untrust policy vpn-to-untrust match source-address 192.168.100.0/24
                #Это не адреса, а элементы addressbook! 
set policies from-zone trust to-zone untrust policy vpn-to-untrust match destination-address 10.0.0.10/32
set policies from-zone trust to-zone untrust policy vpn-to-untrust match application any
set policies from-zone trust to-zone untrust policy vpn-to-untrust then permit tunnel ipsec-vpn vpn_1
                            #Здесь мы указываем "зеркальную" политику. 
                            #без нее работать не будет
set policies from-zone trust to-zone untrust then permit tunnel pair-policy vpn-from-untrust
set policies from-zone untrust to-zone trust policy vpn-from-untrust match source-address 10.0.0.10/32
set policies from-zone untrust to-zone trust policy vpn-from-untrust match destination-address 192.168.100.0/24
set policies from-zone untrust to-zone trust policy vpn-from-untrust match application any
set policies from-zone untrust to-zone trust policy vpn-from-untrust then permit tunnel ipsec-vpn vpn_1
set policies from-zone untrust to-zone trust policy vpn-from-untrust then permit tunnel pair-policy vpn-to-untrust

Такая схема эффективна, например, для связи с одним мелким филиалом через Интернет. При этом обе сети видят друг друга абсолютно прозрачно. В общем-то, это аналог обычного cisco-like ipsec без лишних приукрашиваний или усложнений. Заметное отличие – разрешающих политик нужно две, а не одна, иначе не заработает.

2. Route-based
Гораздо интересней с Route-based. При этом используется специальный туннельный интерфейс, соответственно, получаем возможность делать NAT (dst, src, static), организовывать схемы hub-and-spoke и т.д. Аналогом будет IPSec VTI и, отчасти, DMVPN (заявлена реализация hub-and-spoke, но сравнить с DMVPN не представляется возможным, потому что SRX всего один стоит только в HQ).

В схему выше добавим одно условие: все адреса нашей локалки будут транслироваться в один. Допустим, 192.168.100.100. Делается это обычно затем, чтобы не превращать acl на стороне заказчика в лютую портянку.
Будем считать, что на удаленную сторону влиять мы можем крайне ограниченно (сменить PSK или уточнить параметры криптотуннеля, но не более того).

edit security ike
#Здесь, в общем-то, ничего не меняется
set policy ike_policy_1 mode main
set policy ike_policy_1 proposals ike_prop_1
set policy ike_policy_1 pre-shared-key ascii-text "XXXXXXXXXXXX"
set gateway ike_gateway_1 ike-policy ike_policy_1
set gateway ike_gateway_1 address 2.2.2.2
set gateway ike_gateway_1 dead-peer-detection always-send
set gateway ike_gateway_1 external-interface reth2.10

top
edit security ipsec
#Здесь добавляется новый параметр: bind-interface
#Биндить будем на специальный туннельный интерфейс st0
set vpn vpn_1 bind-interface st0.1
set vpn vpn_1 df-bit clear
set vpn vpn_1 ike gateway ike_gateway_1
#А теперь следите за руками
#proxy-identity, это, фактически, ipsec acl
#Который на роутера Cisco, например, 
#Прописывается в настройках crypto map
set vpn vpn_1 ike proxy-identity local 192.168.100.100/32
set vpn vpn_1 ike proxy-identity remote 10.0.0.10/32
set vpn vpn_1 ike proxy-identity service any
#proxy-identity должен зеркально совпадать с acl на удаленном криптошлюзе,
#иначе туннель не поднимется. или поднимется, но только при инициации
#с удаленной стороны
set vpn vpn_1 ike ipsec-policy ipsec_policy_1
#Поднимает туннель сразу, не дожидаясь трафика
set vpn supervpn establish-tunnels immediately

#Специальный туннельный интерфейс, он служит только для заворота трафика в туннель
#Соответственно, адреса на нем могут быть любыми, и никак не связаны с адресами в vpn
top
set interfaces st0 unit 1 description vpn_1
#Здесь начинается "магия":
set interfaces st0 unit 1 family inet next-hop-tunnel 172.27.1.1 ipsec-vpn vpn_1
set interfaces st0 unit 1 family inet address 172.27.1.254/24
#Т.к. никакого трафика, идущего к маршрутизатору, быть не должно
#То host-inbound не прописываем.
#Но можно оставить, например, ping для отладки
set security zones security-zone VPN interfaces st0.1
#А вот на "внешнем" интерфейсе нужно открыть ike
set security zones security-zone INTERNET host-inbound-traffic system-services ping
set security zones security-zone INTERNET host-inbound-traffic system-services traceroute
set security zones security-zone INTERNET host-inbound-traffic system-services ike
set security zones security-zone INTERNET interfaces reth2.10

#Вот так незамысловато мы отправляем трафик в туннель
set routing-options static route 10.0.0.10/32 next-hop 172.27.1.1

Но что делать, если доступ нужно получить больше чем к одному серверу на удаленной стороне? На каждую пару source/destination необходим отдельный vpn-инстанс. К счастью, только он. Все остальные параметры (policy/proposal/gateway) можно оставить прежними.

Добавляем:

#Указываем, что туннельный интерфейс у нас будет P2MP
set interfaces st0 unit 1 multipoint
#Создаем еще одну точку туннеля
set interfaces st0 unit 1 family inet next-hop-tunnel 172.27.1.2 ipsec-vpn vpn_2
set routing-options static route 10.0.0.3/32 next-hop 172.27.1.2

edit security ipsec
set vpn vpn_2 bind-interface st0.1
set vpn vpn_2 df-bit clear
#IKE GW можно использовать старый
set vpn vpn_2 ike gateway ike_gateway_1
set vpn vpn_2 ike proxy-identity local 192.168.100.100/32
set vpn vpn_2 ike proxy-identity remote 10.0.0.3/32
set vpn vpn_2 ike proxy-identity service any

Обратите внимание: unit остается тот же, мы просто добавляем к нему еще один vpn-туннель. А вот если понадобится построить ipsec-туннель с другим клиентом, то логичней будет выделить его в отдельный unit.

Ну а теперь добавляем policy и NAT. Т.к. st0.1 у нас в отдельной зоне, то policy мы строим не в untrust, а в VPN.

edit security nat
set source pool pool1 address 192.168.100.100/32 to 192.168.100.100/32
set source rule-set SNAT-TO-VPN from zone trust
set source rule-set SNAT-TO-VPN to zone VPN
set source rule-set SNAT-TO-VPN rule snat match source-address-name 192.168.100.0/24
set source rule-set SNAT-TO-VPN rule snat match destination-address-name 10.0.0.3/32
set source rule-set SNAT-TO-VPN rule snat match destination-address-name 10.0.0.10/32
set source rule-set SNAT-TO-VPN rule snat then source-nat pool pool1

Security-policy в таком виде создается исключительно для тестов! В дальнейшем доступ должен быть ограничен в соответствии с требованиями безопастности.

edit security 
set policies from-zone VPN to-zone trust policy permit-all match source-address any
set policies from-zone VPN to-zone trust policy permit-all match destination-address any
set policies from-zone VPN to-zone trust policy permit-all match application any
set policies from-zone VPN to-zone trust policy permit-all then permit

Если нужен доступ только “в одну сторону”, то “обратную” policy создавать необязательно.

Применяем изменения:

commit

Проверяем:

show security ipsec statistics 
show security ike security-associations detail 

SA устанавливаются, пакетики бегают, канал работает.
На этом все. Удачи в настройке!

P.S. Обсудить материал можно также на нашем форуме