Не так давно мы пощупали немножко Juniper SRX, настроили его , и собрали отказоустойчивый кластер. Теперь начнем поднимать на нем «боевые» схемы, ради которых все и затевалось.
Например, соберем мысленно вот такую схему:
На схеме видим центральный офис и подключенную к нему ноду — это может быть как филиал, так и какой-то удаленный заказчик/клиент, для связи с которыми требуется защищенное соединение. Разумеется, их может быть несколько (об этом ниже). Способ связи при этом нам абсолютно не важен: хоть Интернет, хоть «темное волокно» — данные все равно нужно шифровать, чтобы свести к нулюминимуму риск их утечки. И чем выше стойкость шифра и совершенней способ фильтрации, тем целее будут нервы администратора (как вы, наверное, знаете, сисадмин, как и любая замкнутая система, всегда стремится к состоянию покоя).
Главным отличием 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 устанавливаются, пакетики бегают, канал работает.
На этом все. Удачи в настройке!
Автор: Night_Snake
