Конфигурирование Route-Based site-to-site VPN

Всем привет, в данном примере поднимем  Route-Based VPN, рассмотрим конфигурацию необходимую только для функционирования Route-Based VPN, ну и для правильности NAT, другого не будет.

Настроим Route-Based  site-to-site VPN  между двумя площадками, для примера будем использовать всем известные названия поселений родного Каларского районаJ.

На рисунке ниже отображена логическая схема подключения, туннель будем пробрасывать между пос. Новая Чара и с. Чара. Сразу раскрою секрет, на начальном этапе оба Juniper-ра находятся  в одном помещении и соединены обычным «прямым» патч-кордом через интерфейсы fe-0/0/0 и ge-0/0/0, в интерфейсы fe-0/0/1 и ge-0/0/1 подключены ноутбуки. Также сразу оговорю некоторые моменты, на рисунке (по середине) обозначено облако «Internet», а интерфейсы смотрящие в него имеют адреса из частной сети (10.10.10.0), я думаю всем понятно, что это только пример конфигурации для написания статьи. В боевой же схеме, одним из бюджетных способов объединить офисы, является организация защищенной виртуальной частной сети поверх незащищенной сети Интернет, соответственно и ip-адреса должны быть глобальные.

Топология Route-Based VPN

 

 

Первым делом смотрим:

root@Chara# run show version

Hostname: Chara

Model: srx100b

JUNOS Software Release [12.1X44-D40.2]

Как мы видим, чтобы выполнить команды операционного режима, такие как ping, show version и другие в режиме конфигурирования нужно вести команду run

[edit]

root@New_Chara# run show version

Hostname: New_Chara

Model: srx240b

JUNOS Software Release [12.1X44-D40.2]

 

Теперь приступим непосредственно к настройке SRX New_Chara.

Конфигурирование WAN интерфейса:

root@New_Chara# set interfaces ge-0/0/0 unit 0 description WAN_INTERFACE  -  описание интерфейса

root@New_Chara# set interfaces ge-0/0/0 unit 0 family inet address 10.10.10.10/24

Конфигурирование LAN интерфейса:

root@New_Chara# set interfaces ge-0/0/1 unit 0 description LAN_INTERFACE  -  описание интерфейса

root@New_Chara# set interfaces ge-0/0/1 unit 0 family inet address 10.1.1.1/24

Конфигурирование туннельного интерфейса:

root@New_Chara# set interfaces st0 unit 1 family inet address 192.168.5.1/30

Конфигурирование таблицы маршрутизации:

root@New_Chara# set routing-options static route 0.0.0.0/0 next-hop 10.10.10.1 - маршрут до сети Интернет, т.к. у меня нет в наличии двух внешних ip-адресов, приходится работать с частными, но для примера этого вполне достаточно.

root@New_Chara# set routing-options static route 10.2.2.0/24 next-hop st0.1 - маршрут до удаленной сети 10.2.2.0/24, т.е. чтобы попасть на 10.2.2.0/24 нужно пройти через туннельный интерфейс st0.1

Конфигурирование security zones:

Зона безопасности WAN:

root@New_Chara# set security zones security-zone WAN host-inbound-traffic system-services all

root@New_Chara# set security zones security-zone WAN interfaces ge-0/0/0

Зона безопасности LAN:

root@New_Chara# set security zones security-zone LAN host-inbound-traffic system-services all

root@Chara# set security zones security-zone LAN interfaces ge-0/0/1

Зона безопасности VPN:

root@New_Chara# set security zones security-zone VPN interfaces st0.1  - для зоны VPN этого достаточно.

 

Да кстати, совсем забыл, конечно же для создания защищенного VPN туннеля мы будем использовать IPSec, для дальнейшего удобства и понимания хотелось бы коротко разместить интересующую нас информацию с Wikipedia и других источников, попробую это сделать максимально коротко:

Классификация VPN:

По степени защищенности используемой среды:

Защищённые: IPSec, OpenVPN и PPTP, нас интересует IPSec.

 

IPSec:

IPsec (сокращение от IP Security) — набор протоколов для обеспечения защиты данных, передаваемых по межсетевому протоколу IP. Позволяет осуществлять подтверждение подлинности (аутентификацию), проверку целостности и/или шифрование IP-пакетов. IPsec также включает в себя протоколы для защищённого обмена ключами в сети Интернет.

IPsec является набором стандартов Интернет и своего рода «надстройкой» над IP-протоколом. Его ядро составляют три протокола:

