Компания
59,68
рейтинг
18 июля 2014 в 07:20

Разработка → Настойка можжевельника: готовим Juniper SRX. Часть 2: IPSec tutorial

Не так давно мы пощупали немножко 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

Комментарии (19)

  • 0
    Отличная статья!
    Ее бы пару годков назад...)

    Чтобы добавил:
    — обозначить объекты в address book (у вас указано, что в политиках объекты, имеет смысл сразу определять их при создании политик, т.е. добавить пример в статью)
    — в Policy Based ipsec важно следить за порядком правил в политиках между зонами. Если в политиках есть финальная, «deny all» политика с логированием, то нужно не забывать смещать ее в самый низ, после создания ipsec политик. (например insert security policy from zone UNTRUST to-zone TRUST policy DENY-ALL after policy vpn-from-untrust)
    — если у вас стоит глобальное правило «запрещать все», то нужно добавить правила для ike между пирами
    — стоит указать недостаток route-based ipsec: если вы хотите организовать доступ с нескольких подсетей к одной подсети на другой стороне — с route-based не получится, нужно использовать policy based. Но с policy based ipsec вы не сможете натить трафик, по крайней мере source (на самом деле, получалось это делать, но только если туннель инициировался с другой стороны относительно ната)
    • 0
      — обозначить объекты в address book (у вас указано, что в политиках объекты, имеет смысл сразу определять их при создании политик, т.е. добавить пример в статью)
      Я добавил их в самом начале =)

      — в Policy Based ipsec важно следить за порядком правил в политиках между зонами.
      Это общее правило безотносительно ипсека, для всех zone-based политик

      — если у вас стоит глобальное правило «запрещать все», то нужно добавить правила для ike между пирами
      ike открывается в host-inbound-traffic для соотвествующего интерфейса.

      — стоит указать недостаток route-based ipsec: если вы хотите организовать доступ с нескольких подсетей к одной подсети на другой стороне
      зато routed-based позволяет NAT, и эту проблему можно обойти =) А если nat не нужен, то можно обойтись policy-based
      • 0
        Я добавил их в самом начале =)

        оу, утро такое утро, был невнимателен)

        Это общее правило безотносительно ипсека, для всех zone-based политик

        Разумеется, но тут мы обсуждаем ipsec)

        ike открывается в host-inbound-traffic для соотвествующего интерфейса.

        Да, но помоему мы там открываем возможность этому протоколу ходить через интерфейс, в случае если нет разрешающей политики из зоны в зону — трафик даже не попадет на этот интерфейс, нет?

        зато routed-based позволяет NAT, и эту проблему можно обойти =) А если nat не нужен, то можно обойтись policy-based

        С этим я не спорю, просто лучше заранее выбирать тип ipsec, исходя из задач.
        • 0
          policy, ЕМНИП, влияют только на forwarded трафик. А входящий определяется host-inbound
          • 0
            может быть, могу напутать и ввести в заблуждение — надо проверять)
            • 0
              вот я тоже на память не вспомню, надо будет проверить при случае
  • 0
    Самого интересного-то и нету.
    SA устанавливаются, пакетики бегают, канал работает.

    Допустим, SA не согласовывается, пакетики не бегают. Как траблшутить? Сразу говорю, «сверить конфиги» — не наш метод :)
    через ipsec гораздо проще, нежели поднимать между ними ppp-соединение. Потому что ipsec умеют почти все роутеры умнее домашней мыльницы (есть и специальные VPN-шлюзы), а вот с ppp-соединениями всегда возможны нюансы.

    Теоретически, вы совершенно правы. Практически — изредка бывают очень интересные проблемы при попытках поднять IPSec туннель между двумя железками разных вендоров, следующие как из багов, так и из немного разного понимания стандарта. И вообще, IPSec — весьма навороченный и сложный фреймворк.
    Хотя PPP тоже не сахар…
    • 0
      Допустим, SA не согласовывается, пакетики не бегают.

      Я думаю, траблшутингу IPSec можно целый материал посвятить =) Хотя сколько я сталкивался с IPSec, проблема в 99% была либо в некорректных policy, либо несогласованности настроек. Были траблы с микротиком — тому помог апгрейд прошивки

      Теоретически, вы совершенно правы. Практически — изредка бывают очень интересные проблемы при попытках поднять IPSec туннель между двумя железками разных вендоров, следующие как из багов, так и из немного разного понимания стандарта.

      Ну на моей памяти проблем с IPSec не больше, чем с ppp. С тем же ovpn проблем случается больше разных)
      • 0
        Хотя сколько я сталкивался с IPSec, проблема в 99% была либо в некорректных policy, либо несогласованности настроек


        по началу примерно такая же статистика была.
        Сейчас же 80% проблем — ipsec оборвался на другой стороне и джунипер не смог корректно это обработать (сессия висит как рабочая, трафик не идет)
        и 20% какие то странные глюки- несколько раз было, что сидели несколько часов мазолили глазами логи, потом плевали, удаляли конфиг и заливали его заново — все начинало работать
        • 0
          А еще провайдеры временами творят потрясающие вещи с трафиком. Мой самый любимый косяк такого рода — через минуту после установления SA ESP трафик начинает теряться. После переинициализации SA всё восстанавливается на минуту. Возможности собрать дамп пакетов с обеих сторон не было. Однако, я сумел доказать провайдеру, что косяк именно у него, и это поправили :)
          • 0
            Ну нам вроде с операторами везло. Траблы обычно случаются после смены vpn-железки у заказчика, либо при изменениях в его сети, после чего забывают поправить policy
          • 0
            я как то с одним известным провайдером мобильной связи воевал на тему того, что они резали gre пакеты. Причем tcp1723 проходил, а 47 протокол — нет(снимал дампы с джунипера со стороны работы и со своей машины как инициатора соеденения). ПРоблема была в том, что этот провайдер предоставлял один из каналов непосредственно моему домашнему провайдеру. Как следствие — дома не работал vpn на один из рабочих vpn серверов.
            Обидно, что я не мог надавить на этого провайдера, т.к. услугу покупал я у своего домашнего провайдера. Забавно то, что на работе, у нас был один временный канал этот этого мобильного оператора, и там всплыла та же тема, хотя и город совсем другой.Результатом переписки было полное отрицание самой возможности того что они резали 47 протокол, и полная работоспособность gre через них в этот же вечер. Может конечно и совпало, но очень уж странное совпадение, до этого не работало около полугода)
            • 0
              Я в Питере встречался с тем, что GRE не проходил. Естественно, первая линия знать ничего не знала ни про какие GRE, и бодро рапортовала, что «у нас все хорошо и ничего не режется».
              Тащем-то поэтому мы в свое время стали упаковывать трафик от удаленных точек в ppp (ovpn тогда, сейчас не знаю, что у них там)
              • 0
                1-я линия техподдержки моего провайдера предложила мне два варианта
                — перезагрузить роутер
                — проверить оплачен ли у меня интернет
  • 0
    А если с каждой стороны по 2 провайдера, т.е. 4 возможные комбинации провайдеров, можете посоветовать как лучше сделать? сейчас у меня 4 отдельных туннеля и в роутинге прописано использовать st.0, st.1, st.2, st.3 по очереди, возможно, есть лучший способ?
    • 0
      Тут вариантов много. Зависит от того, какая схема включения к провайдерам (есть ли своя AS?) Хотите ли использовать динамику? Ну и т.д.
      • 0
        AS нет, динамики нет, второй провайдер используется как резервный канал.
        Ну и, кстати, еще вопрос — а умеют ли srx балансировку каналов?
        • 0
          Ну тогда думаю надо будет настроить по два gateway с каждой стороны.
          насчет балансировки — тут нужно смортеть по конечной ситуации
          • 0
            Ок, спасибо за ответ.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка