Начнем с принципиальной схемы нашей сети:
Из этой схемы видно, что оба устройства подключены к провайдеру через интерфейсы 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 ссылка на оригинал статьи http://habrahabr.ru/post/230087/
Добавить комментарий