1.      Authentication Header (АН) обеспечивает целостность виртуального соединения (передаваемых данных), аутентификацию источника информации и функцию по предотвращению повторной передачи пакетов.

2.      Encapsulating Security Payload (ESP) обеспечивает конфиденциальность (шифрование) передаваемой информации, ограничение потока конфиденциального трафика. Кроме этого, он может исполнять функции AH: обеспечить целостность виртуального соединения (передаваемых данных), аутентификацию источника информации и функцию по предотвращению повторной передачи пакетов.

3.      Internet Security Association and Key Management Protocol (ISAKMP) — протокол, используемый для первичной настройки соединения, взаимной аутентификации конечными узлами друг друга и обмена секретными ключами. Протокол предусматривает использование различных механизмов обмена ключами, включая задание фиксированных ключей, использование таких протоколов, как Internet Key Exchange (IKE).

Нас интересует протокол безопасности ESP и протокол IKE, используемый для первичной настройки соединения:

 

Протокол безопасности ESP - шифрует передаваемые данные, гарантируя конфиденциальность, также поддерживает аутентификацию и обеспечивает целостность данных.

SRX поддерживает несколько алгоритмов хеширования для обеспечения аутентификации:

• Message-Digest Algorithm 5 (MD5) - 128-битный алгоритм хеширования.
• Secure Hash Algorithm 1 (SHA-1) -  160- битный алгоритм хеширования.
• Secure Hash Algorithm 2 (SHA-2) – 256- битный алгоритм хеширования.

       Алгоритмы аутентификации для ipsec можно посмотреть:

root@New_Chara# set security ipsec proposal IPSEC-PROTOSAL authentication-algorithm ?

Possible completions:

  hmac-md5-96          HMAC-MD5-96 authentication algorithm

  hmac-sha-256-128     HMAC-SHA-256-128 authentication algorithm

  hmac-sha-256-96      HMAC-SHA-256-96 authentication algorithm (non-RFC compliant)

  hmac-sha1-96         HMAC-SHA1-96 authentication algorithm

 

SRX поддерживает три алгоритма шифрования:

·         Data Encryption Standard (DES) - для шифрования использует ключ с длиной 56 бит.

·         Triple Data Encryption Standard (3DES) - имеет длину ключа равную 168 бит, но эффективная криптостойкость составляет 112 бит.

·         Advanced Encryption Standard (AES) – размер ключа 128/192/256 бит.

Смотрим:

root@New_Chara# set security ipsec proposal IPSEC-PROTOSAL encryption-algorithm ?

Possible completions:

  3des-cbc             3DES-CBC encryption algorithm

  aes-128-cbc          AES-CBC 128-bit encryption algorithm

  aes-192-cbc          AES-CBC 192-bit encryption algorithm

  aes-256-cbc          AES-CBC 256-bit encryption algorithm

  des-cbc              DES-CBC encryption algorithm

 

IKE (айк) — протокол, связывающий все компоненты IPsec в работающее целое. В частности, IKE обеспечивает первоначальную аутентификацию сторон, а также их обмен общими секретными ключами.

Существует IKE и более новая версия протокола: IKEv2. В спецификациях и функционировании этих протоколов есть некоторые различия. IKEv2 устанавливает параметры соединения за одну фазу, состоящую из нескольких шагов. Процесс работы IKE можно разбить на две фазы:

1.      Фаза первая.

IKE создает безопасный канал между двумя узлами, называемый IKE security association (IKE SA). Также, в этой фазе два узла согласуют сессионный ключ по алгоритму Диффи-Хеллмана. Первая фаза IKE может проходить в одном из двух режимов:

o   Основной режим (Main mode).

§  Согласуются алгоритмы для защиты IKE соединения.

§  Происходит обмен секретным ключом, используя алгоритм Диффи-Хеллмана.

§  Проверяется идентичность противоположной стороны и создается безопасный канал для второй фазы IKE.

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

o        Агрессивный режим (Aggressive mode) – этот режим обходится меньшим числом обменов. С точки зрения безопасности агрессивный режим слабее, так как участники начинают обмениваться информацией до установления безопасного канала, поэтому возможен несанкционированный перехват данных.

 После выше прочитанного уже не очень хочется слышать о преимуществах агрессивного режима в скорости, поэтому нас он не интересует.

По сути, целью первой фазы является организация безопасного канала (IKE SA) между сторонами.

2.      Фаза вторая.

