Вы находитесь на странице: 1из 289

VPN

R75.40VS
Руководство администратора

20 ноября 2012 г.
© 2012 Check Point Software Technologies Ltd.
Все права защищены. Данный продукт и соответствующие документы защищены авторским
правом, и распространяются по лицензированию, ограничивающему их использование,
копирование, распространение и декомпиляцию. Никакая часть настоящего продукта или
соответствующей документации не может воспроизводиться ни в какой форме, никакими
средствами без предварительного письменного разрешения со стороны Check Point. Несмотря на
все меры предосторожности, принятые при подготовке данной книги, Check Point не берет на себя
ответственность за ошибки или упущения. Данное издание и описанные в нем функциональные
возможности могут быть изменены без предупреждения.
ИНФОРМАЦИЯ ОБ ОГРАНИЧЕНИИ ПРАВ:
На использование, копирование и предоставление информации правительством действуют
ограничения, установленные в подпункте (c)(1)(ii) пункта о Правах в Положении о технических
данных и программном обеспечении в DFARS 252.227-7013 и FAR 52.227-19.
ТОВАРНЫЕ ЗНАКИ:
Список товарных знаков представлен на странице об авторском праве
(http://www.checkpoint.com/copyright.html).
Список соответствующих авторских прав и лицензий третьих сторон представлен в уведомлениях
об авторском праве третьих сторон (http://www.checkpoint.com/3rd_party_copyright.html).

Руководство администратора VPN R75.40VS | 2


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

Новейшая документация
Последняя версия этого документа содержится по адресу:
http://supportcontent.checkpoint.com/documentation_download?ID=16210
Для получения дополнительной технической информации посетите центр технического обслуживания Check
Point (http://supportcenter.checkpoint.com).

История редакций
Дата Описание
20 ноября 2012 г. Обновлен пункт «Особенности проводного режима» (на стр. 101)
Обновлен пункт «Обзор VPN на основе маршрутов» (на стр. 71)
5 августа 2012 г. Обновлена информация о поддержке IKEv1 («IKEv1 и IKEv2» на стр. 17)
15 июля 2012 г. Первый выпуск данного документа

Обратная связь
Check Point непрерывно работает над усовершенствованием своей документации.
Просим Вас помочь нам в этом, направляя Ваши комментарии
(mailto:cp_techpub_feedback@checkpoint.com?subject=Feedback on VPN R75.40VS Administration
Guide).

Руководство администратора VPN R75.40VS | 3


СОДЕРЖАНИЕ

ВАЖНАЯ ИНФОРМАЦИЯ..................................................................................................................... 3
РЕШЕНИЕ ДЛЯ VPN КОМПАНИИ CHECK POINT ............................................................................... 9
КОМПОНЕНТЫ VPN ............................................................................................................................... 9
ТЕРМИНОЛОГИЯ .................................................................................................................................... 9
VPN SITE-TO-SITE .............................................................................................................................. 10
VPN-СООБЩЕСТВА ............................................................................................................................. 10
VPN С УДАЛЕННЫМ ДОСТУПОМ ............................................................................................................ 11
ПОРТАЛЫ ШЛЮЗА БЕЗОПАСНОСТИ ........................................................................................................ 12
IPSEC И IKE ........................................................................................................................................ 14
ОБЗОР ............................................................................................................................................... 14
IKE, фаза I .................................................................................................................................... 14
IKE, фаза II (Быстрый режим или фаза IPSec) ............................................................................ 16
IKEv1 и IKEv2................................................................................................................................ 17
Методы шифрования и проверки подлинности ........................................................................... 17
Режимы фазы I ............................................................................................................................. 18
Периодичность повторных согласований IKE и IPSec ................................................................ 18
Совершенная прямая секретность .............................................................................................. 18
Сжатие IP...................................................................................................................................... 19
Подсети и Ассоциации защиты .................................................................................................... 19
ЗАЩИТА IKE ОТ DOS-АТАК................................................................................................................... 20
Понятие DoS-атак......................................................................................................................... 20
DoS-атаки IKE ............................................................................................................................... 21
Защита от DoS-атак IKE ............................................................................................................... 21
Настройки защиты IKE от DoS-атаки в SmartDashboard ............................................................. 22
Дополнительные настройки защиты IKE от DoS-атак ................................................................. 22
НАСТРОЙКА ДОПОЛНИТЕЛЬНЫХ СВОЙСТВ IKE ....................................................................................... 23
На сетевом объекте VPN-сообщества......................................................................................... 24
На сетевом объекте шлюза безопасности .................................................................................. 24
ВВЕДЕНИЕ В VPN SITE-TO-SITE....................................................................................................... 25
ЗАЧЕМ НУЖНЫ ВИРТУАЛЬНЫЕ ЧАСТНЫЕ СЕТИ?...................................................................................... 25
Секретность .................................................................................................................................. 25
Проверка подлинности ................................................................................................................. 25
Целостность ................................................................................................................................. 25
Как это работает ........................................................................................................................... 26
VPN-сообщества .......................................................................................................................... 26
Проверка подлинности между членами сообщества .................................................................. 27
Топологии VPN ............................................................................................................................. 28
Контроль доступа и VPN-сообщества.......................................................................................... 33
Маршрутизация трафика в VPN-сообществе .............................................................................. 34
Исключенные службы .................................................................................................................. 34
ОСОБЕННОСТИ ПЛАНИРОВАНИЯ ТОПОЛОГИИ VPN ................................................................................. 34
КОНФИГУРАЦИЯ VPN SITE-TO-SITE ...................................................................................................... 34
Переход из традиционного режима в упрощенный ..................................................................... 35
Настройка ячеистого сообщества между шлюзами, управляемыми изнутри ............................ 35
Настройка звездообразного VPN-сообщества ............................................................................ 36
Подтверждение успешного открытия VPN-туннеля .................................................................... 36
НАСТРОЙКА VPN СО ШЛЮЗАМИ БЕЗОПАСНОСТИ, УПРАВЛЯЕМЫМИ ИЗВНЕ, ПОСРЕДСТВОМ PKI ................. 36
НАСТРОЙКА VPN СО ШЛЮЗАМИ БЕЗОПАСНОСТИ, УПРАВЛЯЕМЫМИ ИЗВНЕ, ПОСРЕДСТВОМ ОБЩЕГО
СЕКРЕТНОГО КЛЮЧА ............................................................................................................................ 38
КАК АВТОРИЗОВАТЬ УПРАВЛЯЮЩИЕ СОЕДИНЕНИЯ БРАНДМАУЭРА В VPN-СООБЩЕСТВАХ .......................... 39
Почему отключение неявных правил брандмауэра блокирует управляющие соединения ....... 40
Разрешение брандмауэром управляющих соединений внутри VPN.......................................... 40
Определение служб, используемых для управляющих соединений .......................................... 40
ИНФРАСТРУКТУРА ОТКРЫТОГО КЛЮЧА ....................................................................................... 41
НЕОБХОДИМОСТЬ ИНТЕГРАЦИИ С РАЗЛИЧНЫМИ РЕШЕНИЯМИ PKI ........................................................... 41
ПОДДЕРЖКА ШИРОКОГО СПЕКТРА РЕШЕНИЙ PKI .................................................................................... 41

Руководство администратора VPN R75.40VS | 4


PKI и пользователи удаленного доступа ..................................................................................... 42
Развертывания PKI и VPN ........................................................................................................... 42
Доверие внешнему СА ................................................................................................................. 44
Регистрация объекта управления................................................................................................ 44
Проверка сертификата ................................................................................................................. 45
ОСОБЕННОСТИ PKI ............................................................................................................................. 48
Использование внутреннего СА и развертывание стороннего СА ............................................. 48
Распределенное управление и хранение ключей ....................................................................... 48
НАСТРОЙКА ОПЕРАЦИЙ PKI ................................................................................................................. 48
Установление доверия к СА – шаг за шагом ............................................................................... 48
Отзыв сертификата (все типы СА)............................................................................................... 50
Восстановление и возобновление сертификата ......................................................................... 50
СА Certificate Rollover ................................................................................................................... 50
Добавление критериев соответствия в процесс проверки.......................................................... 51
Использование кэша CRL ............................................................................................................ 52
Изменение кэша для предварительной загрузки CRL ................................................................ 52
Изменение периода отсрочки CRL .............................................................................................. 52
НАСТРОЙКА OCSP ............................................................................................................................. 52
VPN SITE-TO-SITE .............................................................................................................................. 53
VPN НА ОСНОВЕ ДОМЕНОВ .................................................................................................................. 54
Обзор VPN на основе доменов .................................................................................................... 54
VPN-маршрутизация и контроль доступа .................................................................................... 54
Настройка VPN на основе доменов ............................................................................................. 55
VPN НА ОСНОВЕ МАРШРУТОВ .............................................................................................................. 62
Обзор VPN на основе маршрутов ................................................................................................ 62
Туннельный интерфейс VPN (VTI) ............................................................................................... 63
Использование протоколов динамической маршрутизации ....................................................... 64
Настройка нумерованных VTI ...................................................................................................... 64
VTI в кластерной среде ................................................................................................................ 66
Настройка VTI в кластерной среде .............................................................................................. 66
Включение протоколов динамической маршрутизации .............................................................. 71
Настройка антиспуфинга на VTI .................................................................................................. 72
Настройка кольцевого интерфейса ............................................................................................. 75
Настройка ненумерованного VTI ................................................................................................. 75
Маршрутизация многоадресных пакетов через VPN-туннели .................................................... 76
УПРАВЛЕНИЕ ТУННЕЛЯМИ .................................................................................................................... 78
Обзор управления туннелями...................................................................................................... 78
Настройка функций туннелей ...................................................................................................... 80
МЕХАНИЗМ ВВОДА ТРАФИКА ................................................................................................................. 83
Обзор ввода трафика ................................................................................................................... 83
Автоматический RIM .................................................................................................................... 83
Пользовательские сценарии ........................................................................................................ 84
Ввод интерфейсов удаленного шлюза безопасности ................................................................. 86
Настройка RIM .............................................................................................................................. 86
Настройка RIM под Gaia............................................................................................................... 88
ПРОВОДНОЙ РЕЖИМ ............................................................................................................................ 89
Обзор проводного режима ........................................................................................................... 89
Ситуации с проводным режимом ................................................................................................. 89
Особенности проводного режима ................................................................................................ 92
Настройка проводного режима .................................................................................................... 92
УСТАНОВЛЕНИЕ НАПРАВЛЕННОЙ VPN .................................................................................................. 94
Обзор направленной VPN ............................................................................................................ 94
Установление направления в пределах сообщества.................................................................. 94
Объекты, настраиваемые по направлению ................................................................................. 95
Установление направления между сообществами ..................................................................... 96
Настройка направленной VPN в пределах сообщества ............................................................. 96
Настройка направленной VPN между сообществами ................................................................. 97
ВЫБОР ЛИНИИ СВЯЗИ .......................................................................................................................... 98
Обзор выбора линии связи .......................................................................................................... 98
Настройка выбора IP-адреса по удаленному узлу ...................................................................... 98
Настройка выбора исходящего маршрута................................................................................. 100
Настройка IP-адреса источника ................................................................................................. 100
Отслеживание исходящей линии связи..................................................................................... 102

Руководство администратора VPN R75.40VS | 5


Ситуации с выбором линии связи.............................................................................................. 102
Выбор линии связи на основе служб ......................................................................................... 102
Доверенные линии связи ........................................................................................................... 106
Линии связи по требованию (ODL) ............................................................................................ 113
Выбор линии связи и ISP-резервирование ................................................................................ 115
Выбор линии связи при наличии устройств не Check Point ...................................................... 116
VPN С МНОЖЕСТВЕННЫМИ ТОЧКАМИ ВХОДА ....................................................................................... 117
Обзор МЕР ................................................................................................................................. 117
Явные МЕР ................................................................................................................................. 118
Неявные МЕР ............................................................................................................................. 123
Маршрутизация ответных пакетов ............................................................................................ 125
Особенности ............................................................................................................................... 126
Настройка МЕР........................................................................................................................... 126
VPN ТРАДИЦИОННОГО РЕЖИМА ......................................................................................................... 130
Введение в VPN традиционного режима ................................................................................... 130
VPN-домены и правила шифрования ........................................................................................ 131
Определение свойств VPN ........................................................................................................ 130
Шлюзы безопасности, управляемые изнутри и извне............................................................... 130
Прежде чем создавать VPN… ................................................................................................... 131
Настройка VPN традиционного режима .................................................................................... 132
ПРЕОБРАЗОВАНИЕ ТРАДИЦИОННОЙ ПОЛИТИКИ В ПОЛИТИКУ НА ОСНОВЕ СООБЩЕСТВА ........................... 137
Основы преобразования в упрощенный режим VPN ................................................................ 137
Отличия традиционного и упрощенного режимов VPN............................................................. 137
Работа правила шифрования в традиционном режиме ........................................................... 138
Принципы преобразования в упрощенный режим .................................................................... 139
Помещение шлюзов безопасности в сообщества ..................................................................... 139
Преобразование правила шифрования..................................................................................... 139
VPN С УДАЛЕННЫМ ДОСТУПОМ ................................................................................................... 143
РЕШЕНИЯ CHECK POINT ДЛЯ УДАЛЕННОГО ДОСТУПА ............................................................................ 144
Обеспечение безопасного удаленного доступа ........................................................................ 144
Типы решений ............................................................................................................................ 144
Сравнение решений для удаленного доступа........................................................................... 145
Сводная характеристика вариантов удаленного доступа ......................................................... 146
ОБЗОР VPN С УДАЛЕННЫМ ДОСТУПОМ ............................................................................................... 149
Обзор VPN с удаленным доступом............................................................................................ 149
Решение для удаленного доступа SecureClient ........................................................................ 149
Необходимость в VPN с удаленным доступом.......................................................................... 154
ОСОБЕННОСТИ VPN С УДАЛЕННЫМ ДОСТУПОМ ................................................................................... 155
Определение политики для удаленного доступа ...................................................................... 155
Методы создания пользовательского сертификата при использовании ICA ........................... 155
Несколько сертификатов для одного пользователя ................................................................. 155
Внутренняя и внешняя базы данных пользователей ................................................................ 155
Функция аутентификации NT-группами / классами RADIUS ..................................................... 156
НАСТРОЙКА VPN С УДАЛЕННЫМ ДОСТУПОМ ........................................................................................ 157
Работа VPN с удаленным доступом .......................................................................................... 158
Создание сертификатов VPN с удаленным доступом для пользователей .............................. 158
Создание и настройка шлюза безопасности ............................................................................. 160
Определение пользователя и методов аутентификации в LDAP............................................. 160
Регистрация пользовательских сертификатов – Средство управления ICA............................ 160
Настройка сертификатов с использованием стороннего PKI ................................................... 160
Включение гибридного режима и методы проверки подлинности ............................................ 161
Настройка аутентификации NT-групп и классов RADIUS ......................................................... 161
Использование общего секретного ключа ................................................................................. 162
Определение группы пользователей LDAP .............................................................................. 162
Определение группы пользователей......................................................................................... 162
Определение VPN-сообщества и его участников ..................................................................... 162
Определение правил контроля доступа .................................................................................... 162
Установка политики .................................................................................................................... 162
Управление сертификатами пользователей ............................................................................. 163
Изменение свойств шифрования для VPN с удаленным доступом ......................................... 163
Работа с аппаратными и программными токенами RSA .......................................................... 164
ОФИСНЫЙ РЕЖИМ ............................................................................................................................. 166
Удаленные клиенты должны быть частью локальной сети ...................................................... 166

Руководство администратора VPN R75.40VS | 6


Офисный режим ......................................................................................................................... 166
Включение функции «IP-адрес для пользователя» .................................................................. 171
Особенности офисного режима ................................................................................................. 174
Настройка офисного режима ..................................................................................................... 174
УПАКОВКА SECURECLIENT ................................................................................................................. 180
Введение: необходимость упрощения установки удаленного клиента .................................... 180
Решение Check Point – SecureClient Packaging Tool ................................................................. 180
Создание предварительно настроенного пакета ...................................................................... 181
Настройка MSI Packaging ........................................................................................................... 182
БЕЗОПАСНОСТЬ НАСТОЛЬНЫХ СИСТЕМ ............................................................................................... 185
Потребность в безопасности настольных систем ..................................................................... 185
Особенности безопасности настольных систем ....................................................................... 185
Настройка безопасности настольных систем............................................................................ 186
КЛИЕНТЫ ПРОТОКОЛА ТУННЕЛИРОВАНИЯ ВТОРОГО УРОВНЯ (L2TP) ...................................................... 187
Необходимость поддержки клиентов L2TP ............................................................................... 187
Решение – Работа с клиентами L2TP........................................................................................ 187
Особенности выбора клиентов Microsoft IPSec/L2TP................................................................ 190
Настройка удаленного доступа для клиентов Microsoft IPSec/L2TP......................................... 191
ПРОВЕРКА БЕЗОПАСНОЙ КОНФИГУРАЦИИ ............................................................................................ 195
Зачем проверять безопасность удаленного клиента? .............................................................. 195
Решение для проверки безопасной конфигурации ................................................................... 195
Особенности SCV....................................................................................................................... 198
Настройка SCV ........................................................................................................................... 198
VPN-МАРШРУТИЗАЦИЯ – УДАЛЕННЫЙ ДОСТУП .................................................................................... 219
Необходимость VPN-маршрутизации ........................................................................................ 219
Решение Check Point для улучшения связи и безопасности .................................................... 219
Настройка VPN-маршрутизации для VPN с удаленным доступом ........................................... 222
ВЫБОР ЛИНИИ СВЯЗИ ДЛЯ КЛИЕНТОВ УДАЛЕННОГО ДОСТУПА ................................................................ 224
Обзор .......................................................................................................................................... 224
Настройка выбора линии связи только для удаленного доступа ............................................. 224
ИСПОЛЬЗОВАНИЕ НАПРАВЛЕННОЙ VPN ДЛЯ УДАЛЕННОГО ДОСТУПА...................................................... 225
Направленные VPN в сообществах с удаленным доступом..................................................... 225
Настройка направленных VPN в сообществах с удаленным доступом ................................... 225
ДОПОЛНИТЕЛЬНАЯ НАСТРОЙКА УДАЛЕННОГО ДОСТУПА ........................................................................ 226
Нечастные IP-адреса клиентов .................................................................................................. 226
Предотвращение шифрования клиента внутри домена шифрования ..................................... 227
Срок действия аутентификации и кэширование пароля ........................................................... 230
Безопасный вход в домен (SDL) ................................................................................................ 230
Обратные соединения (от сервера к клиенту) .......................................................................... 231
Автообновление топологии (только режим соединения) .......................................................... 232
Как работать с брандмауэрами не Check Point ......................................................................... 232
Преобразование внутренних имен сервером DNS SecuRemote .............................................. 232
МНОЖЕСТВЕННЫЕ ТОЧКИ ВХОДА ДЛЯ VPN С УДАЛЕННЫМ ДОСТУПОМ ................................................... 233
Необходимость множественных точек входа в виде шлюзов безопасности............................ 233
Решение Check Point для множественных точек входа ............................................................ 233
Выключение МЕР ....................................................................................................................... 235
Настройка МЕР........................................................................................................................... 235
Настройка предпочитаемых резервных шлюзов безопасности ................................................ 236
Выключение МЕР ....................................................................................................................... 236
КОНФИГУРАЦИОННЫЕ ФАЙЛЫ USERC.C И PRODUCT.INI ........................................................................ 237
Введение в Userc.C и Product.ini ................................................................................................ 238
Параметры файла userc.C ......................................................................................................... 245
Параметры Product.ini ................................................................................................................ 248
Введение в SSL Network Extender ............................................................................................. 248
Принцип работы SSL Network Extender ..................................................................................... 249
Распространенные подходы ...................................................................................................... 249
Особенности SSL Network Extender ........................................................................................... 250
Настройка SSL Network Extender ............................................................................................... 252
Работа пользователя с SSL Network Extender .......................................................................... 258
Поиск и устранение неполадок SSL Network Extender .............................................................. 268
РЕШЕНИЕ ПРОБЛЕМ СВЯЗИ ................................................................................................................ 270
Необходимость функций решения проблем связи.................................................................... 270
Решение Check Point для проблем святи .................................................................................. 270

Руководство администратора VPN R75.40VS | 7


Решение проблем, связанных с NAT ......................................................................................... 270
Решение проблем, связанных с ограничением доступа в Интернет ........................................ 275
Настройка удаленного доступа .................................................................................................. 278
ПРИЛОЖЕНИЯ.................................................................................................................................. 283
ИНТЕРФЕЙС КОМАНДНОЙ СТРОКИ VPN ...................................................................................... 284
КОМАНДЫ VPN ................................................................................................................................. 284
КОМАНДЫ SECURECLIENT .................................................................................................................. 285
КОМАНДЫ ПОЛИТИКИ НАСТОЛЬНЫХ СИСТЕМ ........................................................................................ 286
VPN SHELL........................................................................................................................................ 288
НАСТРОЙКА ВИРТУАЛЬНОГО ИНТЕРФЕЙСА С ПОМОЩЬЮ VPN SHELL ..................................................... 288

Руководство администратора VPN R75.40VS | 8


Глава 1
Решение для VPN компании Check
Point
В этой главе
КОМПОНЕНТЫ VPN ............................................................................................................................................. 9
ТЕРМИНОЛОГИЯ ................................................................................................................................................. 9
VPN SITE-TO-SITE .............................................................................................................................................. 10
VPN-СООБЩЕСТВА ........................................................................................................................................... 10
VPN С УДАЛЕННЫМ ДОСТУПОМ...................................................................................................................... 11
ПОРТАЛЫ ШЛЮЗА БЕЗОПАСНОСТИ .............................................................................................................. 12

Технология виртуальных частных сетей (VPN) улучшает существующую инфраструктуру (Интернет) в аспекте
построения и расширения существующих связей безопасным образом. Основываясь на стандартных
защитных протоколах Интернета, внедрение VPN дает возможность формирования надежных соединений
между особыми типами узлов сети – шлюзами безопасности Check Point. VPN Site-to-Site обеспечивает
надежные соединения между шлюзами безопасности, а VPN с удаленным доступом обеспечивает надежные
соединения между шлюзами безопасности и клиентами удаленного доступа.
Шлюз безопасности Check Point – это интегральное программное решение, обеспечивающее установление
связи в пределах корпоративных сетей, между удаленными пользователями и владельцами мобильных
устройств, филиалами компании и бизнес-партнерами в широком спектре открытых платформ и устройств
защиты.
Шлюзы безопасности Check Point сочетают контроль доступа, проверку подлинности и шифрования, таким
образом, гарантируя безопасность сетевых соединений в Интернете общего пользования.
При типичном развертывании шлюз безопасности Check Point подключается к корпоративной сети (из
Интернета), а программное обеспечение для удаленного доступа устанавливается на компьютеры мобильных
пользователей. Прочие удаленные узлы охраняются дополнительными шлюзами безопасности Check Point, а
связь между всеми компонентами подчиняется строгой политике безопасности.

Компоненты VPN
VPN состоит из:
 терминалов VPN, таких как шлюзы безопасности, кластеры шлюзов безопасности или удаленные клиенты
(ноутбуки, мобильные телефоны), сообщающиеся посредством VPN;
 объектов сертификации VPN, таких как Внутренний сертификационный центр Check Point (ICA). ICA
является частью пакета Check Point, которая служит для формирования защищенного соединения между
шлюзами безопасности, администраторами проверки подлинности и сторонними серверами. ICA
обеспечивает сертификаты для внутренних шлюзов безопасности и клиентов удаленного доступа,
связанных по линии VPN;
 инструментов управления VPN. Сервер управления защитой и SmartDashboard. SmartDashboard – это
SmartConsole для доступа к Серверу управления защитой. Диспетчер VPN является частью
SmartDashboard. SmartDashboard предоставляет организациям возможность определять и развертывать
Интрасеть, а также VPN с удаленным доступом.

Терминология
При внедрении безопасной VPN широко используются ряд специальных терминов.
 VPN. Зашифрованная частная сеть, осуществляющая безопасную связь между шлюзами безопасности и
терминалами VPN через сеть общего доступа, например, Интернет.
 Интерфейс туннеля VPN. Интерфейс виртуального туннеля (VTI) – виртуальный интерфейс шлюза
безопасности, относящийся к существующему VPN-туннелю на основе маршрутов. VPN-туннель на основе
маршрутов работает как соединение точка-точка между двумя одинаковыми шлюзами безопасности VPN-
сообщества.
 Узел. Шлюз безопасности, соединяющийся с другим шлюзом безопасности посредством интерфейса
виртуального туннеля.
Решение для VPN компании Check Point

 Топология VPN. Базовым элементом VPN является линия связи или зашифрованный туннель. Линии
связи создаются между шлюзами безопасности. Множество линий связи образуют топологию. Топология
представляет собой план VPN. Две базовые топологии, по которым строится VPN, – это звездообразная и
ячеистая.
 Шлюз безопасности VPN. Терминал шифрованного соединения, который может быть любым узлом,
поддерживающим среду протокола IPSec. Шлюзы безопасности могут быть отдельными модулями или
быть организованными в кластеры для «высокой доступности» и «распределения нагрузки».
 VPN-домен. Группа, объединяющая хосты или сети, для которых выполняется шифрование IP-датаграмм.
Шлюз безопасности VPN является точкой входа в VPN-домен.
 VPN Site-to-Site. Относится к VPN-туннелю между двумя шлюзами безопасности.
 VPN с удаленным доступом. Относится к удаленным пользователям, которые получают доступ к сети
при помощи клиентского ПО, такого как Клиенты удаленного доступа Check Point или сторонние клиенты
IPSec. Шлюз безопасности Check Point обеспечивает Службу удаленного доступа для удаленных
клиентов.
 Алгоритм шифрования. Набор математических процессов преобразования информации в
бессмысленную форму, при этом математические трансформации управляются специальным ключом.
Шифрование при помощи различных алгоритмов, например, 3DES и AES, обеспечивает возможность
расшифровки сообщения только теми узлами, между которыми осуществляется связь.
 Целостность. Проверка целостности (с помощью хэш-функций) обеспечивает тот факт, что во время
передачи данные не были перехвачены или изменены.
 Доверие. Для установления доверия между шлюзами безопасности задействованы инфраструктура
открытого ключа (PKI), сертификаты и сертификационные центры. (В отсутствие PKI шлюзы безопасности
применяют общий секретный ключ (pre-shared secret)).
 IKE и IPSec. Безопасные VPN-протоколы, используемые для управления ключами шифрования и обмена
зашифрованными пакетами. IPSec – технология шифрования, поддерживающая несколько стандартов,
обеспечивающая проверку подлинности и услугу шифрования данных в частных и общественных сетях.
IKE (Internet Key Exchange) – стандарт протокола управления ключами. IKE дополняет IPSec,
предоставляя дополнительные функции, гибкость и простоту настройки.

VPN Site-to-Site
В центре VPN находится зашифрованный туннель (или линия связи VPN), созданный с помощью протоколов
IKE/IPSec. На концах туннеля пребывают либо шлюзы безопасности Check Point, либо клиенты удаленного
доступа. Первым делом узлы одного ранга, использующие линию связи, формируют доверие между собой.
Это доверие устанавливается с помощью сертификационных центров, PKI или общих секретных ключей.
Происходит обмен методами и создание ключей. Организуется зашифрованный туннель, который
поддерживается для нескольких соединений, при необходимости обновляя ключи за счет обмена ключевыми
материалами.

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

Руководство администратора VPN R75.40VS | 10


Решение для VPN компании Check Point

Шлюз безопасности

В звездообразном сообществе шлюзы безопасности, определенные как сателлитные («лучи»), могут


связываться только с центральным шлюзом безопасности («концентратором»), но не между собой.

Сателлитный шлюз

Центральный шлюз
ячеистый

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

VPN с удаленным доступом


Когда пользователи получают доступ к сети организации из удаленных положений, необходимо выполнение
не только обычных требований к безопасности связи, но и особых требований к удаленным клиентам.
SecuRemote/SecureClient расширяет функциональность VPN, предоставляет пользователям возможность
безопасно обмениваться чувствительной информацией между сетями и серверами через VPN-туннель, с

Руководство администратора VPN R75.40VS | 11


Решение для VPN компании Check Point

использованием как dial-up (в том числе широковещательную связь), так и LAN (в том числе беспроводную
LAN). Управление пользователями осуществляется либо посредством внутренней базы данных шлюз
безопасности Check Point, либо через внешний сервер LDAP.

Хост 1
Интернет
Удаленный клиент

Удаленный пользователь инициирует связь со шлюзом безопасности. Во время согласования протокола IKE
происходит проверка подлинности. После подтверждения существования пользователя шлюз безопасности
проверяет его подлинность, например, проверяя сертификат пользователя. После успешного завершения IKE
создается туннель; удаленный клиент соединяется с Хостом 1.

Порталы шлюза безопасности


Шлюзом безопасности по HTTPS выполняется ряд веб-порталов.
 Мобильный портал веб-доступа
 Веб-интерфейс SecurePlatform
 Веб-интерфейс Gaia
 Identity Awareness (портал авторизации)
 Портал DLP
 Портал расширения сети SSL
 Портал UserCheck
Эти порталы (и проверка HTTPS) поддерживают последние версии протокола TLS. Помимо SSLv3 и TLS 1.0
(RFC 2246) шлюз безопасности поддерживает:
 TLS 1.1 (RFC 4346)
 TLS 1.2 (RFC 5246)
Поддержка TLS 1.1 и TLS 1.2 включена по умолчанию, однако, ее можно отключить в SmartDashboard (для
веб-порталов) или GuiDBedit (для проверки HTTPS).
Чтобы настроить поддержку порталами протокола TLS, необходимо выполнить такие шаги.
1. В SmartDashboard откройте Глобальные свойства > Настройка SmartDashboard (Global Properties >
SmartDashboard Customization).
2. В разделе Дополнительные настройки (Advanced Configuration) нажмите Настроить. Откроется окно
Дополнительные настройки.
3. На странице Свойства портала укажите минимальную и максимальную версии протоколов SSL и TLS.
4. Чтобы настроить поддержку протокола TLS
Чтобы настроить поддержку протокола TLS проверкой HTTPS, необходимо выполнить такие шаги.

Руководство администратора VPN R75.40VS | 12


Решение для VPN компании Check Point

1. В GuiDBedit на вкладке Таблицы (Tables) выберите Прочие > ssl_inspection (Other > ssl_inspection).
2. В столбце Объекты (Objects) выберите general_confs_obj.
3. В столбце Поля (Fields) измените поля:
 ssl_max_ver
 ssl_min_ver

Руководство администратора VPN R75.40VS | 13


IPSec и IKE

Глава 2
IPSec и IKE
В этой главе
ОБЗОР ................................................................................................................................................................ 14
ЗАЩИТА IKE ОТ DOS-АТАК .............................................................................................................................. 20
НАСТРОЙКА ДОПОЛНИТЕЛЬНЫХ СВОЙСТВ IKE........................................................................................... 23

Обзор
В симметричных криптографических системах обе связывающиеся стороны для шифрования и расшифровки
применяют один и тот же ключ. Материал, используемый для построения этого ключа, необходимо уметь
передать безопасным способом. Безопасный обмен информацией происходит лишь тогда, когда ключ
принадлежит исключительно связывающимся сторонам.
Целью Обмена ключами по Интернету (IKE – Internet Key Exchange) для обеих сторон является независимое
производство одинакового симметричного ключа. В дальнейшем с помощью этого ключа шифруются и
расшифровываются обычные IP-пакеты, используемые при групповой пересылке данных между
противоположными узлами VPN. IKE выстраивает VPN-туннель, проводя аутентификацию обеих сторон и
находя соответствие относительно методов шифрования и проверки целостности. Результатом работы IKE
является Ассоциация защиты (SA – Security Association).
Данное соглашение о ключах и методах шифрования также должно выполняться безопасным образом.
Поэтому IKE состоит из двух фаз. Во время первой фазы закладывается фундамент для второй. Шлюзы
безопасности версии R71 или выше поддерживают и IKEv1, и IKEv2.
Для обмена материалом для построения симметричных ключей служит часть протокола IKE, называемая
метод Диффи-Хеллмана (DH). Алгоритм Диффи-Хеллмана позволяет построить шифровальный ключ,
известный как «общий секретный ключ» (shared secret), из частного ключа одной стороны и открытого ключа
другой. Поскольку симметричные ключи IPSec получаются из ключа DH, общего для обоих узлов,
фактического обмена симметричными ключами не происходит.

IKE, фаза I
Во время первой фазы IKE происходит следующее.
 Происходит проверка подлинности узлов на основании сертификатов или через общий секретный ключ.
(Если один из узлов – клиент удаленного доступа, тогда методов аутентификации может быть больше).
 Создается ключ Диффи-Хеллмана. Суть протокола Диффи-Хеллмана подразумевает независимое
формирование общего ключа на обеих сторонах, причем ключ известен только связывающимся сторонам.
 Между узлами происходит обмен материалом для ключа (произвольные биты и прочие математические
данные) и соглашением о методах, применяемых на второй фазе IKE.
Генерация ключа Диффи-Хеллмана в контексте производительности протекает медленно и тяжело. В
результате фазы I IKE образуется Ассоциация защиты (SA) IKE – соглашение о ключах и методах для фазы II
IKE. На рис. 2-1 показан процесс, происходящий во время фазы I IKE, который, впрочем, не обязательно
отражает фактическую последовательность событий.

Руководство администратора VPN R75.40VS | 14


IPSec и IKE

Фаза I IKE для шлюзов безопасности

Сертификат – Сертификат
Происходит проверка подлинности узлов на основании сертификатов или общего секретного ключа
Частный ключ – Открытый ключ – Открытый ключ – Частный ключ
Из совокупности произвольных битов на каждой стороне образуется частный ключ DH

Из своего частного ключа каждый узел получает открытый ключ DH


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

Общий секретный ключ и является ключом Диффи-Хеллмана


Общий секретный ключ – Общий секретный ключ

Материал для ключа


Ключ Диффи-Хеллмана – Соглашения – Ключ Диффи-Хеллмана

Ключ DH применяется для обмена материалом для ключа (произвольные биты и прочие математические данные)
Соглашение о методах шифрования и проверки целостности на второй фазе IKE

Симметричный ключ – Материал для ключа – Материал для ключа – Симметричный ключ
Каждая сторона независимо генерирует симметричный ключ на основании ключа DH материала для ключа, который они передали
друг другу

SA IKE

Руководство администратора VPN R75.40VS | 15


IPSec и IKE

IKE, фаза II (Быстрый режим или фаза IPSec)


Фаза II IKE шифруется согласно ключам и методам, согласованным на первой фазе IKE. Материал для
ключей, обмен которым происходит на фазе II IKE, используется для построения ключей IPSec. В результате
фазы II образуется Ассоциация защиты (SA) IPSec. SA IPSec – это соглашение о ключах и методах IPSec,
таким образом, IPSec выполняется согласно ключам и методам, согласованным во время фазы II IKE.

Фаза II IKE

Шлюз безопасности – Шлюз безопасности


Симметричный ключ – Материал для ключа – Соглашения – Симметричный ключ
Узлы обмениваются дальнейшим материалом для ключа и согласовывают методы шифрования и проверки целостности IPSec

Ключ DH фазы I – Материал для ключа – Материал для ключа – Ключ DH фазы I
Ключ DH комбинируется с материалом для ключа, образуя симметричный ключ IPSec
Ключ IPSec – Ключ IPSec

Симметричные ключи IPSec применяются при групповой пересылке данных


SA IPSec

Руководство администратора VPN R75.40VS | 16


IPSec и IKE

После формирования ключей IPSec происходит групповая пересылка данных:

IPSec
Шлюз безопасности – VPN-туннель – Пакет IPSec – Зашифрованные данные – Шлюз безопасности
Шифрование – Расшифровка
Шифрование – Расшифровка

Во время выполнения IKE строится туннель


Ключи IPSec используются для создания зашифрованных IP-пакетов для передачи данных
Полезная информация зашифрована (DES, AES или другой)

Целостность данных обеспечивается односторонними хэш-функциями (MD5 или SHA1)


Быстрая групповая пересылка данных

IKEv1 и IKEv2
IKEv2 поддерживается внутри VPN-сообществ, работающих в упрощенном режиме в версиях R71 или выше.
IKEv2 – это стандарт, по-разному внедряемый в продуктах разных производителей. Внедряя IKEv2
одинаковым способом, производители способствуют повышению совместимости и интеграции. Подробнее см.
RFC 4306 и 4301.
Настройка IKEv2 происходит в окне Свойства VPN-сообщества > Шифрование (VPN Community
Properties > Encryption). Значение по умолчанию только IKEv1.
Для удаленных пользователей настройки IKE выполняются в меню Глобальные свойства > Удаленный
доступ > Аутентификация и шифрование VPN (Global Properties > Remote Access > VPN Authentification
and Encryption).
Примечание. IKEv2 не поддерживается устройствами UTM-1 Edge и VSX-объектами ранее
R75.40VS. Если в VPN-сообщество входят устройства UTM-1 Edge или указанные VSX-объекты,
параметр Шифрование должен принимать значение Поддержка IKEv1.

Методы шифрования и проверки подлинности


В ходе работы происходит принятие решения по двум параметрам:
 Алгоритм шифрования.
 Хэш-алгоритм.
Методы шифрования/проверки целостности при IKE

Параметр Фаза I IKE (SA IKE) Фаза II IKE (SA IPSec)


AES -256 (по умолч.) AES -128 (по умолч.)
Шифрование
3DES 3DES
DES AES - 256
CAST DES

Руководство администратора VPN R75.40VS | 17


IPSec и IKE

CAST
DES -40CP
CAST -40
NULL
AES-GCM -128
AES-GCM - 256
SHA1 (по умолч.) MD5 (по умолч.)
Проверка целостности
MD5 SHA1
SHA -256 SHA -256
AES-XCBC AES-XCBC
SHA -384 SHA -384
Значение NULL означает отсутствие шифрования пакетов; выполняется только проверка целостности.

Группы Диффи-Хеллмана
Вычисление ключа Диффи-Хеллмана (иначе называемое «согласование экспоненциального ключа»)
основывается на математических группах Диффи-Хеллмана (DH). Эти группы DH поддерживаются шлюзом
безопасности в течение прохождения обеих фаз IKE.

Параметр Фаза I IKE (SA IKE) Фаза II IKE (SA IPSec)


Группа2 (1024 бит) (по умолч.) Группа2 (1024 бит)
Группы Диффи-Хеллмана
Группа1 (768 бит) (по умолч)
Группа5 (1536 бит) Группа1 (768 бит)
Группа14 (2048 бит) Группа5 (1536 бит)
Группа19 (256-бит ECP) Группа14 (2048 бит)
Группа20 (384-бит ECP) Группа19 (256-бит ECP)
Группа20 (384-бит ECP)
Чем больше бит в группе, тем сложнее взломать соответствующий код, однако, тем выше потери
производительности, в силу того, что сложное вычисление занимает больше циклов ЦП.

Режимы фазы I
Между шлюзами безопасности существует 2 режима фазы I IKE. Эти режимы относятся только к IKEv1:
 Основной режим
 Агрессивный режим
Если не выбран агрессивный режим, то шлюз безопасности по умолчанию работает в основном режиме,
выполняя согласование IKE с использованием шести пакетов; в агрессивном режиме согласование IKE
выполняется тремя пакетами.

Предпочтительным является основной режим. Причиной тому служит следующее:

 Основной режим шифруется частично, с того момента, когда общий ключ DH становится известен обоим
узлам.
 Основной режим менее подвержен атакам типа "отказ в обслуживании" (DoS). В основном режиме
вычисление ключа DH осуществляется после проверки подлинности. В агрессивном режиме вычисление
ключа DH выполняется одновременно с проверкой подлинности. Еще не проверенный узел имеет
возможность принудительно инициировать вычисление процессором ключа Диффи-Хеллмана на другом
узле.
Примечание. Прибегайте к агрессивному режиму, когда шлюз безопасности Check Point должен
взаимодействовать со сторонними решениями VPN, не поддерживающими основной режим.
При работе через удаленный доступ у IKE есть дополнительные режимы:
 Гибридный режим. Гибридный режим представляет собой альтернативу фазе I IKE, когда шлюзу
безопасности разрешено проводить проверку подлинности по сертификатам, а клиенту – каким-нибудь
еще способом, например, при помощи SecurID. Подробнее о гибридном режиме см. Введение в VPN с
удаленным доступом.
 Офисный режим. Офисный режим – это расширение протокола IKE. Этот режим призван решать
проблемы маршрутизации между клиентами удаленного доступа и VPN-доменом. Во время работы IKE
между первой и второй фазами вставляется специальный режим, который называется режим
конфигурации. В режиме конфигурации клиент удаленного доступа запрашивает IP-адрес у шлюза
безопасности. После того, как шлюз безопасности присваивает IP-адрес, клиент создает в операционной
системе виртуальный адаптер, использующий присвоенный IP-адрес. Подробнее см. в разделе Офисный
режим (на стр. 185)

Руководство администратора VPN R75.40VS | 18


IPSec и IKE

Периодичность повторных согласований IKE и IPSec


Фаза I IKE больше загружает процессор, чем фаза II, поскольку каждый раз необходимо формировать ключи
Диффи-Хеллмана и выполнять проверку подлинности узлов. Поэтому первая фаза IKE выполняется реже
второй. Однако, SA IKE действительна лишь в течение некоторого времени, после которого необходимо
выполнять повторное согласование. SA IPSec действительна еще меньшее время, а значит, фаза II IKE
должна выполняться много раз.
Период времени между повторными согласованиями называется «время жизни». Обычно, чем короче время
жизни, тем безопаснее туннель IPSec (и тем интенсивнее приходится работать процессору над
согласованием IKE). Чем дольше время жизни, тем быстрее можно настраивать будущие VPN-соединения.
По умолчанию фаза I IKE происходит раз в день; фаза II IKE выполняется ежечасно, однако, периодичность
каждой фазы можно изменить.
Время жизни IPSec можно также настроить в килобайтах при помощи GuiDBedit, редактируя файл
objects_5_0.c. Соответствующие свойства настраиваются под параметрами сообщества:
 ike_p2_use_rekey_kbytes. Меняем значение false (по умолчанию) на true.
 ike_p2_rekey_kbytes. Изменяем на требуемую периодичность повторного согласования (по умолчанию
50 000).

Совершенная прямая секретность


Ключи, сформированные сторонами во время фазы II IKE и используемые для IPSec, основываются на
последовательности произвольных двоичных цифр, которыми обмениваются узлы, и на ключе DH,
вычисленном во время фазы I IKE.
Ключ DH вычисляется один раз, а затем несколько раз используется в ходе фазы II IKE. Поскольку ключи,
используемые во время фазы II IKE, основываются на ключе DH, который был вычислен на первой фазе IKE,
между ними существует математическая взаимосвязь. Таким образом, использование единого ключа DH
может ослабить защиту последующих ключей. Если взломан один ключ, последующие ключи можно взломать
еще проще.
В криптографии совершенной прямой секретностью (Perfect Forward Secrecy, PFS) называется состояние,
когда взлом ключа текущего сеанса или частного ключа длительного действия не может оказать
поспособствовать взлому ранних или последующих ключей. Шлюзы безопасности соответствуют
требованиям режима PFS. При задействовании PFS во время фазы II IKE формируется новый ключ DH,
который обновляется при каждом обмене ключами.
Однако, поскольку новый ключ DH создается во время фазы I IKE, нет зависимости между этими ключами и
теми, что будут сформированы на последующих фазах I согласования IKE. PFS на фазе II IKE следует
включать только тогда, когда требуется предельная безопасность.
Группа DH, используемая в режиме PFS, может быть группой 1, 2, 5 и 14. По умолчанию используется группа
2 (1042 бит).
Примечание. Режим PFS поддерживается только между шлюзами, а не между шлюзами
безопасности и клиентами удаленного доступа.

Сжатие IP
Сжатие IP – это процесс сокращения размера доли данных в пакете TCP/IP. Такое сокращение может дать
существенный прирост производительности. IPSec поддерживает алгоритм сжатия IP Flate/Deflate. Deflate –
это интеллектуальный алгоритм, подстраивающий способ сжатия данных под сами данные. Решение об
использовании сжатия IP принимается на второй фазе IKE. По умолчанию сжатие IP выключено.
Сжатие IP важно для пользователей SecuRemote/SecureClient с медленной связью. Например, для модемов
коммутируемых линий передачи сжатие IP – способ ускорения линии. Шифрование шлюза безопасности
делает пакеты TCP/IP «смешанными». Такой тип данных невозможно сжать, в результате теряется скорость
передачи. При включенном сжатии IP пакеты сжимаются перед шифрованием. Это восстанавливает
потерянную полосу пропускания линии.

Подсети и Ассоциации защиты


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

Руководство администратора VPN R75.40VS | 19


IPSec и IKE

Хост А Шлюз безопасности

Хост В Удаленный VPN-узел


Хост С Интернет

Шлюз безопасности защищает сеть, состоящую из двух подсетей (10.10.10.х и 10.10.11.х, для обеих маска
подсети 255.255.255.0). Второй шлюз безопасности, удаленный узел, защищает подсети 10.10.12.х и
10.10.13.х с маской подсети 255.255.255.0.
Поскольку по умолчанию в VPN-туннель создается для полных подсетей, между шлюзами безопасности
одного ранга существуют четыре SA. Когда хост А связывается с хостом В, между подсетью хоста А и
подсетью хоста В создается SA.

Уникальная SA для пары узлов одного ранга


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

Хост А Шлюз безопасности


Хост В Удаленный VPN-узел

Хост С Интернет
Если в настройках шлюза безопасности настроена Поддержка обмена ключами для подсетей, однако, эта
опция не поддерживается второй стороной, когда хост А связывается с хостом С, между подсетью хоста А и
IP-адресом хоста С согласовывается Ассоциация защиты (SA 1). Затем та же SA используется между любым
хостом подсети 10.10.11.х и хостом С.

Руководство администратора VPN R75.40VS | 20


IPSec и IKE

Когда хост А связывается с хостом В, между подсетью хоста А и хостом В согласовывается отдельная
Ассоциация защиты (SA 2).

Хост А Шлюз безопасности


Хост В Удаленный VPN-узел
Хост С Интернет

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

Защита IKE от DoS-атак


Понятие DoS-атак
DoS-атаки (Denial of Service – отказ в обслуживании) нацелены на сокращение производительности,
блокировании службы для законных пользователей или даже на вывод службы из строя. Они не являются
прямыми угрозами конфиденциальности, в том смысле, что не предназначены для перехвата
зашифрованных данных или предоставления пользователям несанкционированных прав. Однако, они
потребляют ресурсы компьютера – память или ЦП.
В общем существует два типа DoS-атак. Один вид состоит в отсылке искаженных пакетов (мусора) в надежде
подселить вирус или разрушить службу. Другой вид DoS-атак предусматривает попытку злоумышленника
использовать уязвимость службы или протокола, отправляя правильные пакеты. Защита IKE от DoS-атак
ориентируется на второй вид атак.

DoS-атаки IKE
Протокол IKE требует, чтобы принимающий шлюз безопасности выделял память для первого полученного
запроса на фазу I IKE. Шлюз безопасности отвечает и принимает другой пакет, который затем обрабатывает,
используя информацию из первого пакета.
Злоумышленник может отослать много первых пакетов IKE, назначая каждому из них разный исходящий IP-
адрес. Принимающий шлюз безопасности обязан ответить на каждый из них и выделить для каждого из них
память. Так можно занять все ресурсы процессора, не давая установить соединение законным
пользователям.
Пакеты IKE может отсылать машина, которой разрешено выполнения согласования IKE, например, шлюз
безопасности Check Point. Это – идентифицированный источник. У злоумышленника также может быть IP-
адрес, о котором принимающий шлюз безопасности не знает, например, SecuRemote/SecureClient, или шлюз
безопасности Check Point с динамическим IP-адресом. Это – неидентифицированный источник.

Защита от DoS-атак IKE


Когда количество одновременных согласований IKE, подлежащих обработке, превышает принятый порог,
принимается решение о том, что либо слишком велика нагрузка, либо имеет место DoS-атака. В этом случае
шлюз безопасности может отфильтровать узлы, вероятно, являющиеся источником возможной атаки «отказ в
обслуживании». В следующих разделах описаны различные типы защиты IKE от DoS-атак.

Руководство администратора VPN R75.40VS | 21


IPSec и IKE

Защита IKE от DoS-атак без сохранения состояния


Шлюз безопасности не допускает DoS-атак IKE, откладывая момент выделения шлюзом безопасности
ресурсов до тех пор, пока узел не докажет свою законность. Описанный здесь процесс называется защитой
без сохранения состояния (stateless protection).
Если шлюз безопасности приходит к выводу, что либо пребывает под нагрузкой, либо испытывает DoS-атаку,
то по получении запроса IKE он отсылает ответ предполагаемому источнику, содержащий пакет с числом,
которое может сгенерировать только шлюз безопасности. После этого шлюз безопасности «забывает» о
запросе IKE. Иначе говоря, шлюзу безопасности не нужно хранить запрос IKE в памяти (поэтому защита
называется «без сохранения состояния»).
Машина, получившая пакет, должна повторно инициализировать запрос IKE, отослав запрос IKE,
включающий это число.
Если шлюз безопасности получает запрос IKE с этим номером, он распознает этот номер как таковой,
который мог сгенерировать только сам шлюз безопасности, и только после этого продолжит согласование
IKE, даже будучи под нагрузкой.
Если шлюз безопасности Check Point получает запросы IKE от многих IP-адресов, каждому адресу
отсылается различный уникальный номер; каждый адрес должен повторно инициализировать согласование
IKE при помощи пакета, содержащего этот номер. Если узел не пребывает на заданных IP-адресах,
уникальный номер до него никогда не дойдет. Таким образом, план злоумышленника, отсылающего запросы
IKE с разных IP-адресов, будет провален.
Защита IKE от DoS-атак недоступна для сторонних шлюзов безопасности. При сильной нагрузке сторонние
шлюзы безопасности и клиенты (такие как клиенты Microsoft IPSec/L2TP) могут утратить возможность связи.

Защита IKE от DoS-атак с помощью головоломок


Защита без сохранения состояния подходит тогда, когда пакет IKE исходит от идентифицированного
источника, т. е., машины, имеющей разрешение на инициирование согласования IKE, напр., шлюз
безопасности Check Point.
Неидентифицированный источник – это IP-адрес, не распознанный принимающим шлюзом безопасности,
например, SecuRemote/SecureClient, или шлюз безопасности Check Point с динамическим IP-адресом.
Злоумышленник может контролировать много неидентифицированных IP-адресов, может иметь возможность
отвечать со всех этих адресов на пакеты без сохранения состояния. Таким образом, если атака
осуществляется с неидентифицированного источника, необходим другой подход.
Шлюз безопасности может потребовать, чтобы источник запроса IKE решил некоторую головоломку,
требующую значительных вычислительных ресурсов. Большинство компьютеров способны решить лишь
очень малое количество таких головоломок в секунду, поэтому атакующий сможет отослать лишь несколько
пакетов IKE в секунду. Это сводит на нет эффективность DoS-атаки.
Защита IKE от DoS-атаки невозможна для сторонних шлюзов безопасности. При сильной нагрузке они могут
утратить возможность связи.

Настройки защиты IKE от DoS-атаки в SmartDashboard


Для защиты IKE от DoS-атак измените настройки SmartDashboard Защита IKE от DoS-атак (IKE Denial of
Service Protection) на странице VPN > Дополнительно (Advanced) пункта Глобальные свойства (Global
Properties).
 Поддержка защиты IKE on DoS-атак с идентифицированных источников – значение по умолчанию
для идентифицированных источников Без сохранения состояния (Stateless). Если шлюз безопасности
нагружен, то при такой настройке от узла потребуется ответ на IKE-уведомление, подтверждающий, что
IP-адрес не сымитирован. Если подтверждения от узла не поступает, шлюз безопасности не начинает
согласование IKE.
Если источник идентифицирован, то нет смысла устанавливать этому параметру значение Головоломки
(Puzzles), поскольку это сильно сократит производительность. Третье возможное значение – Нет (None),
означающее выключение защиты от DoS-атак.
 Поддержка защиты IKE on DoS-атак с неидентифицированных источников – значение по умолчанию
для неидентифицированных источников Головоломка (Puzzles). Если шлюз безопасности нагружен, то
при такой настройке от узла потребуется решение математической задачи. На такое решение тратится
много ресурсов процессора, при этом инициирование нескольких одновременных согласований IKE
значительно усложняется.
Если источник не идентифицирован, то нет смысла устанавливать этому параметру значение Без
сохранения состояния (Stateless) – такая защита будет неэффективной. Злоумышленник может
контролировать все IP-адреса, с которых отсылаются запросы IKE. Третье возможное значение – Нет
(None), означающее выключение защиты от DoS-атак.

Дополнительные настройки защиты IKE от DoS-атак


Кроме того, настройка защиты IKE от DoS-атак выполняется на Сервере управления защитой при помощи
командной строки GuiDBedit или посредством GuiDBedit – инструмента Check Point для работы с базами
данных. Защита настраивается путем изменения следующих глобальных настроек.

Руководство администратора VPN R75.40VS | 22


IPSec и IKE

ike_dos_threshold
Значения: 0-100, по умолчанию: 70. Определяет максимальный процент одновременно выполняемых
согласований, превышение которого вынудит шлюз безопасности запросить защиту от DoS-атаки. Если
пороговым значением установить 0, шлюз безопасности всегда будет запрашивать защиту от DoS-атаки.
ike_dos_puzzle_level_identified_initiator
Значения: 0-32, по умолчанию: 19. Определяет уровень головоломок, отсылаемых шлюзу безопасности
известного узла. Этот атрибут определяет также максимальный уровень головоломки, который шлюз
безопасности готов решать.
ike_dos_puzzle_level_unidentified_initiator
Значения: 0-32, по умолчанию: 19. Определяет уровень головоломок, отсылаемых неизвестным узлам (таким
как SecuRemote/SecureClient и шлюзам безопасности DAIP). Этот атрибут определяет также максимальный
уровень головоломки, который шлюзы безопасности DAIP и SecuRemote/SecureClient готов решать.
ike_dos_max_puzzle_time_gw
Значения: 0-30000, по умолчанию: 500. Определяет максимальное время в миллисекундах, которое готов
потратить шлюз безопасности на решение головоломок защиты от DoS-атаки.
ike_dos_max_puzzle_time_daip
Значения: 0-30000, по умолчанию: 500. Определяет максимальное время в миллисекундах, которое готов
потратить шлюз безопасности DAIP на решение головоломок защиты от DoS-атаки.
ike_dos_max_puzzle_time_sr
Значения: 0-30000, по умолчанию: 500. Определяет максимальное время в миллисекундах, которое готов
потратить SecuRemote на решение головоломок защиты от DoS-атаки.
ike_dos_supported_protection_sr
Значения: Нет, Без сохранения состояния, Головоломки, по умолчанию: Головоломки. При загрузке в
SecuRemote/SecureClient управляет уровнем защиты, который клиент готов поддерживать.
Шлюзы безопасности используют свойство ike_dos_protection_unidentified_initiator (эквивалентно
глобальному свойству SmartDashboard Поддержка защиты IKE on DoS-атак с неидентифицированных
источников) для принятия решения о том, какую защиту потребовать от удаленных клиентов; однако,
клиенты SecuRemote/SecureClient используют ike_dos_protection. То же самое свойство клиента на шлюзе
безопасности называется ike_dos_supported_protection_sr.

Защита после успешной проверки подлинности


Вы можете настроить поля GuiDBedit для защиты IKE от DoS-атак со стороны узлов, которые могут атаковать
шлюз безопасности после успешной аутентификации. Такие настройки задаются в таблице Глобальные
свойства, а не для каждого шлюза безопасности. По умолчанию эта защита выключена. После введения
значения защита активируется.
Для ограничения количества Ассоциаций защиты (SA) IKE, доступных для открытия пользователем,
настройте следующие поля:

Тип VPN Поле Рекомендованное значение

Site-to-Site number_of_ISAKMP_SAs_kept_per_peer 5

Удаленный пользователь number_of_ISAKMP_SAs_kept_per_user 5

Для ограничения количества туннелей, которые может открыть пользователь на один IKE, настройте
следующие поля:

Тип VPN Поле Рекомендованное значение

Site-to-Site number_of_ipsec_SAs_per_IKE_SA 30

Удаленный пользователь number_of_ipsec_SAs_per_user_IKE_SA 5

Свойства клиента
Некоторые свойства шлюза безопасности изменяют свое название при загрузке в SecuRemote/SecureClient.
Измененное название указывается в файле User.C следующим образом.
Названия свойств
Название свойства на шлюзе Название свойства User.C у клиента

ike_dos_protection_unidentified_initiator ike_dos_protection или


(эквивалентно глобальному свойству ike_support_dos_protection
SmartDashboard Поддержка защиты IKE

Руководство администратора VPN R75.40VS | 23


IPSec и IKE

on DoS-атак с неидентифицированных
источников)

ike_dos_supported_protection_sr ike_dos_protection

ike_dos_puzzle_level_unidentified_initiator ike_dos_acceptable_puzzle_level

ike_dos_max_puzzle_time_sr ike_dos_max_puzzle_time

Настройка дополнительных свойств IKE


IKE настраивается в двух местах:
 на сетевом объекте VPN-сообщества (свойства IKE);
 на сетевом объекте шлюза безопасности (обмен ключами подсети).

На сетевом объекте VPN-сообщества


1. На странице Свойства VPN-сообщества > Шифрование (VPN Community Properties > Encryption)
выберите:
 Метод шифрования – для фаз I и II IKE.
 Только IKEv2 – поддержка шифрования при помощи только IKEv2. В этом сообществе шлюзы
безопасности не могут получать доступ к шлюзам того же уровня, которые поддерживают только
IKEv1.
 Предпочтительно IKEv2, поддержка IKEv1 – если узел поддерживает IKEv2, I, будет
использовать IKEv2. В противном случае будет применено шифрование IKEv1. Этот вариант
рекомендуется, если в сообществе участвуют как новые, так и старые шлюзы безопасности
Check Point.
 Только IKEv1 – IKEv2 не поддерживается.
 Пакет шифрования – методы, согласовываемые в ходе фазы II IKE, используемые в связях IPSec.
Выберите вариант, исходя из соображений улучшения взаимодействия с аппаратурой других
производителей в данной среде.
 VPN-A или VPN-B – Подробнее см. RFC 4308.
 Suite-B GCM-128 или 256 – Подробнее см. RFC 6379.
 Если вам нужны алгоритмы, не перечисленные среди вариантов, выберите Пользовательский
и щелкните Дополнительно, чтобы выбрать свойства фаз I и II IKE.
2. На странице Свойства VPN-сообщества > Дополнительные настройки > Дополнительные свойства
VPN (VPN Community Properties > Advanced Settings > Advanced VPN Properties) выберите:
 какую группу Диффи-Хеллмана использовать;
 когда следует выполнять повторное согласование Ассоциаций защиты IKE;
 когда прибегать к агрессивному режиму (по умолчанию включен основной режим);
 когда использовать совершенную прямую секретность и с какой группой Диффи-Хеллмана;
 когда следует выполнять повторное согласование Ассоциаций защиты IPSec;
 когда использовать Поддержку сжатия IP;
 когда в рамках VPN-сообщества отключать NAT.

На сетевом объекте шлюза безопасности


 На странице VPN Дополнительно (VPN Advanced) выберите один из вариантов в разделе Совместное
использование VPN-туннеля (VPN Tunnel Sharing). Здесь представлено несколько настроек,
управляющих количеством VPN-туннелей между шлюзами одного уровня.
 Использовать настройки сообщества – количество создаваемых VPN-туннелей соответствует
настройкам, заданным на странице Управление туннелями сообщества.
 Пользовательские настройки:
 Один VPN-туннель для каждой пары хостов – VPN-туннель создается для каждого сеанса
связи между каждой парой хостов.
 Один VPN-туннель для пары подсетей – VPN-туннель открывается между двумя подсетями и
впоследствии используется в дальнейших сеансах связи между этими же подсетями. Это
значение установлено по умолчанию, оно соответствует промышленному стандарту IPSec.
 Один VPN-туннель для пары шлюзов – Один VPN-туннель создается между шлюзами одного
уровня и совместно используется всеми хостами, расположенными позади этих шлюзов.
 На странице Оптимизация пропускной способности (Capacity Optimization) можно максимально
повысить пропускную способность VPN, ограничив следующие параметры связи.
 Максимальное количество одновременных согласований IKE
 Максимальное количество одновременных туннелей
Если у вас многие сотрудники работают удаленно, то, вероятно, для вас будет целесообразно увеличить
значения по умолчанию.

Руководство администратора VPN R75.40VS | 24


Глава 3
Введение в VPN Site-to-Site
В этой главе
ЗАЧЕМ НУЖНЫ ВИРТУАЛЬНЫЕ ЧАСТНЫЕ СЕТИ? ....................................................................................... 25
ОСОБЕННОСТИ ПЛАНИРОВАНИЯ ТОПОЛОГИИ VPN .................................................................................... 34
КОНФИГУРАЦИЯ VPN SITE-TO-SITE................................................................................................................. 34
НАСТРОЙКА VPN СО ШЛЮЗАМИ БЕЗОПАСНОСТИ, УПРАВЛЯЕМЫМИ ИЗВНЕ, ПОСРЕДСТВОМ PKI ...... 36
НАСТРОЙКА VPN СО ШЛЮЗАМИ БЕЗОПАСНОСТИ, УПРАВЛЯЕМЫМИ ИЗВНЕ, ПОСРЕДСТВОМ ОБЩЕГО
СЕКРЕТНОГО КЛЮЧА ....................................................................................................................................... 38
КАК АВТОРИЗОВАТЬ УПРАВЛЯЮЩИЕ СОЕДИНЕНИЯ БРАНДМАУЭРА В VPN-СООБЩЕСТВАХ .............. 39

Зачем нужны виртуальные частные сети?


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

Секретность
Только взаимодействующие стороны должны иметь возможность считать ту личную информацию, обмен
которой имеет место.

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

Целостность
Чувствительные данные должны пройти через канал связи без изменений, что должно подтверждаться
проверкой целостности.

Как это работает


На рисунке изображена ситуация, когда хост 1 и хост 6 собираются установить связь. Между хостом 1 и
локальным шлюзом безопасности находится нешифрованная линия. Шлюз безопасности обнаруживает, что
между исходным адресом и адресом назначения пакета должна быть зашифрованная связь. Если это первое
соединение, локальный шлюз безопасности инициирует согласование IKE с другим шлюзом безопасности, за
которым находится хост 6. В ходе согласования происходит взаимная проверка подлинности шлюзов
безопасности и установление методов и ключей шифрования. После успешного согласования IKE
формируется VPN-туннель. С этого момента каждый пакет, проходящий между шлюзами безопасности,
шифруется по протоколу IPSec. IKE обеспечивает подлинность (шлюзы безопасности проверили, что
установили связь именно друг с другом) и закладывает базу для IPSec. После создания туннеля IPSec
обеспечивает конфиденциальность (путем шифрования) и целостность (посредством односторонней хэш-
функции).
Введение в VPN Site-to-Site

Хост 1 Интернет
Хост 2 Зашифрован
Хост 3 Без шифрования

Без шифрования Шлюз безопасности


Шлюз безопасности Хост 4
VPN-туннель (IPSec) Хост 5
Зашифрован Хост 6

После установления VPN-туннеля происходит следующее.


 Пакет покидает хост-источник и достигает шлюза безопасности.
 Шлюз безопасности зашифровывает пакет.
 Пакет по VPN-туннелю следует ко второму шлюзу безопасности. Фактически, речь идет о стандартных IP-
пакетах, проходящих через среду Интернет. Однако, поскольку пакеты зашифрованы, мы считаем их
проходящими через частный «виртуальный» туннель.
 Второй шлюз безопасности расшифровывает пакеты.
 Пакет в расшифрованном виде доставляется адресату. С точки зрения хостов, между ними происходит
прямое соединение.
Подробнее о согласовании IKE см. раздел IPSec и IKE (стр. 9)

VPN-сообщества
Создание VPN-туннелей между шлюзами безопасности облегчается за счет настройки VPN-сообществ. VPN-
сообщество – это набор шлюзов, включенных в VPN, способных взаимодействовать посредством VPN-
туннелей.
Чтобы лучше понять концепцию VPN-сообществ, введем некоторую терминологию.
 Член VPN-сообщества. Шлюз безопасности, пребывающий на одном из концов VPN-туннеля.
 VPN-домен. Хосты, находящиеся за шлюзом безопасности. VPN-доменом может оказаться целая сеть,
лежащая позади шлюза безопасности, или часть этой сети. Например, шлюз безопасности может
защищать корпоративную локальную сеть и DMZ. Есть смысл называть VPN-доменом только
корпоративную локальную сеть.
 VPN-узел. Член сообщества со своим VPN-доменом. Типичным примером VPN-узла является отделение
банка.
 VPN-сообщество. Набор туннелей/линий связи и прочих атрибутов VPN.
 VPN на основе доменов. Маршрутизация трафика VPN основывается на домене шифрования позади
каждого шлюза безопасности сообщества. В звездообразном сообществе сателлитные шлюзы
безопасности могут взаимодействовать между собой через центральные шлюзы безопасности.

Руководство администратора VPN R75.40VS | 26


Введение в VPN Site-to-Site

 VPN на основе маршрутов. Маршрутизация трафика внутри VPN-сообщества основывается на


маршрутной информации, статической или динамической, которая задается в операционных системах
шлюзов безопасности.

VPN-домен
VPN-узел
Члены сообщества
VPN-туннель

VPN-сообщество

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

Сообщество с удаленным доступом


Сообщество с удаленным доступом – это тип VPN-сообщества, создаваемый специально для пользователей,
обычно работающих из удаленных пунктов вне корпоративной локальной сети. Такой тип сообщества
обеспечивает безопасную связь между пользователями и корпоративной локальной сетью. Подробнее см.
раздел «VPN с удаленным доступом» (стр. 44).

Проверка подлинности между членами сообщества


Прежде чем шлюзы безопасности смогут обмениваться шифровальными ключами и выстраивать VPN-
туннели, они должны аутентифицировать друг друга – взаимно проверить подлинность. Шлюзы безопасности
проверяют друг друга, предъявляя один из двух типов «документов».
 Сертификаты. Каждый шлюз безопасности предъявляет сертификат, содержащий собственно
идентифицирующую информацию и открытый ключ шлюза безопасности. И сертификат, и ключ имеют
подпись доверенного центра сертификации. Для удобства в комплект продукции Check Point входит
собственный внутренний центр сертификации ICA, устанавливаемый с целью автоматической выдачи
сертификатов всем внутренним шлюзам безопасности, не требующим настройки пользователя. К тому
же, пакет продукции Check Point поддерживает прочие решения PKI. Подробнее см. раздел
«Инфраструктура открытого ключа» (на стр. 48).
 Общий секретный ключ (pre-shared secret). Общий – значит, определенный для пары шлюзов
безопасности. Каждый шлюз безопасности подтверждает, что знает условленный общий секретный ключ.
Таковым ключом может быть набор букв и цифр, некоторый пароль.
Из соображений защищенности сертификаты оказываются предпочтительнее. К тому же этот тип проверки
подлинности удобнее, поскольку внутренний центр сертификации на Сервере управления защитой
автоматически снабжает сертификатом каждый шлюз безопасности Check Point, им управляемый.

Руководство администратора VPN R75.40VS | 27


Введение в VPN Site-to-Site

Впрочем, если VPN-туннель требуется создать со шлюзом безопасности, управляемым извне (шлюз,
управляемый другим Сервером управления защитой), то возможны два варианта.
 Шлюз безопасности, управляемый извне, поддерживает сертификаты, но выданные внешним центром
сертификации – тогда каждому шлюзу безопасности придется доверять центру сертификации другого
шлюза безопасности. Подробнее см. раздел «Настройка VPN со шлюзами безопасности, управляемыми
извне, посредством PKI» (на стр. 41).
 Шлюз безопасности, управляемый извне, не поддерживает сертификаты – в данном случае VPN
поддерживает использование общего секретного ключа. Подробнее см. раздел «Настройка VPN со
шлюзами безопасности, управляемыми извне, посредством общего секретного ключа» (на стр. 44).
«Секретный ключ» определяется для каждого внешнего шлюза безопасности. Если имеется пять
внутренних шлюзов безопасности и два внешне управляемых шлюза безопасности, то формируется два
общих секретных ключа. Два общих секретных ключа используются пятью шлюзами безопасности,
управляемыми изнутри. Иначе говоря, все шлюзы безопасности, управляемые изнутри, при связи с
отдельным шлюзом безопасности, управляемым извне, используют один и тот же общий секретный ключ.

Топологии VPN
Самая простая топология состоит из двух шлюзов безопасности, способных создать между собой VPN-
туннель. Сервер управления защитой, поддерживающий более сложные технологии, позволяет создание
VPN-сообществ под конкретные цели организации. Сервер управления защитой поддерживает два основных
типа топологии:
 ячеистая;
 звездообразная.

Ячеистое VPN-сообщество
В VPN-сообществе с ячеистой топологией VPN-узел может создать VPN-туннель с любым другим VPN-узлом
сообщества:

Шлюз безопасности

Звездообразное VPN-сообщество
VPN-сообщество с топологией типа «звезда» состоит из центральных шлюзов безопасности
(«концентраторов») и сателлитных шлюзов безопасности («лучей»). В этом типе топологии сателлитный
шлюз может образовывать туннель только с узлами, чьи шлюзы безопасности определены как центральные.

Руководство администратора VPN R75.40VS | 28


Введение в VPN Site-to-Site

Сателлитный шлюз
Центральные шлюзы

ячеистая

Сателлитный шлюз безопасности не может образовать VPN-туннель со шлюзом безопасности, который также
определен как сателлитный.
Центральные шлюзы безопасности могут образовывать VPN-туннели с другими центральными шлюзами
безопасности только в том случае, если выбрана опция Соединять центральные шлюзы безопасности
ячеистой сетью (Mesh center Security Gateway) на странице Центральные шлюзы безопасности окна
Свойства звездообразного сообщества.

Шлюзы безопасности с динамическим присвоением IP


Шлюз безопасности с динамическим присвоением IP (DAIP) – это шлюз безопасности, в котором IP-адрес
внешнего интерфейса динамически присваивается ISP. Создание VPN-туннеля со шлюзами безопасности
DAIP поддерживается только при аутентификации сертификатами. Шлюзы безопасности идентифицируют
шлюзы безопасности DAIP, управляемые изнутри, посредством DN сертификата. Шлюзы безопасности
идентифицируют шлюзы безопасности DAIP, управляемые извне, и сторонние шлюзы безопасности DAIP при
помощи конфигурации Критериев соответствия.
Шлюзы безопасности DAIP могут инициировать VPN-туннель со шлюзами безопасности не-DAIP. Однако, в
силу того, что внешний IP-адрес шлюза безопасности DAIP постоянно меняется, другие шлюзы безопасности
не могут заранее знать, по какому IP-адресу следует связываться с данным шлюзом безопасности DAIP. В
результате обычный шлюз безопасности не может образовать VPN-туннель со шлюзом безопасности DAIP,
если DNS Resolving не настроен на шлюз безопасности DAIP. Подробнее см. раздел «Выбор линии связи»
(стр. 86).
Если IP-адрес шлюза безопасности DAIP изменяется во время сеанса, повторное согласование IKE будет
выполняться с использованием нового IP-адреса.
В звездообразном сообществе при настроенной маршрутизации VPN шлюзы безопасности DAIP не могут
инициировать соединения с внешних IP через центральный шлюз (или шлюзы) безопасности с другими
шлюзами безопасности DAIP или с узлами в Интернете. При данной конфигурации поддерживается
установление соединений со стороны домена шифрования DAIP.

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

Руководство администратора VPN R75.40VS | 29


Введение в VPN Site-to-Site

безопасности, являющиеся частью сети, управляемой изнутри; шлюзы безопасности партнеров компании к
ней не допускаются.
Топология VPN «звезда» обычно приемлема для организаций, для которых важен обмен информацией с
сетями, принадлежащими внешним партнерам. Эти партнеры должны взаимодействовать с нашей
компанией, но не между собой. Шлюз безопасности организации определяется как центральный, а
партнерские шлюзы безопасности – как сателлитные.
Более сложная ситуация: у компании есть центральные офисы в двух странах: в Великобритании (Лондон) и в
США (Нью-Йорк). У каждого центрального офиса есть ряд филиалов. Филиалы должны взаимодействовать
только с тем центральным офисом, который находится с ними в одной стране; при этом они не связываются
друг с другом. Между центральными офисами в Нью-Йорке и Лондоне должна быть налажена прямая связь.
Для реализации такой политики, определим два звездообразных сообщества – лондонское и нью-йоркское.
Лондонский и нью-йоркский шлюзы безопасности настроим как «центральные». Шлюзы безопасности во всех
филиалах будут выступать «сателлитными». Это даст возможность филиалам взаимодействовать с
центральными офисами у себя в стране. А теперь создадим третье VPN-сообщество с ячеистой топологией,
включающее лондонский и нью-йоркский шлюзы безопасности.

Лондон – Нью-Йорк, ЯЧЕИСТАЯ

Лондон, ЗВЕЗДА
Нью-Йорк, ЗВЕЗДА

Проблемы с топологией и шифрованием


Проблемы с топологией или шифрованием могут возникать вследствие корпоративной политики
безопасности. Например, в стране пребывания филиала организации может быть принята национальная
политика относительно шифрования информации. Например, принята политика, обуславливающая, что
шлюзы безопасности Вашингтона должны взаимодействовать, используя для шифрования 3DES. Политика
Лондона предусматривает в качестве алгоритма шифрования при взаимодействии шлюзов безопасности
алгоритм DES.

Кроме того, шлюзы безопасности Вашингтона и Лондона должны связываться между собой, используя более
слабый DES. Рассмотрим решение:

Руководство администратора VPN R75.40VS | 30


Введение в VPN Site-to-Site

Вашингтон, ячеистая

Все шлюзы Вашингтона взаимодействуют со всеми шлюзами Лондонской звезды.

Лондон, звезда с ячеистым центром

В данном решении шлюзы безопасности ячеистой сети Вашингтона также определены как сателлиты
Лондонской звездообразной сети. В Лондонской звезде центральные шлюзы безопасности связаны ячеистой
сетью. Шлюзы безопасности Вашингтона образуют VPN-туннели с шлюзами безопасности Лондона,
используя DES. При внутреннем взаимодействии шлюзы безопасности Вашингтона строят VPN-туннели,
используя 3DES.

Особое условие для шлюзов безопасности VPN


Каждый шлюз безопасности сам по себе может входить во многие VPN-сообщества; однако, два шлюза
безопасности, способные образовать между собой линию связи VPN в одном VPN-сообществе, не могут
входить в другое VPN-сообщество, в котором они тоже могут создать линию связи. Например:

Руководство администратора VPN R75.40VS | 31


Введение в VPN Site-to-Site

Лондон ЯЧЕИСТАЯ СЕТЬ ЛОНДОН–НЬЮ-ЙОРК

Нью-Йорк Париж

Шлюзы безопасности Лондона и Нью-Йорка принадлежат VPN-сообществу Лондон – Нью-Йорк с ячеистой


топологией. Создание дополнительного VPN-сообщества, включающего Лондон, Нью-Йорк и Париж,
запрещено. Шлюзы безопасности Лондона и Нью-Йорка не могут «вместе» войти в более, чем одно VPN-
сообщество.

Два шлюза безопасности, способных создать между собой линию связи VPN в одном сообществе, могут
войти в другое VPN-сообщество при условии, что во втором VPN-сообществе они неспособны создать между
собой линию связи. Например:

Лондон ЯЧЕИСТАЯ СЕТЬ ЛОНДОН–НЬЮ-ЙОРК

Нью-Йорк Париж, ЗВЕЗДА

Руководство администратора VPN R75.40VS | 32


Введение в VPN Site-to-Site

Шлюзы безопасности Лондона и Нью-Йорка входят в ячеистую сеть Лондон – Нью-Йорк. Эти два шлюза
безопасности, кроме того, входят в качестве сателлитных в VPN-сообщество со звездообразной топологией с
центром в Париже. Исходя из топологии, сателлитные шлюзы безопасности (в Лондоне и в Нью-Йорке) могут
взаимодействовать только с центральным шлюзом безопасности Парижа. Поскольку шлюзы безопасности
Лондона и Нью-Йорка не могут открыть между собой линию связи VPN, такая конфигурация возможна.

Контроль доступа и VPN-сообщества


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

Конфигурация шлюзов безопасности в VPN-сообщество означает, что если политика контроля доступа
разрешает этим шлюзам безопасности взаимодействовать, то связь будет зашифрована. Контроль доступа
настраивается в базе правил политики безопасности.

Работая со столбцом VPN базы правил политики безопасности, можно создать правила доступа,
относящиеся только к членам VPN-сообщества. Например:

Источник Адресат VPN Служба Действие

Любой Любой Community_A HTTP Принять

Связь возможна лишь при выполнении всех условий правила: это должно быть HTTP-соединение между IP-
адресами источника и адресата в рамках VPN-сообщества. При невыполнении любого их этих условий
правило будет работать как запрет. Если выполняются все условия, тогда правило разрешает установление
связи.

Правило из базы правил политики безопасности может подходить для обоих VPN-сообществ и хост-машин,
не принадлежащих сообществу. Например:

VPN-узел Внутренний Веб-сервер

Хост 1 Шлюз безопасности 2

Шлюз безопасности 1 Интернет

Правило в базе правил политики безопасности допускает HTTP-соединение между любым внутренним IP и
любым другим IP:

Источник Адресат VPN Служба Действие

Любая_внутренняя_машина Любой Любая HTTP Принять

Руководство администратора VPN R75.40VS | 33


Введение в VPN Site-to-Site

Под это правило подходит HTTP-соединение между хостом 1 и внутренним веб-сервером позади шлюза
безопасности 2. Соединение между хостом 1 и веб-сервером в Интернете также не противоречит данному
правилу; а соединение между хостом 1 и внутренним веб-сервером – это соединение между членами VPN-
сообщества, проходящее в зашифрованном виде; соединение между хостом 1 и веб-сервером в Интернете
проходит в открытом виде.
В обоих случаях соединение просто удовлетворяет правилу политики безопасности; зашифровано
соединение или нет – оно рассматривается на уровне VPN. VPN – это другой уровень защиты, отдельный
от уровня контроля доступа.

Прием всего зашифрованного трафика


Если на странице Общие (General) окна Свойства VPN-сообщества выбрать Принимать весь
зашифрованный трафик (Accept all encrypted traffic), в базу правил политики безопасности будет
добавлено новое правило. Это ни обычное правило, ни подразумеваемое. Это автоматическое правило
сообщества, оно выделяется среди прочих бежевым фоном.

Маршрутизация трафика в VPN-сообществе


VPN-маршрутизация обеспечивает управление трафиком в VPN. Существует два метода VPN-
маршрутизации:
 VPN на основе доменов;
 VPN на основе маршрутов.

VPN на основе доменов


Данный метод направляет VPN-трафик на основании домена шифрования за каждым шлюзом безопасности
сообщества. В звездообразном сообществе такой метод позволяет сателлитным шлюзам безопасности
взаимодействовать друг с другом через центральные шлюзы безопасности. Конфигурация VPN на основе
доменов выполняется прямо через SmartDashboard. Подробнее см. раздел «VPN на основе доменов» (на стр.
62).

VPN на основе маршрутов


Трафик в пределах VPN-сообщества направляется согласно маршрутной информации, статической или
динамической, которая задается в операционных системах шлюзов безопасности. Подробнее см. раздел
«VPN на основе маршрутов» (на стр. 71).
Примечание. Если настроены и VPN на основе доменов, и VPN на основе маршрутов,
приоритет будет иметь VPN на основе доменов.

Исключенные службы
В окне Свойства VPN-сообществ (VPN Communities Properties) на странице Исключенные службы
(Excluded
Services) можно выбрать службы, которые не следует шифровать, например, контрольные соединения
брандмауэра. Нешифрованная служба предусматривает отсутствие формирования VPN-туннеля для этого
соединения. Подробнее о контрольных соединениях см. «Как авторизовать управляющие соединения
брандмауэра в VPN-сообществах» (на стр. 45). Обратите внимание, что исключенные службы не
поддерживаются при использовании VPN на основе маршрутов.

Особенности планирования топологии VPN


При планировании топологии VPN важно знать ответы на следующие вопросы.
1. Кому необходим безопасный/частный доступ?
2. С точки зрения VPN, какова будет структура организации?
3. Шлюзы безопасности, управляемые изнутри проверяют подлинность друг друга посредством
сертификатов. Как будет проходить проверка подлинности шлюзов безопасности, управляемых
снаружи?
 Поддерживают ли эти шлюзы безопасности, управляемые снаружи, PKI?
 Какому центру сертификации следует доверять?

Конфигурация VPN Site-to-Site


VPN-сообщества модно настраивать в традиционном или упрощенном режиме. В традиционном режиме
одним из действий, доступных в базе правил политики безопасности, является Зашифровать. Когда выбрано

Руководство администратора VPN R75.40VS | 34


Введение в VPN Site-to-Site

это действие, весь трафик между шлюзами безопасности шифруется. Шлюзы безопасности Check Point
настраиваются легче посредством использования VPN-сообществ – это и есть упрощенный режим.
Подробнее о традиционном режиме см. раздел «VPN традиционного режима» (на стр. 144).

Переход из традиционного режима в упрощенный


Для перехода из традиционного режима в упрощенный (подробнее см. раздел «Преобразование
традиционной политики в политику на основе сообщества» (на стр. 151)):
Выберите Политика > Преобразовать в > Упрощенная VPN (Policy > Convert to > Simplified VPN).
ИЛИ
1. На странице Глобальные свойства > VPN выберите Традиционный режим для всех новых политик
безопасности (Traditional mode to all new Security Policies) или Новая политика безопасности
традиционного либо упрощенного режима (Traditional or Simplified per new Security Policy), а затем
Файл > Сохранить. Если не сохранить изменения, система предложит вам сделать это. Щелкните ОК.
1. Файл > Новый… Откроется окно Новый пакет политик.
2. Назовите новый пакет политики безопасности и выберите Брандмауэр и трансляция адреса.
В базе правил политики безопасности появится новый столбец VPN, а в столбце Действие вариант
Зашифровать будет более недоступен. Теперь вы работаете в упрощенном режиме.

Настройка ячеистого сообщества между шлюзами,


управляемыми изнутри
VPN-сообщества, управляемые изнутри, могут иметь одну из двух допустимых топологий: ячеистую и
звездообразную. Для настройки ячеистого VPN-сообщества, управляемого изнутри, создайте шлюзы
безопасности и добавьте их в сообщество.
1. В дереве Сетевые объекты щелкните правой кнопкой
Сетевые объекты > Новый > Check Point > Шлюз безопасности… Выберите Простой режим
(мастер) или Классический режим. Откроется окно Свойства шлюза безопасности Check Point.
a) На странице Общие свойства после наименования
объекта и присвоения ему IP-адреса выберите VPN и установите SIC-связь.
b) На странице Топология щелкните Добавить, чтобы
добавить интерфейсы. Когда интерфейс появится в таблице, нажмите Редактировать…, чтобы
открыть окно Свойства интерфейса.
c) В окне Свойства интерфейса определите общие
свойства интерфейса и топологию сети за ним.
d) На странице Топология, в части VPN-домен
определите VPN-домен как все машины позади шлюзом безопасности на основе информации о
топологии или задайте их вручную:
(i) в виде диапазона адресов;
(ii) в виде сети;
(iii) в виде группы, являющейся комбинацией диапазонов
адресов, сетей и даже других групп.
(Существуют случаи, когда VPN-домен – это группа, содержащая только лишь шлюз безопасности,
например, когда шлюз безопасности выступает в качестве резервного шлюза для основного шлюза
безопасности в среде МЕР).
Теперь сетевые шлюзовые объекты настроены, пора добавить их в VPN-сообщество.
Примечание. На странице VPN нечего настраивать, ведь шлюзы безопасности, управляемые
изнутри, получают сертификаты автоматически от внутреннего центра сертификации.
2. В дереве Сетевые объекты выберите вкладку VPN-
сообщества.
a) Щелкните правой кнопкой Site-to-Site.
b) Из контекстного меню выберите Новая Site-to-Site… >
Ячеистая. Откроется окно Свойства ячеистых сообществ.
c) На странице Общие выберите Принимать весь
зашифрованный трафик, если весь трафик между шлюзами безопасности должен быть
зашифрован. В противном случае с базе правил политики безопасности создайте подходящие
правила, которые допускали бы передачу зашифрованного трафика между членами сообщества.
d) На странице Участвующие шлюзы безопасности
добавьте шлюзы безопасности, созданные на шаге 1.
Теперь VPN-туннель настроен. Подробнее о прочих опциях, таких как Свойства VPN, Дополнительные
свойства, Общий секретный ключ, см. раздел «IPSec и IKE» (на стр. 14).
3. Если вы не выбрали в сообществе Принимать весь
зашифрованный трафик, постройте политику контроля доступа, например:

Руководство администратора VPN R75.40VS | 35


Введение в VPN Site-to-Site

Источник Адресат VPN Служба Действие

Любой Любой Ячеистое Любая Принять


сообщество

Ячеистое сообщество – это VPN-сообщество, которое вы только что определили.

Настройка звездообразного VPN-сообщества


VPN-сообщество со звездообразной топологией настраивается преимущественно так же, как и ячеистое
сообщество. Разница состоит в опциях, содержащихся в окне Свойства звездообразного сообщества.
 На странице Общие > Дополнительные настройки > VPN-маршрутизация выберите Только в центр.
 На странице Центральные шлюзы безопасности нажмите Добавить…, чтобы добавить центральные
шлюзы.
 На странице Центральные шлюзы безопасности выберите Соединять центральные шлюзы
безопасности ячеистой сетью (Mesh central Security Gateways), если вы хотите, чтобы центральные
шлюзы безопасности взаимодействовали между собой.
 На странице Сателлитные шлюзы безопасности нажмите Добавить…, чтобы добавить сателлитные
шлюзы безопасности.

Подтверждение успешного открытия VPN-туннеля


Чтобы убедиться в успешном открытии VPN-туннеля:
1. Отредактируйте правило VPN и выберите Журнал как параметр отслеживания.
2. Откройте соответствующее соединение.
3. Откройте SmartView Tracker и изучите записи журнала. Успешное соединение оказывается
зашифрованным.

Настройка VPN со шлюзами безопасности,


управляемыми извне, посредством PKI
Настройка VPN с внешними шлюзами безопасности (которые управляются другим Сервером управления
защитой) более сложна, чем настройка VPN с внутренними шлюзами безопасности (которые управляются тем
же Сервером управления защитой). Причиной тому являются следующие факторы.
 Настройка осуществляется отдельно в двух разных системах.
 Администраторы должны согласовать и скоординировать между собой все подробности. Такие детали,
как IP-адрес или топология VPN-домена не обнаруживаются автоматически, их должны вручную
передать администраторы соответствующих шлюзов безопасности VPN.
 Скорее всего, шлюзы безопасности используют разные центры сертификации (СА). Даже если оба
шлюза безопасности получают сертификаты от внутренних СА (ICA), это все равно разные СА.
В случае шлюзов безопасности, управляемых извне, возможно несколько путей настройки. Ниже попытаемся
очертить типичные ситуации; будем считать, что узлы работают с сертификатами. Если это не так, см. пункт
«Настройка VPN со шлюзами безопасности, управляемыми извне, посредством общего секретного ключа»
(на стр. 44).
Примечание. Настройка VPN с помощью PKI и сертификатов более надежна, чем посредством
общих секретных ключей.
Хотя выбор типа сообщества предоставлен администратору, для VPN со шлюзами безопасности,
управляемыми извне, звездообразная топология является более естественной. Внутренние шлюзы
безопасности определяются как центральные шлюзы, а внешние – как сателлитные. Решение о
необходимости соединения центральных, внутренних шлюзов безопасности в ячеистую сеть принимается,
исходя из требований организации. Эта типичная топология приведена на диаграмме ниже.
Обратите внимание, что это – топология с точки зрения администратора шлюзов безопасности А1 и А2.
Администратор шлюзов безопасности В1 и В2 тоже может определить звездообразную топологию, однако,
для него В1 и В2 будут центральными шлюзами безопасности, а А1 и А2 – сателлитными.

Руководство администратора VPN R75.40VS | 36


Введение в VPN Site-to-Site

Шлюз безопасности В1 (Внешний, сателлитный)


Шлюз безопасности А1 (Внутренний, центральный)

Шлюз безопасности А2 (Внутренний, центральный)


Шлюз безопасности В2 (Внешний, сателлитный)
Соединены в ячеистую сеть

Инструкции по настройке требуют понимания того, как строится VPN. Подробнее об этом см. в разделе
«Введение в VPN Site-to-Site» (на стр. 28).
Кроме того, вам понадобится понимание конфигурации PKI. См. «Инфраструктура открытого ключа» (на стр.
48).

Настройка VPN звездообразной топологии, использующей сертификаты,


содержащей внешние шлюзы безопасности в качестве сателлитных.
1. У администратора другой сети получите сертификат, выданный центром сертификации
противоположным шлюзам безопасности VPN. Если противоположный шлюз безопасности использует
ICA, сертификат центра сертификации можно получить через веб-браузер по адресу:
http://<IP-адрес противоположного шлюза безопасности или Сервера управления защитой>:18264
2. В SmartDashboard определите СА-объект для СА, выдавшей сертификат противоположному узлу. См.
«Регистрация центра сертификации» (на стр. 53).
3. Определите СА, который будет сертифицировать вашу сторону, если сертификат, выданный ICA, не
подойдет для требуемого VPN-туннеля.
Возможно, придется экспортировать сертификат СА и передать его администратору противоположного
узла.
4. Определите сетевой объект (или объекты) шлюза (или шлюзов) безопасности, управляемых изнутри. В
частности, будьте готовы сделать следующее:
 На странице Общие свойства шлюзового объекта выберите VPN.
 На странице Топология определите Топологию и VPN-домен. Если в VPN-домен не входят все IP-
адреса за шлюзом безопасности, определите VPN-домен вручную, задав группу или сеть машин и
настроив их как VPN-домен.
5. Если для VPN-туннеля не подходит сертификат ICA, на странице VPN сгенерируйте сертификат от
подходящего центра сертификации (см. «Регистрация центра сертификации» (на стр. 53)).
6. Определите сетевой объект (или объекты) для шлюзов безопасности, управляемых извне.
 Если шлюз безопасности не производства Check Point, определите объект Совместимое устройство:
Управление > Сетевые объекты… > Новый… > Совместимый объект… (Manage > Network
Objects… > New… > Interoperable Device…)
 Если шлюз безопасности производства Check Point, в дереве Сетевые объекты щелкните правой
кнопкой и выберите Новый > Check Point > Шлюз безопасности, управляемый извне… (New >
Check Point > Externally Managed Security Gateway…)
7. Задайте различные атрибуты противоположного шлюза безопасности. В частности, сделайте
следующее.
 На странице Общие свойства шлюза безопасности выберите VPN (только для объекта Check Point,
управляемого извне).
 На странице Топология определите Топологию и VPN-домен, используя информацию о VPN-
домене, полученную от администратора другой сети. Если в VPN-домен не входят все IP-адреса за
шлюзом безопасности, определите VPN-домен вручную, задав группу или сеть машин и настроив
их как VPN-домен.

Руководство администратора VPN R75.40VS | 37


Введение в VPN Site-to-Site

 На странице VPN определите Критерии соответствия (Matching criteria), укажите, что


противоположный узел должен предоставить сертификат, подписанный его собственным центром
сертификации. Если этого мало, оговорите подробности, которые должны содержаться в
сертификате.
8. Определите сообщество. Ниже примем, что выбрано сообщество со звездообразной топологией;
впрочем, можно выбрать и ячеистое сообщество. При работе с ячеистой топологией следует
проигнорировать разницу между центральными и сателлитными шлюзами безопасности.\
 Согласуйте с администратором другой сети различные свойства IKE и задайте их на странице
Свойства VPN и на странице Дополнительные свойства объекта сообщества.
 Определите центральные шлюзы безопасности. Обычно это те шлюзы, которые управляются
изнутри. Если для них не определено другое сообщество, примите решение о необходимости
соединения центральных шлюзов безопасности ячеистой сетью. Если центральные шлюзы
безопасности уже состоят в сообществе, не связывайте их.
 Определите сателлитные шлюзы безопасности. Обычно это внешние шлюзы.
9. Определите релевантные правила доступа в политике безопасности. Добавьте сообщество в столбец
VPN, службы – в столбец Службы, желаемое Действие и соответствующий Параметр отслеживания.
10. Установите политику безопасности.

Настройка VPN со шлюзами безопасности,


управляемыми извне, посредством общего
секретного ключа
Настройка VPN с внешними шлюзами безопасности (которые управляются другим Сервером управления
защитой) более сложна, чем настройка VPN с внутренними шлюзами безопасности (которые управляются тем
же Сервером управления защитой). Причиной тому являются следующие факторы.
 Настройка осуществляется отдельно в двух разных системах.
 Администраторы должны согласовать и скоординировать между собой все подробности. Такие детали,
как IP-адрес или топология VPN-домена не обнаруживаются автоматически, их должны вручную
передать администраторы соответствующих шлюзов безопасности VPN.
В случае шлюзов безопасности, управляемых извне, возможно несколько путей настройки. Ниже попытаемся
очертить типичные ситуации; будем считать, что узлы работают с общими секретными ключами. Если это не
так, см. пункт «Настройка VPN со шлюзами безопасности, управляемыми извне, посредством PKI» (на стр.
41).
Примечание. Настройка VPN с помощью PKI и сертификатов более надежна, чем посредством
общих секретных ключей.
Хотя выбор типа сообщества предоставлен администратору, для VPN со шлюзами безопасности,
управляемыми извне, звездообразная топология является более естественной. Внутренние шлюзы
безопасности определяются как центральные шлюзы, а внешние – как сателлитные. Решение о
необходимости соединения центральных, внутренних шлюзов безопасности в ячеистую сеть принимается,
исходя из требований организации. Эта типичная топология приведена на диаграмме ниже.
Обратите внимание, что это – топология с точки зрения администратора шлюзов безопасности А1 и А2.
Администратор шлюзов безопасности В1 и В2 тоже может определить звездообразную топологию, однако,
для него В1 и В2 будут центральными шлюзами безопасности, а А1 и А2 – сателлитными.

Шлюз безопасности В1
(Внешний, сателлитный)

Шлюз безопасности А1
(Внутренний, центральный)
Шлюз безопасности А2
(Внутренний, центральный)

Шлюз безопасности В2
(Внешний, сателлитный)
Соединены в ячеистую сеть

Руководство администратора VPN R75.40VS | 38


Введение в VPN Site-to-Site

Инструкции по настройке требуют понимания того, как строится VPN. Подробнее об этом см. в разделе
«Введение в VPN Site-to-Site» (на стр. 28).

Настройка VPN звездообразной топологии, использующей общие секретные


ключи, содержащей внешние шлюзы безопасности в качестве сателлитных.
1. Определите сетевой объект (или объекты) шлюза (или шлюзов) безопасности, управляемых изнутри. В
частности, будьте готовы сделать следующее:
 На странице Общие свойства шлюзового объекта выберите VPN.
 На странице Топология определите Топологию и VPN-домен. Если в VPN-домен не входят все IP-
адреса за шлюзом безопасности, определите VPN-домен вручную, задав группу или сеть машин и
настроив их как VPN-домен.
2. Определите сетевой объект (или объекты) для шлюзов безопасности, управляемых извне.
 Если шлюз безопасности не производства Check Point, определите объект Совместимое устройство:
Управление > Сетевые объекты… > Новый… > Совместимый объект… (Manage > Network
Objects… > New… > Interoperable Device…)
 Если шлюз безопасности производства Check Point, в дереве Сетевые объекты щелкните правой
кнопкой и выберите Новый > Check Point > Шлюз безопасности, управляемый извне… (New >
Check Point > Externally Managed Security Gateway…)
3. Задайте различные атрибуты противоположного шлюза безопасности. В частности, сделайте
следующее.
 На странице Общие свойства шлюза безопасности выберите VPN (только для объекта Check Point,
управляемого извне).
 На странице Топология определите Топологию и VPN-домен, используя информацию о VPN-
домене, полученную от администратора другой сети. Если в VPN-домен не входят все IP-адреса за
шлюзом безопасности, определите VPN-домен вручную, задав группу или сеть машин и настроив
их как VPN-домен.
4. Определите сообщество. Ниже примем, что выбрано сообщество со звездообразной топологией;
впрочем, можно выбрать и ячеистое сообщество. При работе с ячеистой топологией следует
проигнорировать разницу между центральными и сателлитными шлюзами безопасности.\
 Согласуйте с администратором другой сети различные свойства IKE и задайте их на странице
Свойства VPN и на странице Дополнительные свойства объекта сообщества.
 Определите центральные шлюзы безопасности. Обычно это те шлюзы, которые управляются
изнутри. Если для них не определено другое сообщество, примите решение о необходимости
соединения центральных шлюзов безопасности ячеистой сетью. Если центральные шлюзы
безопасности уже состоят в сообществе, не связывайте их.
 Определите сателлитные шлюзы безопасности. Обычно это внешние шлюзы.
5. Согласуйте с администратором внешних членов сообщества общий секретный ключ. Затем на странице
Общий секретный ключ сообщества выберите Использовать только общий секретный ключ для
всех внешних членов (Use Only Shared Secret for all External Members). Для каждого внешнего узла
следует задать общий секретный ключ.
6. Определите релевантные правила доступа в политике безопасности. Добавьте сообщество в столбец
VPN, службы – в столбец Службы, желаемое Действие и соответствующий Параметр отслеживания.
7. Установите политику безопасности.

Как авторизовать управляющие соединения


брандмауэра в VPN-сообществах
Узлы Check Point взаимодействуют между собой при помощи управляющих соединений. Например,
управляющее соединение используется при установке политики безопасности с Сервера управления защиты
на шлюз безопасности. По управляющим соединениям на сервер управления защитой отправляются
журналы с шлюзов безопасности. Управляющие соединения применяют протокол SIC – Secure Internal
Communication (Безопасная внутренняя связь).
Управляющие соединения руководствуются неявными правилами базы правил безопасности. Неявные
правила добавляются в базу правил безопасности или изымаются из нее путем выбора опций на странице
Неявные правила брандмауэра Глобальных свойств SmartDashboard.
Некоторые администраторы предпочитают не полагаться на неявные правила, определяя в базе правил явно
выраженные правила.

Почему отключение неявных правил брандмауэра блокирует


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

Руководство администратора VPN R75.40VS | 39


Введение в VPN Site-to-Site

Сервер управления защитой Шлюз безопасности А

Попытка согласования IKE Шлюз безопасности В

Администратор хочет настроить VPN между шлюзами безопасности А и В, настроив SmartDashboard. Для
этого администратору необходимо установить политику с Сервера управления защитой на шлюзы
безопасности.
1. Сервер управления защитой успешно устанавливает политику на шлюз безопасности А. Поскольку мы
задействовали шлюз А, шлюзы безопасности А и В теперь принадлежат одному и тому же VPN-
сообществу. Впрочем, на В еще не установлена политика.
2. Сервер управления защитой пытается открыть связь с шлюзом безопасности В, чтобы установить
политику.
3. Шлюз безопасности А допускает соединение, поскольку оно удовлетворяет явно заданным правилам
для управляющих соединений, и начинает согласование IKE с шлюзом безопасности В, чтобы
сформировать VPN-туннель для управляющего соединения.
4. Шлюз безопасности В не знает, как взаимодействовать с А – у него ведь до сих пор нет политики. Таким
образом, установка политики на шлюз безопасности В не получается.
В качестве решения проблемы можно сделать так, чтобы управляющие соединения не проходили сквозь
VPN-туннель.

Разрешение брандмауэром управляющих соединений внутри


VPN
Выключая неявные правила, следует убедиться, что шлюзы безопасности не изменили управляющие
соединения. Для этого добавьте используемые для управляющих соединений службы на странице
Исключенные службы объекта сообщества.
Примечание. Хотя управляющие соединения между Сервером управления защитой и шлюзом
безопасности не шифруются сообществом, тем не менее, они зашифровываются и
аутентифицируются при помощи протокола SIC.

Определение служб, используемых для управляющих


соединений
1. В главном меню выберите Вид > Неявные правила (View > Implied Rules).
2. На странице Брандмауэр Глобальных свойств убедитесь, что принимаются «управляющие
соединения».
3. Изучите базу правил безопасности и выясните, какие неявные правила видны. Обратите внимание на
службы, используемые в неявных правилах.

Руководство администратора VPN R75.40VS | 40


Глава 4
Инфраструктура открытого ключа
В этой главе
НЕОБХОДИМОСТЬ ИНТЕГРАЦИИ С РАЗЛИЧНЫМИ РЕШЕНИЯМИ PKI ........................................................ 41
ПОДДЕРЖКА ШИРОКОГО СПЕКТРА РЕШЕНИЙ PKI ....................................................................................... 41
ОСОБЕННОСТИ PKI........................................................................................................................................... 48
НАСТРОЙКА ОПЕРАЦИЙ PKI ............................................................................................................................ 48
НАСТРОЙКА OCSP ............................................................................................................................................ 52

Необходимость интеграции с различными решениями


PKI
Решения PKI (Public Key Infrastructure – Инфраструктура открытого ключа) на основе Х.509 обеспечивают
инфраструктуру, в которой объекты устанавливают между собой доверительные отношения, основываясь на
обоюдном доверии центру сертификации (СА). Доверенный СА выдает объекту сертификат, включающий
открытый ключ объекта. Разные объекты, доверяющие СА, могут не сомневаться в подлинности сертификата
– ведь они могут проверить подпись СА. Они доверяют информации, указанной в сертификате, из которой
самое главное – связь объекта и открытого ключа.
Стандарты IKE рекомендуют в среде VPN использовать PKI, требующую строгой проверки подлинности.
Шлюз безопасности, участвующий в организации VPN? обязан иметь пару ключей RSA и сертификат от
доверенного СА. В сертификате указываются подробности о модуле, его открытый ключ, детали получения
списка отзыва сертификатов (CRL), и он подписывается СА.
Когда два объекта пытаются образовать VPN-туннель, каждая сторона предоставляет свои данные с
произвольной информацией, подписанные ее открытым ключом, и сертификат, содержащий открытый ключ.
Сертификат позволяет установить доверительные отношения между шлюзами безопасности: каждый шлюз
использует открытый ключ другого шлюза безопасности, чтобы проверить источник подписанной
информации, и открытый ключ СА, чтобы проверить подлинность сертификата. Иными словами, проверенный
сертификат применяется для проверки подлинности противоположного узла.
Каждое развертывание Сервера управления защитой Check Point включает в себя внутренний центр
сертификации (ICA), выдающий VPN-сертификаты тем модулям VPN, которыми он управляет. Эти VPN-
сертификаты упрощают определение сетей VPN между заданными модулями.
В сочетании с другими решениями PKI могут возникнуть такие ситуации.
 Необходимо организовать VPN с шлюзом безопасности, управляемым внешним Сервером управления
защитой. Например, противоположный шлюз безопасности принадлежит другой организации,
использующей продукты Check Point, а его сертификат подписан ICA его собственного Сервера
управления защитой.
 Необходимо организовать VPN с объектом, произведенным не Check Point. Тогда сертификат
противоположного узла подписан сторонним СА.
 По некоторым причинам руководство организации может решить для создания сертификатов для своих
шлюзов безопасности использовать сторонний СА.

Поддержка широкого спектра решений PKI


Шлюзы безопасности Check Point поддерживают множество разных сценариев интеграции PKI в среду VPN.
 Поддержка нескольких СА для одного VPN-туннеля. Два шлюза безопасности предоставляют
сертификаты, подписанные разными ICA.
 Поддержка невнутренних СА. Помимо ICA, шлюзы безопасности поддерживают следующие центры
сертификации:
 Внешние ICA – ICA другого Сервера управления защитой
 Прочие решения PKI, сертифицированные OPSEC
 Иерархия СА. Центры сертификации обычно формируют иерархическую структуру, в которой несколько
СА подчинены корневому центру. Подчиненный СА – это центр сертификации, сертифицированный
другим центром сертификации. Подчиненные СА могут сертифицировать другие СА, которые в свою
очередь подчинены им. Так образуется сертификационная цепочка или иерархия.
Инфраструктура открытого ключа

PKI и пользователи удаленного доступа


Пакет Check Point поддерживает сертификаты не только для шлюзов безопасности, но и для пользователей.
Подробнее о пользовательских сертификатах см. «VPN с удаленным доступом» (на стр. 158).

Развертывания PKI и VPN


Ниже указаны несколько примеров развертываний СА.
 Простое развертывание – внутренний СА.
 СА внешнего Сервера управления защитой
 Услуги СА, предоставляемые через Интернет
 СА по локальной сети

Простое развертывание – внутренний СА


Когда создается VPN-туннель между шлюзами безопасности, которые управляются одним и тем же Сервером
управления защитой, у каждого из них есть сертификат, выданный ICA Сервера управления защитой.

СА внешнего Сервера управления защитой


Если шлюз Check Point управляется внешним Сервером управления защитой (например, при установлении
VPN-туннеля с VPN-модулями другой организации), тогда у каждого узла есть сертификат, подписанный ICA
его собственного Сервера управления защитой.

ICA Сервера управления защитой А Интернет

Сертификат Сертификат
Сертификат Шлюз безопасности В

Шлюз безопасности А ICA Сервера управления защитой В

Шлюз безопасности

Сервер управления защитой А выдает сертификаты Серверу управления защитой В, который в свою очередь
предоставляет сертификаты шлюзу безопасности В.

Услуги СА, предоставляемые через Интернет


Если сертификат шлюза безопасности выдан сторонним СА, доступным через Интернет, операции СА
(регистрация или отзыв) обычно выполняются через HTTP-формы. Получение CRL происходит от HTTP-
сервера, служащего CRL-хранилищем.

Руководство администратора VPN R75.40VS | 42


Инфраструктура открытого ключа

Сертификат Интернет

Сертификат HTTP-сервер

Шлюз безопасности А Предоставитель услуги PKI

Шлюз безопасности В Центр сертификации

Шлюзы безопасности А и А получают сертификаты от предоставителя услуги PKI, который доступен через
Интернет. Сертификаты, выданные сторонними СА, могут использоваться шлюзами безопасности,
управляемыми одним и тем же Сервером управления защитой, в целях проверки.

СА в локальной сети
Если сертификат противоположного шлюза безопасности выдан сторонним СА по локальной сети, CRL
обычно загружается с внутреннего сервера LDAP, как показано на иллюстрации.

Руководство администратора VPN R75.40VS | 43


Инфраструктура открытого ключа

Центр сертификации Интернет


Сервер LDAP Сертификат

Сертификат Шлюз безопасности


Шлюз безопасности Сервер LDAP (Реплика)

Доверие внешнему СА
Доверительное отношение – необходимое условие создания VPN-туннеля. Однако, доверительные
отношения возможны лишь если СА, подписывающему сертификат противоположного узла, «доверяют».
Доверие СА означает получение и проверку собственного сертификата СА. После проверки сертификата СА,
указанные в нем подробности и его открытый ключ можно использовать для получения и проверки других
сертификатов, выданных этим СА.
Внутреннему СА (ICA) автоматически доверяют все модули, управляемые Сервером управления защитой,
которому СА принадлежит. Внешние СА (даже ICA внешнего Сервера управления защитой Check Point)
автоматическим доверием не пользуются, поэтому модуль вначале должен получить и подтвердить
сертификат внешнего СА. Внешний СА должен обеспечить способ импортирования своего сертификата на
сервер управления защитой.
Внешний СА может быть:
1. ICA внешнего Сервера управления защитой, подробнее см. «Руководство администратора Сервера
управления защитой R75.40VS» (http://supportcontent.checkpoint.com/solutions?id=sk76540);
2. СА, сертифицированным OPSEC; определите СА с помощью опций СА на вкладке Серверы и
приложения OPSEC и получите его сертификат.

Подчиненные центры сертификации


Подчиненный СА – это центр сертификации, сертифицированный другим центром сертификации.
Подчиненные СА могут выдавать сертификаты другим, более подчиненным СА, таким образом, формируя
сертификационную цепочку или иерархию. СА, находящийся на верхушке иерархии, называется корневым
центром или корневым СА. Дочерний СА корневого СА называются подчиненным центром сертификации.
При помощи опций СА на вкладке Серверы и приложения OPSEC можно определить любой СА как
доверенный или подчиненный. Подчиненные СА имеют тип OPSEC и не является доверенными .

Регистрация объекта управления


Регистрацией называется получение сертификата от СА; т. е., запрос СА на выдачу объекту сертификата.

Руководство администратора VPN R75.40VS | 44


Инфраструктура открытого ключа

Процесс регистрации начинается с генерации пары ключей. Впоследствии запрос на сертификат реализуется
из открытого ключа и дополнительной информации о модуле. Тип запроса на сертификацию и остальной
процесс регистрации зависит от типа СА.
Проще всего, когда речь идет о шлюзе безопасности, управляемом изнутри. В этом случае на машине, на
которой установлен Сервер управления защитой, располагается ICA. Процесс регистрации завершается
автоматически.
Чтобы получить сертификат от СА, сертифицированного OPSEC, Сервер управления защитой считывает
информацию о модуле, открытый ключ и зашифровывает запрос PRCS#10. Этот запрос (который может
включать SubjectAltName для сертификатов OPSEC и расширения для Расширенного использования ключей)
передается СА вручную администратором. После того, как СА выдает сертификат, администратор может
завершить процесс, импортировав сертификат на Сервер управления защитой.
Сертификат шлюза безопасности также можно получить с помощью Автоматической регистрации. В случае
Автоматической регистрации есть возможность автоматической посылки запроса на сертификат для шлюза
безопасности сообщества со стороны доверенного СА. Автоматическая регистрация поддерживает
следующие протоколы:
 SCEP
 CMPV1
 CMPV2
Примечание. Во время регистрации SCEP некоторые HTTP-запросы могут превышать 2К и быть
не пропущены механизмом проверки протокола HTTP, если последний включен (Web
Intelligence > Проверка протокола HTTP > Размеры форматов HTTP). Для получения
возможности передачи HTTP-запросов понадобится изменение значения по умолчанию. Если
регистрация не удается, выполните ее вручную. Подробнее см. «Руководство администратора
IPS R75.40VS» (http://supportcontent.checkpoint.com/solutions?id=sk76540);

Проверка сертификата
После получения объектом сертификата от другого объекта, необходимо выполнить следующее.
1. Проверить подпись сертификата, т. е., убедиться, что сертификат подписан доверенным СА. Если
сертификат подписан не непосредственно доверенным СА, а его подчиненным, то проверить следует
всю цепочку сертификатов вплоть до доверенного СА.
2. Проверить, не истек ли срок давности цепочки сертификатов.
3. Проверить, не отозваны ли сертификаты из цепочки. Чтобы убедиться, что серийный номер
проверенного сертификата не включен в число отозванных, загружается CRL.
Вдобавок, VPN проверяет возможность использования сертификата в данной ситуации, подтверждая, что:
 Сертификат позволяет выполнять требуемое действие. Например, если для подписи данных необходим
частный ключ (напр., для аутентификации), для разрешения такого действия на сертификате
проверяется расширение KeyUsage – если таковое присутствует.
 При согласовании противоположный узел использовал корректный сертификат. При создании VPN-
туннеля с модулем, управляемым извне, администратор может решить принимать только сертификаты,
подписанные конкретным СА из числа доверенных. (Также возможен прием сертификатов только с
конкретными деталями, напр. с различаемым именем).

Проверка отзыва
Для определения статуса сертификата существует два доступных метода:
1. CRL
2. Протокол статуса онлайн-сертификатов (OCSP)

Регистрация центра сертификации


Объектам, управляемым изнутри, подходящим для включения в VPN, ICA автоматически выдает сертификат.
То есть, после проверки опции VPN в области Продукты Check Point вкладки Общие свойства сетевых
объектов.
Процесс получения сертификата от OPSEC PKI или Внешнего СА Check Point идентичен.

Ручная регистрация с PKI, сертифицированной OPSEC


Создание запроса на сертификат PKCS#10.
1. Создайте объект СА, как описано в пункте «Установление доверия к СА, сертифицированному OPSEC»
(на стр. 56).

Руководство администратора VPN R75.40VS | 45


Инфраструктура открытого ключа

2. Откройте вкладку VPN соответствующего сетевого объекта.


3. В поле Список сертификатов нажмите Добавить… Откроется окно Свойства сертификата.
4. Введите Название сертификата. Название является лишь идентификатором и никоим образом не
влияет на содержание сертификата.
5. Из выпадающего списка Центр сертификации для регистрации (СА to enroll from) выберите прямой
СА OPSEC или внешний СА Check Point, который выдаст сертификат.
Примечание. В списке отображаются только доверенные СА и те подчиненные СА, которые
ведут непосредственно к доверенным. Если СА, выдающий сертификат, не является
подчиненным непосредственно доверенного СА, в списке его не будет.
6. Выберите соответствующий метод создания пары ключей и хранения. Подробнее см. пункт
«Распределенное управление и хранение ключей» (на стр. 56).
7. Щелкните Генерировать… Появится окно Свойства генерируемого сертификата.
8. Введите соответствующий DN.
Какой DN будет последним на сертификате – это решает администратор СА.
Если сертификату необходимо расширение Альтернативное имя (Subject Alternate Name), отметьте
флажок Определить альтернативное имя.
Добавление объекта IP в качестве расширения альтернативного имени может быть настроено как
действие по умолчанию, если выбрать в Глобальные свойства > Настройка SmartDashboard >
Настроить > Сертификаты и свойства PKI:
add_ip_alt_name_for_opsec_certs
add_ip_alt_name_for_ICA_certs
На этом этапе конфигурация возможна и для внутренних СА.
9. Щелкните ОК.
После этого открытый ключ и DN используются для DER-шифрования запроса на сертификат PKCS#10.
10. После того, как запрос на сертификат будет готов, нажмите Обзор…
Появляется окно Обзор запроса на сертификат с шифрованием.
11. Скопируйте полностью текст в окне и отправьте его СА.
Администратору СА теперь надлежит завершить задачу выдачи сертификата. Различные СА
предоставляют различные способы выполнения этого действия, например, посредством
регистрационной формы (enrollment form) (в отличие от обычной формы для пользователей). Существует
несколько способов доставки выданного сертификата, например, по электронной почте. По прибытии
сертификата его следует сохранить.
a) Перейдите на вкладку Серверы и приложения OPSEC сетевого объекта, выберите
соответствующий объект СА.
b) Откройте вкладку OPSEC PKI, нажмите Загрузить… и выберите местоположение сохраненного
сертификата.
c) Выберите соответствующий файл и проверьте детали сертификата.
d) Закройте объект и сохраните.

Автоматическая регистрация с центром сертификации


На вкладке OPSEC PKI объекта СА выберите Автоматически регистрировать сертификат, а в роли
протокола связи выберите SCEP или CMP. Затем выполните следующие действия.
1. Откройте вкладку VPN соответствующего сетевого объекта.
2. В поле Список сертификатов нажмите Добавить… Откроется окно Свойства сертификата.
3. Введите Название сертификата (любая строка, используемая как идентификатор).
4. Из выпадающего меню выберите СА, выдающий сертификат.
Примечание. В меню отображаются только доверенные СА и те подчиненные СА, которые
ведут непосредственно к доверенным. Если СА, выдающий сертификат, не является
подчиненным непосредственно доверенного СА, в меню его не будет.
5. Выберите соответствующий метод создания пары ключей и хранения.
6. Щелкните Генерировать… и выберите Автоматическая регистрация. Появится окно Генерация
ключей и сертификата автоматической регистрации.
 Укажите Идентификатор ключа и свой секретный код авторизации.
 Щелкните OK.
7. Когда сертификат появится в Списке сертификатов на странице VPN сетевых объектов, нажмите Обзор
и выберите действие, которое хотите выполнить над текстом в окне Обзор запроса на сертификат –
Скопировать в буфер обмена или Сохранить в файл.
8. Отошлите запрос администратору СА.
Разные центры сертификации предоставляют для этого разные средства, например, расширенную
форму регистрации на веб-сайте. Существует несколько способов доставки выданного сертификата,
например, по электронной почте. По прибытии сертификата его следует сохранить на диск.
9. На вкладке VPN сетевого объекта выберите соответствующий сертификат из Списка сертификатов и
нажмите Завершить…
10. Перейдите в папку, в которой хранится выданный сертификат, выберите сертификат и проверьте его
содержимое.

Руководство администратора VPN R75.40VS | 46


Инфраструктура открытого ключа

11. Закройте сетевой объект и нажмите Сохранить.


Регистрация посредством подчиненного СА
При регистрации посредством подчиненного СА:
 Укажите пароль подчиненного СА, который выдает сертификат (а не СА, возглавляющего иерархию).
 Подчиненный СА в иерархии должен следовать непосредственно за проверенным СА.

CRL
VPN может загрузить CRL либо с HTTP-сервера, либо с сервера LDAP. Если CRL-хранилищем является
HTTP-сервер, модуль пользуется URL, опубликованным в CRL-расширении сертификата Точка
распределения (Distribution point) и для загрузки CRL открывает HTTP-соединение с хранилищем CRL.
Если CRL-хранилищем выступает сервер LDAP, VPN делает попытку отыскать CRL в одном из определенных
блоков учетной записи LDAP. В такой ситуации должен быть определен блок учетной записи LDAP. Если
существует CRL-расширение Точка распределения, оно публикует DN CRL, т. е., запись в директории, под
которой опубликован CRL или URI LDAP. Если это расширение не существует, тогда VPN делает попытку
отыскать CRL в самой записи СА на сервере LDAP.

OCSP
Протокол статуса онлайн-сертификатов OCSP предоставляет возможность приложениям получать
информацию о состоянии сертификата. OCSP может использоваться для получения более своевременной
информации об отзыве сертификатов, чем это возможно, используя CRL. Информацию OCSP можно
использовать для получения дополнительных сведений о состоянии сертификата. Когда клиент OCSP
передает запрос о статусе на сервер OCSP, прием сертификата задерживается до того момента, пока сервер
не предоставит ответ.
Чтобы использовать OCSP, корневой СА должен быть настроен на этот метод, а не на CRL/ Эта настройка
наследуется подчиненными СА.

Предварительная загрузка CRL в кэш


Поскольку получение CRL может занять длительное время (сопоставимое со всем процессом согласования
IKE), VPN хранит CRL в CRL-кэше, чтобы впоследствии при согласования IKE не требовалось многократной
передачи CRL.
Загрузка в кэш осуществляется:
 каждые два часа;
 при установке политики;
 по истечении кэша.
При неудачном выполнении очередной загрузки в кэш предыдущее содержимое кэша не вытирается.
Примечание. Для ICA необходимо использование CRL-кэша.
Администратор может сократить время пребывания CRL в кэше, может ладе отменить использование кэша.
Если работа CRL-кэша отменена, при каждом последующем согласовании IKE придется загружать
актуальный CRL, что существенно замедлит установление VPN-туннеля. Исходя из сказанного выше,
отключать CRL-кэш рекомендуется только в тех случаях, когда требования безопасности требуют
непрерывного считывания CRL.

Особенности механизма предварительной загрузки CRL


Механизм предварительной загрузки CRL – это лучший метод получения наиболее актуального списка
отозванных сертификатов. Однако, после выполнения команд cpstop, cpstart кэш прекращает обновление.
Шлюз безопасности продолжает использовать устаревший CRL, пока не истечет его срок годности (даже если
на СА уже есть обновленный CRL). Механизм предварительной загрузки возобновляет нормальную работу
лишь после истечения срока годности старого CRL и загрузки нового CRL из СА.
Если после команд cpstop, cpstart следует требование обновления кэша, CRL обновится сразу же. Для этого:
 после выполнения команды cprestart запустите crl_zap для опустошения кэша ИЛИ
 в Глобальные свойства > Настройка SmartDashboard > Настроить > Свойства СА Check Point
выберите flush_crl_cache_file_on_install.
После установки новой политики кэш опустошается и по запросу туда загружается новый CRL.

Руководство администратора VPN R75.40VS | 47


Инфраструктура открытого ключа

Период отсрочки CRL


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

Особенности PKI

Использование внутреннего СА и развертывание стороннего


СА
Внутренний СА облегчает использование PKI приложениям Check Point, таким как VPN Site-to-Site и с
удаленным доступом. Впрочем, администратор может предпочесть продолжить использование того СА,
который уже работает в организации, например, СА, обеспечивающего безопасность электронной почты и
шифрование содержимого дисков.

Распределенное управление и хранение ключей


Распределенное управление ключами (DKM – Distributed Key Management) дает еще один уровень защиты во
время генерации ключей. Вместо того, чтобы Сервер управления защитой генерировал открытый и частный
ключи, а затем загружал их в модуль при установке политики, сервер управления отдает модулю команду
создать собственные открытый и частный ключи, а затем отослать на сервер управления лишь открытый
ключ. Частный ключ после создания сохраняется на модуле – либо на физическом накопителе, либо в
программе, эмулирующей физический накопитель. После этого Сервер управления защитой выполняет
регистрацию сертификата. При установке политики сертификат загружается на модуль. Таким образом,
частный ключ ни при каком условии не покидает модуль.
Локальное хранение ключа поддерживают все типы СА.
Все методы регистрации поддерживают DRM. Его можно сделать настройкой по умолчанию, выбрав в
Глобальные свойства > Настройка SmartDashboard > Настроить > Сертификаты и свойства PKI опцию
use_dkm_cert_by_default.
Примечание. Генерация сертификатов для устройств EDGE не поддерживает DKM. Они генерируются
локально на сервере управления, даже если настроено use_dkm_cert_by_default.

Настройка операций PKI


Установление доверия к СА – шаг за шагом
В этом разделе описаны процедуры для получения собственного сертификата СА. Это необходимо для
установления доверия к сертификатам, которые будет выдавать СА.
Для установления доверия к СА необходимо определить объект сервера СА. Ниже описаны различные этапы
конфигурации, необходимые в различных ситуациях.

Установление доверия к ICA


VPN модуль автоматически доверяет ICA Сервера управления защитой, который им управляет. Дальнейшие
настройки не нужны.

Установление доверия к CA, управляемому извне


CA, управляемый извне, - это ICA другого Сервера управления защитой. Сертификат СА следует загрузить и
заранее сохранить на диск. Для установления доверительных отношений выполните следующие действия.
1. Откройте Управление > Серверы и приложения OPSEC. Откроется окно Серверы и приложения
OPSEC.
2. Выберите Новый > СА. Выберите Доверенный… Откроется окно Свойства центра сертификации.
3. Введите Название объекта СА, а в выпадающем списке Тип центра сертификации выберите Внешний
СА Check Point.
4. Перейдите на вкладку Внешний СА Check Point, нажмите Загрузить…
5. Перейдите в папку, в которой вы сохранили сертификат противоположного СА, и выберите ее.

Руководство администратора VPN R75.40VS | 48


Инфраструктура открытого ключа

VPN считает сертификат и отобразит его подробности. Проверьте подробности сертификата.


Просмотрите и проверьте отпечатки SHA-1 и MD5 сертификата СА.
6. Щелкните ОК.

Установление доверия к СА, сертифицированному OPSEC


Предварительно сертификат этой СА необходимо загрузить и сохранить на диске.
Примечание. В случае автоматической регистрации SCEP этот этап можно пропустить и
автоматически считать сертификат СА после настройки параметров SCEP.
Сертификат СА следует загрузить, либо настроив параметры СА на вкладке Серверы и приложения Opsec,
либо заранее получив сертификат СА у администратора противоположного узла.
После этого определите объект СА, выполнив следующие шаги.
1. Откройте Управление > Серверы и приложения OPSEC. Откроется окно Серверы и приложения
OPSEC.
2. Выберите Новый > СА. Выберите Доверенный… Откроется окно Свойства центра сертификации.
3. Введите Название объекта СА, а в выпадающем списке Тип центра сертификации выберите OPSEC
PKI.
4. На вкладке OPSEC PKI:
 Для автоматической регистрации выберите автоматически регистрировать сертификат
 В меню Подключаться к СА через протокол (Connect to CA with protocol) выберите протокол для
подключения к центру сертификации, SCEP, CMPV1 или CMPV2.
Примечание. Для установления доверия 5.0 и выше используйте CMPV1.
5. Нажмите Свойства…
 Если вы выбрали протокол SCEP, в окне Свойства протокола SCEP введите идентификатор СА
(напр., example.com) и URK центра сертификации/регистрации.
 Если вы выбрали протокол cmpV1, в окне Свойства протокола CMP – V1 введите соответствующий
IP-адрес и номер порта. (Порт по умолчанию 829).
 Если вы выбрали протокол cmpV2, в окне Свойства протокола CMP – V2 выберите протокол для
транспортного слоя – прямой TCP или HTTP.
Примечание. Если не выбрана автоматическая регистрация, ее придется выполнять вручную.
6. Выберите метод получения CRL от этого СА.
Если СА публикует CRL на HTTP-сервере, выберите HTTP-сервер(ы). Выданные СА сертификаты
должны содержать местоположение CRL в URL и в расширении CRL Точка распределения.
Если СА публикует CRL на сервере LDAP, выберите LDAP-сервер(ы). В этом случае вам следует
определить также блок учетной записи LDAP. Подробнее об определении объекта LDAP см.
«Руководство администратора Сервера управления защитой»
(http://supportcontent.checkpoint.com/solutions?id=sk76540).
Убедитесь, что на вкладке Общие окна Свойства блока учетной записи LDAP отмечен флажок
Загрузка CRL.
Сертификаты, выдаваемые СА, должны содержать DN LDAP, на которой находится CRL в расширении
точки распределения CRL.
7. Щелкните Загрузить…
8. Если настроен SCEP, он попытается связаться с СА и загрузить сертификат. В противном случае найдите
папку, в которую вы сохранили сертификат противоположного СА и выберите его.
VPN считает сертификат и отобразит его подробности. Проверьте подробности сертификата.
Просмотрите и проверьте отпечатки SHA-1 и MD5 сертификата СА.
9. Щелкните OK.

Отзыв сертификата (все типы СА)


Сертификат, выданный внутренним центром сертификации, отзывается при удалении объекта сертификата.
Как вариант, отзыв сертификата может выполнить администратор СА, используя опции на вкладке
Дополнительно объекта СА. Кроме того, сертификат следует удалить из модуля.
Удаление сертификата
1. Откройте вкладку VPN соответствующего сетевого объекта.
2. В поле Список сертификатов выберите необходимый сертификат и нажмите Удалить.
Сертификат нельзя удалить, если сервер Smart Center обнаружит, что он задействован. Например, если
модуль принадлежит нескольким VPN-сообществам, а у модуля это – единственный сертификат.

Руководство администратора VPN R75.40VS | 49


Инфраструктура открытого ключа

Восстановление и возобновление сертификата


После отзыва или истечения сертификата необходимо создать новый сертификат или обновить
существующий.

Восстановление и возобновление с внутренним СА


Удаление скомпрометированного или истекшего сертификата автоматически, без вмешательства
администратора приводит к созданию нового сертификата. Для ручного возобновления сертификата
воспользуйтесь кнопкой Возобновить… на странице VPN шлюза безопасности.
Примечание. Шлюз безопасности может иметь только один сертификат, подписанный одним
СА. При выдаче нового сертификата, вам будет предложено заменить существующий
сертификат, подписанный тем же СА.

СА Certificate Rollover
СА Certificate Rollover – это функция VPN-1, позволяющая продлевать сертификаты СА, которыми
подписывается клиент, и сертификаты шлюзов безопасности для VPN-трафика, не рискуя потерять
работоспособность при переходе.
Для достижения постепенного продления сертификата СА Certificate Rollover предоставляет VPN-1
возможность поддерживать несколько сертификатов СА, сгенерированных сторонними OPSEC-
совместимыми СА, например Microsoft Windows CA. Используя несколько сертификатов СА, можно
постепенно выполнять продление клиентских сертификатов и сертификатов шлюзов безопасности в течение
переходного периода, когда происходит распознавание сертификатов клиента и шлюза безопасности,
подписанных обоими СА.
Когда к СА, имеющему сертификат, добавляется еще один сертификат, он определяется как Дополнительный
и получает номер, на один больший, чем наивысший существующий номер сертификата. Первоначальный
сертификат определяется Основным.
Удалять можно только дополнительные сертификаты. СА Certificate Rollover предоставляет инструментарий
для добавления и удаления сертификатов, изменения статуса сертификатов (основной <> дополнительный).
СА Certificate Rollover служит для продления сертификатов СА с разными ключами. Для добавления
сертификата с использованием того же самого ключа, как у существующего сертификата СА (например,
чтобы продлить срок годности), загрузите сертификат со вкладки OPSEC PKI свойства СА и не пользуйтесь
СФ Certificate Rollover.

Управление СА Certificate Rollover


Используя несколько сертификатов СА, можно постепенно продлить сертификаты клиента и шлюза
безопасности в переходный период, в ходе которого происходит распознавание сертификатов клиента и
шлюза безопасности, подписанных обоими СА.
В данном пункте описан рекомендуемый порядок работы для наиболее общей ситуации. Подробности о
командах для командной строки см. пункт «Командная строка СА Certificate Rollover» (на стр. 59).
Прежде чем начать:
В SmartDashboard определите сторонний OPSEC-совместимый СА, например, Microsoft Windows CA,
способный генерировать несколько сертификатов СА. Сгенерируйте основной сертификат и определите его в
SmartDashboard.
Продление сертификата СА за счет нового сертификата
1. Сгенерируйте сторонним СА второй сертификат СА в формате DER (формат PEM не поддерживается) с
ключами, отличающимися от предыдущего сертификата СА. Скопируйте сертификат на Сервер
управления защитой.
2. Войдите на Сервер управления защитой и остановите процессы Check Point:
сpstop
3. Выполните резервное копирования базы данных Сервера управления защитой:
vpn mcc backup
4. Добавьте к определениям базы данных Сервера управления защитой новый сертификат стороннего СА:
vpn mcc add <CA> <CertificateFile>
5. <CA> – это имя СА, определенное в базе данных Сервера управления защитой. <CertificateFile> – это
имя файла сертификата или путь к нему.

Руководство администратора VPN R75.40VS | 50


Инфраструктура открытого ключа

6. Теперь новый сертификат СА должен быть определен как дополнительный №1. Убедитесь в этом при
помощи «vpn mcc lca» или «vpn mcc show» («Командная строка СА Certificate Rollover» на стр. 59).
7. Запустите процессы Check Point:
cpstart
8. Установите политику на все шлюзы безопасности.
Для подписания клиентских сертификатов используйте новый дополнительный сертификат СА.
Пока большинство клиентов используют сертификаты, подписанные старым сертификатом СА, из
соображений производительности, новый сертификат СА следует оставить дополнительным, а старый –
основным. Пока новый сертификат СА не станет основным, не используйте его для подписания сертификатов
шлюзов безопасности.

Командная строка СА Certificate Rollover


СА Certificate Rollover использует набор команд VPN Multi-Certificate CA, как и описано в данном разделе.
Команды конфигурации VPN Multi-Certificate CA не могут выполняться, когда SmartDashboard или Database
Tool подключены к Серверу управления защитой, или когда запущены процессы Check Point.
Чтобы отобразить инструкции по использованию команд командной строки, запустите без аргументов:
vpn mcc

Добавление критериев соответствия в процесс проверки


Пока сертификаты объекта VPN, управляемого извне, не обрабатываются локальным Сервером управления
защитой, вы можете настроить узел так, чтобы при создании VPN-туннеля он предъявлял конкретный
сертификат.
1. Откройте страницу VPN объекта VPN, управляемого извне.
2. Нажмите Критерии соответствия…
3. Выберите желаемые характеристики сертификата узла, которые желаете отобразить при его
предъявлении, включая:
 выдавший его СА;
 точный DN сертификата;
 IP-адрес, указанный в расширении Альтернативное имя сертификата. (Этот IP-адрес сравнивается
с IP-адресом самого узла VPN, видимым модулю VPN во время согласования IKE);
 адрес электронной почты, указанный в расширении Альтернативное имя сертификата.

Использование кэша CRL


Отмена или изменение поведения CRL-кэша
1. Откройте вкладку Дополнительно объекта центра сертификации.
2. Для включения CRL-кэша отметьте Кэшировать CRL на модуле (Cache CRL on the module).
Кэш не следует выключать для ICA. Вообще рекомендуется, чтобы кэширование было включено для всех
типов СА. Выключать его следует лишь тогда (для не-ICA), когда строжайшие требования безопасности
требуют непрерывной загрузки CRL.
Примечание. Для ICA необходимо использование CRL-кэша, никогда не выключайте его.
3. Если CRL-кэш включен, выберите, когда следует вытирать старый CRL – по истечении его срока годности
или через фиксированные промежутки времени (если второй срок не короче первого). Второй вариант
способствует более частной загрузке CRL – ведь CRL могут издаваться чаще, чем наступает конец их
срока годности. По умолчанию CRL удаляется из кэша каждые 24 часа.
Подробнее о кэшировании CRL см. «Предварительная загрузка CRL в кэш» (на стр. 55).

Изменение кэша для предварительной загрузки CRL


Процесс предварительной загрузки можно изменить через Глобальные свойства:
1. Кнопка Глобальные свойства > Настройка SmartDashboard > Настроить… Откроется окно
Дополнительные настройки.
2. Выберите свойства СА Check Point.

Руководство администратора VPN R75.40VS | 51


Инфраструктура открытого ключа

Изменение периода отсрочки CRL


Значения отсрочки CRL модно просмотреть, выбрав Политика > Глобальные свойства > VPN >
Дополнительно. Период отсрочки можно определить как перед, так и после указанного для CRL срока
годности.

Настройка OCSP
Для использования OCSP объект СА должен быть настроен на метод проверки отзывов OCSP, а не CRL.
C помощью GuiDBedit измените поле oscp_validation на true. После такой установки этот СА будет
проверять актуальность сертификата при помощи OCSP. Конфигурация распространяется на корневой СА и
наследуется подчиненными СА.
Настройка доверенного сервера OCSP с использованием GuiDBedit для objectc.c.
1. Создайте новый серверный объект типа oscp_server.
2. Настройте для серверов OCSP URL и сертификат.
3. В объекте СА настройте oscp_server. Добавьте ссылку на созданный серверный объект OCSP и
установите политику.

Руководство администратора VPN R75.40VS | 52


VPN Site-to-Site
В этом разделе

VPN НА ОСНОВЕ ДОМЕНОВ ............................................................................................................................. 54


VPN НА ОСНОВЕ МАРШРУТОВ ........................................................................................................................ 62
УПРАВЛЕНИЕ ТУННЕЛЯМИ .............................................................................................................................. 78
МЕХАНИЗМ ВВОДА ТРАФИКА.......................................................................................................................... 83
ПРОВОДНОЙ РЕЖИМ ........................................................................................................................................ 89
УСТАНОВЛЕНИЕ НАПРАВЛЕННОЙ VPN.......................................................................................................... 94
ВЫБОР ЛИНИИ СВЯЗИ ..................................................................................................................................... 98
VPN С МНОЖЕСТВЕННЫМИ ТОЧКАМИ ВХОДА............................................................................................ 117
VPN ТРАДИЦИОННОГО РЕЖИМА................................................................................................................... 130
ПРЕОБРАЗОВАНИЕ ТРАДИЦИОННОЙ ПОЛИТИКИ В ПОЛИТИКУ НА ОСНОВЕ СООБЩЕСТВА ............... 137
Глава 5
VPN на основе доменов
В этой главе
ОБЗОР VPN НА ОСНОВЕ ДОМЕНОВ................................................................................................................ 54
VPN-МАРШРУТИЗАЦИЯ И КОНТРОЛЬ ДОСТУПА ........................................................................................... 54
НАСТРОЙКА VPN НА ОСНОВЕ ДОМЕНОВ....................................................................................................... 55

Обзор VPN на основе доменов


VPN на основе доменов – это метод управления маршрутизацией трафика VPN между модулями шлюзов
безопасности и клиентами удаленного доступа в рамках сообщества.
Для направления трафика к хосту позади шлюза безопасности следует настроить для данного шлюза
безопасности домен шифрования.
Конфигурация маршрутизации VPN осуществляется либо напрямую через SmartDashboard, либо редактируя
конфигурационные файлы VPN-маршрутизации на шлюзах безопасности.
На рисунке одна из хост-машин за шлюзом безопасности А инициирует соединение с хост-машиной за
шлюзом безопасности В. Либо из технических, либо из нормативных соображений шлюз безопасности А не
может установить VPN-туннель с шлюзом безопасности В. Используя VPN-маршрутизацию, оба шлюза
безопасности могут установить VPN-туннель с шлюзом безопасности С, направляя связь через шлюз
безопасности С.

Шлюз безопасности А
Шлюз безопасности С

Интернет
Шлюз безопасности В

VPN-маршрутизация и контроль доступа


Соединения VPN-маршрутизации подчиняются тем же правилам контроля доступа, что и любое другое
соединение. Если VPN-маршрутизация налажена верно, однако существует правило политики безопасности,
VPN Site-to-Site
не допускающее установление соединения, соединение устраняется. Например: у шлюза безопасности есть
правило, запрещающее FTP-трафик из внутренней сети куда-либо наружу. Когда противоположный шлюз
безопасности устанавливает FTP-соединение с этим шлюзом безопасности, связь не состоится.
Для успешной VPN-маршрутизации в базе правил политики безопасности должно быть единое правило,
обуславливающее трафик в обоих направлениях, входящий и исходящий, а также через центральный шлюз
безопасности. Для настройки этого правила см. «Настройка “Правила приема VPN-трафика”» на стр. 64.

Настройка VPN на основе доменов


Общие сценарии маршрутизации VPN настраиваются через звездообразное VPN-сообщество, однако, не
всякую маршрутизацию VPN можно настроить через SmartDashboard. VPN-маршрутизацию между шлюзами
безопасности (в звездообразной или ячеистой топологии) также можно настроить, редактируя файл
конфигурации $FWDIR\conf\vpn_route.conf.
VPN-маршрутизацию нельзя настроить между шлюзами безопасности, не принадлежащими VPN-сообществу.

Настройка VPN-маршрутизации шлюзов безопасности посредством


SmartDashboard
Простые концентраторы и лучи (даже если есть лишьодин концентратор) звездообразной VPN-топологии
проще всего настраивать в SmartDashboard.
1. В окне Свойства звездообразного сообщества на странице Центральные шлюзы безопасности
выберите шлюз безопасности, работающий в роли концентратора.
2. На странице Сателлитные шлюзы безопасности выберите «лучевые» шлюзы безопасности, т. е.,
сателлитные.
3. На странице Маршрутизация VPN в области Включить маршрутизацию VPN для сателлитов
выберите один из вариантов
 К центру и к прочим сателлитам через центр. Эта опция позволяет устанавливать связь между
шлюзами безопасности, например, если лучевые шлюзы безопасности – это шлюзы DAIP, а
концентратор – шлюз безопасности со статичным IP-адресом.
 К центру или через центр к прочим сателлитам, в Интернет и другие VPN. Эта опция позволяет
устанавливать связь между шлюзами безопасности и проверять все соединения, проходящие через
концентратор в Интернет.
4. В базе правил политики безопасности создайте соответствующее правило контроля доступа. Помните:
одно правило должно охватывать трафик в обоих направлениях.
5. Транслируйте (NAT) сателлитные шлюзы безопасности на концентратор, если концентратор
используется для направления соединений от сателлитов в Интернет.
Два шлюза безопасности DAIP могут безопасно направлять взаимодействия через шлюз безопасности со
статическим IP-адресом.
Настройка VPN-маршрутизации шлюзов безопасности Smart LSM.
1. Создайте сетевой объект, содержащий VPN-домены всех шлюзов безопасности, которые управляются
Provisioning.
2. Измените файл vpn_route.conf, чтобы сетевой объект числился в столбце адресат (центральный шлюз
безопасности звездообразного сообщества).
3. Установите файл vpn_route.conf на все профили LSM, входящие в VPN-сообщество.

Настройка путем редактирования файла конфигурации VPN


Для более точного контроля VPN-маршрутизации следует изменить файл vpn_route.conf в папке conf
Сервера управления защитой.
Файл конфигурации vpn_route.conf – это текстовый файл, содержащий имена сетевых объектов. Формат
такой: Адресат, Следующий объект, Установить на шлюз безопасности (отделяются знаками табуляции).
Рассмотрим простой сценарий VPN-маршрутизации, состоящий из концентратора и двух лучей (рис. 5-3). Все
машины управляются одним и тем же Сервером управления защитой, все шлюзы безопасности принадлежат
одному и тому же VPN-сообществу. Между лучами шифруются только службы Telnet и FTP, которые
направляются через концентратор:

Руководство администратора VPN R75.40VS | 55


VPN Site-to-Site

Луч А
Концентратор

Луч В
Сеанс Telnet
Сеанс FTP

Хотя это легко выполняется путем настройки звездообразного VPN-сообщества, того же результата можно
достичь, редактируя vpn_route.conf.

Адресат Интерфейс маршрутизатора Установить на


следующего объекта

Spoke_B_VPN_Dom Hub_C Spoke_A

Spoke_A_VPN_Dom Hub_C Spoke_B

Настройка “Правила приема VPN-трафика”


В SmartDashboard:
1. Дважды щелкните по топологии сообщества: звезда или ячейки.
2. На странице Общие свойства отметьте флажок Принять весь зашифрованный трафик.
3. Для звездообразного сообщества нажмите Дополнительно, чтобы выбрать, принимать ли шифрованный
трафик через Центральные и сателлитные шлюзы безопасности (Both center and satellite Security
Gateways) или через Только сателлитные шлюзы безопасности (Satellite Security Gateways only).
4. Щелкните OK.
В базе правил появится еще одно правило, принимающее VPN-трафик между выбранными шлюзами
безопасности.

Настройка нескольких концентраторов


Рассмотрим два концентратора, А и В. Концентратор А имеет два луча, spoke_A1 и spoke_A2. У
концентратора В один луч, spoke_B. К тому же, концентратор А управляется Сервером управления защитой
А, а концентратор В – Сервером управления защитой В.

Руководство администратора VPN R75.40VS | 56


VPN Site-to-Site

Интернет
Сервер управления защитой А Луч А1
Концентратор А Концентратор В
Луч В Сервер управления защитой В

Луч А2

Для двух звездообразных VPN-сообществ, основывающихся вокруг концентраторов А и В:


 Лучи А1 и А2 должны направлять весь трафик, идущий за пределы VPN-сообщества, через
концентратор В.
 Лучи А1 и А2 также должны направлять весь трафик, которым они обмениваются, на концентратор А,
являющийся центром их звезды.
 Луч В должен направлять весь трафик, выходящий за пределы его VPN-сообщества, через концентратор
В.
A_community – это VPN-сообщество, содержащее концентратор А с принадлежащими ему лучами.
B_community – это аналогичное VPN-сообщество. Hubs_community – это VPN-сообщество концентраторов
Hub_A и Hub_B.
Настройка VPN-маршрутизации и контроля доступа на Сервере управления защитой А
Файл vpn_route.conf на Сервере управления защитой 1 выглядит так:

Адресат Интерфейс маршрутизатора Установить на


следующего объекта

Spoke_B_VPN_Dom Hub_А A_Spokes

Spoke_A1_VPN_Dom Hub_A Spoke_A2

Spoke_A2_VPN_Dom Hub_A Spoke_A1

Spoke_В_VPN_Dom Hub_В Hub_A

Лучи А1 и А2 объединены в сетевую группу «A_spokes». Соответствующее правило в базе правил политики
безопасности выглядит так:
Источник Адресат VPN Служба Действие

Любой Любой А_Community Любая Принять

В_Community

Hubs_Community

Руководство администратора VPN R75.40VS | 57


VPN Site-to-Site

Настройка VPN-маршрутизации и контроля доступа на Сервере управления защитой А


Файл vpn_route.conf на Сервере управления защитой 2 выглядит так:

Адресат Интерфейс маршрутизатора Установить на


следующего объекта

Spoke_A1_VPN_Dom Hub_B Spoke_B

Spoke_A2_VPN_Dom Hub_B Spoke_B

Spoke_A1_VPN_Dom Hub_A Hub_B

Spoke_A2_VPN_Dom Hub_A Hub_B

Соответствующее правило в базе правил политики безопасности выглядит так:


Источник Адресат VPN Служба Действие

Любой Любой В_Community Любая Принять

А_Community

Hubs_Community

Для обоих файлов vpn_route.conf:


 «A_Community» – звездообразное VPN-сообщество, представленное Hub_A, Spoke_A1 и Spoke_A2.
 «B_Community» – звездообразное VPN-сообщество, представленное Hub_B и Spoke_B.
 «Hubs_Community» – ячеистое VPN-сообщество, представленное Hub_A и Hub_B (это сообщество
может иметь и звездообразную топологию с центральными шлюзами безопасности, связанными
ячеистой сетью).

Луч А1
Луч А2

Концентратор А
Сообщество А
Сообщество концентраторов

Концентратор В

Луч В
Сообщество В

Руководство администратора VPN R75.40VS | 58


VPN Site-to-Site

VPN для профиля SmartLSM


Если шлюзы безопасности филиалов управляются SmartProvisioning как шлюзами безопасности SmartLSM,
включите VPN-маршрутизацию для конфигурации концентратора и луча, отредактировав файл
vpn_route.conf на Сервере управления защитой.

Настройка VPN для одного профиля SmartLSM с несколькими шлюзами.


1. В SmartDashboard создайте Группу, содержащую домены шифрования всех сателлитных шлюзов
безопасности SmartLSM и назовите ее Robo_domain.
2. Создайте Группу, содержащую все центральные шлюзы безопасности, и назовите ее Center_gws
3. В vpn_route.conf добавьте правило:
Адресат Маршрутизатор Установить на
Robo_Domain Center_gws Robo_profile
Если необходим доступ к шлюзу безопасности SmartLSM по VPN-туннелю, в ROBO_domain необходимо
включить внешний IP-адрес шлюза безопасности.
Теперь включена поддержка нескольких шлюзов-маршрутизаторов, при условии что:
 в vpn_route.conf в столбце «Установить на» перечислены шлюзы безопасности ИЛИ
 в SmartDashboard выбраны сателлитные шлюзы безопасности.

VPN с одним или несколькими профилями LSM


Звездообразное VPN-сообщество можно организовать между двумя профилями SmartLSM. Ниже приведены
процедуры, показывающие шлюз и кластер профиля SmartLSM. Также можно настроить сообщество с двумя
кластерами профиля SmartLSM или двумя шлюзами профиля SmartLSM. У всех включенных шлюзов и
кластеров профиля SmartLSM должен быть активирован VPN-блейд IPSec.
Процедура требует настройки в:
 SmartDashboard;
 Командной строке Сервера управления защитой;
 SmartProvisioning Console;
 Командной строке центрального шлюза.

Использование SmartDashboard
В SmartDashboard создайте сетевые объекты, представляющие члены VPN-сообщества и их сети.
Необходимо создать сообщество со звездообразной топологией, а для параметра Маршрутизация VPN
выбрать параметр К центру и к прочим сателлитам через центр.

Организация звездообразного VPN-сообщества между двумя профилями SmartLSM в


SmartDashboard.
1. Создайте и настройте кластер профиля SmartLSM.
a) При настройке топологии выберите те же интерфейсные имена, что и у фактического шлюза.
2. Создайте и настройте шлюз профиля SmartLSM.
3. Создайте обычный шлюз безопасности, который будет центральным шлюзом.
Примечание. Шлюз безопасности 80 не может быть центральным шлюзом.
4. Создайте звездообразное VPN-сообщество: вкладка VPN-сообщества > в контекстном меню выберите
Новое > Site-to-Site > Звезда.
a) Выберите из дерева Центральные шлюзы.
b) Щелкните Добавить и выберите шлюз безопасности, который желаете назначить центральным.
c) Выберите из дерева Сателлитные шлюзы.
d) Щелкните Добавить и выберите кластер профиля SmartLSM и шлюз профиля SmartLSM (или второй
кластер).
e) Выберите из дерева Дополнительные настройки > Маршрутизация VPN.
f) Выберите К центру и к прочим сателлитам через центр.
5. Создайте Сетевой объект, представляющий внутреннюю сеть каждого сателлита VPN-сообщества.
a) На дереве Сетевых объектов щелкните правой кнопкой Сети, выберите Сеть.
b) В поле Сетевой адрес введите внутренний IP-адрес сателлита. Если сателлитом является кластер,
введите внутренний виртуальный IP.
6. Создайте объект Узел (Node), представляющий собой внешний IP-адрес каждого сателлита VPN-
сообщества.
a) На дереве Сетевых объектов щелкните правой кнопкой Узлы, выберите Узел > Шлюз.

Руководство администратора VPN R75.40VS | 59


VPN Site-to-Site
b) В поле IP-адрес введите внешний IP-адрес сателлита. Если сателлитом является кластер, введите
внешний виртуальный IP.
7. Создайте объект Группа, представляющий собой сети каждого сателлитного объекта.
a) На дереве Сетевых объектов щелкните правой кнопкой и выберите Новый > Группы > Простая
группа.
b) Введите Имя группы, уникальное для каждого сателлита.
c) Выберите объект Сеть, созданный вами для внутренней сети этого сателлита, и щелкните
Добавить.
d) Выберите объект Узел, созданный вами для внешнего IP-адреса этого сателлита, и щелкните
Добавить.
8. Создайте объект Группа, представляющий центральный шлюз.
a) На дереве Сетевых объектов щелкните правой кнопкой и выберите Новый > Группы > Простая
группа.
b) Введите Имя группы, уникальное для каждого центрального шлюза.
c) Выберите шлюзовой объект и щелкните Добавить.

Использование интерфейса командной строки


Чтобы два шлюза или кластера профиля SmartLSM могли взаимодействовать друг с другом через
центральный шлюз, следует изменить таблицу маршрутизации Сервера управления доменом или Сервера
управления защитой. Сделайте это через командную строку в файле vpn_route.conf.
Изменение файла vpn_route.conf.
1. Откройте файл vpn_route.conf.
 В среде Многодоменного управления защитой, на Сервере управления доменом:
 Если сателлитами являются шлюзы или кластеры серии 80:
/var/opt/CPmds-<version>/customers/<Domain Management
Server_name>/CPSG80CMP-<version>/conf/vpn_route.conf
 Если сателлиты располагаются на другом устройстве SecurePlatform или открытом сервере:
/opt/CPmds-<version>/customers/<Domain Management Server_name>/CPsuite-
<version>/fw1/conf/vpn_route.conf
 В среде Сервера управления защитой:
 Если сателлитами являются шлюзы или кластеры серии 80:
/opt/CPSG80CMP-<version>/conf/vpn_route.con
 Если сателлиты располагаются на другом устройстве SecurePlatform или открытом сервере:
/opt/CPsuite-<version>/fw1/conf/vpn_route.conf
2. Если два шлюза SmartLSM на разных профилях шлюзов LSM будут взаимодействовать друг с другом
через центральный шлюз, измените файл так:

# destination router [install on]


<Имя простой группы
внутренней сети шлюза <Центральный шлюз> <Имя второго профиля LSM>
SmartLSM>

<Имя простой группы


внутренней сети второго шлюза <Центральный шлюз> <Имя профиля LSM>
SmartLSM>

3. Если свыше одного шлюза SmartLSM из одного профиля LSM будут взаимодействовать друг с другом
через центральный шлюз, измените файл так:

# destination router [install on]


<Имя простой группы
внутренней сети шлюза <Центральный шлюз> <Имя профиля LSM>
SmartLSM>

Руководство администратора VPN R75.40VS | 60


VPN Site-to-Site
4. Установите политику на профили SmartLSM и на центральный шлюз.
Завершение настройки
Завершите настройку в SmartProvisioning Console и в командной строку центрального шлюза.
Завершение настройки VPN
1. Откройте SmartProvisioning GUI Console.
2. Создайте новый кластер или шлюз SmartLSM, исходя из типа вашего устройства. Выберите Файл >
Новый > нужный вариант.
3. Сгенерируйте сертификат VPN для каждого шлюза или члена кластера:
a) Откройте кластерный или шлюзовой объект > вкладка VPN.
b) Выберите Использовать сертификат центра сертификации.
c) Нажмите Генерировать.
d) Повторите эти шаги для каждого члена кластера.
Примечание. Если информация о топологии, дате и времени изменится после генерации
сертификата, придется сформировать новый сертификат во вкладке VPN и обновить шлюз
(Действия > Обновить шлюз).
4. В командной строке центрального шлюза запустите LSMenabler on
5. В SmartProvisioning GUI Console щелкните правой кнопкой по центральному шлюзу и выберите Действия
> Обновить шлюз.
6. На вкладке Топология каждого объекта проверьте корректность указанной топологии для всех устройств
сети:
 Убедитесь, что у интерфейсов те же IP-адреса, что и у фактических шлюзов.
 Убедитесь, что внешние и внутренние интерфейсы распознаны и помечены верно: «Внутренний»,
«Внешний».
7. На вкладке Топология настройте VPN-домен:
 Для шлюзов профиля SmartLSM выберите соответствующую опцию.
 Для кластеров профиля SmartLSM выберите Определить вручную и вручную добавьте домены
шифрования, которые хотите включить.
8. Загрузить политику.
Весь трафик между сателлитами и центральным шлюзом зашифровывается.

Руководство администратора VPN R75.40VS | 61


Глава 6
VPN на основе маршрутов
В этой главе
ОБЗОР VPN НА ОСНОВЕ МАРШРУТОВ ........................................................................................................... 62
ТУННЕЛЬНЫЙ ИНТЕРФЕЙС VPN (VTI) ............................................................................................................. 63
ИСПОЛЬЗОВАНИЕ ПРОТОКОЛОВ ДИНАМИЧЕСКОЙ МАРШРУТИЗАЦИИ .................................................... 64
НАСТРОЙКА НУМЕРОВАННЫХ VTI .................................................................................................................. 64
VTI В КЛАСТЕРНОЙ СРЕДЕ .............................................................................................................................. 66
НАСТРОЙКА VTI В КЛАСТЕРНОЙ СРЕДЕ ........................................................................................................ 66
ВКЛЮЧЕНИЕ ПРОТОКОЛОВ ДИНАМИЧЕСКОЙ МАРШРУТИЗАЦИИ.............................................................. 71
НАСТРОЙКА АНТИСПУФИНГА НА VTI ............................................................................................................. 72
НАСТРОЙКА КОЛЬЦЕВОГО ИНТЕРФЕЙСА ..................................................................................................... 75
НАСТРОЙКА НЕНУМЕРОВАННОГО VTI ........................................................................................................... 75
МАРШРУТИЗАЦИЯ МНОГОАДРЕСНЫХ ПАКЕТОВ ЧЕРЕЗ VPN-ТУННЕЛИ .................................................... 76

Обзор VPN на основе маршрутов


Применение туннельных интерфейсов VPN (VTI) представляет новый метод настройки VPN – VPN на основе
маршрутов. Данный метод основывается на утверждении, что настройка VTI между одноранговыми шлюзами
безопасности во многом напоминает их соединение напрямую.
VTI – это виртуальный интерфейс на уровне операционной системы, который можно использовать как шлюз
безопасности для домена шифрования другого шлюза безопасности. Каждый VTI связан с одним туннелем,
ведущим к шлюзу безопасности. Сам туннель со всеми его свойствами определяется, как и ранее, VPN-
сообществом, которое связывает два шлюза безопасности. Противоположный шлюз безопасности тоже
должен быть настроен соответствующим VTI. В этом случае «родной» механизм IP-маршрутизации каждого
шлюза безопасности может направить трафик через туннель, как это было бы для любого другого типа
интерфейса.
Весь трафик, предназначенный домену шифрования противоположного шлюза безопасности, будет
направлен через «связанный» VTI. Такая инфраструктура позволяет использование VTI протоколами
динамической маршрутизации. Демон протокола динамической маршрутизации, запущенный на шлюзе
безопасности, способен обмениваться информацией о маршрутизации с соседним демоном маршрутизации,
который запущен на другом конце туннеля IPSec, находясь в соседнем блоке.
VPN на основе маршрутов поддерживается только платформами SecurePlatform и Gaia, и может быть
внедрена только между двумя шлюзами безопасности из одного сообщества.

Туннельный интерфейс VPN (VTI)


Туннельный интерфейс VPN – это виртуальный интерфейс на шлюзе безопасности, привязанный к VPN-
туннелю и соединяющийся с удаленным узлом. VTI создается на каждом шлюзе безопасности удаленного
узла, связывающемся с VTI. Трафик, проходящий от локального шлюза безопасности через VTI, в
зашифрованном виде переносится на связанный противоположный шлюз безопасности.
VPN Site-to-Site

Кластер GWA

В данной ситуации:
 Есть VTI, объединяющий кластер GWA и GWb
 Есть VTI, объединяющий кластер GWA и GWс
 Есть VTI, объединяющий GWс и GWb

Виртуальный интерфейс ведет себя как интерфейс «точка-точка», напрямую подключенный к удаленному
узлу. Трафик между сетевыми хостами направляется в VPN-туннель при помощи механизма IP-
маршрутизации операционной системы. Для определения доступных туннелей все также требуются
шлюзовые объекты, VPN-сообщества (с политиками контроля доступа). Однако домены шифрования VPN
для каждого шлюза безопасности одного уровня больше не нужны. Шифровать пакет или нет – это зависит от
того, направляется ли трафик через виртуальный интерфейс. Маршрутизация динамически меняется, если в
сети доступен протокол динамической маршрутизации (OSPF/BGP).

Примечание. Для NGX (R60) и выше пакет динамической маршрутизации внедрен в


SecurePlatform Pro. Администратор запускает демон на шлюзе безопасности, публикующий в
сеть измененные маршруты.

Когда соединение, начавшееся на GWb, направляется через VTI на GWc (или серверы позади GWc),
удовлетворяя неявным правилам, то уже от GWb связь осуществляется в нешифрованном виде с локальным
IP-адресом VTI в качестве исходящего IP-адреса. Если маршрутизация к этому IP-адресу невозможна,
обратные пакеты будут утрачены.
Решение состоит в следующем:
 настроить статический маршрут на GWb, предохраняющий пакеты, предназначенные GWc, от
направления через VTI;
 не включать его ни в какой публикуемый маршрут;
 добавить карты маршрутизации, отфильтровывающие IP-адреса GWc.

Руководство администратора VPN R75.40VS | 63


VPN Site-to-Site
Исключив эти IP-адреса из VPN на основе маршрутов, мы все еще можем устанавливать другие
зашифрованные соединения с этими адресами (напр., при неудовлетворении неявным правилам),
воспользовавшись определениями VPN на основе доменов.

VTI может быть настроена двумя способами:

 нумерованный;
 ненумерованный.

Нумерованный VTI
Для каждого нумерованного туннельного интерфейса VPN (VTI) задается локальный или удаленный IP-адрес.
Для каждого шлюза безопасности задается локальный IP-адрес, удаленный адрес и исходящий IP-адрес для
исходящих соединений через туннель. Удаленный IP-адрес должен быть локальным IP-адресом на
удаленном шлюзе безопасности. Одним IP-адресом могут пользоваться несколько VTI, однако, они не могут
использовать IP-адрес существующего физического интерфейса.
Нумерованные интерфейсы поддерживаются операционными системами SecurePlatform и Gaia.

Ненумерованный VTI
В случае ненумерованных VTI для каждого шлюза безопасности определяется прокси-интерфейс. Каждый
шлюз безопасности использует IP-адрес прокси-интерфейса в качестве исходящего при исходящем трафике.
Ненумерованные интерфейсы позволяют присвоить один IP-адрес каждому интерфейсу и управлять им. В
качестве прокси-интерфейса может выступать физический или кольцевой интерфейс.
Ненумерованные интерфейсы поддерживаются платформами Gaia и IPSO (3.9 и выше).

Использование протоколов динамической маршрутизации


Для обмена информацией о маршрутизации между шлюзами безопасности VTI позволяют использовать
протоколы динамической маршрутизации. Поддерживаются такие протоколы:
1. BGP4
2. OSPF
3. RIPv1 (только SecurePlatform Pro)
4. RIPv2 (только SecurePlatform Pro)

Настройка нумерованных VTI


VPN на основе маршрутов поддерживается только платформами SecurePlatform и IPSO 3.9 и может быть
внедрена между двумя шлюзами безопасности в рамках одного сообщества.

Включение VPN на основе маршрутов


Если настроить шлюз безопасности под VPN на основе доменов и VPN на основе маршрутов, то по
умолчанию приоритет будет за первым типом VPN. Для того, чтобы отдать приоритет VPN на основе
маршрутов, следует создать пустышку – пустую группу – и присвоить ее VPN-домену.
Назначение приоритета VPN на основе маршрутов.
1. В SmartDashboard выберите Управление > Сетевые объекты.
2. Выберите шлюз безопасности Check Point и щелкните правой кнопкой Изменить.
3. В списке Свойства выберите Топология.
4. В разделе VPN-домен выберите Определить вручную.
5. Нажмите Новая > Группа > Простая группа.
6. Введите имя в поле Имя и нажмите ОК.

Руководство администратора VPN R75.40VS | 64


VPN Site-to-Site

Нумерованные VTI
С помощью нового интерфейса командной строки VPN (VPN Shell) администратор создает туннельный
интерфейс VPN на принудительный модуль для каждого шлюза безопасности и «ассоциирует» интерфейс с
противоположным шлюзом безопасности. Туннельный интерфейс VPN может быть нумерованным или
ненумерованным. Подробнее о VPN Shell см. «VPN Shell» (на стр. 316).
Каждому нумерованному VTI присваивается локальный IP-адрес и удаленный IP-адрес. Перед настройкой
необходимо определить диапазон IP-адресов, присваиваемых VTI.

Кластер GWA

VTI соединяет:

 Кластер GWA и GWb


 Кластер GWA и GWc
 GWb и GWc

В данной ситуации участвуют такие устройства:

ClusterXL:

 Кластер GWA
 member_GWA1
 member_GWA2

Модули VPN:

 GWb
 GWc

Руководство администратора VPN R75.40VS | 65


VPN Site-to-Site

IP-конфигурации:

 Кластер GWA
 member_GWA1
 Внешний уникальный IP eth0: 170.170.1.1/24
 Внешний VIP eth0: 170.170.1.10/24
 Интерфейс синхронизации eth1: 5.5.5.1/24
 IP VTI vt-GWb: Локальный: 10.0.1.11, Удаленный: 10.0.0.2
 VIP VTI vt-GWb: 10.0.1.10
 IP VTI vt-GWс: Локальный: 10.0.1.21, Удаленный: 10.0.0.3
 VIP VTI vt-GWс: 10.0.1.20
 member_GWA2
 Внешний уникальный IP eth0: 170.170.1.2/24
 Внешний VIP eth0: 170.170.1.10/24
 Интерфейс синхронизации eth1: 5.5.5.1/24
 IP VTI vt-GWb: Локальный: 10.0.1.12, Удаленный: 10.0.0.2
 VIP VTI vt-GWb: 10.0.1.10
 IP VTI vt-GWс: Локальный: 10.0.1.22, Удаленный: 10.0.0.3
 VIP VTI vt-GWс: 10.0.1.20
 GWb
 Внешний уникальный IP eth0: 180.180.1.1/24
 IP VTI vt-ClusterGWa: Локальный: 10.0.0.2, Удаленный: 10.0.1.10
 IP VTI vt-GWс: Локальный: 10.0.0.2, Удаленный: 10.0.0.3
 GWc
 Внешний уникальный IP eth0: 190.190.1.1/24
 IP VTI vt-ClusterGWa: Локальный: 10.0.0.3, Удаленный: 10.0.1.20
 IP VTI vt-GWb: Локальный: 10.0.0.3, Удаленный: 10.0.0.2

Руководство администратора VPN R75.40VS | 66


VPN Site-to-Site

VTI в кластерной среде


При настройке нумерованных VTI в кластерной среде следует учитывать ряд нюансов.
 У каждого члена должен быть уникальный исходящий IP-адрес.
 Каждый интерфейс каждого члена требует уникальные IP-адрес.
 Все VTI, ведущие к одному и тому же удаленному узлу, должны называться одинаково.
 Кластерам необходимы IP-адреса.

Настройка VTI в кластерной среде


В следующих примерах конфигурации используются те же имена шлюзов безопасности и IP-адреса, что и в
разделе «Нумерованные VTI» (на стр. 73).
Чтобы узнать, как настроить VTI в среде Gaia, см. раздел «Туннельные интерфейсы VPN» в «Руководстве
администратора Gaia» R75.40VS (http://supportcontent.checkpoint.com/solutions?id=sk76540).
Настройка member_GWA1
--------- Доступ к командной строке VPN Shell
[member_GWa2]# vpn shell
? - This help
.. - Go up one level
quit - Quit
[interface ] - Manipulate tunnel interfaces
[show ] - Show internal data
[tunnels ] - Manipulate tunnel data
--------- Добавление vt-GWb
VPN shell:[/] > /interface/add/numbered 10.0.1.12 10.0.0.2
GWb
Interface 'vt-GWb' was added successfully to the system
--------- Добавление vt-GWc
VPN shell:[/] > /interface/add/numbered 10.0.1.22 10.0.0.3
GWc
Interface 'vt-GWc' was added successfully to the system
---------- Проверка конфигурации
VPN shell:[/] > /show/interface/detailed all
vt-GWb Type:numbered MTU:1500
inet addr:10.0.1.12 P-t-P:10.0.0.2
Mask:255.255.255.255
Peer:GWb Peer ID:180.180.1.1 Status:attached
vt-GWc Type:numbered MTU:1500
inet addr:10.0.1.22 P-t-P:10.0.0.3
Mask:255.255.255.255
Peer:GWc Peer ID:190.190.1.1 Status:attached
VPN shell:[/] > /quit
[member_GWa2]# ifconfig vt-GWb
vt-GWb Link encap:IPIP Tunnel HWaddr
inet addr:10.0.1.12 P-t-P:10.0.0.2
Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500
Metric:1
RX packets:0 errors:0 dropped:0 overruns:0
frame:0
TX packets:1 errors:0 dropped:0 overruns:0
carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:36 (36.0 b)
[member_GWa2]# ifconfig vt-GWc
vt-GWc Link encap:IPIP Tunnel HWaddr
inet addr:10.0.1.22 P-t-P:10.0.0.3
Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500
Metric:1

Руководство администратора VPN R75.40VS | 67


VPN Site-to-Site
RX packets:0 errors:0 dropped:0 overruns:0
frame:0
TX packets:1 errors:0 dropped:0 overruns:0
carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:36 (36.0 b)

Настройка member_GWA2
--------- Доступ к командной строке VPN shell
[member_GWa2]# vpn shell
? - This help
.. - Go up one level
quit - Quit .
[interface ] - Manipulate tunnel interfaces
[show ] - Show internal data
[tunnels ] - Manipulate tunnel data
--------- Добавление vt-GWb
VPN shell:[/] > /interface/add/numbered 10.0.1.12 10.0.0.2
GWb
Interface 'vt-GWb' was added successfully to the system
--------- Добавление vt-GWc
VPN shell:[/] > /interface/add/numbered 10.0.1.22 10.0.0.3
GWc
Interface 'vt-GWc' was added successfully to the system
---------- Проверка конфигурации
VPN shell:[/] > /show/interface/detailed all
vt-GWb Type:numbered MTU:1500
inet addr:10.0.1.12 P-t-P:10.0.0.2
Mask:255.255.255.255
Peer:GWb Peer ID:180.180.1.1 Status:attached
vt-GWc Type:numbered MTU:1500
inet addr:10.0.1.22 P-t-P:10.0.0.3
Mask:255.255.255.255
Peer:GWc Peer ID:190.190.1.1 Status:attached
VPN shell:[/] > /quit
[member_GWa2]# ifconfig vt-GWb
vt-GWb Link encap:IPIP Tunnel HWaddr
inet addr:10.0.1.12 P-t-P:10.0.0.2
Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500
Metric:1
RX packets:0 errors:0 dropped:0 overruns:0
frame:0
TX packets:1 errors:0 dropped:0 overruns:0
carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:36 (36.0 b)
[member_GWa2]# ifconfig vt-GWc
vt-GWc Link encap:IPIP Tunnel HWaddr
inet addr:10.0.1.22 P-t-P:10.0.0.3
Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500
Metric:1
RX packets:0 errors:0 dropped:0 overruns:0
frame:0
TX packets:1 errors:0 dropped:0 overruns:0
carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:36 (36.0 b)

Руководство администратора VPN R75.40VS | 68


VPN Site-to-Site

При настройке VTI в кластерной среде, если не задано имя интерфейса, оно предоставляется. По
умолчанию, имя для VTI «vt-[имя противоположного шлюза безопасности]». Например, если имя
противоположного шлюза безопасности Server_2, то по умолчанию имя VTI будет vt-Server_2. Для шлюзов
безопасности, имя которых по длине превышает 12 знаков, интерфейсным именем по умолчанию будут
последние 5 знаков плюс 7-байтный хэш, полученный из имени, – так интерфейсное имя будет уникальным.
После настройки VTI на членах кластера необходимо в SmartConsole настроить VIP этих VTI.
В SmartDashboard:
1. Выберите Управление > Сетевые объекты.
2. Выберите кластер Check Point и нажмите правой кнопкой Изменить.
3. В окне Топология нажмите Изменить топологию.
4. Нажмите Загрузить топологию всех членов.
VTI показаны на топологии.
Обратите внимание, что в окне Изменить топологию перечислены на одной строке члены VTI при
совпадении следующих критериев:
 имя удаленного узла;
 IP-адрес удаленного узла;
 интерфейсное имя.
5. Настройте VIP VTI на вкладке Топология.
6. Щелкните OK и загрузите политику.

Настройка GWb
--------- Доступ к командной строке VPN shell
[GWb]# vpn shell
? - This help
.. - Go up one level
quit - Quit
[interface ] - Manipulate tunnel interfaces
[show ] - Show internal data
[tunnels ] - Manipulate tunnel data
--------- Добавление vt-GWa
VPN shell:[/] > /interface/add/numbered 10.0.0.2 10.0.1.10
GWa
Interface 'vt-GWa' was added successfully to the system
--------- Добавление vt-GWc
VPN shell:[/] > /interface/add/numbered 10.0.0.2 10.0.0.3
GWc
Interface 'vt-GWc' was added successfully to the system
---------- Проверка конфигурации
VPN shell:[/] > /show/interface/detailed all
vt-GWa Type:numbered MTU:1500
inet addr:10.0.0.2 P-t-P:10.0.1.10
Mask:255.255.255.255
Peer:GWa Peer ID:170.170.1.10 Status:attached
vt-GWc Type:numbered MTU:1500
inet addr:10.0.0.2 P-t-P:10.0.0.3
Mask:255.255.255.255
Peer:GWc Peer ID:190.190.1.1 Status:attached
VPN shell:[/] > /quit
[GWb]# ifconfig vt-GWa
vt-GWa Link encap:IPIP Tunnel HWaddr
inet addr:10.0.0.2 P-t-P:10.0.1.10
Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500
Metric:1
RX packets:0 errors:0 dropped:0 overruns:0
frame:0
TX packets:1 errors:0 dropped:0 overruns:0

Руководство администратора VPN R75.40VS | 69


VPN Site-to-Site
carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:36 (36.0 b)
[GWb]# ifconfig vt-GWc
vt-GWc Link encap:IPIP Tunnel HWaddr
inet addr:10.0.0.2 P-t-P:10.0.0.3
Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500
Metric:1
RX packets:0 errors:0 dropped:0 overruns:0
frame:0
TX packets:1 errors:0 dropped:0 overruns:0
carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:36 (36.0 b)

Настройка GWс
--------- Доступ к командной строке VPN shell
[GWc]# vpn shell
? - This help
.. - Go up one level
quit - Quit
[interface ] - Manipulate tunnel interfaces
[show ] - Show internal data
[tunnels ] - Manipulate tunnel data
--------- Добавление vt-GWa
VPN shell:[/] > /interface/add/numbered 10.0.0.3 10.0.1.20
GWa
Interface 'vt-GWa' was added successfully to the system
--------- Добавление vt-GWb
VPN shell:[/] > /interface/add/numbered 10.0.0.3 10.0.0.2
GWb
Interface 'vt-GWb' was added successfully to the system
---------- Проверка конфигурации
VPN shell:[/] > /show/interface/detailed all
vt-GWa Type:numbered MTU:1500
inet addr:10.0.0.3 P-t-P:10.0.1.20
Mask:255.255.255.255
Peer:GWa Peer ID:170.170.1.10 Status:attached
vt-GWb Type:numbered MTU:1500
inet addr:10.0.0.3 P-t-P:10.0.0.2
Mask:255.255.255.255
Peer:GWb Peer ID:180.180.1.1 Status:attached
VPN shell:[/] > /quit
[GWc]# ifconfig vt-GWa
vt-GWa Link encap:IPIP Tunnel HWaddr
inet addr:10.0.0.3 P-t-P:10.0.1.20
Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500
Metric:1
RX packets:0 errors:0 dropped:0 overruns:0
frame:0
TX packets:1 errors:0 dropped:0 overruns:0
carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:36 (36.0 b)
[GWc]# ifconfig vt-GWb
vt-GWb Link encap:IPIP Tunnel HWaddr
inet addr:10.0.0.3 P-t-P:10.0.0.2
Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500
Metric:1

Руководство администратора VPN R75.40VS | 70


VPN Site-to-Site
RX packets:0 errors:0 dropped:0 overruns:0
frame:0
TX packets:1 errors:0 dropped:0 overruns:0
carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:36 (36.0 b)

Руководство администратора VPN R75.40VS | 71


VPN Site-to-Site

Включение протоколов динамической маршрутизации


Обратимся к такому примеру:

Кластер GWA

В следующих таблицах проиллюстрировано включение протокола динамической маршрутизации OSPF на VTI


с помощью SecurePlatform как для единичных, так и для кластерных членов. Обратите внимание, что сетевые
команды для отдельных членов и кластерных членов отличаются.

Подробнее о командах маршрутизации и их синтаксисе см. книгу «Пакет расширенной маршрутизации Check
Point – Интерфейс командной строки».

Подробнее о включении протоколов динамической маршрутизации на VTI в среде Gaia см. раздел
«Туннельные интерфейсы VPN» в «Руководстве администратора Gaia» R75.40VS
(http://supportcontent.checkpoint.com/solutions?id=sk76540).

При пиринге с устройством, на котором активирован Cisco GRE, необходимо формирование GRE-туннеля
«точка-точка». Для конфигурации определения туннельного интерфейса воспользуйтесь следующей
командой:

Руководство администратора VPN R75.40VS | 72


VPN Site-to-Site
ip ospf network point-to-point
Динамическая маршрутизация на member_GWA1
--------- Запуск модуля динамической маршрутизации
[member_GWa1]# expert
Enter expert password:
You are in expert mode now.
[Expert@member_GWa1]# cligated
localhost>enable
localhost#configure terminal
--------- Включение OSPF и предоставление OSPF идентификатора маршрутизатора
localhost(config)#router ospf 1
localhost(config-router-ospf)#router-id 170.170.1.10
--------- Определение интерфейсов/IP, на которых работает OSPF (Используйте
кластерный IP, как определено топологией) и ID зоны для интерфейса/IP
localhost(config-router-ospf)#network 10.0.1.10 0.0.0.0
area 0.0.0.0
localhost(config-router-ospf)#network 10.0.1.20 0.0.0.0
area 0.0.0.0
--------- Перераспределение маршрутов ядра (здесь лиш в качестве примера,
подробнее о командах, касающихся перераспределения маршрутов, см. книгу по
динамической маршрутизации)
localhost(config-router-ospf)#redistribute kernel
localhost(config-router-ospf)#exit
localhost(config)#exit
-------- Запись конфигурации на диск
localhost#write memory
IU0 999 Configuration written to '/etc/gated.ami'
localhost#quit
Динамическая маршрутизация на member_GWA2
--------- Запуск модуля динамической маршрутизации
[member_GWa2]# expert
Enter expert password:
You are in expert mode now.
[Expert@member_GWa2]# cligated
localhost>enable
localhost#configure terminal
--------- Включение OSPF и предоставление OSPF идентификатора маршрутизатора
localhost(config)#router ospf 1
localhost(config-router-ospf)#router-id 170.170.1.10
--------- Определение интерфейсов/IP, на которых работает OSPF (Используйте
кластерный IP, как определено топологией) и ID зоны для интерфейса/IP
localhost(config-router-ospf)#network 10.0.1.10 0.0.0.0
area 0.0.0.0
localhost(config-router-ospf)#network 10.0.1.20 0.0.0.0
area 0.0.0.0
--------- Перераспределение маршрутов ядра (здесь лиш в качестве примера,
подробнее о командах, касающихся перераспределения маршрутов, см. книгу по
динамической маршрутизации)
localhost(config-router-ospf)#redistribute kernel
localhost(config-router-ospf)#exit
localhost(config)#exit
-------- Запись конфигурации на диск
localhost#write memory
IU0 999 Configuration written to '/etc/gated.ami'
localhost#quit

Руководство администратора VPN R75.40VS | 73


VPN Site-to-Site

Динамическая маршрутизация на GWb


--------- Запуск модуля динамической маршрутизации
[GWb]# expert
Enter expert password:
You are in expert mode now.
[Expert@GWb]# cligated
localhost>enable
localhost#configure terminal
--------- Включение OSPF и предоставление OSPF идентификатора маршрутизатора
localhost(config)#router ospf 1
localhost(config-router-ospf)#router-id 180.180.1.1
--------- Определение интерфейсов/IP, на которых работает OSPF (Используйте
кластерный IP, как определено топологией) и ID зоны для интерфейса/IP
localhost(config-router-ospf)#network 10.0.1.10 0.0.0.0
area 0.0.0.0
localhost(config-router-ospf)#network 10.0.0.3 0.0.0.0 area
0.0.0.0
--------- Перераспределение маршрутов ядра (здесь лиш в качестве примера,
подробнее о командах, касающихся перераспределения маршрутов, см. книгу по
динамической маршрутизации)
localhost(config-router-ospf)#redistribute kernel
localhost(config-router-ospf)#exit
localhost(config)#exit
-------- Запись конфигурации на диск
localhost#write memory
IU0 999 Configuration written to '/etc/gated.ami'
localhost#quit
Динамическая маршрутизация на GWс
--------- Запуск модуля динамической маршрутизации
[GWc]# expert
Enter expert password:
You are in expert mode now.
[Expert@GWc]# cligated
localhost>enable
localhost#configure terminal
--------- Включение OSPF и предоставление OSPF идентификатора маршрутизатора
localhost(config)#router ospf 1
localhost(config-router-ospf)#router-id 190.190.1.1
--------- Определение интерфейсов/IP, на которых работает OSPF (Используйте
кластерный IP, как определено топологией) и ID зоны для интерфейса/IP
localhost(config-router-ospf)#network 10.0.1.20 0.0.0.0
area 0.0.0.0
localhost(config-router-ospf)#network 10.0.0.2 0.0.0.0 area
0.0.0.0
--------- Перераспределение маршрутов ядра (здесь лиш в качестве примера,
подробнее о командах, касающихся перераспределения маршрутов, см. книгу по
динамической маршрутизации)
localhost(config-router-ospf)#redistribute kernel
localhost(config-router-ospf)#exit
localhost(config)#exit
-------- Запись конфигурации на диск
localhost#write memory
IU0 999 Configuration written to '/etc/gated.ami'
localhost#quit

Руководство администратора VPN R75.40VS | 74


VPN Site-to-Site

Настройка антиспуфинга на VTI


В SmartDashboard:
1. Выберите Управление > Сетевые объекты.
2. Выберите шлюз безопасности Check Point и правой кнопкой нажмите Изменить.
3. В списке Свойства нажмите Топология.
4. Нажмите Загрузить > Интерфейсы, чтобы считать интерфейсную информацию на машину с шлюзом
безопасности.
5. Выберите интерфейс, щелкните Изменить.
6. В окне Свойства Интерфейса нажмите Топология.
7. В разделе IP-адреса за шлюзом безопасности в пределах досягаемости этого интерфейса (IP
Addresses behind peer Security Gateway that are within reach of this interface) выберите:
 не определено, чтобы принимать весь трафик;
 конкретные, чтобы выбрать конкретную сеть. IP-адреса этой сети станут единственными, которые
будут приняты шлюзом.
8. В разделе Выполнять антиспуфинг на основании топологии интерфейса (Perform Anti-Spoofing
based on interface topology) выберите Не проверять пакеты от (Don’t check packets from), не
выполнять антиспуфинговую проверку адресов из конкретных внутренних сетей, связывающихся с
внешним интерфейсом. Определите сетевой объект, представляющий собой эти внутренние сети с
действительными адресами, и выберите сетевой объект из выпадающего списка.
Объекты, выбранные из выпадающего меню Не проверять пакеты от не будут подвергаться
воздействию антиспуфингового механизма.
9. Параметру Отслеживание спуфинга придайте значение Журнал и нажмите OK.

Настройка кольцевого интерфейса


Когда VTI соединяется с машиной IPSO или машиной SecurePlatform, необходимо задать кольцевой
интерфейс т определить его на вкладке Топология шлюза безопасности.

В IPSO Network Voyager:

1. Выполните вход – появится домашняя страница IPSO.


2. Нажмите Конфигурация интерфейса.
3. На странице Конфигурация нажмите Интерфейсы.
4. На странице Конфигурация интерфейса нажмите loop0.
5. На странице Физический интерфейс loop0 введите IP-адрес в поле Создать новый кольцевой
интерфейс с IP-адресом и значение «30» в поле Длина эталонной маски.
6. Нажмите Применить. Страница Физический интерфейс loop0 обновится и на ней отобразится только
что настроенный кольцевой интерфейс.
7. Щелкните Сохранить.

Настройка ненумерованного VTI


Платформа IPSO поддерживает ненумерованные VTI в конфигурации VRRP HA, только режим актив-пассив.

Если туннельный интерфейс VPN не нумерован, локальный и удаленный IP-адреса не настраиваются.


Данный интерфейс ассоциируется с прокси-интерфейсом, от которого виртуальный интерфейс наследует IP-
адрес. Трафик, исходящий из шлюза безопасности и направляющийся через виртуальный интерфейс, будет
иметь IP-адрес физического интерфейса и исходящий IP.

Руководство администратора VPN R75.40VS | 75


VPN Site-to-Site
Работая с ненумерованными интерфейсами, у нас отпадает необходимость присваивать два IP-адреса на
интерфейс (локальный и удаленный IP-адреса) и синхронизировать эту информацию между узлами.
Ненумерованные интерфейсы поддерживаются только на платформах IPSO 3.9 и выше.

В IPSO Network Voyager.

1. Выполните вход.
2. Нажмите Конфиг.
3. На странице Конфигурация щелкните Check Point Firewall-1
4. На следующей странице нажмите Настройка FWVPN.
5. На странице Настройка туннеля FWVPN в поле Имя противоположного шлюза безопасности введите
имя шлюза безопасности, с которым желаете соединиться.
6. Нажмите Применить.
7. Теперь новый интерфейс числится на странице Конфигурация туннеля FWVPN.

Маршрутизация многоадресных пакетов через VPN-туннели


Групповая передача используется для передачи одного сообщения избранной группе получателей.
Приложения IP-широковещания отсылают одну копию каждой датаграммы (IP-пакет), адресуя ее группе
компьютеров, желающих ее получить. Данная технология направляет датаграммы группе получателей (на
много адресов), а не одному (на один адрес). Сеть отвечает за перенаправление датаграмм только в те сети,
которые должны их получить. Подробнее о групповой передаче см. раздел «Контроль доступа при групповой
передаче» в «Руководстве администратора брандмауэра» R75.40VS
(http://supportcontent.checkpoint.com/solutions?id=sk76540).
Групповой трафик может быть зашифрован и направлен через VPN-туннели, настроенные на использование
интерфейсов VPN-туннелей (виртуальные интерфейсы, связанные с теми же физическими интерфейсами).
Все участвующие шлюзы безопасности, как на передающем, так и на принимающем конце, должны иметь
виртуальный интерфейс для каждого VPN-туннеля и для всех участвующих шлюзов безопасности должен
быть активирован протокол многоадресной маршрутизации.
Подробнее о виртуальных интерфейсах см. «Настройка виртуального интерфейса с помощью VPN Shell» (на
стр. 316).

Руководство администратора VPN R75.40VS | 76


VPN Site-to-Site

На рисунке:

Хост 3 Шлюз безопасности 3


Хост 2 Шлюз безопасности 2
Шлюз безопасности 1
Хост 1

 У шлюза безопасности 1 виртуальный интерфейс настроен на VPN-туннель, связанный со шлюзом


безопасности 2 и другим виртуальным интерфейсом для VPN-туннеля, связанного со шлюзом
безопасности 3.

 Хост 1 за шлюзом безопасности 1 инициирует групповую рассылку, адресованную групповому адресату,


в которых входят хост 2 за шлюзом безопасности 2 и хост 3 за шлюзом безопасности 3.

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

Источник Адресат VPN Служба Действие Отслеживание

Multicast_Gatew Multicast_Gatew Любой трафик igmp принять журнал


ays ays
pim

Sample_Host Multicast_Group Sample_Commu Multicast_Servic принять журнал


_address nity e_Group

Руководство администратора VPN R75.40VS | 77


Глава 7
Управление туннелями
В этой главе
ОБЗОР УПРАВЛЕНИЯ ТУННЕЛЯМИ ................................................................................................................. 78
НАСТРОЙКА ФУНКЦИЙ ТУННЕЛЕЙ.................................................................................................................. 80

Обзор управления туннелями


Виртуальная частная сеть (VPN) предоставляет безопасную связь, обычно через Интернет. Задача
выполняется посредством создания зашифрованного туннеля, обеспечивающего такую же безопасность, как
и частная сеть. Это дает работникам, которые работают на выезде или дома, возможность безопасно
подключаться к удаленному корпоративному серверу. Компании могут иметь безопасную связь с офисами
филиалов и прочими компаниями через Интернет. VPN-туннель гарантирует:

 проверку подлинности посредством стандартных методов аутентификации;


 конфиденциальность за счет шифрования данных;
 целостность за счет использования стандартных методов обеспечения целостности.

Управление типами и количеством туннелей осуществляется при помощи таких средств:


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

Состояние всех VPN-туннелей можно проследить в SmartView Monitor. Подробнее о слежении см. раздел
«Мониторинг туннелей» в «Руководстве администратора SmartView» R75.40VS
(http://supportcontent.checkpoint.com/solutions?id=sk76540).

Постоянные туннели
По мере роста зависимости компаний, связывающихся с другими узлами, от VPN, все критичнее становится
обеспечение непрерывного соединения. Необходимо быть уверенным в том, что VPN-туннели включены и
функционируют. Постоянные туннели активны все время – а значит, в них проще распознать неполадки и
проблемы со связью. Администраторы имеют возможность двустороннего мониторинга VPN-туннеля и
незамедлительного обнаружения проблем.
Каждый VPN-туннель сообщества может быть назначен постоянным. Поскольку постоянные туннели
постоянно отслеживаются, то при выходе VPN-туннеля из строя можно сделать запись в журнале, вывести
сигнальное сообщение или выполнить другое действие, заданное пользователем. Отслеживание VPN-
туннеля выполняется путем периодической отправки пакетов «тестирования туннеля». Пока приходят
ответные пакеты, VPN-туннель считается «действующим». Если в течение заданного периода времени
ответный пакет не поступает, VPN-туннель признается «недействующим». Постоянные туннели
устанавливаются только между шлюзами безопасности Check Point. Конфигурация постоянных туннелей
выполняется на уровне сообщества.
 Она может быть задана для всего сообщества. Тогда все VPN-туннели сообщества станут постоянными.
 Она может быть задана для конкретного шлюза безопасности. Эта опция используется для настройки
конкретных шлюзов безопасности на постоянные туннели.
 Она может быть задана для одного VPN-туннеля. Так можно назначить постоянными конкретные VPN-
туннели между конкретными шлюзами безопасности.
VPN Site-to-Site

Постоянные туннели в среде МЕР


В среде со множественными точками входа (MEP – Multiple Entry Point) активные VPN-туннели в случае
недоступности заданного заранее первичного шлюза безопасности перенаправляются с первичного шлюза
безопасности к резервному шлюзу безопасности. Когда постоянный туннель настроен между шлюзами
безопасности в среде MEP с активным RIM, для сателлитных шлюзов безопасности центральные шлюзы
безопасности представляются в «унифицированном» виде. В результате соединение не прервется, а
переключится на другой центральный шлюз безопасности вновь созданного постоянного туннеля. Подробнее
о МЕР см. раздел «VPN с множественными точками входа» (на стр. 128).
В данной ситуации:

VPN-домен M1 Первичный шлюз безопасности

VPN-домен М2 Постоянный туннель


Хост 2 VPN-домен S1
Выделенная линия Хост 1
Резервный шлюз безопасности

 Хост 1, расположенный за шлюзом безопасности S1, взаимодействует через постоянный туннель с


хостом 2, который расположен за шлюзом безопасности М1.
 М1 и М2 пребывают в МЕР-среде.
 М1 и М2 пребывают в МЕР-среде с активным механизмом ввода трафика (RIM).
 M1 – это первичный шлюз безопасности, М2 – резервный.
В данном случае, если связь со шлюзом безопасности М1 пропадет, соединение продолжится через вновь
созданный постоянный туннель между S1 и М2.

Проверка постоянных туннелей


Туннельный тест – это собственный протокол Check Point, используемый для проверки активности VPN-
туннеля. У пакета есть контрольная длина, при этом значащая информация содержится лишь в первом байте
– это поле «тип».
Поле «тип» может принимать любое из следующих значений:
 Test (тест)
 Reply (ответить)

Руководство администратора VPN R75.40VS | 79


VPN Site-to-Site

 Connect (подключить)
 Connected (подключен)
Для туннельного теста нужно два шлюза безопасности: один должен быть настроен в роли пингера, другой –
в роли ответчика. Шлюз безопасности пингера использует демон VPN для отсылки зашифрованных пакетов
тестирования туннеля шлюзам безопасности, которые настроены на прием сигнала от него. Шлюз
безопасности ответчика настроен на прием специальных пакетов тестирования туннеля по порту 18234.
Пингер отсылает сигнал типа 1 или 3. Ответчик отвечает пакетом той же длины, типа 2 или 4 соответственно.
На этапе соединения туннельный тест применяется двояко.
1. Шлюзу безопасности отправляется сообщение «connect». Если в ответ приходит сообщение «connected»,
значит связь в порядке. Если ответного сообщения нет, то сообщения «connect» после согласования IKE
посылаются повторно в течение 10 секунд.
2. Отсылается серия сообщений «test» разной длины, таким образом, определяется максимальный блок
передачи (PMTU) линии связи. Процесс занимает до 10 секунд. Этот тест выполняется для того, чтобы
убедиться, что слишком длинные TCP-пакеты не отправляются. Слишком длинные TCP-пакеты
фрагментируются и сокращают скорость передачи.
Шлюзы безопасности версии R54 и выше могут выступать как пингерами, так и ответчиками. В среде МЕР
центральные шлюзы безопасности могут служить только ответчиками.
Шлюзы безопасности с внедренной NG 5.0 и выше могут быть как пингерами, так и ответчиками. Более
старые версии этого ПО могут выступать только в роли ответчиков.
Сторонние шлюзы безопасности не могут быть ни пингерами, ни ответчиками.

Разделение VPN-туннелей
Разные производители, используя множество разных методов, внедряют туннели IPSec. В этой ситуации
администраторам приходится разбираться с различными средствами внедрения IPSec-среды.
Разделение VPN-туннелей улучшает взаимодействие и вносит масштабируемость, контролируя количество
VPN-туннелей, создаваемых между шлюзами безопасности. Существует три доступные конфигурации:
 один VPN-туннель на каждую пару хостов;
 один VPN-туннель на пару подсети;
 один VPN-туннель на пару шлюзов безопасности.

Настройка функций туннелей

Настройка опций управления туннелями


1. В SmartDashboard выберите Управление > VPN-сообщества. Появится окно VPN-сообщества.
2. Выберите сообщество («звезда», ячеистое) для настройки и нажмите Изменить…
3. Нажмите Управление туннелями.
Появится окно Управление туннелями.
 Для настройки постоянных туннелей см. «Постоянные туннели» (на стр. 85).
 Для настройки слежения см. «Опции слежения» (на стр. 88).
 Для настройки разделения VPN-туннелей см. «Разделение VPN-туннелей» (на стр. 89).

Постоянные туннели
В окне Свойства сообщества на странице Управление туннелями выберите Задать постоянные туннели;
для вас откроются следующие три режима постоянных туннелей:
1. Все туннели сообщества
2. Все туннели конкретных шлюзов безопасности
3. Конкретные туннели сообщества
Для того, чтобы все туннели стали постоянными, выберите Все туннели сообщества. Чтобы закрыть все
постоянные туннели в сообществе, снимите этот флажок.

Руководство администратора VPN R75.40VS | 80


VPN Site-to-Site
Чтобы настроить Все туннели конкретных шлюзов безопасности:
1. Выберите Все туннели конкретных шлюзов безопасности и щелкните Выбрать шлюзы
безопасности. Отобразится окно Выбрать шлюзы безопасности.
Чтобы закрыть постоянные туннели, соединенные с конкретным шлюзом безопасности, подсветите шлюз
безопасности и нажмите Удалить.
2. Чтобы настроить опции слежения конкретного шлюза безопасности, подсветите шлюз безопасности и
нажмите Свойства туннелей шлюза безопасности.
Чтобы настроить Конкретные туннели сообщества:
1. Выберите Конкретные туннели сообщества и щелкните Выбрать постоянные туннели. Отобразится
окно Выбрать постоянные туннели.
2. Щелкните в ячейке, пересекающей шлюзы безопасности, в которых требуется постоянный туннель.
3. Нажмите Свойства выбранного туннеля: отобразится окно Свойства туннеля.
Чтобы закрыть постоянный туннель между этими двумя шлюзами безопасности, снимите флажок
Назначить эти туннели постоянными.
4. Нажмите OK.

Дополнительная настройка постоянного туннеля


В SmartDashboard:
1. Нажмите Политика > Глобальные свойства. Отобразится окно Глобальные свойства.
2. Выберите из списка свойств Настройка SmartDashboard.
3. В разделе Дополнительная настройка нажмите Настроить. Откроется окно Дополнительная
настройка.
4. Нажмите Дополнительные свойства VPN > Управление туннелями, чтобы отобразить пять атрибутов,
изменение которых приводит к регулированию количества туннельных тестов и интервалов между их
отсылкой.
 life_sign_timeout – указание времени, в течение которого туннельный тест будет работать, не получая
ответа, прежде чем хост будет объявлен «неактивным».
 life_sign_transmitter_interval – указание интервала времени между туннельными тестами.
 life_sign_retransmissions_count – когда туннельный тест не получает отклика, в подтверждение
«неактивности» узла отсылается другой тест. Данный параметр задает количество повторов отсылки
туннельного теста без получения ответа.
 life_sign_retransmissions_interval – указание интервала времени между повторными отсылками
туннельного теста при отсутствии отклика от узла.
 cluster_status_polling_interval – (только для кластеров НА) – указание времени между тестами туннеля
между первичным шлюзом безопасности и резервным шлюзом безопасности. Туннельный тест
отправляется резервным шлюзом безопасности. При отсутствии отклика резервный шлюз безопасности
становится активным.

Опции слежения
Чтобы администратор всегда знал о состоянии VPN-туннелей, можно настроить несколько видов
сигнализации. Опции слежения меняются на странице Управление туннелями экрана Свойства
сообщества для всех VPN-туннелей или отдельно для каждого при настройке самих постоянных туннелей.
Опции здесь таковы: Журнал (Log), Всплывающее окно (Popup Alert), Почтовое сообщение (Mail Alert),
SNMP-ловушка (SNMP Trap Alert) и Пользовательская сигнализация. Выбрав один из типов сигнализации,
вы сможете немедленно идентифицировать проблему и эффективно на нее среагировать.

Закрытие постоянных туннелей


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

Руководство администратора VPN R75.40VS | 81


VPN Site-to-Site

Разделение VPN-туннелей
В VPN-сообществе настройка осуществляется на странице Управление туннелями окна Свойства
сообщества.
Для настройки конкретного шлюза безопасности необходимо перейти на страницу VPN Дополнительно окна
свойства шлюза безопасности.
Разделение VPN-туннелей улучшает взаимодействие и повышает масштабируемость сети за счет контроля
количества VPN-туннелей, создаваемых между шлюзами безопасности одного уровня. Конфигурация
разделения VPN-туннелей может проводиться как для VPN-сообщества, так и для шлюза безопасности.
 Один VPN-туннель на каждую пару хостов – VPN-туннель создается для каждого сеанса связи между
каждой парой хостов.
 Один VPN-туннель на пару подсети – VPN-туннель, открытый между двумя подсетями, используется и
при дальнейших сеансах связи между этими подсетями. Это значение по умолчанию, совпадающее с
промышленным стандартом IPSec.
 Один VPN-туннель на пару шлюзов безопасности – между парой шлюзов безопасности создается
VPN-туннель, который впоследствии попадает в общее пользование всех хостов, находящихся за
каждым из шлюзов безопасности.
В случае конфликта между свойствами туннеля VPN-сообщества и шлюза безопасности, являющегося
челном этого VPN-сообщества, выполняется более «жесткая» настройка. Например, если шлюз безопасности
настроен на Один VPN-туннель на каждую пару хостов, а сообщество – на Один VPN-туннель на пару
подсети, то выполняться будет Один VPN-туннель на каждую пару хостов.

Руководство администратора VPN R75.40VS | 82


Глава 8
Механизм ввода трафика
В этой главе
ОБЗОР ВВОДА ТРАФИКА ................................................................................................................................. 83
АВТОМАТИЧЕСКИЙ RIM.................................................................................................................................... 83
ПОЛЬЗОВАТЕЛЬСКИЕ СЦЕНАРИИ .................................................................................................................. 84
ВВОД ИНТЕРФЕЙСОВ УДАЛЕННОГО ШЛЮЗА БЕЗОПАСНОСТИ ................................................................. 86
НАСТРОЙКА RIM ................................................................................................................................................ 86
НАСТРОЙКА RIM ПОД GAIA .............................................................................................................................. 88

Обзор ввода трафика


Механизм ввода трафика (RIM – Route Injection Mechanism) предоставляет шлюзу безопасности возможность
использовать протоколы динамической маршрутизации для распространения сигнала домена шифрования
удаленного шлюза безопасности (peer gateway) VPN во внутреннюю сеть и инициирования обратной связи.
По создании VPN-туннеля RIM обновляет локальную таблицу маршрутизации шлюза безопасности, включая
в нее домен шифрования VPN-узла.
RIM можно включить только при наличии постоянных туннелей, настроенных для сообщества. Постоянные
туннели удерживаются в активном состоянии тестирующими пакетами. Если шлюз безопасности не отвечает,
туннель считается «неактивным». В результате RIM удаляет маршрут к нерабочей линии связи из локальной
таблицы маршрутизации; соседние устройства со включенной динамической маршрутизацией в свою очередь
обновляют соответствующим образом свои таблицы маршрутизации. В результате происходит
переадресация всего трафика, направляемого в VPN-туннель, через определенный заранее альтернативный
путь.
Существует два способа настройки RIM:
 Автоматический RIM – RIM самостоятельно вводит маршрут в домен шифрования шлюзов
безопасности.
 Пользовательский сценарий – RIM выполняет указанные ему задачи согласно конкретной
необходимости.
Ввод трафика можно сочетать с функцией МЕР (направляющей ответные пакеты назад через тот же шлюз
безопасности МЕР). Подробнее о МЕР см. «VPN с множественными точками входа» (на стр. 128).

Автоматический RIM
Автоматический RIM включается через графический интерфейс, если на шлюзе безопасности в качестве
операционной системы выступает SecurePlatform, IPSO или Linux. В этих системах возможно и выполнение
пользовательского сценария, впрочем, в этом нет необходимости.
В данной ситуации:

Выделенная линия

 Шлюзы безопасности 1 и 2 в режиме RIM, в них работает протокол динамической маршрутизации.


 R1 и R4 – включенные маршрутизаторы.
 После создания VPN-туннеля RIM обновляет локальные таблицы маршрутизации шлюза безопасности 1
и шлюза 2, включая домен шифрования другого шлюза безопасности.
 Если VPN-туннель станет недоступным, трафик перенаправляется на выделенную линию.
VPN Site-to-Site
Таблицы маршрутизации шлюзов безопасности и маршрутизаторов выглядят, как показано ниже. Записи,
выделенные жирным шрифтом, представляют маршруты, введенные RIM в локальные таблицы
маршрутизации:
Для шлюза безопасности 1:

Адресат Маска сети Шлюз безопасности Метрика

0.0.0.0 0.0.0.0 172.16.10.2 1

192.168.21.0 255.255.255.0 172.16.10.2 1

192.168.11.0 255.255.255.0 192.168.10.1 1

Для шлюза безопасности 2:

Адресат Маска сети Шлюз безопасности Метрика

0.0.0.0 0.0.0.0 172.16.20.2 1

192.168.11.0 255.255.255.0 172.16.20.2 1

192.168.21.0 255.255.255.0 192.168.20.1 1

R1 (за шлюзом безопасности 1):

Адресат Маска сети Шлюз безопасности Метрика

0.0.0.0 0.0.0.0 192.168.10.2 1

192.168.21.0 255.255.255.0 192.168.10.2 1

192.168.21.0 255.255.255.0 0.10.10.2 2

R4 (за шлюзом безопасности 2):

Адресат Маска сети Шлюз безопасности Метрика

0.0.0.0 0.0.0.0 192.168.20.2 1

192.168.11.0 255.255.255.0 192.168.20.2 1

192.168.11.0 255.255.255.0 10.10.10.1 2

Пользовательские сценарии
Пользовательские сценарии можно запустить на любом шлюзе безопасности сообщества. Эти сценарии
выполняются тогда, когда туннель изменяет свое состояние, т. е. из «активного» становится «неактивным»
или наоборот. Такое событие может, например, стать причиной включения соединения dial-up.
Шаблон сценария custom_rim (с расширением .sh или .bat, в зависимости от операционной системы)
содержится в папке $FWDIR/Scripts. Это базовый сценарий (только для SecurePlatform, IPSO или Linux).
Пример сценария, написанного для SecurePlatform, IPSO, Linux
#!/bin/sh
# This script is invoked each time a tunnel is configured
with the RIM option
# and the tunnel changed state.
#
# You may add your custom commands to be invoked here.
# Parameters read from command line.
RIM_PEER_Security Gateway=$1
RIM_NEW_STATE=$2
RIM_HA_STATE=$3

Руководство администратора VPN R75.40VS | 84


VPN Site-to-Site
RIM_FIRST_TIME=$4
RIM_PEER_ENC_NET=$5
case "${RIM_NEW_STATE}" in
up)
# Place your action for tunnels that came up
;;
down)
# Place your action for tunnel that went down
;;
esac

Для платформы Windows сценарий приобретает форму пакетного исполняемого файла.


Пример сценария, написанного для Windows
@echo off
rem . This script is invoked each time a tunnel is
configured with the RIM option
rem . and the tunnel changed state.
rem .
rem . You may add your custom commands to be invoked here.
rem . Parameters read from command line.
set RIM_PEER_Security Gateway=%1
set RIM_NEW_STATE=%2
set RIM_HA_STATE=%3
set RIM_FIRST_TIME=%4
set RIM_PEER_ENC_NET=%5
goto RIM_%RIM_NEW_STATE%
:RIM_up
rem . Place your action for tunnels that came up
goto end
:RIM_down
rem . Place your action for tunnel that went down
goto end
:end
В приведенных сценариях:
 RIM_PEER_Security Gateway: удаленный шлюз безопасности.
 RIM_NEW_STATE: изменение состояния шлюза безопасности – «активен» <> «неактивен».
 RIM_HA_STATE: состояние единственного шлюза безопасности в кластере (т. е., ожидает или активен).
 RIM_FIRST_TIME: сценарий выполняется отдельно для каждой сети в пределах достижимости другого
домена шифрования. Хотя сценарий можно на одном узле выполнять по несколько раз, этот параметр
будет передан сценарию со значением «1» лишь в первый его запуск в узле. Значение «1» показывает,
что это первое выполнение сценария. При следующем запуске сценария параметр передается со
значением «0» и игнорируется.
 RIM_PEER_ENC_NET: VPN-домен VPN-узла.

Ввод интерфейсов удаленного шлюза безопасности


Флаг RIM_inject_peer_interfaces используется для введения в таблицы маршрутизации IP-адресов
удаленного шлюза безопасности вдобавок к сетям позади шлюза безопасности.
Например, после создания VPN-туннеля RIM вводит в локальные таблицы маршрутизации обоих шлюзов
безопасности домен шифрования удаленного шлюза безопасности. Однако, когда RIM дал шлюзам
безопасности возможность взаимодействовать со шлюзом безопасности, на котором включен параметр Hide
NAT, появляется необходимость ввода интерфейсов удаленного узла.
В данной ситуации:

Руководство администратора VPN R75.40VS | 85


VPN Site-to-Site

Хост 2 Маршрутизатор 1

Шлюз безопасности В Интернет


Маршрутизатор 3 Маршрутизатор 4
Маршрутизатор 2 Шлюз безопасности С
Шлюз безопасности А Хост 1

1. На шлюзах безопасности А и В включен RIM, а у шлюза безопасности С на внешнем интерфейсе


активен параметр Hide NAT («скрывающий» все IP-адреса за ним).
2. Хост 1 за шлюзом безопасности С инициирует VPN-туннель с хостом 2 через шлюз безопасности А.
3. Маршрутизатор 3 строит пути ко всем хостам позади шлюза безопасности С. Однако, у маршрутизатора
3 нет IP-адреса Hide NAT шлюза безопасности С; в результате он не может правильно перенаправлять
пакеты обратно хосту 1.
Решение для маршрутизации обратной отправки пакетов двоякое:
1. На странице Глобальные свойства выберите RIM_inject_peer_interfaces. Этот флаг введет в
маршрутизатор 3 все IP-адреса шлюза безопасности С, в том числе адрес Hide NAT.
2. Настройте маршрутизатор так, чтобы он не передавал информацию, введенную в другие шлюзы
безопасности. Если маршрутизатор настроен неверно, то, согласно примеру на рис. 8-4, шлюз
безопасности В будет передавать трафик шлюзу безопасности С через шлюз безопасности А.

Настройка RIM
Настройка RIM в звездообразном сообществе
1. Откройте страницу Свойства звездообразного сообщества > Управление туннелями.
2. В разделе Постоянные туннели выберите Задать постоянные туннели. Для вас откроются следующие
три режима постоянных туннелей:
 Все туннели сообщества
 Все туннели конкретных шлюзов безопасности
 Конкретные туннели сообщества
Подробнее об этих опциях см. «Постоянные туннели» (на стр. 88).
При выборе туннелей имейте в виду, что RIM включается лишь на тех туннелях, которые заданы как
постоянные. Если в сообществе действует МЕР, следует выбирать пункт Все туннели сообщества. Для
настройки постоянных туннелей см. «Настройка функций туннелей» (на стр. 87).
1. Выберите Включить механизм ввода трафика (RIM).
2. Нажмите Настройки…

Руководство администратора VPN R75.40VS | 86


VPN Site-to-Site
Откроется окно настроек RIM.
Вам предоставлен выбор из двух режимов.
 RIM работает автоматически на центральных или сателлитных шлюзах безопасности (только
SecurePlatform, IPSO, Linux).
 C каждым изменением состояния туннеля («активен» <> «неактивен») на центральных или
сателлитных шлюзах безопасности выполняется пользовательский сценарий.
Опции слежения см. в разделе «Опции слежения» (на стр. 88).
3. Если запущен пользовательский сценарий, отредактируйте файл custom_rim (.sh или .bat) в папке
$FWDIR/Scripts на каждом шлюзе безопасности.

Настройка RIM в ячеистом сообществе


1. Откройте страницу Свойства звездообразного сообщества > Управление туннелями.
В разделе Постоянные туннели выберите Задать постоянные туннели. Для вас откроются следующие три
режима постоянных туннелей:
 Все туннели сообщества
 Все туннели конкретных шлюзов безопасности
 Конкретные туннели сообщества
Подробнее об этих опциях см. «Постоянные туннели» (на стр. 88).
При выборе туннелей имейте в виду, что RIM включается лишь на тех туннелях, которые заданы как
постоянные. Для настройки постоянных туннелей см. «Настройка функций туннелей» (на стр. 87).
1. Выберите Включить механизм ввода трафика (RIM).
2. Нажмите Настройки…
Откроется окно настроек RIM.
Вам предоставлен выбор из двух режимов.
 RIM работает автоматически на центральных или сателлитных шлюзах безопасности (только
SecurePlatform, IPSO, Linux).
 C каждым изменением состояния туннеля («активен» <> «неактивен») на центральных или
сателлитных шлюзах безопасности выполняется пользовательский сценарий.
Опции слежения см. в разделе «Опции слежения» (на стр. 95).
3. Если запущен пользовательский сценарий, отредактируйте файл custom_rim (.sh или .bat) в папке
$FWDIR/Scripts на каждом шлюзе безопасности.

Включение флага RIM_inject_peer_interfaces


Включение флага RIM_inject_peer_interfaces
1. В SmartDashboard нажмите Политика > Глобальные свойства.
2. Перейдите на Настройка SmartDashboard > Настроить > Дополнительные свойства VPN >
Управление туннелем.
3. Выберите RIM_inject_peer_interfaces
4. Нажмите OK.

Опции слежения
Чтобы администратор мог оперативно реагировать на изменения состояния шлюзов безопасности,
существует несколько типов сигналов. Опции слежения настраиваются на странице Свойства механизма
ввода трафика. Опции на выбор: Журнал (Log), Всплывающее окно (Popup Alert), Почтовое сообщение
(Mail Alert), SNMP-ловушка (SNMP Trap Alert) и Пользовательская сигнализация.

Настройка RIM под Gaia


В Gaia механизм ввода трафика добавляет маршруты непосредственно в ядро. Чтобы маршруты оставались
в ядре, необходимо настроить эту опцию.
Установка маршрутов ядра в командной строке
1. Выполните: set kernel-routes on.
2. Выполните: save config.

Установка маршрутов ядра через веб-интерфейс


1. В режиме просмотра дерева нажмите Дополнительная маршрутизация > Опции маршрутизации
(Advanced Routing > Routing Options).
2. В области Опции ядра (Kernel options) выберите опцию Маршруты ядра (Kernel Routes).
3. Нажмите Применить.

Руководство администратора VPN R75.40VS | 87


VPN Site-to-Site

Шлюзы Gaia в звездообразном VPN-сообществе


Чтобы RIM работал, шлюзы Gaia в звездообразном VPN-сообществе должны публиковать маршруты
сателлитных сетей к маршрутизатору. Чтобы шлюзы Gaia публиковали маршруты, выполните эти команды
командной строки для всех шлюзов безопасности в центре сообщества.
1. set routemap <Routemap Name> id <ID Number>
Например:
set routemap RIM id 5
2. set routemap <Routemap Name> id <ID Number> match protocol kernel
Например:
set routemap RIM id 5 match protocol kernel
3. Set ospf export-routemap <Routemap Name> preference 1 on
Например:
set ospf export-routemap RIM preference 1 on
4. set routemap <Routemap Name> id <ID Number> allow
Например:
set routemap RIM id 5 allow
5. set routemap <Routemap Name> id <ID Number> on
Например:
set routemap RIM2 id 10 on
6. set routemap <Routemap Name> id <ID Number> match nexthop <IP of OSPF
Interface of the other RIM GW> on
Например:
set routemap RIM2 id 10 match nexthop <10.16.50.3> on
7. set routemap <Routemap Name> id <ID Number> restrict
Например:
set routemap RIM2 id 10 restrict
8. set ospf import-routemap <Routemap Name> preference 1 on
Например:
set ospf import-routemap RIM2 preference 1 on
9. save config

Руководство администратора VPN R75.40VS | 88


VPN Site-to-Site

Глава 9
Проводной режим
В этой главе
ОБЗОР ПРОВОДНОГО РЕЖИМА ...................................................................................................................... 89
СИТУАЦИИ С ПРОВОДНЫМ РЕЖИМОМ .......................................................................................................... 89
ОСОБЕННОСТИ ПРОВОДНОГО РЕЖИМА ....................................................................................................... 92
НАСТРОЙКА ПРОВОДНОГО РЕЖИМА ............................................................................................................. 92

Обзор проводного режима


Проводной режим улучшает связь, позволяя аварийное переключение существующих соединений, минуя
брандмауэр. По определению, трафик внутри VPN-сообщества конфиденциальный и защищенный. Во многих
случаях брандмауэр и его правило относительно VPN-соединений бывают излишними. В проводном режиме
VPN-соединения могут обойти брандмауэр, определив внутренние интерфейсы и сообщества как
«доверенные».
Когда на шлюз безопасности поступает пакет, шлюз безопасности задает себе два вопроса:
Пришла ли информация от «доверенного» источника?
Предназначена ли информация «доверенному» адресату?
Если на оба вопроса ответ утвердительный, а VPN-сообщество, к которому принадлежит шлюз
безопасности, поддерживает проводной режим, принудительная проверка состояния соединения не
проводится, трафик между доверенными интерфейсами не проходит через брандмауэр. Поскольку проверки
состояния соединения не происходит, пакеты не отбрасываются. VPN-связь не отличается от любого другого
соединения вдоль выделенного провода. В этом и состоит суть проводного режима. Поскольку проверки
состояния соединения не происходит, протоколы динамической маршрутизации (которые не выдерживают
проверки состояния в беспроводном режиме) развернуть нельзя. Таким образом, проводной режим облегчает
VPN на основе маршрутов. Подробнее об этом см. раздел «VPN на основе маршрутов» (на стр. 71).
Проводной режим поддерживается шлюзами безопасности NGX (R60) и далее.

Ситуации с проводным режимом


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

Проводной режим в конфигурации МЕР


В данной ситуации:

Руководство администратора VPN R75.40VS | 89


VPN Site-to-Site

Оригинальный VPN-домен М2 Выделенная линия


Оригинальный VPN-домен М1 VPN-домен S1

Хост 2 Хост 1

 И шлюз безопасности М1, и шлюз безопасности М2 работают в проводном режиме и имеют доверенные
внутренние интерфейсы.
 Сообщество, содержащее шлюзы безопасности М1 и М2, работает в проводном режиме.
 Хост 1, расположенный за шлюзом безопасности S1, соединяется через VPN-туннель с хостом 2,
расположенным за шлюзом безопасности М1.
 МЕР настроен для шлюзов безопасности М1 и М2, при этом шлюз безопасности М1 является первичным
шлюзом безопасности, а шлюз безопасности М2 – резервным. Подробнее о МЕР см. «VPN с
множественными точками входа» (на стр. 128)
В данном случае, если шлюз безопасности М1 выходит из строя, соединение перебрасывается на шлюз
безопасности М2. Пакет, отправленный хостом 2, перенаправится маршрутизатором, находящимся за
шлюзом безопасности М1, к шлюзу безопасности М2, поскольку шлюз безопасности М2 назначен резервным
шлюзом безопасности. В отсутствие проводного режима шлюз безопасности М2 был бы подвергнут проверке
состояния соединения, и связь была бы прервана, поскольку пакеты, приходящие на шлюз безопасности, с
которым связь была инициирована через другой шлюз безопасности, считались бы «неисправными».
Поскольку внутренний интерфейс шлюза безопасности М2 является «доверенным», а в сообществе
действует проводной режим, то проверка состояния соединения не выполняется, и шлюз безопасности М2
успешно подхватывает связь без потери информации.

Проводной режим в VPN на основе маршрутов


В данной ситуации:

Руководство администратора VPN R75.40VS | 90


VPN Site-to-Site

Хост 1 Центральный шлюз С

Шлюз безопасности А Хост 2


Интернет Шлюз безопасности В

 На центральном шлюзе безопасности С активен проводной режим (но не задан внутренний доверенный
интерфейс).
 Сообщество работает в проводном режиме.
 Хост 1, расположенный за сателлитным шлюзом безопасности А, стремится открыть соединение через
VPN-туннель с хостом 2, расположенным за шлюзом безопасности В.
В сателлитном сообществе центральные шлюзы безопасности используются для маршрутизации трафика
между сателлитными шлюзами безопасности сообщества.
В данном случае, трафик от сателлитных шлюзов безопасности только перенаправляется шлюзом
безопасности С, не имея возможности пройти через его брандмауэр. Таким образом, нет необходимости
проводить проверку состояния соединения на шлюзе безопасности С. Поскольку сообщество и шлюз
безопасности С работают в проводном режиме, что делает их доверенными, проверка состояния соединения
пропускается. Однако, эта проверка выполняется на шлюзах безопасности А и В.

Проводной режим между двумя VPN-сообществами


В данной ситуации:

Руководство администратора VPN R75.40VS | 91


VPN Site-to-Site

Хост 1 Интернет

Сообщество 1 Сообщество 2
Шлюз безопасности А Хост 2
Шлюз безопасности С Шлюз безопасности В

 Шлюз безопасности А принадлежит сообществу 1.


 Шлюз безопасности В принадлежит сообществу 2.
 Шлюз безопасности С принадлежит сообществам 1 и 2.
 На центральном шлюзе безопасности С активен проводной режим (но не задан внутренний доверенный
интерфейс).
 Оба сообщества работают в проводном режиме.
 Хост 1, расположенный за сателлитным шлюзом безопасности А, стремится открыть соединение через
VPN-туннель с хостом 2, расположенным за шлюзом безопасности В.
Проводной режим можно активировать для маршрутизации VPN-трафика между двумя шлюзами
безопасности, не являющимися членами одного сообщества. Шлюз безопасности С принадлежит обоим
сообществам, а потому их обоих распознает как доверенные. Когда хост 1 позади шлюза безопасности А
инициирует соединение с хостом 2 позади шлюза безопасности В, центральный шлюз безопасности С
используются для маршрутизации трафика между сообществами. Поскольку трафик фактически не попадает
в шлюз безопасности С, нет необходимости в проверке состояния соединения на этом шлюзе. Однако, эта
проверка выполняется на шлюзах безопасности А и В.

Особенности проводного режима


На сегодняшний день проводной режим поддерживают только платформы SecurePlatform и Gaia.

Настройка проводного режима


Проводной режим настраивается в двух местах:
1. Свойства сообщества (ячеистого или звездообразного)
2. Свойства шлюза безопасности

Включение проводного режима в VPN-сообществе


1. В SmartDashboard нажмите Управление > VPN-сообщества. Появится окно VPN-сообщества.
2. Выберите настраиваемое сообщество и нажмите Изменить…
3. Дважды щелкните Дополнительные настройки для просмотра различных опций.

Руководство администратора VPN R75.40VS | 92


VPN Site-to-Site
4. Щелкните Проводной режим (Wire Mode). Откроется окно с тем же названием.
5. Для включения проводного режима в сообществе выберите Разрешить непроверенный
зашифрованный трафик между интерфейсами проводного режима членов сообщества (Allow
uninspected encrypted traffic between Wire mode interfaces of the Community's members).
6. Для включения маршрутизации проводного режима выберите Маршрутизация проводного режима –
Разрешить членам направлять непроверенный зашифрованный трафик в конфигурациях VPN-
маршрутизации (Wire Mode Routing - Allow members to route uninspected encrypted traffic in VPN
routing configurations).

Включение проводного режима на конкретном шлюзе безопасности


1. В SmartDashboard нажмите Управление > Сетевые объекты. Появится окно Сетевые объекты.
2. Выберите настраиваемый шлюз безопасности и нажмите Изменить…
3. Дважды щелкните VPN, чтобы расширить дерево VPN. Выберите VPN Дополнительно – отобразится
соответствующее окно.
4. Для включения проводного режима на шлюзе безопасности выберите Поддержка проводного режима
(Support Wire Mode).
5. Нажмите Добавить, чтобы включить интерфейсы в число доверенных для выбранного шлюза
безопасности.
6. Нажмите Вести журнал трафика в проводном режиме (Log Wire mode traffic) для ведения журнала
действий в проводном режиме.

Руководство администратора VPN R75.40VS | 93


Глава 10
Установление направленной VPN
В этой главе
ОБЗОР НАПРАВЛЕННОЙ VPN .......................................................................................................................... 94
УСТАНОВЛЕНИЕ НАПРАВЛЕНИЯ В ПРЕДЕЛАХ СООБЩЕСТВА................................................................... 94
ОБЪЕКТЫ, НАСТРАИВАЕМЫЕ ПО НАПРАВЛЕНИЮ...................................................................................... 95
УСТАНОВЛЕНИЕ НАПРАВЛЕНИЯ МЕЖДУ СООБЩЕСТВАМИ ....................................................................... 96
НАСТРОЙКА НАПРАВЛЕННОЙ VPN В ПРЕДЕЛАХ СООБЩЕСТВА ............................................................... 96
НАСТРОЙКА НАПРАВЛЕННОЙ VPN МЕЖДУ СООБЩЕСТВАМИ ................................................................... 97

Обзор направленной VPN


Когда в столбце VPN базы правил политики безопасности выбирают VPN-сообщество, IP-адреса источника и
адресата могут принадлежать любому шлюзу безопасности сообщества. Иначе говоря, трафик
двунаправленный; любой шлюз безопасности может быть источником соединения, любой шлюз безопасности
может быть точкой назначения. А что если администратор (подчиняясь политике безопасности компании)
принудительно направит трафик лишь в одну сторону? Или позволит движение зашифрованного трафика к
шлюзу безопасности или от шлюза безопасности, не входящего в VPN-сообщество? Чтобы иметь такую
возможность, внедряется направленная VPN.
Направленная VPN указывает, где должен быть адрес источника и где должен быть адрес пункта назначения.
Таким образом, установление направления может происходить:
 в рамках одного VPN-сообщества;
 между VPN-сообществами.

Установление направления в пределах сообщества


На рисунке показано примерное VPN-сообщество с ячеистой топологией, названное MyIntranet. VPN-трафик в
сети MyIntranet двунаправленный; т. е., любой из шлюзов безопасности (или хостов позади шлюзов
безопасности в VPN-доменах) может быть как источником, так и адресатом связи.

Источник Адресат VPN Служба Действие Слежение

Любой Любой MyIntranet=>MyIntranet telnet Принять Журнал


VPN Site-to-Site

MyIntranet=>internal_clear

internal_clear=>MyIntranet

Любой Любой MyIntranet telnet Принять Журнал

Условия совпадения представлены серией составных объектов. Выполнение этих условий устремляет
трафик в следующих направлениях:
 В VPN-сообщество и из него посредством VPN-маршрутизации (MyIntranet=>MyIntranet)
 Из сообщества к локальным VPN-доменам (MyIntranet=>internal_clear)
 Из локальных VPN-доменов в VPN-сообщество (internal_clear=>MyIntranet)

Объекты, настраиваемые по направлению


В таблице приведены все настраиваемые по направлению объекты, в том числе новые объекты, созданные
для направленной VPN.

Имя объекта Значение

Сообщество с удаленным доступом


Remote_Access_Community
Обычное звездообразное/ячеистое сообщество
SiteToSiteVPN
Любой трафик
Any Traffic

Весь трафик от шлюза безопасности к шлюзу безопасности


All_GwToGw

Все сообщества (новый объект)


All_Communities

Трафик снаружи сообщества


External_clear

Трафик между локальными доменами в рамках сообщества


Internal_clear

Примечание. Нешифрованные текстовые соединения, исходящие от следующих объектов, не


подлежат установлению направления:
 Any_Traffic
 External_Clear
 Internal_Clear
Не существует предела количеству VPN-направлений, которые можно настроить одним правилом. Вообще,
если у вас много установленных направлений, старайтесь заменять их стандартными двунаправленными
условиями.

Установление направления между сообществами


Установление направления может происходить и между VPN-сообществами. Рассмотрим два VPN-
сообщества: Вашингтон и Лондон.

Руководство администратора VPN R75.40VS | 95


VPN Site-to-Site

Ячеистая сеть Вашингтон


Точка принудительного установления
Звездообразная сеть Лондон

Источник Адресат VPN Служба Действие

Любой Любой Вашингтон => Лондон Любая Принять

Вашингтон – это ячеистое сообщество, а Лондон – VPN-звезда. В столбце VPN базы правил политики
безопасности введено правило направления VPN. Это значит, что для удовлетворения этому правилу
источник VPN-соединения должен находиться в сети Вашингтон, а адресат – в сети Лондон.
Это не значит, что обратные соединения из Лондона в Вашингтон запрещены (трехэтапное квитирование в
начале каждого TCP-соединения требует обратной связи); но первый пакет должен исходить из сети
Вашингтон. Если один их хостов звезды Лондон попробует открыть соединение с хостом из сети Вашингтон,
связь будет разорвана.
Такое установление направления не влияет на топологию сети Вашингтон или Лондон. Можно считать, что
оно происходит где-то между сообществами.

Настройка направленной VPN в пределах сообщества


Настройка направленной VPN в пределах сообщества
1. На странице Глобальные свойства > VPN > Дополнительно выберите Разрешить в столбце VPN
условие направленности VPN (Enable VPN Directional Match in VPN Column).
2. В столбце VPN соответствующего правила щелкните правой кнопкой по VPN-сообществу. Из
выпадающего меню выберите Изменить ячейку… (Edit Cell…) Откроется окно Условия соответствия
VPN.
3. Выберите Учитывать трафик лишь в этом направлении (Match traffic in this direction only), затем
нажмите Добавить… Откроется окно Условия соответствия направленной VPN.
4. Из выпадающего меню Учитывать трафик к шлюзу безопасности от (Match on traffic reaching the
Security Gateway from) выберите объект для internal_clear (источник).
5. В блоке Учитывать трафик от шлюза безопасности к (Match on traffic leaving the Security Gateway
to) выберите соответствующий объект сообщества (адресат).
6. Добавьте другое условие направления, в котором соответствующий объект сообщества был как
источником, так и адресатом. Это позволит прохождение трафика от локального домена в сообщество и в
пределах сообщества.
7. Нажмите OK.

Настройка направленной VPN между сообществами


Настройка направленной VPN между сообществами
1. На странице Глобальные свойства > VPN > Дополнительно выберите Разрешить в столбце VPN
условие направленности VPN (Enable VPN Directional Match in VPN Column).
2. В столбце VPN соответствующего правила щелкните правой кнопкой. Из выпадающего меню выберите
Изменить ячейку… (Edit Cell…) или Добавить направление… (Add Direction…) Откроется окно
Условия соответствия VPN.

Руководство администратора VPN R75.40VS | 96


VPN Site-to-Site
3. Нажмите Добавить… Откроется окно Условия соответствия направленной VPN.
4. Из выпадающего меню слева выберите источник соединения.
5. Из выпадающего меню справа выберите адресата соединения.
6. Нажмите OK.

Руководство администратора VPN R75.40VS | 97


Глава 11
Выбор линии связи
В этой главе
ОБЗОР ВЫБОРА ЛИНИИ СВЯЗИ...................................................................................................................... 98
НАСТРОЙКА ВЫБОРА IP-АДРЕСА ПО УДАЛЕННОМУ УЗЛУ .......................................................................... 98
НАСТРОЙКА ВЫБОРА ИСХОДЯЩЕГО МАРШРУТА...................................................................................... 100
НАСТРОЙКА IP-АДРЕСА ИСТОЧНИКА ........................................................................................................... 102
ОТСЛЕЖИВАНИЕ ИСХОДЯЩЕЙ ЛИНИИ СВЯЗИ ........................................................................................... 102
СИТУАЦИИ С ВЫБОРОМ ЛИНИИ СВЯЗИ ...................................................................................................... 102
ВЫБОР ЛИНИИ СВЯЗИ НА ОСНОВЕ СЛУЖБ ................................................................................................ 106
ДОВЕРЕННЫЕ ЛИНИИ СВЯЗИ ....................................................................................................................... 110
ЛИНИИ СВЯЗИ ПО ТРЕБОВАНИЮ (ODL) ....................................................................................................... 113
ВЫБОР ЛИНИИ СВЯЗИ И ISP-РЕЗЕРВИРОВАНИЕ ....................................................................................... 114
ВЫБОР ЛИНИИ СВЯЗИ ПРИ НАЛИЧИИ УСТРОЙСТВ НЕ CHECK POINT ..................................................... 116

Обзор выбора линии связи


Выбор линии связи – это метод определения интерфейса, используемого для входящего и исходящего VPN-
трафика, а также наилучшего пути для трафика. Владея механизмами выбора линии связи, администратор
может выбирать, какие IP-адреса применять для VPN-трафика на каждом шлюзе безопасности.
Выбор линии связи имеет много конфигурационных настроек, с помощью которых можно управлять VPN-
трафиком. Сюда входят:
 Применение зондирования для выбора линий связи согласно их доступности.
 Применение распределения нагрузки для выбора линии связи с целью распределения VPN-трафика
по доступным каналам (для шлюзов безопасности версии R71 или выше).
 Выбор линии связи на основе обслуживания с целью контроля использования ширины канала (для
шлюзов безопасности версии R71 или выше).
Конфигурационные настройки клиентов удаленного доступа могут быть заданы вместе с конфигурацией Site-
to-Site или отдельно от нее. Подробнее см. «Выбор линии связи для клиентов удаленного доступа» (на стр.
246).

Настройка выбора IP-адреса по удаленному узлу


Существует несколько методов узнать, как удаленные узлы определяют IP-адрес локального шлюза
безопасности. Эти настройки устанавливаются в Свойства шлюза безопасности > VPN IPSec > Выбор
линии связи. При таких настройках удаленные узлы могут соединяться с локальным шлюзом безопасности.
Всегда использовать этот IP-адрес
Настраивается конкретный IP-адрес, который используется всегда. Варианты:
 Основной адрес. VPN-туннель создается с основным IP-адресом шлюза безопасности, указанным в
поле IP-адрес на странице Общие свойства шлюза безопасности.
 Избранный адрес из таблицы топологии. VPN-туннель создается со шлюзом безопасности,
использующим избранный IP-адрес, выбранный из выпадающего меню, в котором числятся IP-адреса,
настроенный на странице Топология шлюза безопасности.
 Статически «NAT-ированный» IP. VPN-туннель создается с использованием NAT-ированного адреса.
Этот адрес не обязательно должен быть перечислен на вкладке топологии.
Расчет IP на основании топологии сети
Это метод расчета IP-адреса, который использует VPN-туннель, на основании расположения удаленного
узла.
Использование разрешения имен DNS
Этот метод необходим для шлюзов безопасности с динамически присваиваемым IP-адресом (DAIP). VPN-
туннель к шлюзу безопасности DAIP может быть сформирован только с помощью преобразования имен DNS
(DNS resolving), поскольку IP-адрес шлюза безопасности DAIP заранее неизвестен. Если применять этот
метод для не-DAIP шлюзов безопасности, IP-адрес должен быть определен на вкладке Топология. Без
VPN Site-to-Site
разрешения DNS шлюз безопасности DAIP может только инициировать первое соединение между узлами.
Второе соединение может исходить от удаленного шлюза безопасности, поскольку IP-адрес шлюза
безопасности DAIP не изменился. Здесь есть варианты:
 Полное имя хоста. Введите полное «полностью уточненное доменное имя» (FQDN – Fully Qualified
Domain Name). Имя хоста, используемое DNS, «Security Gateway_name.domain_name». Например, если
имя объекта «john», а домена – «smith.com», то FQDN будет «john.smith.com».
 Имя шлюза безопасности и имя домена (указано в глобальных свойствах). Имя шлюза
безопасности указано на странице Общие свойства шлюза безопасности, а имя домена – на странице
глобальных свойств.
Использование зондирования. Режим резервирования
Когда на шлюзе безопасности для VPN доступно более одного IP-адреса, механизм выбора линии связи
может задействовать метод зондирования RDP, чтобы определить, какой канал будет использоваться. Метод
зондирования RDP внедряется с применением собственного протокола, который использует UDP-порт 259.
Это собственный протокол Check Point, он работает только с объектами Check Point. (Обратите внимание, что
он не соответствует RDP, как указано в RFC 908/1151). Если некоторые IP-адреса вы не желаете подвергать
зондированию, (т. е., внутренние IP-адреса), их можно удалить из списка зондируемых IP-адресов. Как только
шлюз безопасности обнаружит доступность линии связи, будет сделан выбор линии связи для соединения
согласно следующим режимам резервирования.
 Высокая доступность (по умолчанию)
В режиме высокой доступности VPN-туннель использует для отклика первый IP-адрес, либо первичный
IP-адрес, если таковой настроен и активен. Если выбранный IP-адрес прекращает отвечать, соединение
переключается на другой отвечающий IP-адрес. Если настроен первичный IP-адрес, VPN-туннель
останется на резервном IP-адресе, пока первичный не будет восстановлен.
Обратите внимание, что если настроено одноразовое зондирование, то VPN-туннель останется на
первом выбранном IP-адресе до следующей установки политики. См. методы непрерывного
зондирования и одноразового зондирования, описанные ниже.
 Распределение нагрузки
В режиме распределения нагрузки зашифрованный трафик распределяется между всеми доступными
линиями связи. Каждое новое соединения, готовое к шифрованию, использует следующий доступный
канал – по принципу карусели. Когда линия связи становится занятой, все ее соединения
распределяются между прочими свободными линиями связи. Доступность линии определяется
зондированием RDP.
Удаленный шлюз безопасности, откликающийся на соединение, направит ответный трафик по тому же
маршруту, по которому пришел входной сигнал, если эта линия связи все еще доступна.
Хотя в режиме распределения нагрузки трафик VPN-туннеля может быть направлен по нескольким
каналам, генерируется лишь один VPN-туннель. Сеансы IKE направляются произвольным образом
через один из доступных каналов связи.
Распределение нагрузки поддерживается шлюзами безопасности версии R71 и выше. Если шлюз
безопасности версии R71 и выше настроен на использование режима распределения нагрузки с
резервированием, то шлюзы безопасности версии раньше R71, направляя трафик на шлюз
безопасности R71 или выше, будут использовать режим высокой доступности с резервированием.
Для входящего трафика режим распределения нагрузки доступен под всеми платформами. Для
исходящего трафика VPN-трафик между узлами, настроенными на распределение нагрузки, не будет
ускоряться устройствами IPSO. Устройства UTM-1 Edge не поддерживают распределения нагрузки.
Настройка зондирования
Дополнительные настройки, касающиеся зондирования задаются в меню Выбор линии связи > Выбор IP по
удаленному узлу > Использовать зондирование > Настроить > Параметры зондирования (Link
Selection > IP Selection by Remote Peer > Use probing > Configure > Probing Settings)
 Зондировать все адреса, определенные на вкладке топологии (Probe all addresses defined in the
topology tab) – включить в зондирование все адреса, определенные на вкладке топологии шлюза
безопасности.
 Зондировать следующие адреса (Probe the following addresses) – включить в зондирование только
указанные адреса.
 Первичный адрес (Primary address) – необязательно; чтобы выбрать первичный адрес, отметьте этот
флажок и выберите один из включенных IP-адресов из выпадающего меню. Первичный IP-адрес
используется только в режиме зондирования высокой доступности. Если настроено распределение
нагрузки, первичный адрес игнорируется. Активация первичного IP-адреса никак не влияет на IP-адрес,
выбранный для исходящего трафика. Если удаленный шлюз безопасности подключается к другому
шлюзу безопасности, для которого определен первичный IP-адрес, то удаленный шлюз безопасности
соединится с первичным IP-адресом (если он активен) независимо от скорости (запаздывания) сети или
метрики маршрута.
 Использовать метод зондирования
Выберите один из методов зондирования.

Руководство администратора VPN R75.40VS | 99


VPN Site-to-Site

 Непрерывное зондирование (по умолчанию). После начала сеанса все возможные IP-адреса
назначения непрерывно получают RDP-пакеты. Зондирование RDP включается при открытии
соединения и продолжается как фоновый процесс.
 Одноразовое зондирование. После начала сеанса все возможные IP-адреса назначения
принимают RDP-сеанс с целью проверки маршрута. Эти результаты используются до следующей
установки политики.
Примечание. RDP-пакеты UDP не шифруются. Механизм RDP служит только для проверки
связи.

Последний известный доступный удаленный IP-адрес


IP-адрес, используемый шлюзом безопасности во время успешного IKE-согласования с удаленным шлюзом
безопасности, последний использует как IP-адрес назначения для следующей передачи IPSec и
инициируемых им согласований IKE. Это действительно лишь тогда, когда функция выбора линии связи не
настроена на зондирование.

Настройка выбора исходящего маршрута


Существует несколько способов определить, какой путь следует использовать для исходящего трафика при
соединении к удаленному узлу. Эти настройки задаются в меню Свойства шлюз безопасности > VPN IPSec
> Выбор линии связи.

При инициировании туннеля


 Таблица маршрутизации операционной системы (по умолчанию). При этом методе доступный
маршрут берется из таблицы маршрутизации с минимальной метрикой и максимально подходящий для
трафика через VPN-туннель.
 Зондирование на основе маршрутов. При данном методе доступный путь также ищется в таблице
маршрутизации. Это должен быть максимально подходящий путь с минимальной метрикой. Однако,
перед выбором маршрута его проверяют на доступность путем зондирования RDP. Затем шлюз
безопасности выбирает наиболее подходящий (максимальная длина префикса) активный путь с
минимальной метрикой. Данный метод рекомендован, если в наличии свыше одного внешнего
интерфейса.
Если вы выбрали для параметра Использовать зондирование с распределением нагрузки (Use
probing with Load Sharing) значение Выбор IP по удаленному узлу (IP Selection by Remote Peer), то
ваш выбор влияет также на выбор линии связи путем Зондирования на основе маршрутов (Route
based probing). В этом случае Зондирование на основе маршрутов распределяет исходящий
зашифрованный трафик между доступными линиями связи. Возможные линии связи с удаленным
шлюзом безопасности берутся из таблицы маршрутизации, а их доступность проверяется
зондированием RDP. Каждое новое соединение, готовое к шифрованию, использует следующую
доступную линию связи по принципу карусели.
Зондирование на основе маршрутов разрешает использование Линий связи по требованию (ODL, On
Demand Link), которые включаются в случае выхода из строя всех первичных линий. Для активации
ODL можно запустить сценарий, когда все другие линии большего приоритета недоступны. Подробнее
см. «Линии связи по требованию (ODL)» (на стр. 109).
Во время сеансов IKE и RDP зондирование на основе маршрутов использует тот де IP-адрес и
интерфейс для ответного трафика.
Зондирование на основе маршрутов поддерживается платформами SecurePlatform, Linux и IPSO.VPN-
трафик между узлами в режиме зондирования с распределением нагрузки при настроенном
зондировании на основе маршрутов не будет ускоряться устройствами IPSO

При отклике на туннель, инициированный удаленно


При отклике на туннель, инициированный удаленно, существует два варианта выбора интерфейса и
следующего используемого объекта. Эти настройки релевантны только для сеансов IKE и RDP.
Соответствующие настройки задаются в окне Выбор линии связи > Выбор исходящего маршрута >
Настройка > Выбор линии связи – ответный трафик (Link Selection > Outgoing Route Selection > Setup >
Link Selection - Responding Traffic).
 Использовать конфигурацию исходящего трафика. Эта опция означает выбор интерфейса по тому
же методу, который указан в разделе Выбор исходящего маршрута страницы Выбор линии связи.
 Отвечать с того же интерфейса. Эта опция предусматривает отсылку ответного трафика через тот же
интерфейс и объект, через которые сигнал был получен
Примечание. При включенном зондировании на основе маршрутов выбирается метод
Отвечать с того же интерфейса. Изменить выбор невозможно.

Руководство администратора VPN R75.40VS | 100


VPN Site-to-Site

Использование зондирования на основе маршрутов


Локальный шлюз безопасности, использующий зондирование RDP, рассматривает все возможные пути
между собой и удаленным шлюзом безопасности. После этого шлюз безопасности принимает решение о
наиболее эффективном маршруте между двумя шлюзами безопасности.

Удаленный шлюз безопасности В


Интернет

Шлюз безопасности А

В данной ситуации шлюз безопасности А имеет два внешних интерфейса: 192.168.10.10 и 192.168.20.10. У
удаленного шлюза безопасности В тоже два внешних интерфейса: 192.168.30.10 и 192.168.40.10

Адресат Маска сети Следующий пункт Метрика

192.168.40.10 255.255.255.0 192.168.10.20 1

192.168.40.10 255.255.255.0 192.168.20.20 2

192.168.30.10 255.255.255.0 192.168.10.20 3

192.168.30.10 255.255.255.0 192.168.20.20 4

Для шлюза безопасности В таблица маршрутизации:

Адресат Маска сети Следующий пункт Метрика

192.168.20.10 255.255.255.0 192.168.40.20 1

192.168.20.10 255.255.255.0 192.168.30.20 2

192.168.10.10 255.255.255.0 192.168.40.20 3

192.168.10.10 255.255.255.0 192.168.30.20 4

Если доступны все маршруты для исходящего трафика от шлюза безопасности А, то минимальной метрикой
(высшим приоритетом) обладает маршрут 192.168.10.10 – 192.168.40.10, поэтому он является самым
предпочтительным.

Руководство администратора VPN R75.40VS | 101


VPN Site-to-Site

Настройка IP-адреса источника


IP-адрес источника, используемый для исходящих пакетов, настраивается для сеансов, инициированных
шлюзом безопасности. Соответствующие настройки содержатся в меню Свойства шлюза безопасности >
VPN IPSec > Выбор линии связи > Выбор исходящего маршрута > Настройки IP-адреса источника.
При инициировании VPN-туннеля IP-адрес источника задается одним из следующих способов:
 Автоматически (получается методом выбора IP-адреса по удаленному узлу). IP-адрес источника
исходящего трафика получается по методу, который выбран в разделе Выбор IP-адреса по
удаленному узлу.
 Если в разделе Выбор IP-адреса по удаленному узлу выбран Основной адрес или Избранный
адрес из таблицы топологии, то при инициировании VPN-туннеля назначается IP-адрес
источника, указанный для этого метода.
 Если в разделе Выбор IP-адреса по удаленному узлу выбран вариант Расчет IP на основании
топологии сети, Статически «NAT-ированный» IP, Использование разрешения имен DNS или
Использование зондирования, то при инициировании VPN-туннеля в качестве IP-адреса
источника выступает IP-адрес избранного исходящего интерфейса
 Вручную:
 Основной IP-адрес. IP-адрес источника берется со страницы Общие свойства шлюза
безопасности.
 Избранный адрес из таблицы топологии. IP-адрес, выбранный из выпадающего меню, становится
IP-адресом источника.
 IP-адрес избранного интерфейса. IP-адрес источника – это тот же IP-адрес, что и у интерфейса,
через который был направлен трафик.
Эти настройки релевантны для сеансов RDP и IKE. При ответе на сеанс IKE воспользуйтесь атрибутом
reply_from_same_IP (по умолчанию: true), чтобы применить настройки, заданные в окне Настройки IP-
адреса источника, или чтобы ответить с того же IP-адреса.
Примечание. При включенном зондировании на основе маршрутов у атрибута
reply_from_same_IP будет значение true.

Отслеживание исходящей линии связи


При включенном Отслеживании исходящей линии связи на локальном шлюзе безопасности, последний
отправляет журнал событий при каждом новом принятии решения о разрешении относительно одного из его
удаленных VPN-узлов. Если на локальном шлюзе безопасности для разрешения удаленного узла настроено
значение Использовать зондирование, или если на локальном шлюзе безопасности включено
зондирование на основе маршрутов, то записи в журнал формируются при каждом изменении в разрешениях.
Например, если используемая линия связи становится недоступной и выбирается новая доступная линия, это
фиксируется в журнале событий.

Ситуации с выбором линии связи


Выбор линии связи используется в множестве сред. В данном пункте описаны различные ситуации, в которых
так или иначе происходит настройка выбора линии связи.

Шлюз с одним внешним интерфейсом


Самый простой случай. Локальный шлюз безопасности имеет единственный внешний интерфейс для VPN.

Руководство администратора VPN R75.40VS | 102


VPN Site-to-Site

Шлюз безопасности Check Point


Интернет

Шлюз безопасности Check Point

Как удаленные шлюзы безопасности выбирают IP-адрес локального шлюза безопасности для организации
VPN-трафика?
Поскольку для VPN доступен лишь один интерфейс, для определения, как удаленные узлы узнают IP-адрес
локального шлюза безопасности, на странице выбора линии связи в разделе Выбор IP-адреса по
удаленному узлу:
 задайте Основной адрес или выберите IP-адрес из выпадающего меню Избранный адрес из таблицы
топологии;
 если IP-адрес расположен позади статического NAT-устройства, выберите Статически «NAT-
ированный» IP-адрес.

Шлюз с несколькими IP-адресами, используемыми разными сторонами


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

Руководство администратора VPN R75.40VS | 103


VPN Site-to-Site

Удаленный шлюз безопасности А


Локальный шлюз безопасности
Удаленный шлюз безопасности В

Локальный шлюз безопасности имеет два IP-адреса, которые используются для VPN. Один интерфейс
используется для VPN с удаленным шлюзом безопасности А, а другой – для шлюза безопасности В.
Чтобы определить, как удаленные шлюзы безопасности узнают IP-адрес локального шлюза безопасности,
включите одноразовое зондирование с высокой доступностью в режиме резервирования. Поскольку для
каждого удаленного шлюза безопасности доступен только один IP, зондирование достаточно проводить лишь
раз.

Шлюз с интерфейсом позади статического NAT-устройства


В данной ситуации у локального шлюза безопасности два внешних интерфейса, доступных для VPN. Адрес
интерфейса eth0 транслируется с помощью устройства NAT.

Локальный шлюз безопасности Удаленный шлюз безопасности

Чтобы определить, как удаленные шлюзы безопасности узнают IP-адрес локального шлюза безопасности,
включите непрерывное зондирование с высокой доступностью в режиме резервирования. Для
зондирования IP-адреса статического NAT его следует добавить в список Зондировать следующие адреса
в окне Настройки зондирования.

Руководство администратора VPN R75.40VS | 104


VPN Site-to-Site

Использование распределения нагрузки


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

Распределение нагрузки с несколькими внешними интерфейсами на каждом


конце
В следующей ситуации локальный и удаленный шлюзы безопасности имеют по два внешних интерфейса,
доступных для VPN-трафика.

Локальный шлюз безопасности Удаленный шлюз безопасности

Чтобы воспользоваться обоими внешними интерфейсами, распределяя VPN-трафик между всеми


доступными линиями связи, воспользуйтесь на обоих шлюзах безопасности зондированием и
распределением нагрузки в режиме резервирования. Можно также указать, чтобы зондированию
подвергались лишь конкретные внешние интерфейсы, внеся только их в список Зондировать следующие
адреса в окне Настройки зондирования. Если одна линия связи выходит из строя, трафик автоматически
переадресовывается на другую линию.
Чтобы задействовать эту конфигурацию, проверьте, чтобы таблица маршрутизации позволяла прямое и
обратное прохождение пакетов между интерфейсами eth0 и между интерфейсами eth1. Затем механизм
выбора линии связи может переадресовать VPN-трафик между этими доступными линиями связи.

Распределение нагрузки с несколькими внешними интерфейсами на одном


конце
В следующей ситуации локальный шлюз безопасности имеет два внешних интерфейса, доступных для VPN-
трафика. У удаленного шлюза безопасности один внешний интерфейс для VPN-трафика.

Руководство администратора VPN R75.40VS | 105


VPN Site-to-Site

Локальный шлюз безопасности Удаленный шлюз безопасности

Для использования обоих интерфейсов с распределением VPN-трафика между доступными линиями связи,
воспользуйтесь на локальном шлюзе безопасности зондированием с распределением нагрузки в режиме
резервирования. Тогда удаленный шлюз безопасности распределит исходящий VPN-трафик между
интерфейсами eth0 и eth1 локального шлюза безопасности.
Если значение параметра Выбор исходящего маршрута оставлено по умолчанию Таблица
маршрутизации операционной системы, локальный шлюз безопасности использует для исходящего VPN-
трафика только один локальный интерфейс; это будет маршрут с минимальной метрикой и максимально
подходящие, чтобы пакеты добрались до единственного IP-адреса удаленного шлюза безопасности, исходя
из таблицы маршрутизации.
Если исходящий от локального шлюза безопасности трафик также необходимо распределить по обеим
исходящим линиям связи, выберите значение Зондирование на основе маршрутов для параметра Выбор
исходящего маршрута на странице Выбор линии связи локального шлюза безопасности.

Выбор линии связи на основе служб


Выбор линии связи на основе служб предоставляет администраторам возможность контролировать
исходящий VPN-трафик и использование полосы пропускания – при решении задачи маршрутизации
исходящего трафика – за счет присвоения службы или группы служб конкретному интерфейсу.
Зашифрованный трафик исходящего соединения направляется через соответствующим образом
настроенный интерфейс согласно службе, инициировавшей отправку. Линии связи к удаленному шлюзу
безопасности берутся из таблицы маршрутизации с учетом доступности, которая проверяется путем
зондирования RDP.
Если все линии связи интерфейса, которому присвоена конкретная служба, прекращают откликаться на
зондирование RDP по умолчанию происходит переключение линий, а и в любом другом режиме
зондирования. Когда линия, проходящая через присвоенный службе интерфейс, восстановится, новые
исходящие соединения пойдут через нее, но существующие сеансы связи до самого их завершения будут
проходить через резервную линию.
Можно настроить трафик конкретной службы так, чтобы переключения не происходило. В этом случае трафик
будет направляться только через интерфейсы, которые сопоставлено со службами, даже если они
прекратили реагировать на RDP.
Если одна и та же служба присвоена нескольким интерфейсам, трафик этой службы будет распределяться
между ними. Каждое новое зашифрованное соединение использует следующую доступную линию связи по
принципу карусели.

Руководство администратора VPN R75.40VS | 106


VPN Site-to-Site
Весь трафик от служб, не присвоенных конкретному интерфейсу, распределяется между остальными
интерфейсами. Если все линии, проходящие через эти интерфейсы, неактивны, трафик распределяется
между интерфейсами, настроенными под конкретные службы.
Выбор линии связи на основе служб требует включения следующих функций:
 Выбор IP-адреса по удаленному узлу – распределение нагрузки в режиме резервирования
 Выбор исходящего маршрута – зондирование на основе маршрутов
 Конфигурационный файл выбора линии связи на основе служб на сервере управления
Выбор линии связи на основе служб поддерживается на шлюзах безопасности версии R71 или выше. Эта
функция поддерживается платформами SecurePlatform, Linux и IPSO. VPN-трафик между узлами, на которых
настроен выбор линии связи на основе служб, не ускоряется акселераторами IPSO. Выбор линии связи на
основе служб не поддерживается на устройствах UTM-1 Edge.

Настройка выбора линии связи на основе служб


Чтобы настроить выбор линии связи на основе служб, проделайте следующее.
1. На странице Выбор линии связи в разделе Выбор IP-адреса по удаленному узлу выберите:
 Использовать зондирование. Режим резервирования
 Распределение нагрузки
2. В разделе Выбор исходящего маршрута выберите Зондирование на основе маршрутов.
Отредактируйте конфигурационный файл $FWDIR/conf/vpn_service_based_routing.conf на
сервере управления.
В каждой строке конфигурационного файла укажите целевой шлюз безопасности, интерфейс для
исходящей маршрутизации и службу (или группу служб), направляющую пакеты через этот интерфейс.
Применяйте имена, определенные в графическом интерфейсе SmartDashboard. Заполните все
подробности для каждого шлюза безопасности, на котором требуется настроить выбор линии связи на
основе служб.
Речь идет о следующих полях:
 Шлюз (Gateway) – имя шлюза безопасности (имя шлюза безопасности VPN или кластера).
 Интерфейс (Interface) – имя интерфейса.
 Служба (Service) – имя службы или группы служб.
 don’t_failover – (необязательно) если данная строка присутствует, трафик настроенной службы
будет направляться только через интерфейсы, настроенные для этой службы, не переключаясь
на другой интерфейс.

Ситуации выбора линии связи на основе служб


Ниже приведены примеры использования выбора линии связи на основе служб

Выбор линии связи на основе служб с двумя интерфейсами на каждом


конце
В приведенной ниже ситуации у локального и удаленного шлюзов безопасности по два внешних интерфейса
для VPN-трафика.

Руководство администратора VPN R75.40VS | 107


VPN Site-to-Site

Локальный шлюз безопасности London_GW Удаленный шлюз безопасности Paris_GW

В данном примере интерфейс eth1 обоих шлюзов безопасности предназначен для HTTP- и FTP-трафика.
Остальной трафик направляется на интерфейс eth0.
Если доступная линия связи через eth1 прекращает откликаться на зондирование RDP, HTTP- и FTP-трафик
переключится на eth0. Можно задать, чтобы HTTP- и FTP-трафик направлялся через eth1 даже тогда, когда
линия связи eth1 перестает откликаться. Это задается при редактировании конфигурационного файла выбора
линии связи на основе служб за счет включения флага dont_failover.
Весь остальной трафик, не являющийся HTTP или FTP, будет направляться через eth0. Если линия связи
через eth0 прекратит откликаться на зондирование RDP, весь трафик будет направлен через eth1.
Так выглядит конфигурационный файл выбора линии связи на основе служб для описанной среды.

Шлюз Интерфейс Служба [dont_failover]

London_GW eth1 http

London_GW eth1 ftp

Paris_GW eth1 http

Paris_GW eth1 ftp

Кроме того, в SmartDashboard можно создать группу служб, включающую службы HTTP и FTP. В примере
ниже эта группа называется http_ftp_grp. C этой группой конфигурационный файл выбора линии связи на
основе служб для описанной среды будет выглядеть следующим образом:

Шлюз Интерфейс Служба [dont_failover]

London_GW eth1 http_ftp_grp

Paris_GW eth1 http_ftp_grp

Руководство администратора VPN R75.40VS | 108


VPN Site-to-Site

Выбор линии связи на основе служб с несколькими интерфейсами на


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

Локальный шлюз безопасности Удаленный шлюз безопасности

Для использования всех трех внешних интерфейсов и распределения VPN-трафика между доступными
линиями связи необходимо включить распределение нагрузки выбора линии связи и зондирование на основе
маршрутов. Для контроля использования полосы пропускания присвойте одну или несколько линий связи
конкретной службе или службам с помощью выбора линии связи на основе служб. В данной ситуации
интерфейсы eth0 и eth1 обоих шлюзов безопасности присвоены SIP-трафику. SIP-трафик распределяется
между eth0 и eth1. Весь остальной трафик направляется через eth2.
Если одна из линий связи – через eth0 или через eth1 – прекратит реагировать на зондирование RDP, SIP-
трафик будет переброшен на другой соответствующий интерфейс. Если же прекратит реагировать на
зондирование RDP линия через eth2, тогда весь трафик пойдет через eth0 и eth1.

Выбор линии связи на основе служб с двумя интерфейсами на одном конце


В приведенной ниже ситуации у локального шлюза безопасности два внешних интерфейса для VPN-трафика,
а у удаленного шлюза безопасности он лишь один.

Руководство администратора VPN R75.40VS | 109


VPN Site-to-Site

Локальный шлюз безопасности London_GW

Интернет
Удаленный шлюз безопасности Paris_GW

Для использования всех внешних интерфейсов и распределения VPN-трафика между доступными линиями
связи на локальном шлюзе безопасности London_GW необходимо включить распределение нагрузки выбора
линии связи и зондирование на основе маршрутов. Для контроля использования полосы пропускания с
помощью выбора линии связи на основе служб присвойте интерфейс eth1 локального шлюза безопасности
HTTP- и FTP-трафику. Локальный шлюз безопасности исходящий HTTP- и FTP-трафик направит через
интерфейс eth1. Весь остальной трафик, помимо HTTP и FTP, будет направляться через eth0.

В данном примере HTTP- и FTP-трафик не переключается, а всегда направляется через интерфейс eth1,
даже тогда, когда линия связи eth1 перестает откликаться на зондирование RDP. Это задается за счет
включения флага dont_failover.

Так выглядит конфигурационный файл выбора линии связи на основе служб для описанной среды.

Шлюз Интерфейс Служба [dont_failover]

London_GW eth1 http

London_GW eth1 ftp

Поскольку конфигурация выбора линии связи на основе служб действует только для исходящего трафика
локального шлюза безопасности, удаленный шлюз безопасности может отсылать HTTP- и FTP-трафик на
любой интерфейс локального шлюза безопасности. Исходящий VPN-трафик удаленного шлюза безопасности
распределяется между интерфейсами eth0 и eth1 локального шлюза безопасности.

Доверенные линии связи


Доверенные линии связи – это средство, позволяющее пометить интерфейс VPN-трафика как «доверенный»,
чтобы трафик, идущий на эту линию связи, не шифровался. Если вы уверены, что линия связи уже
зашифрована и безопасна, вам не нужно повторное шифрование – вполне можно пометить эту линию, как
доверенную.

Руководство администратора VPN R75.40VS | 110


VPN Site-to-Site
Если интерфейс настроить как доверенный, то направляемый через него трафик будет отправляться
незашифрованным; трафик, отсылаемый через другие интерфейсы, будет шифроваться.
Доверенные интерфейсы следует настраивать симметрично на локальном и удаленном шлюзе безопасности.
Если доверенной для VPN-трафика будет только одна сторона линии связи, то незашифрованные пакеты,
полученные «недоверенным» интерфейсом, будут пропущены удаленным шлюзом безопасности.
Если при использовании зондирования конкретную линию связи назначили доверенной для VPN-трафика, то
в ходе выбора линии для связи зондированию будут подвержены все линии, в том числе, доверенные.
Методика зондирования предусматривает выбор линии согласно настроенному режиму резервирования,
высокой доступности или распределению нагрузки, а также исходя из того, настроен ли выбор линии связи на
основе служб. Если для соединения выбрана доверенная линия связи, передаваемые пакеты не шифруются.
При выборе другой линии связи трафик подвергается шифрованию.
В конфигурации МЕР доверенными линиями связи можно назначить лишь соединения, инициированные
удаленным шлюзом безопасности в сторону шлюза безопасности МЕР. Незашифрованные VPN-соединения,
направленные через доверенный интерфейс, инициированные шлюзом безопасности МЕР могут быть
отвергнуты удаленным шлюзом безопасности.
В традиционном режиме доверенные линии связи не поддерживаются, настройки доверенных линий связи
игнорируются, а VPN-трафик всегда зашифровывается.
Доверенный линии связи поддерживаются шлюзами безопасности R71 и выше.
Примечание. Устройства ускорения IPSO не поддерживают доверенные соединения. Они
пренебрегают настройками доверенных линий связи и зашифровывают трафик, проходящий
через них.

Настройка доверенных линий связи


Для настройки доверенных линий связи воспользуйтесь GuiDBedit, инструментом Check Point для работы с
базами данных.
Настройка доверенной линии связи
1. В GuiDBedit перейдите на Сетевые объекты > network_objects.
2. Выберите шлюз безопасности, который следует отредактировать.
3. Из набора интерфейсов найдите интерфейс, подлежащий назначению доверенным. Имя интерфейса
отображается в атрибуте officialname.
4. В наборе параметров доверенного интерфейса измените значение атрибута vpn_trusted на true (по
умолчанию: false).
5. Доверенные интерфейсы следует настраивать симметрично на противоположных шлюзах безопасности.
Если доверенной для VPN-трафика будет только одна сторона линии связи, то незашифрованные
пакеты, полученные «недоверенным» интерфейсом, будут пропущены удаленным шлюзом безопасности.
6. Сохраните изменения.

Ситуации с доверенными линиями связи


В следующей ситуации у локального и удаленного шлюзов безопасности по два внешних интерфейса,
доступных для VPN-трафика. На обоих шлюзах безопасности интерфейс eth1 настроен как доверенный.
Таким образом, трафик от eth1 локального шлюза безопасности будет отправляться нешифрованным, и
будет принят интерфейсом eth1 удаленного шлюза безопасности – и наоборот.

Руководство администратора VPN R75.40VS | 111


VPN Site-to-Site

Локальный шлюз безопасности Зашифрованный трафик


Нешифрованный трафик Удаленный шлюз безопасности

Если зондирование с резервированием проводить в режиме высокой доступности, а доверенную линию связи
настроить как первичный IP-адрес, доверенная линия будет использоваться для VPN-трафика. Если
доверенная линия прекратит откликаться на зондирование RDP, то для VPN-трафика будет использоваться
линия, проходящая через интерфейс eth0, и передача станет шифрованной.
Если зондирование с резервированием происходит в режиме распределения нагрузки, тогда VPN-трафик
распределяется между доступными линиями связи. Соединения, направляемые через интерфейс eth0, будут
шифроваться, в то время как соединения, направляемые через доверенную линию связи, шифроваться не
будут.

Использование доверенных линий связи при выборе линии связи на основе


служб
В следующей ситуации у локального и удаленного шлюзов безопасности есть по два внешних интерфейса,
доступных для VPN-трафика. На обоих шлюзах безопасности интерфейс eth1 настроен как доверенный
интерфейс для VPN-трафика, а значит, по этой линии связи шифрование не требуется. К тому же, у обоих
шлюзов безопасности интерфейс eth1 посредством выбора линии связи на основе служб назначен для SIP-
трафика.

Руководство администратора VPN R75.40VS | 112


VPN Site-to-Site

Локальный шлюз безопасности Зашифрованный трафик


Нешифрованный трафик Удаленный шлюз безопасности

SIP-трафик направляется через доверенное соединение между двумя интерфейсами eth1 и не подвергается
шифрованию. Если доверенная линия связи прекращает откликаться на зондирование RDP, SIP-трафик
будет перенаправлен через интерфейсы eth0 и, соответственно, зашифрован.
Весь остальной трафик (не SIP) шифруется и направляется через линию связи интерфейса eth0. Однако,
если интерфейс eth0 прекратит реагировать на зондирование RDP, весь трафик будет направляться через
доверенную линию связи, не проходя шифрование.

Линии связи по требованию (ODL)


Зондирование на основе маршрутов позволяет использовать линию связи по требованию (ODL – On Demand
Link), на которую происходит переключение при отказе всех первичных линий. При обнаружении неполадки
запускается пользовательский сценарий, включающий ODL и изменяющий текущую информацию о
маршрутизации. Метрика ODL должна быть больше, чем настроенный минимум, чтобы линия
рассматривалась как ODL.

Локальный шлюз безопасности Соединение ISDN dial-up (настроено как линия святи по
требованию)
У шлюза безопасности две внешних линии для подключения к Интернет: одна к ISP, другая – к ISDN dial-up.
Соединение ISDN dial-up сконфигурировано как линия по требованию.

Руководство администратора VPN R75.40VS | 113


VPN Site-to-Site
На шлюзе безопасности механизм зондирования на основе маршрутов проходит все не-ODL линии и
выбирает активную линию связи с самой низкой метрикой. В данном случае зондировалась линия связи ISP.
Когда все остальные линии связи с высшими приоритетам станут недоступными, запустится сценарий,
включающий линию связи по требованию. Когда линия связи снова освободится, автоматически запустится
закрывающий сценарий и соединение снова пойдет через линию с ISP.
Примечание. Линии связи по требованию зондируются только раз с помощью единственного
сеанса RDP. Переключение между ODL не поддерживается.

Настройка линий связи по требованию


Линии связи по требованию можно включить только при активном зондировании на основе маршрутов.
Команды линий связи по требованию настраиваются в GuiDBedit, средстве Check Point для работы с базами
данных.
Настройка линий связи по требованию

Свойство Описание

use_on_demand_links Включает линии связи по требованию. По умолчанию: FALSE.


Изменить на TRUE.

on_demand_metric_min Определяет минимальное значение метрики для линии связи по


требованию. Данное значение должно быть больше или равно
настроенной минимальной метрике.

on_demand_initial_script Имя сценария по требованию, который запускается, когда все не-ODL


прекращают откликаться. Поместите сценарий в папку $FWDIR/conf.

on_demand_shutdown_script Сценарий выполняется, когда вышедшие из строя линии снова


становятся активными. Поместите сценарий в папку $FWDIR/conf.

Если не желаете использовать GuiDBedit, можете настроить команды use_on_demand_links и


on_demand_metric_min через SmartDashboard.
1. В SmartDashboard нажмите Политика > Глобальные свойства > Настройка SmartDashboard >
Настроить.
2. В Дополнительных свойствах VPN нажмите Выбор линии связи.
3. Для включения линии по требованию, щелкните use_on_demand_links.
4. Командой on_demand_metric_min задайте минимальный уровень метрики для линии связи по
требованию.

Выбор линии связи и ISP-резервирование


ISP-резервирование повышает надежность Интернет-соединения, допуская подключение одинарного или
кластерного шлюза безопасности к Интернету посредством резервных ISP-соединений. Будучи частью
стандартной VPN-установки, это средство имеет два режима работы, настраиваемые в Check Point > Шлюз
безопасности > Топология > ISP-резервирование.
 Распределение нагрузки. Соединение идет к обоим ISP, при этом нагрузка исходящего соединения
распределяется между ISP согласно присвоенным весовым коэффициентам. Новые соединения
присваиваются линиям связи в произвольном порядке. Если линия связи выходит из строя, новые
исходящие соединения направляются на активную линию. Такая конфигурация эффективно повышает
ширину полосы пропускания широковещательной сети, защищая саму связь. Веса, присвоенные линиям
связи ISP, поддерживаются только трафиком брандмауэра.
 Первичный/резервный. В Соединение происходит только с первичной линией ISP; резервная
включается в случае выхода из строя первичной. При восстановлении первичной линии связи новые
исходящие соединения направляются через нее, а существующие соединения до самого своего
завершения следуют через резервную линию.
Настройки, заданные в окне ISP-резервирование, принимаются по умолчанию и имеют больший приоритет,
чем любые ранее заданные конфигурации на странице Выбор ссылки. Переносятся такие настройки.
 При активном ISP-резервировании на странице Выбор линии связи по умолчанию задано значение
Использовать непрерывное зондирование. Однако, при выборе линии связи происходит
зондирование лишь тех ISP, которые указаны в окне ISP-резервирование. Таким образом, возможным
становится переброс VPN-туннеля в случае разрыва связи с одним из шлюзов безопасности.
 Если ISP-резервирование работает в режиме Распределение нагрузки, то режим зондирования с
резервированием на странице Выбор линии связи также будет Распределение нагрузки.

Руководство администратора VPN R75.40VS | 114


VPN Site-to-Site

 Если ISP-резервирование работает в режиме Первичный/резервный, то режим зондирования с


резервированием на странице Выбор линии связи будет Высокая доступность.
 Первичная линия связи ISP-резервирования задается как первичный адрес при зондировании для
выбора линии связи. Первичный адрес задается в Выбор IP-адреса по удаленному узлу >
Использовать зондирование > Настроить (или Обзор, если настройки наследуются от настроек
ISP-резервирования).
Если вы не желаете, чтобы настройки ISP-резервирования влияли на настройки выбора линии связи, на
странице ISP-резервирования снимите отметку с флажка с и настройте необходимые параметры VPN на
странице Выбор линии связи. Это может пригодиться, если вы хотите направить VPN-трафик по-другому,
чем трафик брандмауэра. К примеру, если для трафика брандмауэра требуется распределение нагрузки, а
для VPN-трафика – высокая доступность; или если для VPN-трафика и трафика брандмауэра используются
различные первичные ISP.

Ситуации с выбором линии связи и ISP-резервированием


В следующих ситуациях локальный шлюз безопасности поддерживает линии связи с ISP А и В, обе из
которых обеспечивают связь с Интернетом, прибегая к ISP-резервированию.

Локальный шлюз безопасности Интернет

Линия связи к ISP A Удаленный узел


Линия связи к ISP B

В окне Топология > ISP-резервирование настройте параметры ISP-резервирования так же, как и линии
связи ISP, и режим резервирования. Параметры ISP-резервирования по умолчанию применяются к VPN-
трафику. Заимствованные настройки выбора линии связи видны в окне VPN IPSec > Выбор линии связи.
В следующей ситуации на странице ISP-резервирование была снята отметка с флажка Применить
настройки к VPN-трафику (Apply settings to VPN-traffic) – поэтому для выбора линии связи и ISP-
резервирования настроены разные параметры.

Руководство администратора VPN R75.40VS | 115


VPN Site-to-Site

Шлюз безопасности А Шлюз безопасности В


Интернет Шлюз безопасности С

В данной ситуации:
 У шлюзов безопасности А, В, С есть по два интерфейса, настроенных как линии связи ISP.
 ISP-резервирование настроено на шлюзе безопасности А.
 Шлюз безопасности А должен использовать ISP 1 для соединения с шлюзом безопасности В, а ISP 2 –
для соединения с шлюзом безопасности С. Если одна из линий связи станет недоступной, следует
использовать другую линию ISP.
В данной ситуации администратору шлюза безопасности А необходимо:
 В окне ISP-резервирование снять отметку с флажка Применить настройки к VPN-трафику.
 В окне Выбор линии связи перенастроить Выбор исходящего маршрута на Зондирование на основе
маршрутов.
 Настроить таблицу маршрутизации таким образом, чтобы ISP 1 имела наивысший приоритет для
удаленного шлюза безопасности В, а ISP 2 – для удаленного шлюза безопасности С.

Выбор линии связи при наличии устройств не Check Point


Зондирование RDP, метод зондирования, применяемый для конкретных функций выбора линии связи,
является проприетарным для Check Point? работающий только с объектами Check Point. Сторонние объекты
его не поддерживают.
Поскольку на сторонних шлюзах безопасности зондирование RPD не работает, то при отправке VPN-трафика
шлюзом безопасности Check Point на сторонний шлюз получится ситуация, описанная ниже.
 Опция Использовать зондирование не может использоваться локально управляемыми шлюзами
безопасности Check Point для определения IP-адресов сторонних устройств. Можно использовать любой
другой метод, доступный в разделе Выбор IP-адреса по удаленному узлу.
 Распределение нагрузки и Выбор линии связи на основе служб не работают со сторонними
шлюзами. Если на локальном шлюзе безопасности включить эти функции, а на противоположном конце
линии связи будет устройство, произведенное не Check Point, локальный шлюз безопасности
воспользуется только одной линией связи к стороннему устройству: максимально подходящей линией (с
максимальной длиной префикса) и с минимальной метрикой.
 Если при отправке VPN-трафика на стороннее устройство в качестве метода Выбора исходящего
маршрута выбрать Зондирование на основе маршрутов, локальные шлюзы безопасности всегда будут
пользоваться максимально подходящей линией (с максимальной длиной префикса) и с минимальной
метрикой.

Руководство администратора VPN R75.40VS | 116


Глава 12
VPN с множественными точками входа
В этой главе
ОБЗОР МЕР ...................................................................................................................................................... 117
ЯВНЫЕ МЕР ..................................................................................................................................................... 118
НЕЯВНЫЕ МЕР ................................................................................................................................................ 123
МАРШРУТИЗАЦИЯ ОТВЕТНЫХ ПАКЕТОВ .................................................................................................... 125
ОСОБЕННОСТИ ............................................................................................................................................... 126
НАСТРОЙКА МЕР............................................................................................................................................. 126

Обзор МЕР
Множественные точки входа (МЕР, Multiple Entry Point) – это функция, обеспечивающая решение для высокой
доступности и распределения нагрузки VPN-соединений. Шлюз безопасности, на котором установлен VPN-
модуль, является точкой входа внутренней сети. Именно этот шлюз безопасности делает сеть «доступной»
для удаленных машин. Если шлюз безопасности выходит из строя, то внутренняя сеть становится
недоступной. Среда МЕР обладает двумя и больше шлюзами безопасности, защищающими и
обеспечивающими доступ к одному и тому же VPN-домену; таким образом, удаленным шлюзам безопасности
гарантируется непрерывный доступ.

Высокая доступность VPN при помощи МЕР или кластеризации


МЕР и кластеризация – это методы достижения высокой доступности и распределения нагрузки. При этом:
 В отличие от участия в кластере шлюза безопасности ClusterXL, нет физического ограничения на
расположение шлюзов безопасности с МЕР. Шлюзы безопасности с МЕР могут быть на географически
разнесенных машинах. В то время как шлюзы безопасности из одного кластера должны находиться в
одном месте, соединяясь напрямую интерфейсом синхронизации.
 Шлюзами безопасности с МЕР могут управлять разные Серверы управления защитой; члены кластера
должны управляться одним и тем же Сервером управления защитой.
 В конфигурации МЕР нет «синхронизации состояния» между шлюзами безопасности с МЕР. В кластере
все шлюзы безопасности отслеживают состояние всех соединений внутренней сети. Если один из
шлюзов безопасности выходит из строя, соединение незаметно перебрасывается (происходит
переключение) на другой шлюз безопасности – и связь продолжается. В конфигурации с МЕР при выходе
шлюза безопасности из строя текущее соединение теряется, а следующее соединение подхватывает
один из резервных шлюзов безопасности.
 В среде МЕР решение о том, какой шлюз безопасности использовать, принимается на удаленной
стороне; в кластере это решение принимается на стороне шлюза безопасности.

Внедрение
МЕР внедряется посредством проприетарного протокола зондирования (PP – Probing Protocol),
отправляющего специальные UDP RDP пакеты на порт 259, узнавая, достижим ли IP. Этот протокол является
собственным протоколом Check Point и не соответствует RDP, как указано в RFC 908/1151/
Примечание. Эти UDP RDP пакеты не шифруются, поскольку всего лишь проверяют
доступность узла.
Удаленный узел непрерывно зондирует или опрашивает все шлюзы безопасности с МЕР, чтобы определить,
какие из них активны, и выбирает шлюз безопасности, согласно заданному алгоритму выбора. Поскольку
пакеты RDP отправляются постоянно, состояние шлюзов безопасности известно и обновляется при каждом
изменении. В результате всегда известно, какие шлюзы безопасности активны.
Существует два доступных метода внедрения МЕР.
 Явные МЕР. Этот метод реализуем только в сообществах со звездообразной топологией, в которых
присутствует более одного центрального шлюза безопасности. МЕР вносит в сеть позади шлюза
безопасности множественные точки входа. Если внедрение явных МЕР возможно, этот метод является
предпочтительным.
 Неявные МЕР. Этот метод поддерживается во всех ситуациях, где есть частично или полностью
перекрывающиеся домены шифрования или настроены первичные-резервные шлюзы безопасности (см.
стр. 103). При обновлении после более ранней версии, чем NGX (R60), где неявные МЕР уже настроены,
ранее настроенная конфигурация остается.
VPN Site-to-Site

Явные МЕР
В звездообразном VPN-сообществе Site-to-Site явные МЕР настраиваются через объект сообщества. Когда
МЕР активны, «унифицированный» VPN-домен всех шлюзов безопасности рассматривается сателлитами как
VPN-домен для каждого шлюза безопасности. Этот унифицированный VPN-домен считается VPN-доменом
каждого шлюза безопасности.

Унифицированный VPN-домен

Хост 1
Выделенная линия

На схеме у звездообразного VPN-сообщества два центральных шлюза безопасности, М1 и М2 (для каждого


активированы МЕР), и три сателлитных шлюза безопасности – S1, S2 и S3. Когда S2 открывает соединение с
хостом 1 (находящимся за М1 и М2), сеанс строится либо через М1, либо через М2. Приоритет между
шлюзами безопасности с МЕР определяется механизмом выбора точки входа МЕР.
Если точкой входа выбран М2, а он впоследствии отказывает, то соединение с хостом 1 перебрасывается на
М1. Ответные пакеты перенаправляются посредством RIM или NAT пула IP. Подробнее об ответных пакетах
см. «Маршрутизация ответных пакетов» (на стр. 139).
Для выбора шлюза безопасности, который будет использоваться в качестве входной точки для любого
данного соединения, существует четыре метода.
 Выбор ближайшего шлюза безопасности к источнику (первый ответивший).
 Выбор ближайшего шлюза безопасности к адресату (по VPN-домену).
 Произвольный выбор (для распределения нагрузки).
 Список приоритетов, задаваемый вручную (правила МЕР).
Если выбраны варианты «По VPN-домену» или «Список приоритета, задаваемый вручную», то настройку
можно уточнить Дополнительными опциями.

Методы выбора МЕР


 Первый ответивший. Выбирается первый шлюз безопасности, ответивший удаленному шлюзу
безопасности. В организации следует выбрать этот вариант, если, например, у нее есть два шлюза
безопасности, в конфигурации МЕР – один в Лондоне, второй в Нью-Йорке. Для узлов, расположенных в
Англии, имеет смысл держать связь с Лондонским шлюзом безопасности раньше, а с Нью-Йоркским –

Руководство администратора VPN R75.40VS | 118


VPN Site-to-Site
позже. Поскольку Лондонский шлюз безопасности географически находится ближе к английским узлам, то
и ответит он раньше, таким образом, становясь точкой входа во внутреннюю сеть. См. «Первый
ответивший» (на стр. 131).
 VPN-домен. Когда IP-адрес назначения принадлежит конкретному VPN-домену, шлюз безопасности этого
домена назначается точкой входа. Этот шлюз безопасности становится первичным шлюзом
безопасности, а прочие шлюзы безопасности в конфигурации МЕР становятся для него резервными. См.
«По VPN-домену» (на стр. 131).
 Произвольный выбор. Удаленный узел произвольно выбирает шлюз безопасности, с которым
открывать VPN-соединение. Для каждой пары IP-адресов источник-адресат произвольным образом
выбирается новый шлюз безопасности. У организации может быть в наличии ряд машин одинаковой
производительности. В таком случае есть смысл задействовать распределение нагрузки. Машины
используются поровну и в произвольном порядке. См. «Произвольный выбор» (на стр. 133).
 Список приоритетов, задаваемый вручную. Приоритеты шлюзов безопасности можно расставить
вручную, как для всего сообщества, так и для отдельных сателлитных шлюзов безопасности. См.
«Список приоритетов, задаваемый вручную» (на стр. 133).
Первый ответивший
Когда нет первичного шлюза безопасности, все шлюзы безопасности имеют «равный приоритет». Ниже
описана ситуация, когда у всех шлюзов безопасности равный приоритет.

МЕР множественные точки входа


Шлюз безопасности
VPN-домен
Удаленный узел
Интернет

 Удаленные узлы отсылают пакеты RDP всем шлюзам безопасности в конфигурации МЕР.
 Первый шлюз безопасности, который ответил на зондирующий пакет RDP, выбирается точкой входа в
сеть. Суть метода «первый ответивший» состоит в близости. Тот шлюз безопасности ответит раньше,
который «ближе» к удаленному узлу.
 VPN-туннель открывается с тем шлюзом безопасности, который ближе. Все последующие соединения
проходят через выбранный шлюз безопасности.
 Если шлюз безопасности прекращает откликаться, выбирается новый шлюз безопасности.
По VPN-домену
Перед внедрением МЕР каждый IP-адрес принадлежал конкретному VPN-домену. По методу «по VPN-
домену» шлюз безопасности этого домена становится выбранной точкой входа. На схеме у звездообразного
VPN-сообщества два центральных шлюза безопасности с МЕР (М1 и М2, у каждого свой VPN-домен) и
удаленный сателлит S1.

Руководство администратора VPN R75.40VS | 119


VPN Site-to-Site

Первоначальный VPN-домен М1 Выделенная линия


Первоначальный VPN-домен М2 VPN-домен S1

Хост 3 Хост 2
Хост 1

Хост-2 в VPN-домене сателлита S1 инициирует соединение с хостом 1. Соединение может пройти через М1
или М2. Однако, хост 1 располагается в первоначальном домене М2. По этой причине М2 считается шлюзом
безопасности, «ближайшим» к IP-адресу назначения. Значит, М2 назначается первичным шлюзом
безопасности, а М1 – резервным шлюзом безопасности для хоста 1. Если бы в центре были еще шлюзы
безопасности, они также рассматривались бы как резервные шлюзы безопасности для М2.
Если в VPN-доменах есть частично или полностью перекрывающиеся домены шифрования, тогда
«ближайшей» точкой входа в сеть можно выбрать более одного шлюза безопасности. В результате
«первичными» станут более одного шлюза безопасности. А если в наличии более одного первичного или
резервного шлюза безопасности, для выбора шлюза безопасности применяется дополнительный алгоритм
выбора. Дополнительным алгоритмом может служить (см. «Дополнительные настройки» (на стр. 135)):
 первый ответивший
 произвольный выбор (для распределения нагрузки)
Для получения ответных пакетов можно на центральных шлюзах безопасности воспользоваться RIM. Если
задействован и RIM, выделенной линии необходимо задать метрику с низшим приоритетом, чем у VPN-
туннеля. У сателлита S1 одновременно может быть открыто свыше одного VPN-туннеля со шлюзами
безопасности с МЕР; например, М2 – выбранная точка входа для хоста 1, а М1 – выбранная точка входа для
хоста 3. М1 и М2 будут публиковать маршруты к хосту 1 и хосту 3; метрика низшего приоритета станет
залогом того, что выделенная линия будет использована лишь после того, как выйдет из строя один из
шлюзов безопасности.
Произвольный выбор
При использовании этого метода точкой входа для входящего трафика назначается произвольный шлюз
безопасности. Равномерное распределение входящего трафика между всеми возможными шлюзами
безопасности предотвратит перегрузку одного шлюза безопасности при избытке входящей информации.
С целью создания списка откликающихся шлюзов безопасности, последние зондируются пакетами RDP, как и
во всех остальных конфигурациях МЕР. Шлюз безопасности произвольным образом выбирается из списка
откликающихся шлюзов. Если шлюз безопасности прекращает откликаться, произвольно выбирается другой
шлюз безопасности.

Руководство администратора VPN R75.40VS | 120


VPN Site-to-Site
Для каждой пары IP-адресов источник-адресат произвольным образом выбирается новый шлюз
безопасности. Пока IP-адреса источника и адресата остаются неизменными, соединение продолжает
проходить через выбранный шлюз безопасности.
В такой конфигурации RIM не поддерживается. Для обеспечения корректной маршрутизации ответных
пакетов через выбранный шлюз безопасности необходимо задействовать NAT пула IP.
Список приоритетов, задаваемый вручную
Выбор шлюза безопасности (из центральных шлюзов безопасности звездообразного сообщества) в качестве
точки входа в опорную сеть может регулироваться ручной расстановкой приоритетов исходных шлюзов
безопасности. Каждый приоритет составляет правило МЕР.

Унифицированный VPN-домен

На схеме три члена МЕР (М1, М2, М3) предоставляют точки входа в сеть для трех сателлитных шлюзов
безопасности (S1, S2, S3). Сателлит S1 может быть настроен на такую очередность попыток входа: М1 – М2 –
М3, при этом максимальный приоритет у М1, а минимальный – у М3. Для сателлита S2 может быть настроена
другая последовательность: М2, М3 (а М1 даже не пробовать).
Каждый из этих приоритетов составляет правило МЕР в окне списка приоритетов МЕР, составляемого
вручную.

Руководство администратора VPN R75.40VS | 121


VPN Site-to-Site

Пункт Описание

1 Правило МЕР по умолчанию

2 Первое правило МЕР

3 Второе правило МЕР

Окно списка приоритетов МЕР разделено на правило по умолчанию и правила, представляющие исключения
из правила по умолчанию. Правило по умолчанию действует тогда, когда:
 не определено правил МЕР;
 среди правил-исключений приоритета нет источника соединения.
Область правил приоритета содержит три уровня приоритета: первичный, вторичный и третичный. Поскольку
существует только три уровня приоритета, то:
 нескольким центральным шлюзам безопасности может быть назначен один и тот же приоритет;
 одно и то же правило может быть присвоено нескольким сателлитным шлюзам безопасности;
 уровень приоритета может быть незаполненным.
Во втором правиле МЕР ниже

У центральных шлюзов безопасности М3 и М1 одинаковый уровень приоритета. То же правило применяется к


сателлитам S2 и S3.

Руководство администратора VPN R75.40VS | 122


VPN Site-to-Site
Когда один и тот де уровень приоритет присваивается двум и более шлюзам безопасности, выбор шлюза
безопасности определяется дополнительными настройками. См. «Дополнительные настройки» ниже.
Дополнительные настройки
В некоторых случаях в центре находятся несколько шлюзов безопасности безо всякого видимого приоритета
между ними. Например, как показано на рис. 12-6, более, чем одному шлюзу безопасности присвоен «второй»
уровень приоритета. В этой ситуации для выбора шлюза безопасности (первый ответивший или произвольно
выбранный) используют Дополнительные опции. (Произвольно выбранный шлюз следует выбирать, если
необходимо задействовать распределение нагрузки).
Когда алгоритмом выбора МЕР служит список приоритетов, задаваемый вручную, поддерживается RIM. В
этой конфигурации возможна настройка RIM, поскольку тот алгоритм «произвольного выбора», который
находится за кнопкой Дополнительно, отличается от алгоритма произвольного выбора для МЕР.
Алгоритм произвольного выбора для МЕР предусматривает выбор разного шлюза безопасности для каждой
пары IP-адресов источник-адресат. Согласно алгоритму произвольной выборки, находящемуся за кнопкой
Дополнительно, произвольным образом выбирается одна точка входа МЕР, которая в дальнейшем
используется для всех соединений и не меняется в зависимости от пары источник-адресат. Так достигается
распределение нагрузки, поскольку каждый сателлитный шлюз безопасности произвольно назначается
точкой входа. Таким образом, существует возможность одновременного применения RIM.
Отслеживание
Если в среде МЕР включена опция отслеживания, то каждый сателлитный шлюз безопасности записывает в
журнал такую информацию:
 разрешенный шлюз безопасности (шлюз безопасности в МЕР);
 приоритет разрешенного шлюза безопасности (первичный, вторичный, третичный);
 откликается ли разрешенный шлюз безопасности.
Например, в ситуации, продемонстрированной в пункте «Список приоритетов, задаваемый вручную» (на стр.
133), сателлит S1 открывает соединение с VPN-доменом, включающим шлюзы безопасности М1, М2 и М3.
Разрешенным узлом является М1. При включенном отслеживании в журнале будет такая запись:
Resolved peer for tunnel from S1 to the MEP that contains
M1, M2, and M3, is: M1 (Primary Security Gateway,
responding).
Разрешенный узел для туннеля от S1 к МЕР, среди которых М1, М2 и М3: М1 (первичный шлюз
безопасности, откликается).

Неявные МЕР
Существует три метода внедрения неявных МЕР:
 Первый ответивший. Выбирается первый шлюз безопасности, ответивший удаленному шлюзу
безопасности. В организации следует выбрать этот вариант, если, например, у нее есть два шлюза
безопасности, в конфигурации МЕР – один в Лондоне, второй в Нью-Йорке. Для узлов VPN-1,
расположенной в Англии, имеет смысл держать связь с Лондонским шлюзом безопасности раньше, а с
Нью-Йоркским – позже. Поскольку Лондонский шлюз безопасности географически находится ближе к
английским узлам, то и ответит он раньше, таким образом, становясь точкой входа во внутреннюю сеть.
См. «Первый ответивший» (на стр. 136).
 Первичный-резервный. Один или несколько резервных шлюзов безопасности обеспечивают высокую
доступность первичного шлюза безопасности. Удаленный узел настроен на работу с первичным шлюзом
безопасности, однако, при падении последнего переключается на резервные. Такая конфигурация может
быть выгодна для организации, у которой в МЕР-среде есть два компьютера разной мощности. Есть
смысл более сильную машину настроить как первичную. Даже если машины обладают одинаковой
производительностью, одна из них может быть дешевле или иметь более быстрый доступ в Интернет.
Тогда машину с лучшим соединением с Интернетом необходимо сделать первичной. См. «Первичные-
резервные шлюзы безопасности» (на стр. 138).
 Распределение нагрузки. Удаленный VPN-узел случайно выбирает шлюз безопасности, с которым
открыть соединение. Для каждой пары IP-адресов источник-адресат произвольным образом выбирается
новый шлюз безопасности. У организации может быть ряд машин одинаковой производительности. В
этом случае есть смысл задействовать распределение нагрузки, тогда машины будут использоваться
равномерно и поровну. См. «Произвольный выбор» (на стр. 133).
Неявные МЕР поддерживаются, если в одном и том же сообществе есть шлюзы безопасности с
перекрывающимися доменами шифрования. Если же они расположены в разных сообществах, для этого
домена шифрования будет использоваться только один из шлюзов безопасности.
Примечание. При обновлении после более ранней версии, чем NGX (R60), где неявные МЕР
уже настроены, ранее настроенная конфигурация остается.

Руководство администратора VPN R75.40VS | 123


VPN Site-to-Site

Первый ответивший
В условиях отсутствия первичного шлюза безопасности все шлюзы безопасности имеют равный приоритет. А
если все шлюзы безопасности одинаково приоритетны, тогда:
 Удаленные VPN-узлы отправляют пакеты RDP на все шлюзы безопасности в конфигурации МЕР.
 Первый шлюз безопасности, который ответит на зондирующие пакеты RDP, выбирается в качестве точки
входа в сеть. Суть метода «первый ответивший» состоит в близости. Чем «ближе» шлюз безопасности к
удаленному VPN-узлу, тем раньше он ответит.
 VPN-туннель открывается с первым ответившим шлюзом безопасности. Все последующие соединения
проходят через выбранный шлюз безопасности.
 Если шлюз безопасности прекращает откликаться, выбирается новый шлюз безопасности.
В звездообразном сообществе шлюзам безопасности отправляются пакеты RDP. Первый ответивший шлюз
безопасности используется для маршрутизации при следующих условиях:
1. Существует более одного центрального шлюза безопасности.
2. Выбран один из следующих вариантов VPN-маршрутизации:
 К центру и к прочим сателлитам через центр.
 К центру или через центр к прочим сателлитам, в Интернет и другие VPN.
Данная настройка находится на странице Свойства сообщества > VPN Дополнительно > VPN-
маршрутизация.
В данной ситуации:
VPN-домен В

Шлюз В
Общий домен шифрования

VPN-домен С

VPN-домен А
Шлюз А
Шлюз Х

 В сообществе
МЕР не задействованы.
 Используется метод «первый ответивший».
 Шлюз безопасности Х имеет доступ к VPN-домену А через шлюз безопасности А.
 Шлюз безопасности Х имеет доступ к VPN-домену В через шлюз безопасности В.
 Шлюз безопасности Х имеет доступ к VPN-домену С через шлюз безопасности А или В.
В звездообразном сообществе шлюзам безопасности отправляются пакеты RDP. Первый ответивший шлюз
безопасности используется для маршрутизации при следующих условиях:
1. Существует более одного центрального шлюза безопасности.
2. Выбран один из следующих вариантов VPN-маршрутизации:
 К центру и к прочим сателлитам через центр.
 К центру или через центр к прочим сателлитам, в Интернет и другие VPN.
Данная настройка находится на странице Свойства сообщества > VPN Дополнительно > VPN-
маршрутизация.
Первичные-резервные шлюзы безопасности
Резервные шлюзы безопасности обеспечивают бесперебойную работу первичных шлюзов безопасности.
Если первичный шлюз безопасности выходит из строя, соединение проходит через резервный.
В данной ситуации:

Руководство администратора VPN R75.40VS | 124


VPN Site-to-Site

Удаленный узел МЕР


Интернет Резервный шлюз

Первичный шлюз Целевой хост

Первый шлюз безопасности настраивается как «первичный», а второй – как «вторичный». Если первичный
шлюз безопасности по какой-нибудь причине выйдет из строя, удаленный VPN-узел обнаружит, что линия
связи неактивна и отработает через вторичный шлюз безопасности. Вторичный шлюз наследует весь VPN-
домен первичного. Переключение сигнала в рамках существующего соединения не предусматривается;
текущее соединение в этом случае теряется.
После восстановления первичного шлюза безопасности новые соединения проходят через первичный шлюз
безопасности, а существующие продолжают использовать резервный шлюз.
Примечание. При использовании метода первичных-резервных шлюзов безопасности домены
шифрования не должны перекрываться.
Распределение нагрузки
Чтобы предотвратить явление переполнения одного из шлюзов безопасности соединениями, последние
можно поровну разделить между всеми шлюзами безопасности, распределив нагрузку. Когда все шлюзы
безопасности обладают равным приоритетом (без первичных) и настроены на МЕР в одном и том же
домене, можно задействовать распределение нагрузки между шлюзами безопасности. С целью создания
списка откликающихся шлюзов безопасности, последние зондируются пакетами RDP, как и во всех остальных
конфигурациях МЕР. Шлюз безопасности произвольным образом выбирается из списка откликающихся
шлюзов. Если шлюз безопасности прекращает откликаться, произвольно выбирается другой шлюз
безопасности.
Для каждой пары IP-адресов источник-адресат произвольным образом выбирается новый шлюз
безопасности. Пока IP-адреса источника и адресата остаются неизменными, соединение продолжает
проходить через выбранный шлюз безопасности.

Маршрутизация ответных пакетов


Для правильной маршрутизации ответных пакетов шлюз безопасности с МЕР может воспользоваться одним
из следующих средств:
 NAT пула IP (статическая NAT);
 Механизм ввода трафика.

Трансляция сетевого адреса (NAT) пула IP


NAT пула IP – это такой тип NAT, когда исходящие IP-адреса от удаленных VPN-доменов сопоставляются с
IP-адресом из пула зарегистрированных IP-адресов. Для поддержания симметрии сеансов с использованием
шлюзов безопасности с МЕР последние выполняют NAT, применяя диапазон IP-адресов, назначенных
конкретно данному шлюзу безопасности. Они подлежат маршрутизации в рамках внутренней сети к
первоначальному шлюзу безопасности. По достижении ответными пакетами шлюза безопасности, тот
восстанавливает исходный IP-адрес источника и направляет источнику пакеты.
RIM
Механизм ввода трафика (RIM – Route Injection Mechanism) предоставляет шлюзу безопасности возможность
использовать протокол динамической маршрутизации для распространения сигнала домена шифрования
удаленного шлюза безопасности (peer gateway) VPN во внутреннюю сеть. После создания VPN-туннеля RIM
обновляет локальную таблицу маршрутизации шлюза безопасности, чтобы включить домен шифрования
VPN-узла.

Руководство администратора VPN R75.40VS | 125


VPN Site-to-Site
Если туннель, идущий к шлюзу безопасности с МЕР, выйдет из строя, шлюз безопасности устранит
соответствующий «ответный маршрут» из собственной локальной таблицы маршрутизации. Впоследствии
это изменение передастся на маршрутизаторы позади шлюза безопасности.
RIM основывается на способности шлюза безопасности обновлять локальную таблицу маршрутизации и на
наличии протокола динамической маршрутизации для распространения изменений в сети за шлюз
безопасности. В RIM на шлюзе безопасности было бы мало смысла, если бы не было протокола
динамической маршрутизации, благодаря которому сеть реагирует на изменения.
При включении МЕР RIP можно включить лишь тогда, когда для всего сообщества задействованы постоянные
туннели. В конфигурации МЕР RIP возможен при использовании алгоритмов «первый ответивший», «список
приоритетов, обновляемый вручную» или «VPN-домен». В первых двух случаях сателлитные шлюзы
безопасности «видят» центральные шлюзы безопасности в унифицированном виде, как если бы их
объединял единый туннель. Как следствие, только выбранный МЕР шлюз безопасности введет маршруты.
При алгоритме «VPN-домен» может быть такая ситуация, что все шлюзы безопасности с МЕР введут свои
изменения в трафик, из-за чего маршрутизаторы позади шлюзов безопасности с МЕР придется настраивать с
целью возврата ответных пакетов правильному шлюзу безопасности.
Если для выбора точки входа выбран алгоритм «Произвольный выбор», RIM недоступен.
Подробнее о RIM см. «Механизм ввода трафика» (на стр. 90).

Особенности
1. Если один из центральных шлюзов безопасности управляется извне:
 VPN-домен центральных шлюзов безопасности не будет автоматически наследоваться шлюзами
безопасности, управляемыми извне.
 Конфигурация RIM не будет автоматически загружена.
2. Шлюзы безопасности UTM-1 Edge не настраиваются как шлюзы безопасности с МЕР, однако способны
соединяться с шлюзами безопасности с МЕР.
3. Шлюзы безопасности DAIP, чтобы быть настроенными как шлюзы безопасности с МЕР, требуют
разрешения DNS.

Настройка МЕР
Для настройки МЕР следует принять решение о следующем:
1. Метод МЕР
 Явные МЕР – см. «Явные МЕР» (на стр. 129).
 Неявные МЕР – см. «Неявные МЕР» (на стр. 136).
2. При необходимости, метод возврата ответных пакетов:
 NAT пула IP.
 RIM – для настройки RIM см. «Настройка RIM» (на стр. 94).

Настройка явных МЕР


Явные МЕР возможны только в звездообразных VPN-соединениях с несколькими центральными шлюзами
безопасности.
Настройка МЕР:
1. Откройте страницу Свойства звездообразного сообщества > Дополнительные настройки > MEP
(Множественные точки входа). Выберите Задействовать МЕР для центральных шлюзов
безопасности (Enable center Security Gateways as MEP).
2. Выберите алгоритм выбора точки входа:
 Первый ответивший.
 По VPN-домену.
 Произвольный выбор.
 Ручной список приоритета.
Если выбраны «По VPN-домену» или «Список приоритета, задаваемый вручную», нажмите
Дополнительно, чтобы решить, как выбирать среди шлюзов безопасности одного уровня приоритета.
При выборе «Список приоритета, задаваемый вручную» нажмите на Установить (Set) и задайте серию
правил МЕР.
3. Выберите опцию отслеживания, если это необходимо.

Настройка неявных МЕР


Настройка неявных МЕР, метод «Первый ответивший»
Когда к одному и тому же VPN-домену ведут несколько шлюзов безопасности (перекрываясь), они пребывают
в конфигурации МЕР. Выбран первый ответивший шлюз безопасности. Для настройки метода «первый

Руководство администратора VPN R75.40VS | 126


VPN Site-to-Site
ответивший» определите ту часть сети, которая является общей для всех шлюзов безопасности, в единую
группу и обозначьте эту группу как VPN-домен.
Прежде чем начать, убедитесь, что в SmartDashboard > Глобальные свойства > Удаленный доступ не
выбрано Распределение нагрузки:
 NGX R65 и R70: VPN Базовый (VPN Basic)
 R71 и выше: VPN Дополнительно (VPN Advanced)

Распределение нагрузки
Включить распределение нагрузки для конфигураций МЕР (соединения удаленного доступа)

Настройка МЕР, «Первый ответивший»


1. Выясните, какие шлюзы безопасности пребывают в VPN-домене. В командной строке VPN выполните
команду vpn overlap_encdom.
2. Создайте группу хостов и присвойте ей все эти шлюзы безопасности.
3. В окне Свойства каждого шлюзового сетевого объекта на странице Топология, в разделе VPN-домен
выберите Определить вручную и выберите группу хостов шлюзов с МЕР.
4. Нажмите OK.
5. Установите политику.
Настройка неявных МЕР, метод «Первичный-резервный»
Настройте VPN-домен, включающий первичный шлюз, и другой домен, включающий только резервный шлюз.
Каждый шлюз следует настроить либо как первичный, либо резервный.
Настройка первичного шлюза:
1. Откройте окно Глобальные свойства > VPN > Дополнительно, выберите Включить резервный шлюз
(Enable Backup Gateway).

2. В дереве сетевых объектов, в разделе Группы создайте группу шлюзов, выступающих в роли резервных.
3. Откройте свойства VPN первичного шлюза:
 NGX R65 и R70: Свойства шлюза > VPN
 R71 и выше: Свойства шлюза > VPN IPSec
4. Отметьте Использовать резервные шлюзы (Use Backup Gateways) и выберите группу резервных
шлюзов.

Руководство администратора VPN R75.40VS | 127


VPN Site-to-Site

Этот шлюз является первичным для этого VPN-домена.


5. Для каждого резервного шлюза создайте VPN-домен, не включающий IP-адреса, лежащие в первичном
VPN-домене или в других резервных доменах.
Если у резервного шлюза уже есть VPN-домен, следует убедиться, что его IP-адреса не перекрываются с
другими VPN-доменами.
a) Создайте группу IP-адресов, не принадлежащих другим доменам, или группу, состоящую только из
резервного шлюза.
b) В окне Свойства резервного сетевого объекта, в разделе Топология > VPN-домен выберите
Определить вручную.
c) Выберите группу.
6. Нажмите OK.
7. Установите политику.
Настройка неявного распределения нагрузки
Настройка неявного МЕР с произвольным выбором шлюза:
1. Откройте Глобальные свойства.
2. Откройте VPN IPSec > Дополнительно (или VPN > Дополнительно).
3. Выберите Включить распределение нагрузки для МЕР-конфигураций (соединения Site-to-Site)
(Enable load distribution for Multiple Entry Point configurations (Site to Site connections)).
4. Определите для всех шлюзов один и тот же VPN-домен:
a) Создайте группу шлюзов.
b) В окне Свойства резервного сетевого объекта, в разделе Топология > VPN-домен выберите
Определить вручную.
c) Выберите группу.
5. Нажмите OK.
6. Установите политику.

Настройка NAT пула IP


Настройка NAT пула IP-адресов:
1. На странице Глобальные свойства > NAT выберите Включить NAT пула IP (Enable IP Pool NAT).
2. Задайте параметры отслеживания исчерпания адресов, а также присвоения и освобождения адресов.
Затем:

Руководство администратора VPN R75.40VS | 128


VPN Site-to-Site
3. Для каждого шлюза безопасности создайте сетевой объект, представляющий адреса NAT пула IP
данного шлюза безопасности. IP пулом может служить сеть, группа или диапазон адресов. Например:
 В дереве сетевых объектов щелкните правой кнопкой мыши на ветвь Сетевые объекты > Новый >
Диапазон адресов… Откроется окно свойств диапазона адресов.
 На вкладке Общие введите первый и последний IP-адрес из диапазона.
 Нажмите OK. В дереве сетевых объектов, на ветви Диапазоны адресов (Address ranges) появится
новый диапазон.
4. На шлюзе безопасности, на котором выполняется NAT пула IP, в окне Свойства шлюза безопасности,
страница NAT > NAT пула IP, выберите один из вариантов:
 Присвоить IP адреса из, выберите созданный вами диапазон адресов.
 Определить адреса пула IP на интерфейсах шлюза безопасности. При выборе этой опции
следует определить пул IP на каждом требуемом интерфейсе в окне Свойства интерфейса, на
вкладке NAT пула IP.
5. На странице NAT пула IP выберите один из пунктов (или все):
 Использовать NAT пула IP для соединений с VPN-клиентами
 Использовать NAT пула IP для соединений между шлюзами безопасности
 NAT пула IP предпочтительнее, чем Hide NAT
6. Нажмите Дополнительно…
 Определите, через сколько минут неиспользуемые адреса будут возвращаться в пул IP-адресов.
 Дважды нажмите OK.
7. Измените таблицу маршрутизации каждого внутреннего маршрутизатора так, чтобы пакеты с
присвоенными IP-адресами из пула NAT направлялись на подходящий шлюз безопасности.

Руководство администратора VPN R75.40VS | 129


Глава 13
VPN традиционного режима
В этой главе
ВВЕДЕНИЕ В VPN ТРАДИЦИОННОГО РЕЖИМА ........................................................................................... 130
VPN-ДОМЕНЫ И ПРАВИЛА ШИФРОВАНИЯ .................................................................................................. 131
ОПРЕДЕЛЕНИЕ СВОЙСТВ VPN ...................................................................................................................... 132
ШЛЮЗЫ БЕЗОПАСНОСТИ, УПРАВЛЯЕМЫЕ ИЗНУТРИ И ИЗВНЕ ............................................................... 132
ПРЕЖДЕ ЧЕМ СОЗДАВАТЬ VPN… ................................................................................................................. 132
НАСТРОЙКА VPN ТРАДИЦИОННОГО РЕЖИМА ............................................................................................ 132

Введение в VPN традиционного режима


В упрощенном режиме существует возможность создавать и поддерживать более простые, отказоустойчивые
и безопасные VPN. В этом режиме проще понять топологию VPN организации, кому с кем разрешено
соединяться. К тому же, новые функции VPN, наподобие VPN-маршрутизации, поддерживаются только
политикой безопасности упрощенного режима.
Однако, организациям, использующим крупные VPN со сложными сетями, предпочтительнее поддерживать
существующие VPN-определения и продолжать работать в традиционном режиме до тех пор, пока они не
появится возможность перевести свои политики в упрощенный режим.
Руководство о переводе VPN традиционного режима в упрощенный режим см. «Преобразование
традиционной политики в политику на основе сообщества» (на стр. 151).

VPN-домены и правила шифрования


На схеме изображены VPN между шлюзами безопасности и VPN каждого шлюза безопасности. Net_A и Net_B
– это VPN-домен шлюза безопасности 1, Net_D – VPN-домен шлюза безопасности 2, Net_E – VPN-домен
шлюза безопасности 3.
VPN Site-to-Site

VPN-домен шлюза 1 Интернет


VPN-домен шлюза 3 VPN-домен шлюза 2
VPN-туннель

В таблице ниже показано, как VPN внедряется в правила в традиционном режиме. Единое правило с
действием Зашифровать регулирует и шифрование, и контроль доступа.
Пример правила шифрования в традиционной базе правил

Источник Адресат Служба Действие Слежение Установить на

Net_A Net_A My_Services Зашифровать Журнал Шлюз


безопасности 1
Net_E Net_E
Шлюз 3

Соединение, удовлетворяющее правилу шифрования зашифровывается (или расшифровывается) и


направляется шлюзами безопасности, реализующими политику. Иногда соединение может удовлетворять
правилу шифрования, но не быть зашифрованным. Рассмотрим следующее правило:

Источник Адресат Служба Действие Слежение Установить на

X Y My_Services Зашифровать Журнал Цели политики

Если источник или адресат находятся позади шлюза безопасности, но не в VPN-домене шлюза безопасности,
соединение обрывается.
Например, если источник X – Net_C, а адресат Y – Net_D, то шлюз безопасности 1 оборвет соединение,
поскольку действие гласит «Зашифровать», но это соединение зашифровать невозможно, ибо источник не
находится в VPN-домене шлюза безопасности 1.
Если источник и адресат пребывают внутри VPN-домена одного и того же шлюза безопасности, то
соединение будет принято в нешифрованном виде.
Например, если источник X – Net_A, а адресат Y – Net_B, то соединение исходит от Х и достигает шлюза
безопасности, отправляющего ответ назад на Y. Соединение не шифруется, поскольку у Y нет второго шлюза
безопасности, который расшифровал бы его. В журнале SmartView Tracker формируется запись «Обе
конечные точки в домене шифрования».

Руководство администратора VPN R75.40VS | 131


VPN Site-to-Site

Определение свойств VPN


Между одной парой шлюзов безопасности можно использовать различные методы шифрования. Разные
каналы между двумя шлюзами безопасности могут быть зашифрованы разными методами. Причиной тому
является возможность определения свойств фазы II IKE для каждого правила шифрования.
Свойства фазы I IKE определяются для шлюза безопасности.

Шлюзы безопасности, управляемые изнутри и извне


Шлюзы безопасности на каждом конце VPN-туннеля могут управляться разными или одним и тем же
Сервером управления защитой. Шлюз безопасности, управляемый Сервером управления защитой,
называется шлюзом безопасности, управляемым изнутри. Если шлюз управляется другим Сервером
управления защитой, то он считается управляемым извне.
Если удаленный шлюз безопасности – внешний, необходимо у администратора узнать некоторые сведения
об этом шлюзе безопасности и настроить их в SmartDashboard.

Прежде чем создавать VPN…


Существует много способов настройки VPN. Прежде чем начать, требуется выяснить ряд вопросов, в
частности, выбрать:
 метод проверки подлинности;
 центр сертификации.

Выбор метода проверки подлинности


Перед созданием VPN-туннеля шлюзы безопасности должны проверить подлинность друг друга. Такая
проверка подлинности (аутентификация) выполняется либо при помощи сертификатов, либо посредством
общего секретного ключа. Сертификаты считаются более надежным средством аутентификации.

Выбор центра сертификации


Если шлюзы безопасности используют сертификаты, то последние могут выдаваться либо внутренним
центром сертификации (ICA – Internal Certification Authority) на Сервере управления защитой, либо сторонним
СА, сертифицированным OPSEC.
Внутренний СА облегчает применение PKI с программным обеспечением Check Point, таким как VPN Site-to-
Site и удаленного доступа. Впрочем, администратор может захотеть продолжать использовать привычный
для организации СА в общих приложениях, таких как безопасная электронная почта, шифрование диска.
Если оба шлюза безопасности управляются изнутри и для проверки подлинности пользуются сертификатами,
то проще всего, чтобы оба шлюза безопасности представили сертификаты, подписанные внутренним СА.

Настройка VPN традиционного режима


Изменение политики традиционного режима
Существующая политика традиционного режима откроется в традиционном режиме. Для начала новой
политики традиционного режима выполните следующие действия.
1. В окне Глобальные свойства на странице VPN выберите либо Традиционный режим для всех новых
политик безопасности (Traditional mode to all new Security Policies) или Новая политика
безопасности традиционного либо упрощенного режима (Traditional or Simplified per new Security
Policy).

Руководство администратора VPN R75.40VS | 132


VPN Site-to-Site
Допустим, вы выбрали второй вариант.
1. В меню Файл выберите Новый. Откроется окно Новый пакет политик.
2. Присвойте имя новому пакет политик.
3. Выберите Безопасность и трансляция адреса.
4. В зоне выбора метода настройки VPN выберите Традиционный режим (Traditional mode) и щелкните
OK.
В базе правил политики безопасности среди доступных Действий появилось Зашифровать.

Настройка VPN между внутренними шлюзами безопасности,


использующими сертификаты ICA

Определение шлюзов безопасности


1. Для каждого шлюза безопасности, являющегося частью VPN, определите шлюзовой объект Check Point.
В дереве сетевых объектов нажмите правой кнопкой и выберите Новый > Check Point > Шлюз
безопасности…
2. На странице Общие свойства шлюза безопасности Check Point выберите VPN.
3. В окне Соединение (Communication) установите Безопасное внутреннее соединение.
4. На странице Топология для каждого интерфейса шлюза безопасности определите IP-адрес, маску сети и
антиспуфинг.
5. На той же странице Топология определите VPN-домен. Выберите один из вариантов:
 Все IP-адреса за шлюзом безопасности, исходя из топологии.
 Определить вручную. Выберите либо существующую сеть, либо группу из выпадающего меню; или
создайте новую группу машин или сетей, нажав Новый…
6. На странице VPN, в области Список сертификатов Добавьте сертификат, выданный ICA.
7. На той же странице VPN нажмите Конфигурация традиционного режима (Traditional mode
configuration). Откроется окно Свойства IKE традиционного режима.
 В области Поддерживать методы аутентификации (Support authentication methods) выберите
Подписи открытого ключа. Для того, чтобы указать, что шлюз безопасности будет использовать
только сертификаты, выданные ICA, нажмите Указать (Specify) и выберите ICA.
 Выберите методы шифрования фазы I IKE и проверки целостности данных или согласитесь с
выбором по умолчанию.
Определение правила шифрования
1. В базе правил политики безопасности определите правило (правила) шифрования.
2. Если необходимо для этого правила изменить свойства фазы II IKE, дважды щелкните действие
Зашифровать и выполните необходимые изменения.

VPN между внутренними шлюзами, использующими сертификаты сторонних


СА
Получите сертификат СА и определите объект «центр сертификации» (СА). Подробнее см. «Регистрация
центра сертификации» (на стр. 53).
Определение шлюзов безопасности
1. Определите шлюзовой объект Check Point. В дереве сетевых объектов нажмите правой кнопкой и
выберите Новый > Check Point > Шлюз безопасности…
2. На странице Общие свойства выберите VPN.
3. В окне Соединение установите Безопасное внутреннее соединение.
4. На странице Топология для каждого интерфейса шлюза безопасности определите IP-адрес, маску сети и
антиспуфинг.
5. На той же странице Топология определите VPN-домен. Выберите один из вариантов:
 Все IP-адреса за шлюзом безопасности, исходя из топологии.
 Определить вручную. Выберите либо существующую сеть, либо группу из выпадающего меню; или
создайте новую группу машин или сетей, нажав Новый…
6. На странице VPN, в области Список сертификатов Добавьте сертификат, выданный СА, определенным
на шаге 1. Подробнее см. «Регистрация центра сертификации» (на стр. 53).
7. На той же странице VPN нажмите Конфигурация традиционного режима (Traditional mode
configuration). Откроется окно Свойства IKE традиционного режима.

Руководство администратора VPN R75.40VS | 133


VPN Site-to-Site

 В области Поддерживать методы аутентификации (Support authentication methods) выберите


Подписи открытого ключа. Для того, чтобы указать, что шлюз безопасности будет использовать
только сертификаты, выданные CA, указанным на шаге 1, нажмите Указать (Specify) и выберите CA.
 Выберите методы шифрования фазы I IKE и проверки целостности данных или согласитесь с
выбором по умолчанию.
8. Повторите шаги 2 – 8 для каждого шлюза безопасности, входящего в VPN.
Определение правила шифрования
1. В базе правил политики безопасности определите правило (правила) шифрования.
2. Если необходимо для этого правила изменить свойства фазы II IKE, дважды щелкните действие
Зашифровать и выполните необходимые изменения.

Настройка VPN со шлюзами, управляемыми извне, использующими


сертификаты
Получение информации у администратора удаленного узла
У администратора удаленного узла следует выяснить топологию шлюза безопасности и сведения о VPN-
домене, в частности, о шлюзах безопасности, управляемых извне.
Кроме того, вам следует согласовать методы проверки подлинности, целостности данных и шифрования
VPN.
Помимо этого, требуется получить сертификат СА узла – либо у администратора узла, либо прямо из СА
узла.
Определение СА
1. Получите сертификат СА и создайте объект «центр сертификации» (СА) для шлюзов безопасности,
управляемых изнутри. Подробнее см. «Регистрация центра сертификации» (на стр. 53).
2. Определите объект СА для шлюзов безопасности, управляемых извне, и настройте его, используя
сертификат удаленного СА.

Определение шлюзов безопасности, управляемых изнутри


1. Определите шлюзовой объект Check Point. В дереве сетевых объектов нажмите правой кнопкой и
выберите Новый > Check Point > Шлюз безопасности…
2. На странице Общие свойства выберите VPN.
3. В окне Соединение установите Безопасное внутреннее соединение.
4. На странице Топология для каждого интерфейса шлюза безопасности определите IP-адрес, маску сети и
антиспуфинг.
5. На той же странице Топология определите VPN-домен. Выберите один из вариантов:
 Все IP-адреса за шлюзом безопасности, исходя из топологии.
 Определить вручную. Выберите либо существующую сеть, либо группу из выпадающего меню; или
создайте новую группу машин или сетей, нажав Новый…
6. На странице VPN, в области Список сертификатов Добавьте сертификат, выданный СА, определенным
на шаге 1. Подробнее см. «Регистрация центра сертификации» (на стр. 53).
7. На той же странице VPN нажмите Конфигурация традиционного режима (Traditional mode
configuration). Откроется окно Свойства IKE традиционного режима.
 В области Поддерживать методы аутентификации (Support authentication methods) выберите
Подписи открытого ключа. Для того, чтобы указать, что шлюз безопасности будет использовать
только сертификаты, выданные CA, указанным на шаге 1, нажмите Указать (Specify) и выберите CA.
 Выберите методы шифрования фазы I IKE и проверки целостности данных или согласитесь с
выбором по умолчанию.
8. Повторите шаги 3 – 9 для каждого шлюза безопасности, управляемого изнутри.

Определение шлюзов безопасности, управляемых извне


1. Создайте объект шлюза безопасности, управляемого снаружи:
 Если это шлюз безопасности Check Point, в дереве Сетевые объекты нажмите правой кнопкой и
выберите Новый > Check Point > Шлюз безопасности, управляемый снаружи…
 Если это не шлюз безопасности Check Point, выберите Управление > Сетевые объекты… >
Новый… > Совместимый объект… (Manage > Network Objects… > New… > Interoperable
Device…)
2. Только для внешнего шлюза безопасности Check Point: на странице Общие свойства выберите VPN.

Руководство администратора VPN R75.40VS | 134


VPN Site-to-Site
3. Используя информацию о топологии, полученную у администратора удаленного узла, на странице
Топология вручную укажите IP-адрес и маску сети каждого интерфейса шлюза безопасности.
4. Используя сведения о VPN-домене, полученные у администратора удаленного узла, в области VPN-
домен страницы Топология определите VPN-домен. Выберите Все IP-адреса за шлюзом
безопасности, исходя из топологии или вручную определите группу машин или сеть и обозначьте их
как VPN-домен.
5. На странице VPN нажмите Конфигурация традиционного режима. Откроется окно Свойства IKE
традиционного режима.
 Выберите методы шифрования фазы I IKE и проверки целостности данных (совместно с
администратором удаленного шлюза безопасности) или согласитесь с выбором по умолчанию.
 В области Поддерживать методы аутентификации выберите Подписи открытого ключа.
6. На странице VPN выберите Критерии соответствия… Откроется окно Критерии соответствия
сертификата. Настройки конфигурации этого окна вынуждают шлюз безопасности, управляемый извне,
предоставить сертификат определенного СА. Они обуславливают, что подробности в сертификате
должны соответствовать критериям, указанным здесь. Эта необходимость введена шлюзами
безопасности, управляемыми изнутри, в ходе согласования IKE.

Определение правила шифрования


1. В базе правил политики безопасности определите правило (правила) шифрования.
2. Если необходимо для этого правила изменить свойства фазы II IKE, дважды щелкните действие
Зашифровать и выполните необходимые изменения.

Настройка VPN, использующей общий секретный ключ


Если для проверки подлинности шлюзов безопасности используется общий секретный ключ, каждый шлюз
безопасности в VPN должен быть соответствующим образом настроен на его использование. Затем каждому
шлюзу безопасности требуется определить общий секретный ключ для всех остальных шлюзов
безопасности. Впрочем, для каждой пары шлюзов безопасности вам надо определить общие секретные
ключи лишь на одном шлюзе безопасности из пары.
Например, если в VPN присутствуют четыре шлюза безопасности, А, В, С и D, то будет сформировано шесть
секретных ключей: А-В, А-С, А-D, В-С, В-D, C-D.
 На А определяются секреты для В, С и D.
 На В определяются секреты для С и D.
 На С определяется секрет для D.
Следующая процедура действительна как для внутренних, так и для внешних шлюзов безопасности. При
работе с шлюзами безопасности, управляемыми снаружи, администратор удаленных внешних шлюзов
безопасности должен соответствующим образом настроить свои шлюзы безопасности.

Получение информации у администратора удаленного узла


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

Определение шлюзов безопасности


1. Определите объект шлюза безопасности.
 Если шлюз безопасности внутренний, определите объект «шлюз безопасности» Check Point. В
дереве сетевых объектов нажмите правой кнопкой и выберите Новый > Check Point > Шлюз
безопасности…
 Если шлюз безопасности управляется извне:
 Если это шлюз безопасности Check Point, в дереве Сетевые объекты нажмите правой кнопкой и
выберите Новый > Check Point > Шлюз безопасности, управляемый снаружи…
 Если это не шлюз безопасности Check Point, выберите Управление > Сетевые объекты… >
Новый… > Совместимый объект… (Manage > Network Objects… > New… > Interoperable
Device…)
2. Для шлюза безопасности, управляемого изнутри, или для шлюза безопасности Check Point, управляемого
извне, на странице Общие свойства шлюзового объекта выберите VPN.
3. Только для шлюзов безопасности, управляемых изнутри, в окне Соединение установите Безопасное
внутреннее соединение.

Руководство администратора VPN R75.40VS | 135


VPN Site-to-Site
4. На странице Топология вручную укажите IP-адрес и маску сети каждого интерфейса шлюза
безопасности.
5. На той же странице Топология выберите один из вариантов:
 Все IP-адреса за шлюзом безопасности, исходя из топологии.
 Определить вручную. Выберите либо существующую сеть, либо группу из выпадающего меню; или
создайте новую группу машин или сетей, нажав Новый…
6. На странице VPN нажмите Конфигурация традиционного режима (Traditional mode configuration).
Откроется окно Свойства IKE традиционного режима.
 В области Поддерживать методы аутентификации (Support authentication methods) выберите
Общий секретный ключ, нажмите Изменить секретные ключи… (Edit Secrets…) В списке
отображаются только удаленные шлюзы безопасности, поддерживающие общие секретные ключи.
 Введите секретный ключ для каждого удаленного шлюза безопасности.
 Выберите методы шифрования фазы I IKE и проверки целостности данных или согласитесь с
выбором по умолчанию.
7. Повторите шаги 1 – 6 для каждого шлюза безопасности, входящего в VPN.
Определение правила шифрования
1. В базе правил политики безопасности определите правило (правила) шифрования.
8. Если необходимо для этого правила изменить свойства фазы II IKE, дважды щелкните действие
Зашифровать и выполните необходимые изменения.

Руководство администратора VPN R75.40VS | 136


Глава 14
Преобразование традиционной политики в политику
на основе сообщества
В этой главе
ОСНОВЫ ПРЕОБРАЗОВАНИЯ В УПРОЩЕННЫЙ РЕЖИМ VPN ................................................................... 137
ОТЛИЧИЯ ТРАДИЦИОННОГО И УПРОЩЕННОГО РЕЖИМОВ VPN .............................................................. 137
РАБОТА ПРАВИЛА ШИФРОВАНИЯ В ТРАДИЦИОННОМ РЕЖИМЕ ............................................................. 138
ПРИНЦИПЫ ПРЕОБРАЗОВАНИЯ В УПРОЩЕННЫЙ РЕЖИМ ....................................................................... 139
ПОМЕЩЕНИЕ ШЛЮЗОВ БЕЗОПАСНОСТИ В СООБЩЕСТВА ...................................................................... 139
ПРЕОБРАЗОВАНИЕ ПРАВИЛА ШИФРОВАНИЯ ............................................................................................ 139

Основы преобразования в упрощенный режим VPN


Построение VPN в упрощенном режиме имеет свои преимущества. Упрощенный режим позволяет
поддерживать и создавать более простые, а значит, более отказоустойчивые и безопасные VPN.
Упрощенный режим отделяет определения VPN от политики безопасности контроля доступа. Так проще
понять топологию VPN организации, и кому с кем разрешено связываться. Кроме того, некоторые функции,
среди которых VPN-маршрутизация, поддерживаются только политикой безопасности упрощенного режима.
Для унифицированного управления всеми существующими политиками и применения новейших функций
последних выпусков рекомендуется преобразовать политики безопасности традиционного режима в
упрощенный вид. Для новых политик советуем использовать упрощенный режим по умолчанию.
Политика безопасности, настроенная в традиционном режиме, преобразовывается в упрощенный режим при
помощи мастера преобразования политики безопасности.
После работы мастера преобразования можно значительно упростить многие политики безопасности,
сдвигая и группируя правила.
Процесс прост, ниже разъяснены изменения, выполняемые как автоматически, так и вручную. Хочется
убедить вас в целесообразности перехода от политик традиционной VPN к политикам упрощенного режима.
Для запуска мастера преобразования сохраните политику и в основном меню SmartDashboard выберите
Политика > Преобразовать в > Упрощенная VPN… (Policy > Convert to > Simplified VPN…)

Отличия традиционного и упрощенного режимов VPN


Ниже приведены отличия политик безопасности традиционного режима и упрощенного режима.
В традиционном режиме VPN контроль доступа и шифрование описываются единым правилом с действием
Зашифровать. Свойства VPN описываются для каждого шлюза безопасности.
В упрощенном режиме база правил политики безопасности описывает только контроль доступа. Иначе
говоря, база правил определяет только то, что разрешено. С другой стороны, свойства VPN определяются
для VPN-сообщества.
VPN-сообщества – это группы шлюзов безопасности. Сообщество определяет методы шифрования VPN.
Всякие связи между членами сообщества зашифрованы, а все остальные соединения не шифруются.
Упрощенный режим VPN и принцип сообществ описан в разделе «Введение в VPN Site-to-Site» (на стр. 28).
Имея политику упрощенной VPN, администратору проще настроить VPN. Хотя, традиционные политики
предоставляют возможности более точной настройки создаваемой VPN, поскольку:
 Зашифровывать или не зашифровывать – это определяется правилом (источник, адресат и служба).
 Упрощенные политики предусматривают, что все соединения между двумя шлюзами безопасности
шифруются одним и тем же методом, определенным для сообщества.
Это значит, что после окончания работы мастера может понадобиться некоторая ручная оптимизация базы
правил.
Примечание. Термины «VPN-домен» и «домен шифрования» по сути означают одно и то же.
Обычно «VPN-домен» говорят в контексте упрощенных политик, а «домен шифрования» - в
контексте традиционных.
VPN Site-to-Site

Работа правила шифрования в традиционном режиме


Когда традиционная политика преобразовывается в упрощенную, правило шифрования превращается в
правила, использующие понятие сообщества. Чтобы понять это преобразование, важно уяснить, как работает
правило шифрования.
Для понимания преобразования и существующих при этом ограничений воспользуемся схемой ниже. На ней
показана VPN между шлюзами безопасности, а также домен шифрования каждого шлюза безопасности.
Net_A и Net_B – домен шифрования шлюза безопасности 1, а Net_D – домен шифрования шлюза
безопасности 2.

Домен шифрования шлюза 1

VPN-туннель
Интернет
Домен шифрования шлюза 2

В следующей таблице показано, как VPN внедряется в правило шифрования.


Пример правила шифрования в традиционной базе правил

Источник Адресат Служба Действие Слежение Установить на

X Y My_Services Зашифровать Журнал Цели политики

Соединение, удовлетворяющее правилу шифрования зашифровывается (или расшифровывается) и


направляется шлюзами безопасности, реализующими политику. Существуют два исключения.
Если источник или адресат находятся позади шлюза безопасности, но не в VPN-домене шлюза безопасности,
соединение обрывается.
Например, если источник X – в Net_C, а адресат Y – в Net_D (см. рис. В-1 и табл. В-1), то шлюз безопасности
1 оборвет соединение, поскольку действие гласит «Зашифровать», но это соединение зашифровать
невозможно, ибо источник не находится в VPN-домене шлюза безопасности 1.

Руководство администратора VPN R75.40VS | 138


VPN Site-to-Site
Если источник и адресат пребывают внутри домена шифрования одного и того же шлюза безопасности, то
соединение будет принято в нешифрованном виде.
Например, если источник X – в Net_A, а адресат Y – в Net_B (см. рис. В-1 и табл. В-1), то соединение исходит
от Х и достигает шлюза безопасности, отправляющего ответ назад на Y. Соединение не шифруется,
поскольку у Y нет второго шлюза безопасности, который расшифровал бы его. В журнале SmartView Tracker
формируется запись «Обе конечные точки в домене шифрования».

Принципы преобразования в упрощенный режим


Мастер преобразования старается выдержать максимальный баланс между качеством и безопасностью
соединений, следуя таким принципам.
 Отвергать любой трафик, который был бы отвергнут в традиционном режиме. Это может означать
разрыв некоторых соединений, разрешенных традиционной базой правил.
 Зашифровать по меньшей мере весь трафик, который был бы зашифрован в традиционной политике. Это
значит, что преобразованная политика может подразумевать шифрование большего числа соединений,
чем первоначальная политика.
Отсюда следует, что не всякая традиционная политика может быть преобразована с точным сохранением
политики, задаваемой базой правил безопасности. При определенных обстоятельствах преобразованное
правило (правила) в упрощенном режиме может вести себя несколько отлично от правила шифрования
традиционной VPN (описано в «Работа правила шифрования в традиционном режиме» (на стр. 152).
Работа мастера преобразования – простой двух- или трехэтапный процесс. После выполнения мастера
необходимо пересмотреть базу правил безопасности, чтобы убедиться в ее прежней работоспособности и,
при необходимости, оптимизировать ее.

Помещение шлюзов безопасности в сообщества


Первым шагом при преобразовании традиционной VPN в упрощенную является создание VPN-сообществ,
описывающих топологию организации. Мастеру преобразования необходимо, чтобы администратор
разместил шлюзы безопасности в сообщества. Мастер не может сделать этого автоматически, поскольку из
традиционной политики тяжело сделать вывод, какие сообщества следует определить между шлюзами
безопасности.
Мастер позволяет определить сообщества и перетащить в них шлюзы безопасности. Согласно рис. В-1,
администратор должен сделать шлюз безопасности 1 и шлюз безопасности 2 членами одного сообщества,
перетащив оба шлюзовых объекта в один и то же объект сообщества Site-to-Site.
Возможно, для вас предпочтительнее будет создать несколько сообществ с разными свойствами
шифрования, тем самым отразив работу традиционной политики VPN.
Если сообществ заранее определено не было, по умолчанию предварительно формируются два сообщества
в виде пустых объектов. Одно из них – «интранетовское» VPN-сообщество Site-to-Site (с ячеистой
топологией), а второе – сообщество с удаленным доступом. Если эти сообщества останутся единственными,
то мастер просто предложит вам разместить все шлюзы безопасности в сообществе Site-to-Site, а все шлюзы
безопасности с удаленным доступом – в сообществе с удаленным доступом.

Преобразование правила шифрования


После помещения шлюзов безопасности в сообщества преобразовываются правила шифрования.
Преобразованная база правил в упрощенном режиме VPN максимально возможно сохраняет поведение
правила шифрования.
Правила шифрования преобразуются мастером преобразования в два правила.
Преобразованное правило в упрощенной базе правил

Источник Адресат VPN Служба Действие Слежение Установить


на

X Y All_GW_to_GW My_Services Принять Журнал Цели


политики

X Y Любая My_Services Отбросить Журнал Цели


политики

Первое правило говорит о том, что соединение соответствует критериям и разрешено, если оно исходит от Х
и адресуется Y в рамках сообщества Site-to-Site.

Руководство администратора VPN R75.40VS | 139


VPN Site-to-Site
Второе правило говорит о том, что если соединение исходит от Х и адресуется Y, но не зашифровано (или
расшифровано) любым сообществом Site-to-Site, соединение будет отброшено.
Второе правило (правило отброса) необходимо в том случае, если источник или адресат не в VPN-домене.
По традиционной политике правило шифрования отбросит соединение. Если бы в упрощенной политике не
было правила отброса, соединение могло бы соответствовать критериями и быть разрешенным каким-либо
правилом ниже в базе правил.

Когда преобразованная база правил накладывает слишком много


ограничений
Такое преобразование правил шифрования в два упрощенных режима накладывает не меньше ограничений,
чем исходное правило. Однако, согласно преобразованной базе правил, некоторые ранее подходящие и
разрешенные соединения могут оказаться отброшенными. Такое может произойти с соединениями между
двумя хостами в домене шифрования одного шлюза безопасности.
Например, согласно правилу традиционного режима, показанному ниже, разрешены взаимодействия между
узлом в Net_A и узлом в Net_B.
Пример правила шифрования в традиционной базе правил

Источник Адресат Служба Действие Слежение Установить на

X Y My_Services Зашифровать Журнал Цели политики

После преобразования в упрощенный режим соединение из узла в Net_A к узлу в Net_B будет отвергнуто
новой базой правил. Это произойдет благодаря правилам сообщества, определяющим трафик между VPN-
доменами, и не относящимися к трафику в рамках VPN-домена.
Преобразованное правило в упрощенной базе правил

Источник Адресат VPN Служба Действие Слежение Установить


на

X Y All_GW_to_GW My_Services Принять Журнал Цели


политики

X Y Любая My_Services Отбросить Журнал Цели


политики

Чтобы разрешить эти соединения в преобразованной базе правил, их следует явно разрешить. Чтобы это
сделать, добавьте свое правило между двумя существующими для каждой цели политики из столбца
«Установить на». Например, вместо двух правил, указанных в таблице ниже, могут появиться три правила из
таблицы ниже.
Вручную добавленное правило в преобразованной базе правил шифрования

Источник Адресат VPN Служба Действие Слежение Установить


на

X Y All_GW_to_GW My_Services Принять Журнал Цели


политики

Net_A Net_B Любая My_Services Принять Журнал Шлюз 1

X Y Любая My_Services Отбросить Журнал Цели


политики

В большинстве случаев добавлять эти правила не надо. Это требуется только тогда, когда соединения внутри
домена шифрования помечены правилом шифрования. Признаком этого является появления в журнале
SmartView Tracker записи «Обе конечные точки в домене шифрования».

Преобразование клиентских правил шифрования


Каждое клиентское правило шифрования преобразовывается в единое правило, сохраняющее поведение
клиентского правила шифрования. Например, правило традиционного режима, приведенное ниже в таблице,
допускает пользователям удаленного доступа устанавливать связь с Net_D.

Руководство администратора VPN R75.40VS | 140


VPN Site-to-Site

Правило удаленного доступа в традиционном режиме

Источник Адресат Служба Действие Слежение

All_Users@alaska Net_D My_Services Зашифровать Журнал


клиента

Преобразованное правило показано в следующей таблице. Сообщество с удаленным доступом помещено в


поле VPN, а действием правила стало Принять.
Преобразованное правило удаленного доступа в упрощенном режиме

Источник Адресат VPN Служба Действие Слежение

All_Users@alaska Net_D Сообщество с My_Services Принять Журнал


удаленным
доступом

Преобразование правил Auth+Encrypt


В политике традиционного режима правила Auth+Encrypt – это правила, предусматривающие проверку
подлинности пользователя, клиента или сеанса вместе с опцией Добавить шифрование, выбранной в
столбце Действие правила.
В правилах Auth+Encrypt, как показано в правиле проверки подлинности клиента в таблице ниже, поле
Источник как указывает на ограничение расположения источника, так и ограничивает множество допущенных
пользователей. Любое соединение, удовлетворяющее правилу, должно быть аутентифицировано и
зашифровано. Если шифрование невозможно, связь будет отброшена.
Правило Auth+Encrypt в традиционном режиме

Источник Адресат Служба Действие Слежение

All_Users@alaska Net_D My_Services Client_Auth Журнал

Поскольку идентификация пользователя возможна только в правилах проверки подлинности, а не в правилах


отброса, невозможно назначить правило, которое отбрасывало бы незашифрованные соединения.
Добавьте в список исключенных служб сообщества службы, которые не подлежат шифрованию. Например,
если у вас в традиционной политике четко определены неявные правила. См. «Как авторизовать
управляющие соединения брандмауэра в VPN-сообществах» (на стр. 45).
По этой причине правила Auth+Encrypt не могут автоматически транслироваться таким образом, чтобы
преобразованная база правил накладывала, по меньшей мере, столько же ограничений, сколько у
первоначального правила. Вместо этого мастер преобразования преобразовывает правила Auth+Encrypt в
единое правило и не добавляет правила отброса, как показано в следующей таблице. Это проблема
безопасности, поскольку соединения, подходящие по критерию расположения источника (когда пользователи
успешно аутентифицируются, но не шифруются), могут быть приняты дальнейшими правилами из базы
правил, если в одном из них для того же источника указано действие Принять.
Небезопасное правило Auth+Encrypt, преобразованное в упрощенный режим

Источник Адресат VPN Служба Действие Слежение

All_Users@alaska Net_D All_GwToGw My_Services Client_Auth Журнал

При обнаружении конвертером правил Auth+Encrypt, администратору приходит уведомление в виде ошибки, в
котором говорится, что конвертер не может автоматически преобразовать такие правила. В этом случае
важно перед установкой пересмотреть преобразованную базу данных, чтобы избежать погрешностей защиты.
Возможно, необходимо добавить правила, чтобы весь ранее отбрасываемый первоначальной базой правил
трафик и при новой преобразованной базе правил отбрасывался.

Как поступает конвертер с выключенными правилами


Если в базе правил традиционной VPN правило было выключено, то и его преобразованный аналог в
упрощенной базе правил будет выключен.

Руководство администратора VPN R75.40VS | 141


VPN Site-to-Site

После работы мастера преобразования


После завершения мастера преобразования проверьте базу правил на наличие желаемой функциональности
и, при необходимости, оптимизируйте ее, внеся изменения, как описано ниже. Выше все эти пункты
описывались – подытожим их.
Изъятие ненужных правил отброса
В некоторых случаях можно удалить второе правило отброса, сформированное после преобразования
правила шифрования, поскольку под него никогда не подойдет ни одно соединение – первого правила будет
достаточно. Это касается правил, для которых действительно следующее:
 Источник и адресат находятся в домене шифрования шлюзов безопасности, указанных в столбце
«Установить на» правила.
 Сообщество связано со всеми защитными адресами шлюзов безопасности источника и со всеми
защитными адресами шлюзов безопасности адресата.
Второе правило отброса, сформированное после преобразования правила шифрования, можно также
удалить, если соединения, не подходящие под первое правило, отбрасываются правилами, идущими ниже в
базе правил. Иногда несколько правил отброса, сформированных после преобразования нескольких правил
шифрования, можно сгруппировать в единое правило отброса.
Добавление правил, разрешающих взаимодействие внутри VPN-домена
Соединения, соответствующие правилам шифрования, в которых обе конечные точки расположены внутри
домена шифрования одного и того же шлюза безопасности, принимаются в традиционной базе правил. Чтобы
достичь того же эффекта в упрощенной базе правил, можно вручную добавить правила, принимающие
трафик внутри доменов шифрования шлюзов безопасности. В большинстве случаев нет необходимости
добавлять эти правила. Делайте это, если видите сообщение в журнале SmartView Tracker «Обе конечные
точки в домене шифрования».
Правила Auth+Encrypt
Правила Auth+Encrypt автоматически не преобразовываются. Когда в базе правил обнаруживаются такие
правила, пересмотрите преобразованную базу правил и убедитесь, что такие правила не влияют на
защищенность сети.

Руководство администратора VPN R75.40VS | 142


VPN с удаленным доступом
В этом разделе

РЕШЕНИЯ CHECK POINT ДЛЯ УДАЛЕННОГО ДОСТУПА.............................................................................. 144


ОБЗОР VPN С УДАЛЕННЫМ ДОСТУПОМ ...................................................................................................... 149
ОСОБЕННОСТИ VPN С УДАЛЕННЫМ ДОСТУПОМ........................................................................................ 155
НАСТРОЙКА VPN С УДАЛЕННЫМ ДОСТУПОМ ............................................................................................. 157
ОФИСНЫЙ РЕЖИМ .......................................................................................................................................... 166
УПАКОВКА SECURECLIENT ............................................................................................................................ 180
БЕЗОПАСНОСТЬ НАСТОЛЬНЫХ СИСТЕМ .................................................................................................... 185
КЛИЕНТЫ ПРОТОКОЛА ТУННЕЛИРОВАНИЯ ВТОРОГО УРОВНЯ (L2TP).................................................... 187
ПРОВЕРКА БЕЗОПАСНОЙ КОНФИГУРАЦИИ ................................................................................................ 195
VPN-МАРШРУТИЗАЦИЯ – УДАЛЕННЫЙ ДОСТУП ......................................................................................... 219
ВЫБОР ЛИНИИ СВЯЗИ ДЛЯ КЛИЕНТОВ УДАЛЕННОГО ДОСТУПА............................................................. 224
ИСПОЛЬЗОВАНИЕ НАПРАВЛЕННОЙ VPN ДЛЯ УДАЛЕННОГО ДОСТУПА .................................................. 225
ДОПОЛНИТЕЛЬНАЯ НАСТРОЙКА УДАЛЕННОГО ДОСТУПА........................................................................ 226
МНОЖЕСТВЕННЫЕ ТОЧКИ ВХОДА ДЛЯ VPN С УДАЛЕННЫМ ДОСТУПОМ ............................................... 233
КОНФИГУРАЦИОННЫЕ ФАЙЛЫ USERC.C И PRODUCT.INI.......................................................................... 237
SSL NETWORK EXTENDER.............................................................................................................................. 248
РЕШЕНИЕ ПРОБЛЕМ СВЯЗИ.......................................................................................................................... 270
Глава 15
Решения Check Point для удаленного доступа
В этой главе
ОБЕСПЕЧЕНИЕ БЕЗОПАСНОГО УДАЛЕННОГО ДОСТУПА .......................................................................... 144
ТИПЫ РЕШЕНИЙ ............................................................................................................................................. 144
СРАВНЕНИЕ РЕШЕНИЙ ДЛЯ УДАЛЕННОГО ДОСТУПА................................................................................ 145
СВОДНАЯ ХАРАКТЕРИСТИКА ВАРИАНТОВ УДАЛЕННОГО ДОСТУПА ....................................................... 146

Обеспечение безопасного удаленного доступа


В нынешней бизнес-среде не вызывает сомнений тот факт, что сотрудникам необходим удаленный доступ к
чувствительной информации из множества мет и от множества устройств. Организации должны обеспечить
безопасность собственной корпоративной сети, чтобы удаленный доступ не стал ахиллесовой пятой ее IT-
безопасности.
Данная глава:

 Расскажет вам о безопасных вариантах удаленного доступа от Check Point.


 Поможет выбрать клиент(ы) удаленного доступа, максимально подходящий требованиям вашей
организации.
 Откроет вам источники информации.

Типы решений
Все решения Check Point для удаленного доступа обеспечивают:
 Безопасную связь с корпоративными ресурсами в масштабе предприятия.
 Сильную проверку подлинности пользователей.
 Точный контроль доступа.
Факторы, которые следует учитывать при выборе решения для удаленного доступа
для вашей организации
 Клиентское или бесклиентное. Требует ли решение установки клиентского ПО Check Point на
удаленных терминалах? Или это бесклиентное решение, для которого достаточно веб-браузера?
Возможно в пределах организации вам понадобится несколько решений под разные нужды.
 Безопасная связь и безопасность терминалов. Какими свойствами должно обладать решение?
 Безопасная связь. Трафик между клиентом и шлюзом VPN шифруется. После аутентификации
пользователей, им предоставляется доступ к корпоративным ресурсам, для них открытым политикой
доступа. Это обеспечивают все решения Check Point.
 Безопасность терминалов. Терминальные компьютеры все время защищены, даже когда нет
соединения с корпоративной сетью. Это обеспечивают некоторые решения Check Point.

Клиентское или бесклиентное


Решения Check Point для удаленного доступа имеют разные типы установки.
 Клиентское решение. Перед формированием удаленного соединения должно пройти установку на
клиентских компьютерах и устройствах. Клиентское ПО устанавливается, как правило, на
подконтрольных устройствах, например, на компьютерах, принадлежащих компании. Клиенты
обеспечивают доступ ко всем типам корпоративных ресурсов.
 Бесклиентное решение. Пользователи подключаются посредством веб-браузера. Бесклиентными
решениями можно пользоваться с большинства компьютеров, как с корпоративных, так и с личных или
общественных. На терминале не требуется установка клиентской части. Бесклиентные решения обычно
предоставляют доступ к корпоративным веб-ресурсам.
 Клиент по требованию. Пользователи подключаются через веб-браузер. При необходимости клиент
автоматически из браузера устанавливается на терминальном компьютере. Клиенты по требованию
можно использовать с большинства компьютеров, как с корпоративных, так и с личных или
общественных. Клиенты обеспечивают доступ ко всем типам корпоративных ресурсов.
Все эти типы установки используют два протокола шифрования: IPSec и SSL. Оба они нацелены на создание
надежного удаленного соединения.
VPN с удаленным доступом
С целью соответствия большинству требований, безопасное решение по удаленному доступу может
включать свойства VPN IPSec и SSL. С одного шлюза Check Point можно задействовать программный блейд
VPN IPSec и программный блейд мобильного доступа для VPN SSL.
Все клиенты Check Point способны работать через устройства NAT, беспроводные точки доступа и прокси-
серверы в ситуациях со сложными топологиями, как-то в аэропортах или в гостиницах.

Безопасная связь и безопасность терминалов


Вы можете сочетать безопасную связь с дополнительными функциями, защитив сеть или терминальные
машины.
 Безопасная связь. Трафик между клиентом и шлюзом VPN шифруется, поддерживается сильная
проверка подлинности пользователей. Это обеспечивают все решения Check Point.
Такие решения требуют лицензии по количеству одновременно подключенных пользователей.
 Проверка безопасности терминальных компьютеров. Выполняется проверка устройств,
подключаемых ко шлюзу, на соответствие требованиям безопасности.
 Безопасность терминалов.
 Персональный брандмауэр. Непрерывно защищает терминальные компьютеры, следуя
централизованной политике безопасности. Это важно, поскольку удаленные клиенты не входят в
защищенную сеть, трафик к клиентам проверяется только персональным брандмауэром. Это
обеспечивают некоторые решения Check Point.
 Прочие средства защиты терминалов. Среди решений Check Point существуют разные средства
защиты терминалов от вредоносных программ, средства шифрования диска и т. д.
Эти решения требуют лицензии по количеству установленных клиентов.

Сравнение решений для удаленного доступа


Подробнее о новейшей версии для каждого клиента и ссылки на дальнейшую информацию см. в sk67820
(http://supportcontent.checkpoint.com/solutions?id=sk67820).

Название Поддерживаемые Клиентское Протокол Проверка Персональны


операционные или шифрования безопасности й брандмауэр
системы бесклиентное для на
терминальных терминальны
устройств х устройствах

Mobile Access Web Windows, Linux, Бесклиентное SSL v


Portal Mac OS

SSL Network Extender Windows, Linux, По требованию SSL v


for Mobile Access Blade Mac OS (клиент через
Mobile Access
Portal)

Check Point Mobile for iOS Клиентское SSL


iPhone and iPad

Check Point Mobile VPN iOS Клиентское IPSec / SSL


for iOS

Check Point Mobile for Android Клиентское SSL


Android

SecuRemote Windows Клиентское IPSec

Check Point Mobile for Windows Клиентское IPSec v


Windows

Endpoint Security VPN Windows Клиентское IPSec v v


for Windows

Endpoint Security VPN Mac OS Клиентское IPSec v


for Mac

Руководство администратора VPN R75.40VS | 145


VPN с удаленным доступом

Название Поддерживаемые Клиентское Протокол Проверка Персональны


операционные или шифрования безопасности й брандмауэр
системы бесклиентное для на
терминальных терминальны
устройств х устройствах

Endpoint Security Suite Windows Клиентское IPSec v v


Remote Access VPN
Blade

Check Point GO VPN Windows Бесклиентное – SSL v


требует
устройства
Check Point GO

Сводная характеристика вариантов удаленного доступа


Ниже приводится сводная характеристика для каждого варианта удаленного доступа, который предлагается
Check Point. Все они обеспечивают удаленный доступ к корпоративным ресурсам, однако, у каждого из них
есть индивидуальные функции, которые обуславливают сферу его использования.
Подробнее о новейшей версии для каждого клиента и ссылки на дальнейшую информацию см. в sk67820
(http://supportcontent.checkpoint.com/solutions?id=sk67820).

Mobile Access Web Portal


Mobile Access Portal – это бесклиентное VPN-решение SSL. Рекомендуется для пользователей, которым
нужен доступ к корпоративным ресурсам из дома, интернет-кафе или с другого компьютера, не подвластного
организации. Mobile Access Portal можно использовать и с корпоративными устройствами.
Обеспечивает:
 Безопасную связь
 Проверку безопасности
Mobile Access Portal обеспечивает доступ к корпоративным веб-ресурсам. Чтобы получить доступ через него
ко всем ресурсам предприятия, можно воспользоваться клиентом по требованию, SSL Network Extender.
Требуемые лицензии: блейд Mobile Access Portal на шлюзе.
Поддерживаемые платформы: Windows, Mac OS X, Linux.
Где достать клиент: входит в комплект шлюза безопасности (sk67820).

SSL Network Extender


SSL Network Extender – тонкий VPN-клиент по требованию на SSL, устанавливаемый автоматически на
машине пользователя через веб-браузер. Обеспечивает доступ ко всем типам корпоративных ресурсов.
У SSL Network Extender два режима.
 Сетевой режим. Пользователи могут получать доступ ко всем типам приложений (на родном IP и в сети)
внутренней сети. Чтобы установит клиент сетевого режима, пользователь обязан обладать правами
администратора на клиентском компьютере.
Поддерживаемые платформы: Windows, Mac OS X, Linux
 Режим приложения. Пользователи могут получать доступ к большинству типов приложений (на родном
IP и в сети) внутренней сети, в том числе большей части TCP-приложений. Для этого пользователю не
требуется прав администратора на терминале.
Поддерживаемые платформы: Windows
Требуемые лицензии: блейд Mobile Access Portal на шлюзе.
Где достать клиент: входит в комплект шлюза безопасности (sk67820).

SecuRemote
SecuRemote – безопасный VPN-клиент на IPSec с ограниченной функциональностью. Обеспечивает
безопасную связь.
Требуемые лицензии: программный блейд VPN IPSec на шлюзе. Клиент бесплатный и не требует
дополнительных лицензий.
Поддерживаемые платформы: Windows

Руководство администратора VPN R75.40VS | 146


VPN с удаленным доступом
Где достать клиент: центр поддержки Check Point (sk67820).

Check Point Mobile for Windows


Check Point Mobile for Windows – VPN-клиент на IPSec. Оптимально подходит для средних и крупных
предприятий, не требующих политики безопасности терминалов.
Обеспечивает:
 Безопасную связь
 Проверку безопасности
Требуемые лицензии: блейды Mobile Access Portal и VPN IPSec на шлюзе.
Поддерживаемые платформы: Windows
Где достать клиент: центр поддержки Check Point (sk67820).

Endpoint Security VPN


Endpoint Security VPN – VPN-клиент на IPSec, пришедший на замену SecureClient. Оптимально подходит для
средних и крупных предприятий.
Обеспечивает:
 Безопасную связь
 Проверку безопасности
 Безопасность терминала, включающую интегрированный персональный брандмауэр, централизованно
управляемый Сервером управления защитой.
Требуемые лицензии: программный блейд VPN IPSec на шлюзе, лицензия Endpoint Container, лицензия на
программный VPN-блейд на Сервере управления защитой.
Поддерживаемые платформы: Windows
Где достать клиент: центр поддержки Check Point (sk67820).
Примечание. Endpoint Security VPN на MacOS включает персональный брандмауэр, но не
обеспечивает проверку безопасности.

Endpoint Security Suite


Пакет Endpoint Security упрощает управление безопасностью терминала, унифицируя все средства защиты
терминала в одну консоль. Дополнительные блейды Endpoint Security включают: брандмауэр, ПО полного
шифрования диска, средства шифрования данных и защиты портов, защиту от вредоносных программ и
средство управления программами. Как часть комплексного решения, программный VPN-блейд удаленного
доступа обеспечивает полную безопасную VPN-связь на IPSec.
Пакет Endpoint Security наилучшим образом подходит для средних и крупных предприятий, желающих
управлять безопасностью всех терминалов с помощью единой консоли.
Требуемые лицензии: лицензии Endpoint Security Container and Management, программный VPN-блейд
Endpoint на Сервере управления защитой.
Поддерживаемые платформы: Windows
Где достать клиент: центр поддержки Check Point (sk67820).

Check Point Mobile for iPhone and iPad


Check Point Mobile for iPhone and iPad – это VPN-клиент на SSL. Обеспечивает безопасность связи и доступ к
корпоративным веб-ресурсам и Exchange ActiveSync.
Check Point Mobile for iPhone and iPad идеально подходит для мобильных сотрудников с устройствами iPhone
и iPad.
Требуемые лицензии: блейд Mobile Access Portal на шлюзе.
Поддерживаемые платформы: iOS
Где достать клиент: Apple App Store

Check Point Mobile for Android


Check Point Mobile for Android – это VPN-клиент на SSL. Обеспечивает безопасность связи и доступ к
корпоративным веб-ресурсам и Exchange ActiveSync.
Check Point Mobile for Android идеально подходит для мобильных сотрудников с устройствами Android.

Руководство администратора VPN R75.40VS | 147


VPN с удаленным доступом
Требуемые лицензии: блейд Mobile Access Portal на шлюзе.
Поддерживаемые платформы: Android
Где достать клиент: Android Market

Check Point GO
Check Point GO – это портативное рабочее пространство с виртуализированными приложениями Windows на
защищенном и зашифрованном USB Flash-накопителе. Пользователи вставляют USB-накопитель в хост и
получают безопасный доступ к своему рабочему пространству и корпоративным ресурсам посредством VPN-
технологии SSL.
Check Point GO идеально подходит для мобильных работников, подрядчиков и при аварийном
восстановлении. Виртуальное рабочее пространство отделяется от компьютера-хоста и управляет
приложениями, данными, способными работать под Check Point GO.
Обеспечивает:
 Безопасную связь
 Проверку безопасности
Требуемые лицензии: программный блейд VPN IPSec на шлюзе и устройствах Check Point GO.
Поддерживаемые платформы: Windows
Где достать клиент: центр поддержки Check Point (sk67820).

Руководство администратора VPN R75.40VS | 148


Глава 16
Обзор VPN с удаленным доступом
В этой главе
ОБЗОР VPN С УДАЛЕННЫМ ДОСТУПОМ ...................................................................................................... 149
РЕШЕНИЕ ДЛЯ УДАЛЕННОГО ДОСТУПА SECURECLIENT ........................................................................... 149
НЕОБХОДИМОСТЬ В VPN С УДАЛЕННЫМ ДОСТУПОМ ............................................................................... 154

Обзор VPN с удаленным доступом


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

 IP-адрес удаленного клиента может быть неизвестным.


 Клиент удаленного доступа может оставаться подключенным к корпоративной локальной сети в течение
всего рабочего дня, а вечером подключиться к сети гостиницы, возможно спрятанной за каким-нибудь
NAT-устройством.
 Удаленному клиенту может понадобиться подключиться к корпоративной локальной сети посредством
беспроводной точки доступа.
 Обычно, когда пользователь удаленного клиентского ПО находится не на рабочем месте, его не
защищает текущая политика безопасности; клиент удаленного доступа подвержен Интернет-угрозам, а
также может впустить в корпоративную сеть злоумышленника.

Для решения этих проблем требуется система безопасности, обеспечивающая надежную защиту удаленного
соединения.
Решения Check Point для VPN с удаленным доступом позволяют сформировать VPN-туннель между
удаленным пользователем и внутренней сетью организации. VPN-туннель гарантирует:
 Подлинность за счет применения стандартных средств аутентификации.
 Конфиденциальность за счет шифрования данных.
 Целостность за счет промышленного стандарта контроля целостности данных.
Клиентское ПО Check Point для удаленного доступа расширяет возможности удаленных пользователей.
Последним предоставляется возможность безопасного доступа к чувствительным данным в сетях и на
серверах посредством VPN-туннеля, используя LAN, беспроводную LAN и разные варианты dial-up-
соединений, в том числе широковещательные. Управление пользователями происходит либо во внутренней
базе данных шлюза безопасности, либо через внешний сервер LDAP.

После проверки подлинности пользователя устанавливается прозрачное защищенное соединение.

Решение для удаленного доступа SecureClient


Примечание. SecureClient – устаревший клиент. Прочие варианты см. в пункте «Решения Check
Point для удаленного доступа» (на стр. 159).

Увеличение возможностей SecuRemote расширениями SecureClient


SecureClient – это клиент удаленного доступа, включающий SecuRemote и дополняющий его рядом функций:
 функции безопасности;
 функции связи;
 функции управления.
Функции безопасности
 Политика безопасности настольных систем. См. «Безопасность настольных систем» (на стр. 205).
 Ведение журнала и сигналы тревоги.
 Проверка безопасной конфигурации (SCV). См. «Проверка безопасной конфигурации» (на стр. 215).
Функции связи
 Адреса офисного режима. См. «Офисный режим» (на стр. 185).
VPN с удаленным доступом

 Режим посетителя. См. «Решение проблем связи» (на стр. 297).


 Режим концентратора. См. «Режим концентратора (VPN-маршрутизация для удаленных клиентов)» (на
стр. 239).
Функции управления
 Автоматическое программное распределение.
 Дополнительные опции упаковки и распространения. См. «Упаковка SecureClient» (на стр. 200).
 Средства диагностики.

Установление соединения между удаленным пользователем и шлюзом


безопасности
Чтобы пользователь имел возможность доступа к сетевому ресурсу, защищаемому шлюзом безопасности,
инициируется процесс создания VPN-туннеля. Между узлами происходит согласование IKE (Обмен ключами
по Интернету).
В ходе согласования IKE проверяются идентификаторы узлов. Шлюз безопасности проверяет данные
пользователя, а клиент – шлюза безопасности. Проверка подлинности может происходить несколькими
методами, в том числе с помощью цифровых сертификатов, выданных внутренним центром сертификации
(ICA). Кроме того, для этой цели подходят PKI-решения сторонних производителей, общие секретные ключи
или сторонние методы аутентификации (например, SecurID, RADIUS и т. д.)
После успешного завершения согласования IKE между клиентом и шлюзом безопасности формируется
защищенное соединение – VPN-туннель. Всякое взаимодействие между клиентом и VPN-доменом шлюза
безопасности (локальная сеть позади шлюза безопасности) зашифровывается внутри VPN-туннеля с
использованием стандарта IPSec. Процесс установления VPN прозрачен за исключением тех случаев, когда
пользователя просят каким-либо образом подтвердить свою личность.

VPN-узел 1 Интернет Шлюз 2

Хост 1 Сервер LDAP Удаленный клиент


Шлюз VPN-узел 2
На рисунке удаленный клиент инициирует соединение со шлюзом безопасности 1. Управление
пользователем происходит не через базу данных VPN, а средствами сервера LDAP в VPN-узле 2. Во время
согласования IKE выполняется проверка подлинности. Шлюз безопасности 1 проверяет существование
такого пользователя, опрашивая сервер LDAP позади шлюза безопасности 2. После подтверждения
существования пользователя шлюз безопасности признает его, например, подтверждая его сертификат.
После успешного завершения IKE создается туннель; удаленный клиент соединяется с хостом 1.
Если клиент пребывает позади шлюза безопасности (например, пользователь получает доступ к
корпоративной локальной сети из офиса компании), то соединения между ним и адресатами, также
пребывающими за шлюзом безопасности LAN, не зашифровываются.

Сообщество удаленного доступа


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

Руководство администратора VPN R75.40VS | 150


VPN с удаленным доступом
связи между удаленными пользователями и VPN-доменами шлюзов безопасности защищены (путем
аутентификации и шифрования) согласно параметрам, определенным для соединений удаленного доступа в
глобальных свойствах SmartDashboard.

Представление элементов сети удаленному клиенту


Прежде чем во внутренней сети организации будут созданы зашифрованные соединения к сетевым ресурсам
и обратно, клиенты должны знать ее элементы. Эти элементы, называемые топологией, загружаются с
любого шлюза безопасности, управляемого Сервером управления защитой.
Информация о топологии узла включает IP-адреса объектов сети и адреса хостов в VPN-доменах других
шлюзов безопасности, управляемых тем же самым Сервером управления защитой. Если IP адресата
находится внутри топологии узла, соединение проходит через VPN-туннель.
Когда пользователь создает узел, клиентское ПО автоматически связывается с узлом и загружает сведения о
топологии и различные настройки, определенные администратором для клиента. Такое соединение
защищено, проверка подлинности выполняется с использованием IKE через SSL. У топологии узла есть свой
таймаут, после которого клиенту пора загружать обновленную топологию. Сетевой администратор может для
удаленных клиентов настроить автоматическое обновление топологии. Такое обновление не требует
вмешательства пользователя.

Режим соединения
Клиенты удаленного доступа соединяются с шлюзами безопасности, используя режим соединения.
В режиме соединения удаленный пользователь сознательно инициирует VPN-канал к конкретному шлюзу
безопасности. Последующие соединения с любым хостом позади других шлюзов безопасности в меру
необходимости приведут к прозрачному появлению дополнительных VPN-каналов.
В режиме соединения возможно:
 Офисный режим. Для решения проблем маршрутизации между клиентом и шлюзом безопасности. См.
«Офисный режим» (на стр. 185).
 Режим посетителя. Для ситуаций, когда клиент обязан весь трафик «клиент-шлюз безопасности»
провести через обычное TCP-соединение, порт 443.
 Маршрутизация всего трафика через шлюз безопасности (режим концентратора). Для достижения
высшего уровня безопасности и качества связи.
 Автосоединение. Когда приложение пытается установить связь с хостом позади шлюза безопасности,
пользователь получает приглашение инициировать VPN-канал к этому шлюзу безопасности. Например,
когда почтовый клиент пытается получить доступ к INAP-серверу позади шлюза безопасности Х,
SecureClient посылает пользователю приглашение инициировать туннель к этому шлюзу безопасности.
 Профили пользователей (Профили местоположений). См. «Профили пользователей» (на стр. 168).

Профили пользователей
Перед мобильными пользователями возникает масса разных проблем связи. Утром они подключены к
локальной сети компании-партнера; вечером они подключаются за каким-нибудь NAT-устройством,
используемым в гостинице, в которой они живут.
В изменчивых условиях подключения используются разные профили пользователя. Пользователи создают
собственные профили; или администратор сети создает для них несколько профилей. Если администратор
создает профиль, профиль загружается в клиентское ПО вместе с обновлением топологии узла.
Пользователь выбирает, с каким профилем из списка ему работать. Например, с профилем, допускающим
инкапсуляцию UDP, чтобы справиться с NAT-устройством, или с профилем, разрешающим режим
посетителя, когда удаленный клиент обязан туннелировать VPN-соединение через порт 443. В профиле
содержится также сервер политики, применяемый для загрузки политики безопасности настольных систем.

Контроль доступа в сообществе с удаленным доступом


Обычно администратору приходится задавать набор правил, составляющих суть контроля доступа в сеть и из
сети. Это утверждение остается в силе и для клиентов удаленного доступа, принадлежащих сообществу с
удаленным доступом. Необходимо создавать правила политики, чтобы контролировать доступ удаленных
клиентов ко внутренней сети через шлюз безопасности. (Членство в сообществе не дает автоматического
доступа в сеть).
Контроль доступа определяется базой правил политики безопасности шлюза безопасности. Иначе говоря, эта
база указывает, разрешено ли то или иное соединение. Следует ли шифровать соединение – это
определяется сообществом. Если и источник и адресат принадлежат сообществу, соединение шифруется; в
противном случае – не шифруется. Например, рассмотрим правило, позволяющее FTP-соединения. Если
соединение, соответствующее критериям правила, устанавливается между членами сообщества, его
зашифровывают. Если же соединение не между членами сообщества, шифрование не применяется.

Руководство администратора VPN R75.40VS | 151


VPN с удаленным доступом
Политика безопасности шлюза безопасности обуславливает доступ к ресурсам, находящимся позади шлюза
безопасности, защищая сам шлюз безопасности и сети за ним. Поскольку удаленный клиент находится не
позади шлюза безопасности, он не защищен политикой безопасности шлюза безопасности. Удаленный
доступ посредством SecureClient может быть защищен политикой безопасности настольных систем. См.
«Безопасность настольных систем» (на стр. 205).

Схемы взаимной проверки подлинности клиента и шлюза безопасности


Проверка подлинности (аутентификация) – ключевой фактор при установлении защищенного канала связи
между шлюзами безопасности и удаленными клиентами. Доступны различные методы проверки, к примеру:
 цифровые сертификаты;
 общие секретные ключи;
 прочие методы аутентификации (доступные в гибридном режиме)
Цифровые сертификаты
Цифровые сертификаты являются самым предпочтительным и управляемым методом проверки подлинности.
Обе стороны представляют свои сертификаты как собственное удостоверение. Обе стороны проверяют,
чтобы сертификат противоположной стороны был годен (т. е., подписан известным и доверенным СА, не был
просрочен или отозван).
Цифровые сертификаты выдаются либо внутренним центром сертификации Check Point, либо сторонними
PKI-решениями. ICA Check Point тесно связан с VPN и является самым простым способом настройки VPN с
удаленным доступом. ICA может выдавать сертификаты как шлюзам безопасности (автоматически), так и
удаленным пользователям (генерируется или инициируется).
С помощью ICA можно сгенерировать сертификат и передать его пользователю за пределами канала
передачи. Или процесс создания сертификата можно инициировать на Сервере управления защитой.
Процесс завершается независимо от пользователя. Кроме того, администратор может инициировать
создание сертификата средством управления ICA (единственная возможность, доступная пользователям,
определенным на сервере LDAP).
Для создания сертификатов для взаимной проверки подлинности шлюзов безопасности и удаленных
пользователей можно воспользоваться сторонними центрами сертификации. Поддерживаются форматы
сертификатов PKCS#12, CAPI и Entrust.
Для хранения сертификатов у пользователей может также быть аппаратный токен. Этот вариант
предусматривает еще больший уровень защиты, поскольку частный ключ хранится исключительно на
аппаратном токене.
В рамках процесса проверки сертификатов во время согласования IKE обе стороны – клиент и шлюз
безопасности – проверяют сертификат противоположной стороны в Списке отозванных сертификатов
(CRL), публикуемом СА, выдавшим сертификат. Если клиент не может получить CRL, его от имени клиента
получает шлюз безопасности и передает клиенту во время согласования IKE. Из соображений безопасности
CRL имеет цифровую подпись СА.
Общий секретный ключ
Этот метод проверки подлинности предпочтителен из-за своей простоты, однако, проигрывает предыдущему
по уровню защиты. Обе стороны перед организацией VPN договариваются о пароле. Обмен паролем
происходит за пределами канала передачи, он многократно используется. В ходе процесса проверки
подлинности и клиент, и шлюз безопасности проверяют, знает ли противоположная сторона условленный
пароль.
Примечание. Пароли, настроенные на вкладке общего секретного ключа, используются в
гибридном режиме IKE, а не в режиме общего секретного ключа. Режим общего секретного
ключа IKE применяется для работы с клиентами 4.1.
Прочие методы аутентификации, доступные в гибридном режиме
Разные организации используют разнообразные способы проверки пользователей. Они хотели бы
пользоваться теми же средствами для удаленного доступа. Гибридный режим – это режим IKE,
поддерживающий асимметричный способ аутентификации с целью удовлетворения этому требованию. В
гибридном режиме пользователь для проверки подлинности шлюза безопасности использует один из
перечисленных ниже методов. В свою очередь, шлюз безопасности представляется клиенту, используя
сильный способ аутентификации на основе сертификата. Все методы аутентификации, применимые в
гибридном режиме, поддерживаются при обычной идентификации пользователя в VPN.
 Одноразовый пароль. Пользователю предлагается ввести число, отображаемое на карте Security
Dynamics SecurID. Для схемы аутентификации SecurID нет специфичных параметров. VPN-модуль
работает как ACE/Agent 5.0 для конфигурации агента.
Поддерживаются также SoftID (программная версия SecurID RSA), различные другие карты одноразовых
паролей и USB-токены.

Руководство администратора VPN R75.40VS | 152


VPN с удаленным доступом

 Пароль шлюза безопасности. Пользователю предлагается ввести свой пароль, хранимый на шлюзе
безопасности.
 Пароль ОС. Пользователю предлагается ввести свой пароль операционной системы.
 RADIUS. Пользователю предлагается ввести правильный ответ, определяемый сервером RADIUS.
 TACACS. Пользователю предлагается ввести правильный ответ, определяемый сервером TACACS или
TACACS+.
 SAA. SAA – это API-расширение OPSEC для клиентов удаленного доступа, позволяющее применение
сторонних методов проверки подлинности, таких как биометрическая идентификация, с Endpoint Security
VPN, Check Point Mobile for Windows и SecuRemote.
Настройка проверки подлинности
На шлюзе безопасности проверку подлинности можно настроить в двух местах.
 В окне Свойства шлюза на странице Аутентификация (Authentication) можно настроить доступ для
пользователей, использующих для аутентификации Пароль Check Point, SecurID, Пароль Ос, сервер
RADIUS или сервер TACACS. Вдобавок к выбранному методу по умолчанию разрешается для
аутентификации использовать клиентские сертификаты, выданные внутренним центром сертификации.
 У некоторых блейдов есть собственные настройки аутентификации. Они настраиваются в окне
Свойства шлюза соответствующего шлюза в разделе Аутентификация <название блейда>.
Например, метод аутентификации для клиентов VPN IPSec настраивается в Свойства шлюза > VPN
IPSec > Аутентификация. Если вы выберете метод аутентификации для этого блейда, этим методом
должны будут пользоваться все пользователи, представляющиеся данному блейду. Для других блейдов
на других страницах можно настроить другие методы аутентификации – и пользователи будут
вынуждены использовать их.
Если вы не сделаете выбор для конкретного блейда на странице Аутентификация, соответствующие
настройки для этого блейда шлюз безопасности позаимствует со страницы аутентификации основного
шлюза.
Примечание. В предыдущих выпусках не было возможности настройки аутентификации для
конкретного блейда. Однако, начиная от версии R75, если вы задали метод аутентификации для
отдельного блейда, настройки на этой странице никак не повлияют на этот блейд.
Поиск пользователей шлюзом
Если для блейда параметры проверки подлинности берутся со страницы Аутентификация по-старому
(Legacy Authentication) основного шлюза безопасности, то при попытке пользователей представиться шлюз
безопасности выполняет поиск стандартным способом. Шлюз ищет в следующих местах:
1. Внутренняя база данных пользователей.
2. Если указанный пользователь не найден в этой базе данных, шлюз опрашивает серверы Каталога
пользователей (LDAP), определенные в учетной записи, по одному, в порядке приоритета.
3. Если информация все еще не найдена, шлюз использует внешний пользовательский шаблон, чтобы
проверить, есть ли совпадения по общему профилю. У общего профиля атрибуты по умолчанию,
применяемые к конкретному пользователю.
Если для конкретного блейда назначить метод аутентификации, шлюз будет искать пользователей по
группам, используемым для авторизации в этом блейде.
Например, в Mobile Access шлюз просматривает политику Mobile Access и выясняет, какие группы
пользователей являются частью политики. Когда шлюз пытается аутентифицировать пользователя, он
начинает его поиск в базах данных, связанных с этими группами пользователей.
В VPN IPSec шлюз просматривает VPN-сообщество с удаленным доступом, чтобы узнать, какие в него
включаются группы пользователей. Поиск пользователей производится в базах данных, связанных с этими
группами.
Поиск на основании схемы аутентификации оказывается быстрее и дает лучшие результаты. У вас могут
быть пользователи с одним именем в не связанных между собой группах. А шлюз будет знать, какой именно
пользователь подходит для блейда, поскольку владеет информацией о группах пользователей.

Дополнительные функции
VPN с удаленным доступом поддерживает другие дополнительные функции, такие как:
 Разрешение проблем со связью и маршрутизацией. См. «Офисный режим» (на стр. 185) и «Решение
проблем связи» (на стр. 297).
 IP-per-user/group (IP-адрес каждому пользователю или группе).
 Клиенты L2TP.

Альтернативы SecuRemote/SecureClient
Чтобы избежать головной боли с установкой и поддержкой клиентского ПО, Check Point предоставляет SSL
Network Extender – простой во внедрении тонкий клиент, устанавливаемый на пользовательской машине

Руководство администратора VPN R75.40VS | 153


VPN с удаленным доступом
через веб-браузер. Браузер подключается к веб-серверу с разрешенным SSL и загружает оттуда тонкий
клиент наподобие компонента ActiveX. Установка осуществляется автоматически.

Необходимость в VPN с удаленным доступом


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

 IP-адрес удаленного клиента может быть неизвестным.


 Клиент удаленного доступа может оставаться подключенным к корпоративной локальной сети в течение
всего рабочего дня, а вечером подключиться к сети гостиницы, возможно спрятанной за каким-нибудь
NAT-устройством.
 Удаленному клиенту может понадобиться подключиться к корпоративной локальной сети посредством
беспроводной точки доступа.
 Обычно, когда пользователь удаленного клиентского ПО находится не на рабочем месте, его не
защищает текущая политика безопасности; клиент удаленного доступа подвержен Интернет-угрозам, а
также может впустить в корпоративную сеть злоумышленника.

Для решения этих проблем требуется система безопасности, обеспечивающая надежную защиту удаленного
соединения с сетью.

Руководство администратора VPN R75.40VS | 154


Глава 17
Особенности VPN с удаленным доступом
В этой главе
ОПРЕДЕЛЕНИЕ ПОЛИТИКИ ДЛЯ УДАЛЕННОГО ДОСТУПА.......................................................................... 155
МЕТОДЫ СОЗДАНИЯ ПОЛЬЗОВАТЕЛЬСКОГО СЕРТИФИКАТА ПРИ ИСПОЛЬЗОВАНИИ ICA .................. 155
НЕСКОЛЬКО СЕРТИФИКАТОВ ДЛЯ ОДНОГО ПОЛЬЗОВАТЕЛЯ.................................................................. 155
ВНУТРЕННЯЯ И ВНЕШНЯЯ БАЗЫ ДАННЫХ ПОЛЬЗОВАТЕЛЕЙ ................................................................. 155
ФУНКЦИЯ АУТЕНТИФИКАЦИИ NT-ГРУППАМИ / КЛАССАМИ RADIUS ......................................................... 156

При конструировании VPN с удаленным доступом следует учитывать такие нюансы.

Определение политики для удаленного доступа


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

Методы создания пользовательского сертификата при


использовании ICA
Внутренний центр сертификации (ICA) Check Point предлагает два пути создания и передачи сертификатов
удаленным пользователям.
1. Администратор генерирует сертификат для удаленного пользователя на Сервере управления защитой,
сохраняет его на съемный носитель и передает клиенту за пределами канала передачи.
2. Администратор инициирует процесс создания сертификата на Сервере управления защитой (или
средстве управления ICA), получая регистрационный ключ. Регистрационный ключ передается
пользователю за пределами канала передачи. Клиент устанавливает SSL-соединение с ICA (при помощи
протокола СМС) и завершает генерирование сертификата посредством регистрационного ключа. Таким
образом:
 частные ключи генерируются на клиенте;
 созданный сертификат можно хранить в виде файла на жестком диске машины, на устройстве
хранения данных CAPI или на аппаратном токене.
Этот метод особенно подходит для географически разнесенных пользователей.

Несколько сертификатов для одного пользователя


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

Внутренняя и внешняя базы данных пользователей


Функционал удаленного доступа предусматривает гибкую схему управления пользователями. Управление
пользователями происходит разными способами:
 ВНУТРЕННИЙ. Шлюз безопасности может в локальной базе пользователей хранить статический пароль
для каждого пользователя, настроенного на Сервере управления защитой. Без дополнительного
программного обеспечения.
 LDAP. LDAP – это открытый промышленный стандарт, применяемый многими производителями.
Продукты Check Point сочетают LDAP и Каталог пользователей Check Point. Внешнее управление
пользователями через LDAP отображается на экранах SmartDashboard. При проверке подлинности
пользователей шлюзы безопасности опрашивают Каталог пользователей.
 RADIUS. Служба удаленной аутентификации пользователей по коммутируемой линии (Remote
Authentication Dial-In User Service) – это внешняя схема проверки подлинности, обеспечивающая
безопасность и масштабируемость за счет разделения функций проверки подлинности и сервера
удаленного доступа.
VPN с удаленным доступом
При задействовании RADIUS в качестве схемы аутентификации шлюз безопасности направляет запросы
аутентификации от удаленных пользователей на сервер RADIUS. Сервер RADIUS, хранящий сведения
об учетных записях пользователей, подтверждает наличие таких пользователей. Протокол RADIUS для
связи с шлюзом безопасности использует UDP. Объекты RADIUS Servers и RADIUS Server Group
определяются в SmartDashboard.
 ACE/Сервер управления токенами SecurID. Разработанный RSA Security, SecurID требует, чтобы
пользователи при аутентификации владели токеном и указывали PIN-код или пароль. Токены для
аутентификации генерируют одноразовые пароли, синхронизируемые с ACE/сервером RSA. Они могут
иметь как аппаратную, так и программную форму. Аппаратные токены – это устройства размером с
брелок или кредитную карту. Программные токены располагаются на ПК или другом устройстве, с
которого пользователь желает представиться. Все токены генерируют случайный одноразовый код
доступа, изменяющийся ежеминутно или близко к тому. При попытке пользователя проникнуть на
запрещенный ресурс, необходимо подтверждение этого кода на ACE/сервере.
Если в качестве схемы аутентификации использовать SecurID, шлюз безопасности отправляет
пользовательские запросы на аутентификацию на ACE/сервер. ACE управляет базой пользователей RSA
и присвоенными им аппаратными или программными токенами. Модуль VPN действует как ACE/Агент
5.0, направляя все запросы доступа для проверки подлинности на ACE/сервер RSA. Подробности
конфигурации агента см. в документации к ACE/серверу.
Разница между управлением пользователями посредством внутренней базы данных и Каталога
пользователей состоит в следующем:
 Каталог пользователей выполнен снаружи, а не локально.
 При изменении шаблонов Каталога пользователей изменения динамично, немедленно будут применены.

Функция аутентификации NT-группами / классами RADIUS


Проверка подлинности может осуществляться согласно группам NT или классам RADIUS. В этом случае
пользователи удаленного доступа аутентифицируются в соответствии с группой сообществ с удаленным
доступом, к которой они принадлежат.
Примечание. Поддерживаются только NT-группы. Active Directory не поддерживается.

Руководство администратора VPN R75.40VS | 156


Глава 18
Настройка VPN с удаленным доступом
В этой главе
РАБОТА VPN С УДАЛЕННЫМ ДОСТУПОМ .................................................................................................... 158
СОЗДАНИЕ СЕРТИФИКАТОВ VPN С УДАЛЕННЫМ ДОСТУПОМ ДЛЯ ПОЛЬЗОВАТЕЛЕЙ ......................... 158
СОЗДАНИЕ И НАСТРОЙКА ШЛЮЗА БЕЗОПАСНОСТИ................................................................................. 160
ОПРЕДЕЛЕНИЕ ПОЛЬЗОВАТЕЛЯ И МЕТОДОВ АУТЕНТИФИКАЦИИ В LDAP ............................................. 160
РЕГИСТРАЦИЯ ПОЛЬЗОВАТЕЛЬСКИХ СЕРТИФИКАТОВ – СРЕДСТВО УПРАВЛЕНИЯ ICA...................... 160
НАСТРОЙКА СЕРТИФИКАТОВ С ИСПОЛЬЗОВАНИЕМ СТОРОННЕГО PKI ................................................. 160
ВКЛЮЧЕНИЕ ГИБРИДНОГО РЕЖИМА И МЕТОДЫ ПРОВЕРКИ ПОДЛИННОСТИ ....................................... 161
НАСТРОЙКА АУТЕНТИФИКАЦИИ NT-ГРУПП И КЛАССОВ RADIUS.............................................................. 161
ИСПОЛЬЗОВАНИЕ ОБЩЕГО СЕКРЕТНОГО КЛЮЧА .................................................................................... 162
ОПРЕДЕЛЕНИЕ ГРУППЫ ПОЛЬЗОВАТЕЛЕЙ LDAP ...................................................................................... 162
ОПРЕДЕЛЕНИЕ ГРУППЫ ПОЛЬЗОВАТЕЛЕЙ................................................................................................. 162
ОПРЕДЕЛЕНИЕ VPN-СООБЩЕСТВА И ЕГО УЧАСТНИКОВ .......................................................................... 162
ОПРЕДЕЛЕНИЕ ПРАВИЛ КОНТРОЛЯ ДОСТУПА ........................................................................................... 162
УСТАНОВКА ПОЛИТИКИ ................................................................................................................................. 162
УПРАВЛЕНИЕ СЕРТИФИКАТАМИ ПОЛЬЗОВАТЕЛЕЙ .................................................................................. 163
ИЗМЕНЕНИЕ СВОЙСТВ ШИФРОВАНИЯ ДЛЯ VPN С УДАЛЕННЫМ ДОСТУПОМ ........................................ 163
РАБОТА С АППАРАТНЫМИ И ПРОГРАММНЫМИ ТОКЕНАМИ RSA ............................................................ 164

Данный раздел содержит процедуры и пояснения для настройки VPN с удаленным доступом.
VPN с удаленным доступом

Работа VPN с удаленным доступом


В данном разделе показана работа VPN с удаленным доступом.

(перевод описаний сверху вниз, слева


направо)
Создание шлюза и определение
свойств шлюза
Создание блока учетной записи LDAP
и определение свойств пользователя
LDAP
Управление пользователями
Внутренняя база данных брандмауэра
Методы аутентификации
пользователей
Методы аутентификации
пользователей
Сторонний PKI
ICA
Общий секретный ключ
Другой
Сторонний PKI
ICA
Общий секретный ключ
Другой
Инициирование сертификата
пользователя в средстве управления
ICA
Настройка общего секретного ключа
Методы генерирования
сертификата
Настройка общего секретного ключа
Инициирование
Генерирование
Конфигурация сертификатов для
пользователей и шлюза
Включение гибридного режима и
методов аутентификации
пользователей
Инициирование сертификата
пользователя в SmartDashboard
Конфигурация сертификатов для
пользователей и шлюза
Включение гибридного режима и
методов аутентификации
пользователей
Определение группы пользователей
LDAP
Определение группы пользователей
Определение VPN-сообщества и
участников
Определение правил доступа в базе
правил политики безопасности
Установка политики
Начнем сверху, от пункта Создание шлюза и определение свойств шлюза и проложим путь до самого низа –
до пункта Установка политики. Ниже этот «маршрут» разбирается поэтапно.

Создание сертификатов VPN с удаленным доступом для


пользователей
В данном разделе описана процедура создания пользовательских сертификатов удаленной VPN и отправки
их конечным пользователям. Существует две базовые процедуры для снабжения пользователей
сертификатами VPN с удаленным доступом.
 Отправка файла Р12:
 Администратор создает файл сертификата р12 и отправляет его пользователям.

Руководство администратора VPN R75.40VS | 158


VPN с удаленным доступом

 Пользователь сохраняет файл р12 на устройстве и указывает сертификат через удаленный VPN-
клиент.
 Перед подключением к VPN с удаленным доступом пользователи представляются, вводя пароль
сертификата.
 Использование регистрационного ключа:
 Администратор создает регистрационный ключ и отправляет его пользователю.
 Пользователь регистрирует сертификат, вводя регистрационный ключ. Дополнительно пользователь
может сохранить на устройство файл р12. Пользователь должен сделать это в период времени,
указанный администратором.
 Конечные пользователи представляются этим сертификатом. Помимо этого, согласно настройкам
политики безопасности, может понадобиться пароль. Если пользователь сохранил файл р12 на
устройстве, то пароль будет необходим всегда.

Включение сертификата пользователя


Включение сертификата пользователя
1. В SmartDashboard выберите вкладку Брандмауэр (Firewall).
2. Перейдите на вкладку Пользователи и администраторы (Users and Administrators).
3. Создайте нового пользователя или дважды щелкните по существующему.
4. В окне Свойства пользователя нажмите вкладку Шифрование (Encryption).
5. В панели Шифрование нажмите Изменить.
6. В окне Свойства фазы II IKE нажмите на вкладку Аутентификация и выберите Открытый ключ.
7. Нажмите OK, чтобы закрыть окно.

Создание файла сертификата Р12


После создания пользовательского сертификата следует сделать так, чтоб этот сертификат был доступен
пользователям удаленного доступа. Выполните приведенные здесь шаги, чтобы создать сертификат р12.
Создание файла сертификата р12 для пользователей VPN с удаленным доступом
1. Создайте пользовательский сертификат (см. «Включение сертификата пользователя» на стр. 177).
2. В окне Свойства пользователя нажмите Сертификаты.
3. На панели Сертификаты нажмите Новый.
4. Выберите Файл сертификата (.р12).
5. В окне Файл сертификата (.р12) введите и подтвердите пароль сертификата.
6. Можете ввести необязательное описание в поле Комментарий.
7. Нажмите OK и введите путь для сохранения файла р12. В поле Сертификат отображается новый
сертификат. Его статус – Действительный (Valid).
8. Отошлите файл .р12 конечному пользователю по защищенной электронной почте или другим
безопасным способом.

Создание регистрационного ключа сертификата


После создания пользовательского сертификата следует сделать так, чтоб этот сертификат был доступен
пользователям удаленного доступа. Выполните приведенные здесь шаги, чтобы создать регистрационный
ключ сертификата, который позволит пользователю зарегистрировать сертификат для использования с
устройством.
Создание файла сертификата р12 для пользователей VPN с удаленным доступом
1. Создайте пользовательский сертификат (см. «Включение сертификата пользователя» на стр. 177).
2. В окне Свойства пользователя нажмите Сертификаты.
3. На панели Сертификаты нажмите Новый.
4. Выберите Регистрационный ключ для регистрации сертификата (Registration Key for certificate
enrollment).
5. В окне Регистрационный ключ для регистрации сертификата выберите количество дней пригодности
сертификата.
Щелкните на значок электронной почты, чтобы отослать регистрационный ключ пользователю.
6. Можете ввести необязательное описание в поле Комментарий.

Инструкции конечным пользователям


Пользователи VPN с удаленным доступом могут использовать разное клиентское ПО для доступа к сетевым
ресурсам. Администратор обязан надлежащим образом проинструктировать конечных пользователей, чтобы
они успешно зарегистрировали сертификаты.
В разделе Создание сертификатов («Создание сертификатов VPN с удаленным доступом для
пользователей» на стр. 177) указаны общие процедуры, действительные для многих VPN-клиентов.
Подробнее см. документацию к VPN-клиенту.

Руководство администратора VPN R75.40VS | 159


VPN с удаленным доступом

Создание и настройка шлюза безопасности


1. В SmartDashboard создайте сетевой объект «шлюз безопасности».
2. На странице Общие свойства выберите VPN.
3. Сформируйте защищенный канал связи между VPN-модулем и Сервером управления защитой, нажав
Соединение (Communication).
4. На странице Топология определите интерфейсы и VPN-домен.
ICA автоматически создает сертификат для шлюза безопасности.

Определение пользователя и методов аутентификации в LDAP


1. Получите и установите лицензию, дающую возможность VPN-модулю получать информацию от сервера
LDAP.
2. Создайте блок учетной записи LDAP.
3. Определите пользователей как пользователей LDAP. В дереве пользователей будет создан новый
сетевой объект для пользователей LDAP. (Пользователи LDAP также отображаются в списке объектов
справа).
Подробнее см. «LDAP и управление пользователями» в Руководстве администратора Сервера управления
защитой R75.40VS (http://supportcontent.checkpoint.com/solutions?id=sk76540).

Регистрация пользовательских сертификатов – Средство


управления ICA
Регистрация пользовательских сертификатов посредством средства управления ICA
1. В SmartDashboard выберите вкладку Брандмауэр (Firewall).
2. Перейдите на вкладку Пользователи и администраторы (Users and Administrators).
3. Создайте нового пользователя или дважды щелкните по существующему.
4. Дважды щелкните по пользователю, чтобы открыть окно свойств.
5. В панели Шифрование нажмите Изменить.
6. В окне Свойства фазы II IKE нажмите на вкладку Аутентификация и выберите Открытый ключ.
7. Зарегистрируйте пользовательский сертификат с помощью Средства управления ICA (ICA management
tool). Подробнее см. Руководство администратора Сервера управления защитой R75.40VS
(http://supportcontent.checkpoint.com/solutions?id=sk76540).

Настройка сертификатов с использованием стороннего PKI


Использование стороннего PKI предусматривает создание:
 сертификата для пользователя;
 сертификата для шлюза безопасности.
Для выдачи сертификатов шлюзам безопасности и пользователям можно воспользоваться сторонним OPSEC
PKI центром сертификации, поддерживающим стандарты PKCS#12, CAPI или Entrust. Шлюз безопасности
должен доверять СА и иметь сертификат, выданный СА.
Для пользователей с сервера LDAP полное различаемое имя (DN), отображаемое на сертификате, должно
совпадать с именем пользователя. Но если пользователь управляется внутренней базой данных, имя
пользователя и DN совпадать не будут. По этой причине имя пользователя во внутренней базе данных
должно либо совпадать с полным DN, указанным на сертификате, либо совпадать с обычным именем,
содержащимся в части CN сертификата. Например, если на сертификате DN указано так:
CN=John, OU=Finance, O=Widget Enterprises, C=US,
то имя пользователя во внутренней базе данных должно быть одним из двух:
 John
 CN=John, OU=Finance, O=Widget Enterprises, C=US
Примечание. DN на сертификате должно включать LDAP-ветвь пользователя. Некоторые PKI-
решения не включают (по умолчанию) все сведения о ветви в обсуждаемый DN, например, DN
может включать только имя. Это исправляется конфигурацией СА.

Чтобы использовать стороннее PKI-решение:


1. В окне Свойства пользователя, на вкладке Шифрование нажмите Изменить… Откроется окно
Свойства фазы II IKE. На вкладке Аутентификация выберите Открытый ключ.
2. Определите сторонний центр сертификации как объект в SmartDashboard. См. «Регистрация центра
сертификации» (на стр. 53).

Руководство администратора VPN R75.40VS | 160


VPN с удаленным доступом
3. Сгенерируйте сертификат для своего шлюз безопасности от стороннего СА. Подробнее см. «Регистрация
центра сертификации» (на стр. 53).
4. Сгенерируйте сертификат для удаленного пользователя от стороннего СА. (Подробнее см.
соответствующую документацию производителя). Передайте сертификат пользователю.
5. В Глобальных свойствах, в окне Аутентификация добавьте или выключите проверочный суффикс.
Пользователям с сертификатами можно указать, что принимаются только сертификаты с указанным
суффиксом в DN. Эта функция по умолчанию включена. Она требуется только если:
 пользователи определены во внутренней базе данных и
 имена пользователей не совпадают с полными DN.
Все DN в сертификатах проверяются на наличие этого суффикса.
Примечание. Если применяется иерархия центров сертификации, цепочка сертификатов
пользователя должна достигать корневого СА, которому доверяет шлюз безопасности.

Включение гибридного режима и методы проверки


подлинности
Гибридный режим предоставляет шлюзу безопасности и клиентам удаленного доступа использовать
различные методы проверки подлинности. Для включения гибридного режима:
в меню Политика > Глобальные свойства > Удаленный доступ > VPN Базовый выберите Гибридный
режим (Hybrid Mode).

Определение методов аутентификации пользователей в гибридном режиме


1. В окне Свойства пользователя на вкладке Аутентификация выберите соответствующую схему
аутентификации.
2. Введите учетные данные пользователя для проверки подлинности.
3. Передайте эти данные пользователю (за пределами канала передачи).

Настройка аутентификации NT-групп и классов RADIUS


Чтобы включить эту функцию групповой аутентификации:
1. Задайте свойству add_radius_groups в файле objects.C значение «true».
2. Определите общий профиль и задайте ему метод аутентификации RADIUS.
3. В базе правил политики создайте правило, где в роли источника выступает данная группа удаленных
пользователей, аутентифицирующих с помощью сервера NT или RADIUS.

Файл присвоения IP в офисном режиме


Данный метод работает и в офисном режиме. Группа, перечисленная в файле ipassignment.conf указывает
на группу, аутентифицирующую с помощью групповой аутентификации NT или классов RADIUS. См.
«Офисный режим посредством файла ipassignment.conf» (на стр. 188).

Использование общего секретного ключа


При использовании общего секретного ключа удаленный пользователь и шлюз безопасности проверяют друг
друга, выясняя, знает ли противоположная сторона общий секретный ключ: пароль пользователя. Для
включения возможности использования общих секретных ключей необходимо предпринять следующие шаги.
1. В меню Политика > Глобальные свойства > Удаленный доступ > VPN Базовый выберите Общий
секретный ключ (для пользователей SecuRemote/SecureClient).
2. Снимите отметку Гибридный режим (Hybrid Mode).
3. Для каждого пользователя зайдите на вкладку Шифрование окна Свойства пользователя, выберите
IKE, нажмите Изменить… Отобразится окно Свойства фазы II IKE.
4. На вкладке Аутентификация включите Пароль (общий секретный ключ) (Password (Pre-Shared
Secret)) и введите общий секретный ключ в поля Пароль (общий секретный ключ) и Подтверждение
пароля.
5. Сообщите пароль пользователю за пределами канала передачи.

Определение группы пользователей LDAP


См. «LDAP и управление пользователями» в Руководстве администратора Сервера управления защитой
R75.40VS (http://supportcontent.checkpoint.com/solutions?id=sk76540).

Руководство администратора VPN R75.40VS | 161


VPN с удаленным доступом

Определение группы пользователей


В SmartDashboard создайте группу пользователей удаленного доступа. Добавьте в эту группу
соответствующих пользователей.

Определение VPN-сообщества и его участников


1. В дереве VPN-сообществ дважды щелкните Remote_Access_Community. Откроется окно Свойства
сообщества с удаленным доступом.
2. На странице Участвующие шлюзы безопасности нажмите Добавить… и добавьте шлюзы
безопасности, участвующие в сообществе с удаленным доступом.
3. На странице Участвующие группы пользователей нажмите Добавить… и добавьте группу,
содержащую пользователей удаленного доступа.

Определение правил контроля доступа


Контроль доступа – это защитная прослойка, не связанная с VPN. Само по себе существование сообщества с
удаленным доступом не подразумевает автоматического доступа в сеть для членов сообщества. Необходимо
в базе правил политики безопасности создать соответствующие правила, которые блокируют или допускают
конкретные устройства.
1. Создайте правило в базе правил политики безопасности, касающееся удаленных соединений.
2. Дважды щелкните по записи в столбце VPN. Откроется окно Критерии соответствия VPN.
3. Выберите Только соединения, зашифрованные в конкретных VPN-сообществах (Only connections
encrypted in specific VPN Communities).
4. Нажмите Добавить…, чтобы включить в это правило конкретное сообщество.
5. Определите службы и действия. Например, чтобы позволить пользователям удаленного доступа
получать доступ к SMTP-серверу организации, который называется SMTP_SRV, создайте такое правило:

Источник Адресат VPN Служба Действие Слежение

Любой SMTP_SRV Remote_Access_Community SMTP Принять Журнал

Установка политики
Установите политику и сообщите пользователям создать или обновить топологию.

Управление сертификатами пользователей


Управление сертификатами пользователей включает в себя:
1. Отслеживание состояния сертификата пользователя.
2. Автоматическое обновление сертификата.
3. Отзыв сертификатов.

Отслеживание состояния сертификата пользователя


Состояние сертификатов пользователей можно в любой момент отследить на вкладке Сертификаты окна
свойств пользователя. Состояние показано в поле Состояние сертификата (Certificate state). Если к дате,
указанной в поле Ожидается до (Pending until), пользователь не генерирует сертификат, регистрационный
ключ удаляется.
Если пользователь определен в LDAP, то отслеживание выполняется средством управления ICA.

Автоматическое обновление сертификата пользователя


Сертификаты, выданные пользователям ICA, могут автоматически обновляться за определенное количество
дней до истечения их срока действия. Клиент инициирует операцию обновления сертификата СА до
истечения срока действия. При успешном завершении клиент получает обновленный сертификат.
Настройка автоматического обновления сертификата
1. Выберите Политика > Глобальные свойства > Удаленный доступ > Сертификаты.
2. Выберите Обновлять пользовательские сертификаты внутреннего СА (Renew users internal CA
certificates) и укажите период времени. Период времени – это число дней перед истечением срока
действия сертификата, когда клиент выполнит попытку обновления сертификата.
3. Установите политику безопасности.
4. Сообщите пользователю обновить топологию узла.

Руководство администратора VPN R75.40VS | 162


VPN с удаленным доступом

Отзыв сертификатов
Способ отзыва сертификатов зависит от того, управляются ли они изнутри или извне, посредством LDAP.

Пользователи, управляемые изнутри


При удалении пользователя его сертификат автоматически отзывается. Сертификаты можно в любое время
выключать и отзывать.
Если вы инициировали генерирование сертификата, а пользователь не завершил процесс, вы можете
выключить ожидание сертификата, нажав Выключить (Disable) на вкладке Сертификаты окна Свойства
пользователя.
Если сертификат уже действует, отозвать его можно, нажав Отозвать (Revoke) на вкладке Сертификаты
окна Свойства пользователя.

Пользователи, управляемые LDAP


Если пользователи управляются LDAP, сертификаты отзываются через средство управления ICA.

Изменение свойств шифрования для VPN с удаленным


доступом
Свойства шифрования пользователей, участвующих в сообществе с удаленным доступом, задается по
умолчанию. Если необходимо изменить алгоритм шифрования, метод проверки целостности данных и/или
группу Диффи-Хеллмана, можно сделать это глобально для всех пользователей или отредактировать
свойства одного пользователя.

Глобальное изменение свойств шифрования пользователя


1. Выберите Политика > Глобальные свойства > Удаленный доступ > VPN – (фаза I IKE). Настройте
соответствующие параметры:
 Поддерживать алгоритмы шифрования. Выберите алгоритмы шифрования, которые будут
поддерживать удаленные хосты.
 Использовать алгоритмы шифрования. Выберите алгоритм шифрования, который будет самым
приоритетным из выбранных алгоритмов. Если существует выбор используемых алгоритмов, будет
использован тот, который указан в этом поле.
 Поддерживать целостность данных. Выберите хэш-алгоритмы, которые будут поддерживать
удаленные хосты, обеспечивая целостность данных.
 Использовать целостность данных. При наличии выбора хэш-алгоритм, выбранный здесь, будет
назначен самым приоритетным.
 Поддерживать группы Диффи-Хеллмана. Выберите группы Диффи-Хеллмана, которые будут
поддерживать удаленные хосты.
 Использовать группу Диффи-Хеллмана. SecureClient будет использовать группу Диффи-
Хеллмана, выбранную в этом поле.
Чтобы принудительно назначить каким-нибудь пользователям глобальные свойства шифрования, не
теряя возможности изменять их для конкретных пользователей, перейдите на Политика > Глобальные
свойства > Удаленный доступ > VPN – (фаза II IKE).
2. Задайте требуемые свойства в окне и выключите Назначить алгоритм шифрования и проверки
целостности данных всем пользователям (Enforce Encryption Algorithm and Data Integrity on all
users).
3. На вкладке Шифрование окна Свойства пользователя выберите IKE и нажмите Изменить.
Отобразится окно Свойства фазы II IKE.
4. Выберите вкладку Шифрование.
5. Если вы желаете заимствовать алгоритмы шифрования и проверки целостности данных из определений
в Глобальных свойствах, выберите страницу Определены в VPN с удаленным доступом (Defined in
the Remote Access VPN) окна Глобальные свойства. Если вы желаете исправить алгоритм для этого
пользователя, выберите Определен ниже (Defined below) и выберите соответствующие алгоритмы
шифрования и проверки целостности данных.

Работа с аппаратными и программными токенами RSA


Если для проверки подлинности вы используете SecurID, управление пользователями вам приходится
осуществлять через сервер управления ACE RSA. ACE управляет базой данных пользователей КЫФ и
присвоенными им аппаратными и программными токенами. SecureClient контактирует с шлюзом безопасности
узла. Шлюз безопасности контактирует с сервером АСЕ, запрашивая информацию о подлинности
пользователя. Это значит следующее.
 Удаленные пользователи на сервере АСЕ должны быть определены как пользователи RSA.

Руководство администратора VPN R75.40VS | 163


VPN с удаленным доступом

 На шлюзе безопасности пользователи SecurID должны быть помещены в группу с внешней учетной
записью профиля, в которой в качестве метода аутентификации указан SecurID.

Устройства аутентификации SecurID


Существует несколько вариантов устройств SecurID. Более старый формат – это маленькое устройство,
показывающее числовой код – код токена – и диаграмму времени. Код токена меняется каждые 60 секунд и
является основанием для аутентификации. Чтобы представиться, пользователь должен к началу кода токена
добавить специальный пароль, называемый PIN-код. Временная диаграмма показывает, как много времени
осталось до генерирования нового кода. Удаленному пользователю предлагается ввести PIN-код и код токена
в окно соединения SecureClient.
Более новое устройство напоминает кредитную карту. На нем показан код токена, временная диаграмма и
цифровая клавиатура для ввода PIN-кода. Этот тип устройства смешивает код токена с введенным PIN-
кодом, формируя пароль. SecureClient запрашивает только пароль.
SoftID работает так же, как и устройство формирования пароля, но состоит только из программы, записанной
на компьютер.

В расширенном виде отображается код токена, пароль с кнопками Копировать, которые позволяют людям
вырезать и вставлять значения между softID и SecureClient.

SoftID и SecureClient
Для успешного использования удаленными пользователями softID RSA выполняется следующее.
1. Администратор создает на сервере ACE удаленных пользователей.
2. За пределами канала связи администратор передает программный токен (токены) SDTID удаленным
пользователям.
3. Удаленный пользователь импортирует токены.

Руководство администратора VPN R75.40VS | 164


VPN с удаленным доступом
4. В разделе OPTIONS файла userc.c на SecureClient параметр support_rsa_soft_tokens должен иметь
значение true.
При входе в систему пользователи должны ввести серийный номер токена и PIN-код.

Руководство администратора VPN R75.40VS | 165


Глава 19
Офисный режим
В этой главе
УДАЛЕННЫЕ КЛИЕНТЫ ДОЛЖНЫ БЫТЬ ЧАСТЬЮ ЛОКАЛЬНОЙ СЕТИ .................................................... 166
ОФИСНЫЙ РЕЖИМ .......................................................................................................................................... 166
ВКЛЮЧЕНИЕ ФУНКЦИИ «IP-АДРЕС ДЛЯ ПОЛЬЗОВАТЕЛЯ» ....................................................................... 171
ОСОБЕННОСТИ ОФИСНОГО РЕЖИМА .......................................................................................................... 174
НАСТРОЙКА ОФИСНОГО РЕЖИМА................................................................................................................ 174

Удаленные клиенты должны быть частью локальной сети


По мере повсеместного распространения удаленного доступа к внутренним сетям организаций растет
необходимость в том, чтобы удаленные пользователи могли получить доступ к максимально возможному
количеству внутренних ресурсов организации. Обычно при внедрении удаленного доступа клиент
подключается через локальный IP-адрес, назначенный, например, ISP. Клиент может даже получить
немаршрутизируемый IP-адрес, спрятанный за NAT-устройство. Исходя из этого, возникает ряд проблем.
 Некоторые сетевые протоколы или ресурсы могут требовать, чтоб IP-адрес клиента был внутренним.
Списки доступа (ACL) маршрутизатора могут, например, быть настроены на пропускание к сетевым
ресурсам только конкретных или внутренних IP-адресов. Не зная IP-адрес удаленного клиента заранее,
тяжело подстроиться.
 Конфликт может произойти и при назначении немаршрутизируемого IP-адреса. Он может быть связан
либо с похожими немаршрутизируемыми адресами, используемыми в корпоративной локальной сети,
либо с другими клиентами, получившими такой же самый IP-адрес, располагаясь за каким-нибудь другим
скрывающим NAT-устройством.
Например, клиент получает IP-адрес 10.0.0.1, который вводится в заголовки пакета IPSec. Пакет
проходит трансляцию на устройстве NAT. Новый исходный IP-адрес пакета – 192.168.17.5. Шлюз
безопасности декапсулирует IP-адрес, скрытый NAT-устройством и расшифровывает пакет. IP-адрес
преобразовывается в свой первоначальный вид 10.0.0.1. Если существует внутренний хост с тем же IP,
пакет может быть утерян (при включенном антиспуфинге). Если дублирующего IP-адреса нет, пакет
передается некоторому внутреннему серверу, а сервер попытается ответить на несуществующий адрес.
 Двум удаленным пользователям ISP присвоен один и тот же IP-адрес (например, два пользователя
осуществляют доступ к организации из гостиницы, предоставляющей внутренние адреса, которые на
выходе транслируются NAT-устройством). Оба пользователя пытаются получить доступ ко внутренней
сети, имея одинаковый IP-адрес. Ресурсы внутренней сети организации могут столкнуться с трудностями
при различении пользователей.

Офисный режим
В офисном режиме шлюз безопасности может присвоить удаленному клиенту IP-адрес. Присвоение
выполняется при подключении и аутентификации пользователя. Аренда адреса возобновляется, пока
пользователь подключен. Адрес может браться либо из общего пула IP-адресов, либо из пула IP-адресов,
указанного для группы пользователей. Адрес может быть указан как для пользователя, так и через сервер
DHCP, позволяя использование службы разрешения имен. При помощи разрешения имен DNS проще
получить доступ к клиенту из корпоративной сети.
Можно разрешить всем пользователям использовать офисный режим, а можно включить эту функцию для
конкретной группы пользователей. Это применимо, например, для предоставления конкретной группе
пользователей привилегированного доступа (напр., администраторам, которые получают доступ к локальной
сети из удаленных терминалов). Кроме того, это полезно на этапах раннего внедрения офисного режима – у
вас появляется возможность «обкатать» эту функцию на конкретной группе пользователей, в то время как
остальные пользователи продолжают работать как и раньше.
Офисный режим поддерживают:
 SecureClient
 Endpoint Connect
 SSL Network Extender
 Crypto
 L2TP
VPN с удаленным доступом

Принцип работы офисного режима


При подключении к организации на шлюзе безопасности автоматически запускается согласование IKE. При
использовании офисного режима между фазой I и фазой II согласования IKE появляется еще одна фаза,
которая называется config mode – режим конфигурации. Во время режима конфигурации клиент запрашивает
у шлюза безопасности IP-адрес. Таким же образом настраиваются еще несколько параметров, такие как IP-
адрес DNS-сервера и WINS-сервера.
После того, как шлюз безопасности выдает IP-адрес, клиент присваивает IP-адрес виртуальному адаптеру
операционной системы. Маршрутизация пакетов в корпоративную сеть настраивается так, чтобы они
проходили через этот адаптер. Пакеты, направленные таким образом, несут IP-адрес, присвоенный шлюзом
безопасности, в качестве IP источника. Перед прохождением через реальный адаптер, пакеты
инкапсулируются IPSec с использованием внешнего IP-адреса (присвоенного реальному адаптеру) в качестве
IP источника. Таким образом, в офисном режиме можно использовать немаршрутизируемые IP-адреса;
немаршрутизируемый адрес офисного режима скрыт в IPSec-пакете.
Для работы офисного режима IP-адрес, присвоенный шлюзом безопасности, должен быть
маршрутизируемым к этому шлюзу безопасности из корпоративной локальной сети. Так пакеты, высланные
клиенту из локальной сети, смогут быть отосланы назад через шлюз безопасности. (См. также «Офисный
режим и статические маршруты в неоднородной сети» на стр. 188).
Примечание. Офисный режим не будет поддерживаться только для удаленных пользователей с
SecuRemote.
Подробное рассмотрение
Описанные ниже шаги иллюстрируют процесс, который происходит, когда удаленный пользователь,
подключенный посредством офисного режима, хочет обменяться информацией с внутренними ресурсами
организации.
 Пользователь пытается подключиться к одному из ресурсов локальной сети, т. е. должен быть отослан
пакет во внутреннюю сеть. Этот пакет направляется через виртуальный интерфейс, настроенный
офисным режимом, и несет IP-адрес источника, выделенный удаленному пользователю.
 Пакет зашифрован, у него новый инкапсулированный IP-заголовок. Исходный IP-адрес
инкапсулированного пакета – это первоначальный IP-адрес удаленного клиента, а его адресат – IP-адрес
шлюза безопасности. Затем инкапсулированный пакет отправляется по Интернету в организацию.
 Шлюз безопасности организации получает пакет, декапсулирует и расшифровывает его, извлекая
первоначальный пакет, на котором исходный IP-адрес – это адрес, выделенный для удаленного
пользователя. Затем шлюз безопасности направляет декапсулированный пакет адресату.
 Внутренний ресурс получает пакет, пришедший, казалось бы, со внутреннего адреса. Пакет
обрабатывается, отправляются ответные пакеты – назад, удаленному пользователю. Эти пакеты
направляются обратно к (внутреннему) IP-адресу, который присвоен удаленному пользователю.
 Шлюз безопасности получает пакет, шифрует его, инкапсулирует первоначальным (маршрутизируемым)
IP-адресом удаленного пользователя и возвращает обратно удаленному пользователю.

Руководство администратора VPN R75.40VS | 167


VPN с удаленным доступом

Хост (IP-адрес 10.0.0.1) Интернет


Сервер ISP-маршрутизатор

Шлюз Машина пользователя

 Удаленный хост использует адрес офисного режима в инкапсулированном пакете и 10.0.0.1 в


инкапсулирующем заголовке.
 Пакет обрабатывается NAT, получается новый исходный адрес: 192.168.17.5
 Шлюз безопасности декапсулирует IP-адрес, полученный после NAT, и расшифровывает пакет. IP-адрес
источника и есть адресом офисного режима.
 Пакет направляется на внутренний сервер, который отправляет корректный ответ.

Присвоение IP-адреса
Внутренние IP-адреса, которые шлюз безопасности присваивает удаленному пользователю, формируются
одним из двух методов:
 пул IP-адресов;
 сервер DHCP.
Пул IP-адресов
Системный администратор обозначает диапазон IP-адресов, которые будут использоваться для машин
удаленных клиентов. Каждый клиент, подающий запрос на подключение в офисном режиме, снабжается
уникальным IP-адресом из пула.
Присвоение IP-адреса на основании IP-адреса источника
IP-адреса в пуле могут быть зарезервированы и присваиваться удаленным пользователям на основании их
исходных IP-адресов. При подключении удаленного хоста к шлюзу безопасности, его IP-адрес сравнивается с
заранее заданным диапазоном исходящих IP-адресов. Если этот IP входит в заданный диапазон, тогда ему
присваивается IP-адрес офисного режима – из числа адресов, предназначенных для этой цели.
IP-адресам из этого зарезервированного пула можно придать особый набор разрешений, который будет
касаться конкретных удаленных пользователей.
Сервер DHCP
Для раздачи IP-адресов клиентам офисного режима можно использовать сервер протокола динамической
настройки хостов (DHCP – Dynamic Host Configuration Protocol). При подключении удаленного хоста к шлюзу
безопасности с использованием офисного режима, шлюз безопасности запрашивает сервер DHCP о

Руководство администратора VPN R75.40VS | 168


VPN с удаленным доступом
присвоении пользователю IP-адреса из диапазона IP-адресов, предназначенных для пользователей
офисного режима.
Запрос шлюза безопасности DHCP может содержать разные атрибуты клиента, позволяющие клиентам
DHCP отличаться от других. Атрибуты заранее настраиваются в клиентской операционной системе и могут
использоваться различными DHCP-серверами в ходе раздачи IP-адресов. Запрос шлюза безопасности DHCP
может содержать такие атрибуты:
 имя хоста
 полностью уточненное доменное имя (FQDN)
 класс вендора
 класс пользователя
Сервер RADIUS
Сервер RADIUS можно использовать для проверки подлинности удаленных пользователей. При подключении
удаленного пользователя к шлюзу безопасности, его имя и пароль передаются на сервер RADIUS, который
проверяет правильность информации и подтверждает подлинность пользователя. Сервер RADIUS также
можно настроить на раздачу IP-адресов.
Примечание. Проверка подлинности и раздача IP-адресов должны выполняться одним и тем же
сервером RADIUS.
Офисный режим и статические маршруты в неоднородной сети
Однородная сеть – это сеть, в которой все терминалы могут взаимодействовать друг с другом без
применения мостов или маршрутизаторов. Один сегмент сети – это «однородная сеть». Статический маршрут
– это маршрут, назначенный системным администратором вручную (маршрутизатору), требующий ручного
вмешательства при изменении сети.
Если локальная сеть неоднородна (на пути между терминалами находятся мосты и маршрутизаторы), тогда
ОМ-адрес удаленного клиента необходимо статически присвоить маршрутизаторам, чтобы пакеты в
локальной сети, предназначенный для удаленного клиента, направлялись точно на шлюз безопасности.

Длительность аренды IP-адреса


Когда машине удаленного пользователя присваивается IP-адрес офисного режима, та может использовать
его определенное количество времени. Этот период называется «длительностью аренды IP-адреса».
Удаленный клиент автоматически запрашивает возобновление аренды по прошествии половины срока
арен