В продолжении темы настройки 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, чтобы было откуда отталкиваться:
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
Автор: begizardov