В фазе два существует один режим – быстрый. Согласуются параметры IPsec SA по защищаемому IKE SA каналу, целью второй фазы является создание IPsec туннеля.

 Алгоритмы аутентификации для ike можно посмотреть:

root@New_Chara# set security ike proposal IKE-PROTOSAL authentication-algorithm ?

Possible completions:

  md5                  MD5 authentication algorithm

  sha-256              SHA 256-bit authentication algorithm

  sha1                 SHA1 authentication algorithm

 

Ну вот, всю wikipedia  закопипастил, вот ссылка на основной источник https://ru.wikipedia.org/wiki/IPsec . Информация была продублирована для удобства, в первую очередь для себя любимогоJ

Ну и перед продолжением немного о группах Диффи-Хеллмана (Diffie-Hellman Groups), которые поддерживает Juniper SRX240:

§  DH Group 1: 768-bit strength

§  DH Group 2: 1024-bit strength

§  DH Group 5: 1536-bit strength

§  DH Group 14: 2048-bit strength

Группы Диффи-Хеллмана относятся к размеру длины ключа, используемого для общения с VPN, группы должны соответствовать по обе стороны туннеля, в противном случае VPN не будет устанавливаться. Чем выше номер группы, тем «сильнее» и безопаснее ключ. Если проще, то группы Диффи-Хеллмана определяют силу ключа шифрования. Стоит учитывать, что увеличение номера группы DH повысит безопасность и одновременно увеличит нагрузку на процессор.

Продолжим конфигурирование.

Конфигурирование Первой фазы IKE (proposal and policy) для основного режима:

root@New_Chara# set security ike proposal IKE-PROTOSAL authentication-method pre-shared-keys

root@New_Chara# set security ike proposal IKE-PROTOSAL dh-group group2

root@New_Chara# set security ike proposal IKE-PROTOSAL authentication-algorithm sha1

root@New_Chara# set security ike proposal IKE-PROTOSAL encryption-algorithm aes-128-cbc

root@New_Chara# set security ike policy IKE-POLICY mode main

root@New_Chara# set security ike policy IKE-POLICY proposals IKE-PROTOSAL

root@New_Chara# set security ike policy IKE-POLICY pre-shared-key ascii-text 123

Конфигурирование VPN шлюза (IKE – Фаза первая):

root@New_Chara# set security ike gateway VPN-GATEWAY ike-policy IKE-POLICY

root@New_Chara# set security ike gateway VPN-GATEWAY address 10.10.10.20

root@New_Chara# set security ike gateway VPN-GATEWAY external-interface ge-0/0/0

Конфигурирование Второй фазы IKE (proposal and policy):

root@New_Chara# set security ipsec proposal IPSEC-PROTOSAL protocol esp

root@New_Chara# set security ipsec proposal IPSEC-PROTOSAL authentication-algorithm hmac-sha1-96

root@New_Chara# set security ipsec proposal IPSEC-PROTOSAL encryption-algorithm aes-128-cbc

root@New_Chara# set security ipsec policy IPSEC-POLICY perfect-forward-secrecy keys group2

root@New_Chara# set security ipsec policy IPSEC-POLICY proposals IPSEC-PROTOSAL

Конфигурирование IPsec VPN (IKE – Фаза вторая):

root@New_Chara# set security ipsec vpn IPSEC-VPN bind-interface st0.1

root@New_Chara# set security ipsec vpn IPSEC-VPN ike gateway VPN-GATEWAY

root@New_Chara# set security ipsec vpn IPSEC-VPN ike ipsec-policy IPSEC-POLICY

root@New_Chara# set security ipsec vpn IPSEC-VPN establish-tunnels immediately

Настройка  политики безопасности (security policies) для VPN трафика.

Политика из зоны LAN в зону VPN:

root@New_Chara# set security policies from-zone LAN to-zone VPN policy LAN_VPN match source-address any

root@New_Chara# set security policies from-zone LAN to-zone VPN policy LAN_VPN match destination-address any

root@New_Chara# set security policies from-zone LAN to-zone VPN policy LAN_VPN match application any

root@New_Chara# set security policies from-zone LAN to-zone VPN policy LAN_VPN then permit

Политика из зоны VPN в зону LAN:

root@New_Chara# set security policies from-zone VPN to-zone LAN policy VPN_LAN match source-address any

root@New_Chara# set security policies from-zone VPN to-zone LAN policy VPN_LAN match destination-address any

root@New_Chara# set security policies from-zone VPN to-zone LAN policy VPN_LAN match application any

root@New_Chara# set security policies from-zone VPN to-zone LAN policy VPN_LAN then permit

