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