Juniper SRX: Site-to-Site IPSec VPN с использованием pre-shared-key

  • Tutorial
В продолжении темы настройки Juniper SRX предлагаю вашему вниманию step-by-step инструкцию по настройке Site-to-Site IPSec VPN с использованием pre-shared-key. Обращаю внимание на то, что оба SRX'а должны обладать статическим внешним IP адресом.

Начнем с принципиальной схемы нашей сети:


Из этой схемы видно, что оба устройства подключены к провайдеру через интерфейсы ge-0/0/0 и за каждым SRX'ом находится своя приватная сеть (подключенная в ge-0/0/1). Наша цель — построить IPSec туннель и разрешить трафик между сетями 172.16.1.0/24 и 172.16.2.0/24.

Предполагается, что внешний интерфейс получает адрес по DHCP, для упрощения конфигурации.

Всех заинтересовавшихся прошу под кат.


Предлагаю сначала взглянуть на конфигурацию одного из роутеров ДО настройки IPSec, чтобы было откуда отталкиваться:
root@gw-jvsrx-a# show
version 12.1X46-D10.2;
system {
    host-name gw-jvsrx-a;
    root-authentication {
        encrypted-password "$1$XXX"; ## SECRET-DATA
    }
    services {
        ssh {
            protocol-version v2;
            client-alive-count-max 5;
            client-alive-interval 120;
            connection-limit 5;
            rate-limit 2;
        }
        dhcp {
            default-lease-time 21600;
            pool 172.16.1.0/27 {
                address-range low 172.16.1.2 high 172.16.1.30;
                router {
                    172.16.1.1;
                }
                propagate-settings ge-0/0/1.0;
            }
        }
    }
    ntp {
        server 0.pool.ntp.org prefer;
        server 1.pool.ntp.org;
        server 2.pool.ntp.org;
        server 3.pool.ntp.org;
    }
}
interfaces {
    ge-0/0/0 {
        unit 0 {
            family inet {
                dhcp;
            }
        }
    }
    ge-0/0/1 {
        unit 0 {
            family inet {
                address 172.16.1.1/27;
            }
        }
    }
    lo0 {
        unit 0 {
            family inet {
                address 172.31.255.1/32;
            }
        }
    }
}
security {
    nat {
        source {
            rule-set trust-to-untrust {
                from zone trust;        
                to zone untrust;
                rule source-nat {
                    match {
                        source-address 0.0.0.0/0;
                    }
                    then {
                        source-nat {
                            interface;
                        }
                    }
                }
            }
        }
    }
    policies {
        from-zone trust to-zone untrust {
            policy trust-to-untrust {
                match {
                    source-address any;
                    destination-address any;
                    application any;
                }
                then {
                    permit;
                }
            }
        }
        from-zone trust to-zone trust {
            policy trust-to-trust {
                match {
                    source-address any;
                    destination-address any;
                    application any;
                }
                then {
                    permit;
                }
            }
        }
    }
    zones {
        security-zone untrust {
            tcp-rst;
            interfaces {
                ge-0/0/0.0 {
                    host-inbound-traffic {
                        system-services {
                            dhcp;
                            ping;
                            ssh;
                        }
                    }
                }
            }
        }
        security-zone trust {
            interfaces {
                ge-0/0/1.0 {            
                    host-inbound-traffic {
                        system-services {
                            all;
                        }
                        protocols {
                            all;
                        }
                    }
                }
                lo0.0 {
                    host-inbound-traffic {
                        system-services {
                            ping;
                        }
                    }
                }
            }
        }
    }
}


Конфигурация второго устройства аналогична, за исключением настроек DHCP сервера и интерфейса lo0. При таком раскладе мы имеем дело с обыкновенным роутером.

Про IPSec более подробно можно почитать (например) на Википедии.

Приступим к настройке туннеля.

Туннельный интерфейс


Для начала создадим виртуальный интерфейс, который будет использоваться для построения туннеля:
set interfaces st0 unit 0 family inet address 172.16.0.1/30

Т.к. строить туннель мы будем только для двух устройств, то нам вполне хватит сети /30.

Первая фаза


Настроим IKE на использование основного режима IKE:
set security ike proposal ike-proposal authentication-method pre-shared-keys
set security ike proposal ike-proposal dh-group group14
set security ike proposal ike-proposal authentication-algorithm sha-256
set security ike proposal ike-proposal encryption-algorithm aes-128-cbc
set security ike proposal ike-proposal lifetime-seconds 3600
set security ike policy ike-policy mode main
set security ike policy ike-policy pre-shared-key ascii-text "YOUR_PRE_SHARED_KEY"
set security ike policy ike-policy proposals ike-proposal
set security ike gateway gw-jvsrx-b ike-policy ike-policy
set security ike gateway gw-jvsrx-b address 20.20.20.20
set security ike gateway gw-jvsrx-b external-interface ge-0/0/0.0


