Не так давно мы пощупали немножко 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, и хотя бы раз его настраивал.
Такая схема эффективна, например, для связи с одним мелким филиалом через Интернет. При этом обе сети видят друг друга абсолютно прозрачно. В общем-то, это аналог обычного 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 или уточнить параметры криптотуннеля, но не более того).
Но что делать, если доступ нужно получить больше чем к одному серверу на удаленной стороне? На каждую пару source/destination необходим отдельный vpn-инстанс. К счастью, только он. Все остальные параметры (policy/proposal/gateway) можно оставить прежними.
Добавляем:
Обратите внимание: unit остается тот же, мы просто добавляем к нему еще один vpn-туннель. А вот если понадобится построить ipsec-туннель с другим клиентом, то логичней будет выделить его в отдельный unit.
Ну а теперь добавляем policy и NAT. Т.к. st0.1 у нас в отдельной зоне, то policy мы строим не в untrust, а в VPN.
Security-policy в таком виде создается исключительно для тестов! В дальнейшем доступ должен быть ограничен в соответствии с требованиями безопастности.
Если нужен доступ только «в одну сторону», то «обратную» policy создавать необязательно.
Применяем изменения:
Проверяем:
SA устанавливаются, пакетики бегают, канал работает.
На этом все. Удачи в настройке!
Например, соберем мысленно вот такую схему:
На схеме видим центральный офис и подключенную к нему ноду — это может быть как филиал, так и какой-то удаленный заказчик/клиент, для связи с которыми требуется защищенное соединение. Разумеется, их может быть несколько (об этом ниже). Способ связи при этом нам абсолютно не важен: хоть Интернет, хоть «темное волокно» — данные все равно нужно шифровать, чтобы свести к
Главным отличием 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
В схему выше добавим одно условие: все адреса нашей локалки будут транслироваться в один. Допустим, 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 устанавливаются, пакетики бегают, канал работает.
На этом все. Удачи в настройке!