На начальном этапе, для проверки соединения, разрешим переход «с любого на любой» source и destination address.

Настройка  политики безопасности (security policies) для Интернет трафика.

Т.к. в нашей топологии присутствует некий Интернет, то для реалистичности настроим политику из зоны LAN в зону WAN:

root@New_Chara# set security policies from-zone LAN to-zone WAN policy LAN_WAN match source-address any

root@New_Chara# set security policies from-zone LAN to-zone WAN policy LAN_WAN match destination-address any

root@New_Chara# set security policies from-zone LAN to-zone WAN policy LAN_WAN match application any

root@New_Chara# set security policies from-zone LAN to-zone WAN policy LAN_WAN then permit

Ну и сам NAT.

Т.к. в нашем примере одна сеть (и один ноут), то создадим только разрешающее правило:

root@New_Chara# set security nat source rule-set LAN_TO_WAN from zone LAN

root@New_Chara# set security nat source rule-set LAN_TO_WAN to zone WAN

root@New_Chara# set security nat source rule-set LAN_TO_WAN rule YES_NAT match source-address 0.0.0.0/0

root@New_Chara# set security nat source rule-set LAN_TO_WAN rule YES_NAT match destination-address 0.0.0.0/0

root@New_Chara# set security nat source rule-set LAN_TO_WAN rule YES_NAT then source-nat interface

Настроим TCP-MSS:

root@New_Chara# set security flow tcp-mss ipsec-vpn mss 1350  - для уменьшения вероятности фрагментации, зададим рекомендованный максимальный размер полезного блока данных в байтах для TCP пакета (сегмента).

 

Juniper New_Chara настроен, теперь по аналогии настраиваем Juniper Chara.

 

Конфигурирование Juniper Chara.

Тут все так же, как и с  New_Chara, изменения только согласно схеме на рисунке.

 

Конфигурирование WAN интерфейса:

root@Chara# set interfaces fe-0/0/0 unit 0 family inet address 10.10.10.20/24

Конфигурирование LAN интерфейса:

root@Chara# set interfaces fe-0/0/1 unit 0 family inet address 10.2.2.1/24

Конфигурирование туннельного интерфейса:

root@Chara# set interfaces st0 unit 0 family inet address 192.168.5.2/30

Конфигурирование таблицы маршрутизации:

root@Chara# set routing-options static route 0.0.0.0/0 next-hop 10.10.10.1  - маршрут до сети Интернет.

root@Chara# set routing-options static route 10.1.1.0/24 next-hop st0.0 - маршрут до удаленной сети 10.1.1.0/24.

Конфигурирование security zones:

Зона безопасности WAN:

root@Chara# set security zones security-zone WAN host-inbound-traffic system-services all

root@Chara# set security zones security-zone WAN interfaces fe-0/0/0

Зона безопасности LAN:

root@Chara# set security zones security-zone LAN host-inbound-traffic system-services all

root@Chara# set security zones security-zone LAN interfaces fe-0/0/1

Зона безопасности VPN:

root@Chara# set security zones security-zone VPN interfaces st0.0

Остальное выкладываю в конфигурации.

root@Chara# show security ike

proposal IKE-PROTOSAL {

    authentication-method pre-shared-keys;

    dh-group group2;

    authentication-algorithm sha1;

    encryption-algorithm aes-128-cbc;

}

policy IKE-POLICY {

    mode main;

    proposals IKE-PROTOSAL;

    pre-shared-key ascii-text "$siляляmfp0"; ## SECRET-DATA

}

gateway VPN-GATEWAY {

    ike-policy IKE-POLICY;

    address 10.10.10.10;

    external-interface fe-0/0/0;

}

root@Chara# show security ipsec

proposal IPSEC-PROPOSAL {

    protocol esp;

    authentication-algorithm hmac-sha1-96;

    encryption-algorithm aes-128-cbc;

}

policy IPSEC-POLICY {

    perfect-forward-secrecy {

        keys group2;

    }

    proposals IPSEC-PROPOSAL;

}

vpn IPSEC-VPN {

    bind-interface st0.0;

    ike {

        gateway VPN-GATEWAY;

        ipsec-policy IPSEC-POLICY;

    }

    establish-tunnels immediately;

}

root@Chara# show security policies

from-zone LAN to-zone VPN {

    policy LAN_VPN {

        match {

            source-address any;

            destination-address any;

            application any;

        }

        then {

            permit;

        }

    }

}