Подробно:
authentication-method pre-shared-keys — включаем использование pre-shared keys;
dh-group group14 — нужен для генерации общего приватного ключа при обмене данными по незащищенному каналу (подробно описано тут), я использую 2048-битный модуль;
authentication-algorithm sha-256 — для аутентификации будем использовать sha-256;
encryption-algorithm aes-128-cbc — шифровать данные в первой фазе будем aes-128-cbc;
lifetime-seconds 3600 — время жизни приватного ключа (был сгенерирован автоматически при инициализации подключения) первой фазы;
mode main — основной режим
pre-shared-key ascii-text — собственно сам ключ (рекомендую генерировать его достаточно большим, например так openssl rand -base64 32)
address 20.20.20.20 — публичный адрес второго SRX'а
external-interface ge-0/0/0.0 — интерфейс, через который будет проходить IPSec трафик.

Вторая фаза


На данном этапе создается сам IPSec туннель.
set security ipsec proposal ipsec-proposal protocol esp
set security ipsec proposal ipsec-proposal authentication-algorithm hmac-sha-256-128
set security ipsec proposal ipsec-proposal encryption-algorithm aes-128-cbc
set security ipsec proposal ipsec-proposal lifetime-seconds 7200
set security ipsec policy ipsec-policy perfect-forward-secrecy keys group14
set security ipsec policy ipsec-policy proposals ipsec-proposal
set security ipsec vpn gw-jvsrx-b bind-interface st0.0
set security ipsec vpn gw-jvsrx-b ike gateway gw-jvsrx-b
set security ipsec vpn gw-jvsrx-b ike ipsec-policy ipsec-policy
set security ipsec vpn gw-jvsrx-b establish-tunnels immediately


Подробно:
protocol esp — будем использовать ESP (Encapsulated Security Payload header) (подробно описано тут);
authentication-algorithm hmac-sha-256-128 — алгоритм аутентификации IPSec;
encryption-algorithm aes-128-cbc — алгоритм шифрования;
lifetime-seconds 7200 — время жизни приватного ключа (был сгенерирован автоматически при инициализации подключения) второй фазы;
perfect-forward-secrecy keys group14 — аналогично dh-group;
bind-interface st0.0 — виртуальный интерфейс для построения IPSec туннеля;
establish-tunnels immediately — создать туннель прямо сейчас.

Аналогичные настройки нужно применить и на втором маршрутизаторе (заменив IP адрес на st0.0 и ike gateway).

Финишная прямая


На этом настройка самого IPSec туннеля завершена, но т.к. серия SRX это еще и firewall, то при таких параметрах туннель не поднимется — firewall будет отбрасывать все пакеты с попыткой установления туннеля. Поэтому внесем изменения в настройки firewall части:
set security zones security-zone untrust interfaces ge-0/0/0.0 host-inbound-traffic system-services ike
set security zones security-zone trust interfaces st0.0 host-inbound-traffic system-services all
set security zones security-zone trust interfaces st0.0 host-inbound-traffic protocols all


Первая команда разрешает IKE трафик на нашем внешнем интерфейсе (который смотрит в сторону провайдера); вторая и третья разрешают прохождение всего трафика внутри IPSec туннеля.

Теперь туннель должен подняться, давайте это проверим:
root@gw-jvsrx-a# run show security ike security-associations detail 
IKE peer 20.20.20.20, Index 2116322, Gateway Name: gw-jvsrx-b
  Role: Responder, State: UP
  Initiator cookie: 1fa7a8730c817511, Responder cookie: 2a3e1f8c554ddb85
  Exchange type: Main, Authentication method: Pre-shared-keys
  Local: 10.10.10.10:500, Remote: 20.20.20.20:500
  Lifetime: Expires in 2291 seconds
  Peer ike-id: 20.20.20.20
  Xauth assigned IP: 0.0.0.0
  Algorithms:
   Authentication        : hmac-sha256-128 
   Encryption            : aes128-cbc
   Pseudo random function: hmac-sha256
   Diffie-Hellman group  : DH-group-14
  Traffic statistics:
   Input  bytes  :                 1244
   Output bytes  :                  948
   Input  packets:                    6
   Output packets:                    4
  Flags: IKE SA is created 
  IPSec security associations: 1 created, 1 deleted
  Phase 2 negotiations in progress: 0

    Negotiation type: Quick mode, Role: Responder, Message ID: 0
    Local: 10.10.10.10:500, Remote: 20.20.20.20:500
    Local identity: 10.10.10.10
    Remote identity: 20.20.20.20
    Flags: IKE SA is created

