Всем привет, в данном примере поднимем 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
можно писать много, предлагаю завершить.
Всем спасибо!!!