from-zone VPN to-zone LAN {

    policy VPN_LAN {

        match {

            source-address any;

            destination-address any;

            application any;

        }

        then {

            permit;

        }

    }

}

from-zone LAN to-zone WAN {

    policy LAN_WAN {

        match {

            source-address any;

            destination-address any;

            application any;

        }

        then {

            permit;

 

root@Chara# show security nat

rule-set LAN_TO_WAN {

        from zone LAN;

        to zone WAN;

        rule YES_NAT {

            match {

                source-address 0.0.0.0/0;

                destination-address 0.0.0.0/0;

            }

            then {

                source-nat {

                    interface;

root@Chara# show security flow

tcp-mss {

    ipsec-vpn {

        mss 1350;

 

Ну вот, базово подняли VPN, теперь самое время воспользоваться командами проверки.

Команды проверки:

root@New_Chara> show security ike security-associations - команда выводит список всех активных IKE Phase 1 соединений (IKE SA).

root@New_Chara> show security ike security-associations detail – вывод дополнительной информации по всем активным IKE SA.

root@New_Chara> show security ike security-associations index …..  detail - вывод дополнительной информации по индексу (id) IKE SA.

 

 

root@New_Chara> show security ipsec security-associations - команда выводит информацию о активных соединений (IPsec SA).

root@New_Chara> show security ipsec security-associations detail – дополнительная информация

root@New_Chara> show security ipsec security-associations index ….. detail  -  вывод дополнительной информации по индексу (id) IPsec SA.

root@New_Chara> show security ipsec statistics – команда покажет ipsec статистику.

Ну и не забываем про утилиту ping и traceroute:

 

root@Chara> ping 10.10.10.10

PING 10.10.10.10 (10.10.10.10): 56 data bytes

64 bytes from 10.10.10.10: icmp_seq=0 ttl=64 time=3.048 ms

 

root@Chara> ping 10.1.1.1

PING 10.1.1.1 (10.1.1.1): 56 data bytes

64 bytes from 10.1.1.1: icmp_seq=0 ttl=64 time=3.750 ms

64 bytes from 10.1.1.1: icmp_seq=1 ttl=64 time=2.695 ms

 

root@Chara> ping 10.1.1.2

PING 10.1.1.2 (10.1.1.2): 56 data bytes

64 bytes from 10.1.1.2: icmp_seq=0 ttl=127 time=3.839 ms

64 bytes from 10.1.1.2: icmp_seq=1 ttl=127 time=2.975 ms

 

root@Chara> traceroute 10.1.1.2

traceroute to 10.1.1.2 (10.1.1.2), 30 hops max, 40 byte packets

 1  192.168.5.1 (192.168.5.1)  4.209 ms  3.644 ms  4.073 ms

 2  10.1.1.2 (10.1.1.2)  4.120 ms  5.221 ms  4.231 ms

 

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

Для начала рассмотрим зону безопасности WAN:

root@Chara# show security zones security-zone WAN

host-inbound-traffic {

    system-services {

        all;

    }

}

interfaces {

    fe-0/0/0.0;

}

Как мы видим разрешены все системные службы, это не очень красиво, поэтому рекомендуется оставить только необходимые, в некоторых случаях запрещается любой доступ из вне, если это так, то вместо all поставим ike, т.к. у нас поднят VPN. В других случаях, к ike добавляют ping, ssh. Мы же в нашем тестовом конфиге поставим ike:

root@Chara# delete security zones security-zone WAN host-inbound-traffic system-services all

root@Chara# set security zones security-zone WAN host-inbound-traffic system-services ike

root@Chara# show security zones security-zone WAN

host-inbound-traffic {

    system-services {

        ike;

    }

}

interfaces {

    fe-0/0/0.0;

Ну и немного об Address Books:

Адресная книга представляет собой сборник адресов.  Juniper позволяет настроить несколько адресных книг.  Ссылки на адресную книгу могут указываться при конфигурации политик, этим самым мы можем жестко прописать, с какой на какую подсеть будет идти обмен трафиком через VPN. Т.е. адресная книга включает адреса хостов и подсетей, чей трафик либо разрешен, либо заблокирован, эти адреса могут быть любой комбинацией (ipv4, ipv6, доменное имя).

В данной статье мы не будем разбираться в тонкостях Address Book,  остановимся на некоторых моментах.  Первое, что бросается в глаза, так это разные способы конфигурирования. Откроем официальную документацию и видим, что Address Book задается в контексте security, т.е. формируется общая или если можно так сказать, глобальная адресная книга. Ищем примеры конфигурации в Интернет, и находим статьи, где Address Book задается в security zones, конечно хотелось бы понять отличия этих двух способов и как правильней настроить Address Book. Ответ простой, в JunOS версии 11,2 и выше появилась возможность конфигурировать  Address Book, скажем так, на общем уровне, это более эффективная модель настройки, такая адресная книга может быть связана с несколькими зонами безопасности, т.к. она не привязана к конкретной зоне, это как минимум позволит уменьшить неэффективное использование ресурсов. В версиях JunOS 11,2 и выше сохранилась возможность настраивать Address Book в двух вариантах, одновременно использовать две схемы сразу не получится,  какой вариант выбрать решайте сами, мы же будем использовать новый способ.

Создадим Address Book на двух устройствах, свяжем с зонами безопасности и проверим работоспособность туннеля.

Для Juniper Chara:

root@Chara# set security address-book book1 address Chara_10.2.2.0/24 10.2.2.0/24

root@Chara# set security address-book book1 attach zone LAN – привязываем к зоне LAN

root@Chara# set security address-book book2 address New_Chara_10.1.1.0/24 10.1.1.0/24

root@Chara# set security address-book book2 attach zone VPN - привязываем к зоне VPN

 

root@Chara# edit security policies from-zone LAN to-zone VPN policy LAN_VPN match

[edit security policies from-zone LAN to-zone VPN policy LAN_VPN match]

root@Chara# show

source-address any;

destination-address any;

application any;

 

[edit security policies from-zone LAN to-zone VPN policy LAN_VPN match]

root@Chara# delete source-address any

 

[edit security policies from-zone LAN to-zone VPN policy LAN_VPN match]

root@Chara# delete destination-address any

 

root@Chara# set source-address ?

Possible completions:

  Chara_10.2.2.0/24    The address in address book book1   - ссылка на адресную книгу уже есть.

  [                    Open a set of values

  any                  Any IPv4 or IPv6 address

  any-ipv4             Any IPv4 address

  any-ipv6             Any IPv6 address

[edit security policies from-zone LAN to-zone VPN policy LAN_VPN match]

root@Chara# set source-address Chara_10.2.2.0/24

 

[edit security policies from-zone LAN to-zone VPN policy LAN_VPN match]

root@Chara# set destination-address ?

Possible completions:

  New_Chara_10.1.1.0/24  The address in address book book2

  [                    Open a set of values

  any                  Any IPv4 or IPv6 address

  any-ipv4             Any IPv4 address

  any-ipv6             Any IPv6 address

[edit security policies from-zone LAN to-zone VPN policy LAN_VPN match]

root@Chara# set destination-address New_Chara_10.1.1.0/24  

Смотрим:

[edit security policies from-zone LAN to-zone VPN policy LAN_VPN]

root@Chara# show

match {

    source-address Chara_10.2.2.0/24;

    destination-address New_Chara_10.1.1.0/24;

    application any;

}

then {

    permit;

}

Теперь для политики VPN_LAN:

[edit security policies from-zone VPN to-zone LAN policy VPN_LAN]

root@Chara# show

match {

    source-address New_Chara_10.1.1.0/24;

    destination-address Chara_10.2.2.0/24;

    application any;

}

then {

    permit;

Для Juniper New_Chara:

root@New_Chara# show security zones security-zone WAN

host-inbound-traffic {

    system-services {

        ike;

    }

}

interfaces {

    ge-0/0/0.0;

 

root@New_Chara# show security address-book

book1 {

    address New_Chara_10.1.1.0/24 10.1.1.0/24;

    attach {

        zone LAN;

    }

}

book2 {

    address Chara_10.2.2.0/24 10.2.2.0/24;

    attach {

        zone VPN;

 

root@New_Chara# show security policies

from-zone LAN to-zone VPN {

    policy LAN_VPN {

        match {

            source-address New_Chara_10.1.1.0/24;

            destination-address Chara_10.2.2.0/24;

            application any;

        }

        then {

            permit;

        }

    }

}

from-zone VPN to-zone LAN {

    policy VPN_LAN {

        match {

            source-address Chara_10.2.2.0/24;

            destination-address New_Chara_10.1.1.0/24;

            application any;

        }

        then {

            permit;

Проверяем командами проверки IKE SA и IPsec SA, пингуем с хостов, убеждаемся, что VPN работает и радуемся.

 

Коллеги, про VPN можно писать много, предлагаю завершить.

Всем спасибо!!!