root@gw-jvsrx-a# run show security ipsec security-associations detail  
  ID: 131073 Virtual-system: root, VPN Name: gw-jvsrx-b
  Local Gateway: 10.10.10.10, Remote Gateway: 20.20.20.20
  Local Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
  Remote Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
  Version: IKEv1
    DF-bit: clear
    Bind-interface: st0.0

  Port: 500, Nego#: 2, Fail#: 0, Def-Del#: 0 Flag: 0x600a29 
  Last Tunnel Down Reason: Delete payload received
    Direction: inbound, SPI: ea287d13, AUX-SPI: 0
                              , VPN Monitoring: -
    Hard lifetime: Expires in 5884 seconds
    Lifesize Remaining:  Unlimited
    Soft lifetime: Expires in 5295 seconds
    Mode: Tunnel(0 0), Type: dynamic, State: installed
    Protocol: ESP, Authentication: hmac-sha256-128, Encryption: aes-cbc (128 bits)
    Anti-replay service: counter-based enabled, Replay window size: 64

    Direction: outbound, SPI: 14a16181, AUX-SPI: 0
                              , VPN Monitoring: -
    Hard lifetime: Expires in 5884 seconds
    Lifesize Remaining:  Unlimited
    Soft lifetime: Expires in 5295 seconds
    Mode: Tunnel(0 0), Type: dynamic, State: installed
    Protocol: ESP, Authentication: hmac-sha256-128, Encryption: aes-cbc (128 bits)
    Anti-replay service: counter-based enabled, Replay window size: 64


Можно еще проверить старым-добрым способом:
root@gw-jvsrx-a# run ping 172.16.0.2 count 5 interface st0.0 
PING 172.16.0.2 (172.16.0.2): 56 data bytes
64 bytes from 172.16.0.2: icmp_seq=0 ttl=64 time=14.274 ms
64 bytes from 172.16.0.2: icmp_seq=1 ttl=64 time=10.420 ms
64 bytes from 172.16.0.2: icmp_seq=2 ttl=64 time=10.448 ms
64 bytes from 172.16.0.2: icmp_seq=3 ttl=64 time=10.448 ms
64 bytes from 172.16.0.2: icmp_seq=4 ttl=64 time=10.439 ms

--- 172.16.0.2 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 10.420/11.206/14.274/1.534 ms


Статистику по использованию туннеля можно посмотреть так:
root@gw-jvsrx-a# run show security ipsec statistics       
ESP Statistics:
  Encrypted bytes:            85052
  Decrypted bytes:            41088
  Encrypted packets:            553
  Decrypted packets:            512
AH Statistics:
  Input bytes:                    0
  Output bytes:                   0
  Input packets:                  0
  Output packets:                 0
Errors:
  AH authentication failures: 0, Replay errors: 0
  ESP authentication failures: 0, ESP decryption failures: 0
  Bad headers: 0, Bad trailers: 0


Но и это еще не все! Нам ведь нужно прописать маршруты до сети «за другим роутером», а т.к. мы ленивы и не любим излишней работы (ведь так?), то будем использовать OSPF:
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
set protocols ospf area 0.0.0.0 interface st0.0


Как всегда, не забываем сделать commit (и применить симметричные настройки на другом конце туннеля), а то ничего работать не будет:
root@gw-jvsrx-a# commit check 
configuration check succeeds

root@gw-jvsrx-a# commit 
commit complete
  • +4
  • 16.3k
  • 6
Share post

Similar posts

Comments 6

    +1
    А какой командой можно отключить бэкдор NSA в оборудовании juniper?
      0
      Он отключается только аппаратно, выдергиванием всех кабелей (в том числе питания) и помещением железки в сейф
        0
        Нет, можно использовать host-to-host security с использованием программных решений. В этом случае бэкдор в juniper оказывается если не выключен, то значительно ослаблен.

        Так что тезис простой: чувствительная информация не должна покидать хост незашифрованной.
      0
      а что скажите про сопряжение openswan и srx?
        0
        На выходных попробую поднять, но не обещаю. С OpenSWAN дела раньше не имел.
          0
          я сопрягал, в целом работает. Есть проблемы с гранулярностью SA — требуется явно указать proxy-id для каждого соедиенния со стороны SRX. Поддержка нескольких proxy-id для одного соединения появилась в JunOS буквально пару месяцев назад, фича еще сырая, и все равно с динамическим роутингом все будет непросто. Пока что если за SRX находится несколько неагрегируемых сетей — лучше по старинке делать gre-over-ipsec.

        Only users with full accounts can post comments. Log in, please.