Не работает checkpoint vpn

Современные приложения не могут подключаться при использовании VPN-подключения Check Point

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

Применяется к: Windows 8
Исходный номер КБ: 2855849

Симптомы

Рассмотрим следующий сценарий.

• Вы используете версию VPN удаленного доступа к конечным точкам Check Point, которая является более ранней, чем E80.50.
• Успешно запущены Windows 8 (Store Apps) и классические настольные приложения.
• Подключение к корпоративной сети с помощью клиентского программного обеспечения Check Point VPN в «концентраторном режиме» (то есть весь трафик проходит через виртуальный сетевой адаптер).
• После подключения индикатор состояния сети показывает, что подключение к Интернету полностью доступно.

В этом сценарии классические приложения могут успешно подключаться к Интернету. Однако современные приложения не могут подключаться. Кроме того, компьютерная версия Windows Internet Explorer 10 не может подключиться, если включен режим расширенной безопасности.

Причина

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

Решение

Чтобы устранить эту проблему, установите check Point VPN E80.50 (ожидается, что она будет доступна осенью 2013 г.) на следующем веб-сайте Центра поддержки контрольных точек:

Обходной путь

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

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

Этот сценарий также задокументирован на следующем веб-сайте Check Point: Microsoft Store (Windows 8) приложение не удается связаться с помощью VPN-туннеля.

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

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

Источник

Проблема с VPN, не маршрутизируются пакеты, CheckPoint

Вот и меня коснулась проблема с VPN. Вводная — есть сервер, который шлюз из офиса в сеть. Есть контейнер на lxc, на котором развёрнута относительно древняя версия дебиана (7), под которым запщен сервер ike. В пакетах он так и зовётся — ike. Этот ike соединяется к другому серваку (CheckPoint) и получает интерфейс tap0, IP и маршруты до той сети. В общем, с самой виртуалки всё ОК. Всё пингуется. Теперь на сервере, который шлюз, хотим маршрутизоваться в нужные нам сети через эту виртуалку. Делаем на виртуалке ip_forward и маскарад при прохождении на tap0. На маршрутизаторе прописываем маршрут до IP (который на tap0 на виртуалке) через виртуалку. Пробуем пинговать. И не работает. 🙁 Если я создают какой-нибудь br0 в виртуалке, задаю ему какой-нибудь адрес и на маршрутизаторе задаю маршрут на этот адрес через виртуалку, то всё пингуется и работает. А с чекпоинтом — нет. Ещё на tap0 получается MTU 1380, но, я так понимаю, именно для данного тестового случая роли не играет. Хотя пробовал и iptables’ами сгладить различия MTU. Кто сталкивался с подобной проблемой? Те же действия с OpenVPN я проделывал и не раз и всё ок. А тут хз что.

Сходу, не очень понял, зачем тебе это:

Теперь на сервере, который шлюз, хотим маршрутизоваться в нужные нам сети через эту виртуалку.

Ну и маршрутизируйся. Зачем тебе NAT? У тебя нет возможности на другом конце прописать маршруты чтоль?

Но вообще, в целом, есть мнение, что в lxc, такие довольно низкоуровневые вещи как ipsec гонять не стоит.

У меня на том конце контроля нет. Поэтому. Ну так через lxc openvpn то гонится нормально. Проблема только с ipsec. Или он ещё более низкоуровневый?

По идее, да. Он вполне вероятно более низкоуровневый. Ну и вообще tap. А всякие /proc/sys/net/ipv4/conf/all/rp_filter — не могут тебе мешать? Посмотри на всякий случай.

Если это Check Point, то вероятнее всего твои сети, которые ты хочешь маршрутизировать в туннель до Check Point-a должны быть описаны в топологии твоего шлюза, который другой админ завёл на СР как Externally Managed Gateway, т.е. надо чтобы тот админ сделал следующее:In the Topology page, define the Topology and the VPN Domain using the VPN Domain information obtained from the peer administrator. If the VPN Domain does not contain all the IP addresses behind the Security Gateway, define the VPN domain manually by defining a group or network of machines and setting them as the VPN Domain.

Ну и попроси у него логи с SmartView Tracker-a.

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

Дык я не хочу соединить сети. Я хочу в одну сторону шлюзоваться посредством NAT. А он у меня даже не хочет локальный IP пинговать, который на этом компе клиентом получен.

rp_filter, если я правильно понял, не мешают.

ipsec это не udp/tcp, a protocol 50 если мне память не изменяет, загугли.

А ты не гадай, включи логирование.

echo 1 > /proc/sys/net/ipv4/conf/all/log_martians

В логах пусто. Буду подымать на реальной железке. О результатах отпишусь.

С некоторых пор пользуюсь duckduckgo, но не суть. Почитал. Протокол 50 такой же отдельный, как tcp/udp и icmp. Но у меня даже icmp не ходит. Причём не ходит он на ту же машину на интерфейс, который поднят и IP, который локально имеется. Т.е. localhost и этот IP в данном случае это одна и та же сущность. Только разные интерфейсы.

Что у вас за демон ike такой? В debian-пакетах не нашел. Это racoon? IPsec работает несколько иначе, нежели привычный вам OpenVPN. Я не знаю про racoon, и, вероятно, KLIPS, который предположительно у вас используется, но с обычным ядровым IPsec (netkey) новых интерфейсов не создается, и маршрутизация вся идет через тот интерфейс, который смотрит в другую сторону, только сразу шифруется.

Используйте ip xfrm для просмотра установленных соединений.

В 8-ке дебиана есть. Это shrew soft. Так создаётся tap0. За hint спасибо. Гляну.

Не работает на реальной железке. Вообще, у ipsec с nat проблемы, как я почитал. Как при использовании ipsec over nat, так и при использовании nat over ipsec.

Да, ipsec делали тогда, когда NAT не был так широко распространён.

Источник

Пользователи VPN-сервиса Check Point столкнулись с проблемами из-за просроченного сертификата

Компания предупреждала о наличии патча, исправляющего проблему, еще в августе 2019 года.

Утро нового года обернулось неприятным сюрпризом для некоторых пользователей устаревших версий сервиса удаленного доступа Check Point Remote Access VPN, которые не смогли подключиться к сети в связи с окончанием срока действия сертификата, истекшим 1 января 2021 года.

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

На прошлой неделе компания выпустила еще одно уведомление, в котором предупредила, что решения Endpoint/VPN E80.81 — E81.10 (только версия для Windows ) и агент SandBlast E80.61 — E81.10 (только версия для Windows) перестанут нормально работать с 1 января 2021 года.

«Эти более не поддерживаемые решения прекратят функционировать 1 января 2021 года. Начиная с этой даты, после перезагрузки компьютера, версии клиента Remote Access VPN and Endpoint Security Client E81.10 и ниже могут перестать работать, а обновиться не получится», — предупредила компания.

Как рассказал изданию The Register один из читателей, работающий в правительственной организации, из-за истекшего срока действия сертификата примерно 1 600 ноутбуков, выделенных сотрудникам, не смогли подключиться к сети. Предлагаемый Check Point патч заменяет .SYS файл без задействования администратора, что запрещено правилами организации, пояснил источник.

В свою очередь, представители Check Point сообщили изданию, что начали информировать пользователей устаревших версий о проблеме еще до нового года. Сколько клиентов уже применили патч, в компании не сообщили.

Источник

Проблема с VPN, не маршрутизируются пакеты, CheckPoint

Вот и меня коснулась проблема с VPN. Вводная — есть сервер, который шлюз из офиса в сеть. Есть контейнер на lxc, на котором развёрнута относительно древняя версия дебиана (7), под которым запщен сервер ike. В пакетах он так и зовётся — ike. Этот ike соединяется к другому серваку (CheckPoint) и получает интерфейс tap0, IP и маршруты до той сети. В общем, с самой виртуалки всё ОК. Всё пингуется. Теперь на сервере, который шлюз, хотим маршрутизоваться в нужные нам сети через эту виртуалку. Делаем на виртуалке ip_forward и маскарад при прохождении на tap0. На маршрутизаторе прописываем маршрут до IP (который на tap0 на виртуалке) через виртуалку. Пробуем пинговать. И не работает. 🙁 Если я создают какой-нибудь br0 в виртуалке, задаю ему какой-нибудь адрес и на маршрутизаторе задаю маршрут на этот адрес через виртуалку, то всё пингуется и работает. А с чекпоинтом — нет. Ещё на tap0 получается MTU 1380, но, я так понимаю, именно для данного тестового случая роли не играет. Хотя пробовал и iptables’ами сгладить различия MTU. Кто сталкивался с подобной проблемой? Те же действия с OpenVPN я проделывал и не раз и всё ок. А тут хз что.

Сходу, не очень понял, зачем тебе это:

Теперь на сервере, который шлюз, хотим маршрутизоваться в нужные нам сети через эту виртуалку.

Ну и маршрутизируйся. Зачем тебе NAT? У тебя нет возможности на другом конце прописать маршруты чтоль?

Но вообще, в целом, есть мнение, что в lxc, такие довольно низкоуровневые вещи как ipsec гонять не стоит.

У меня на том конце контроля нет. Поэтому. Ну так через lxc openvpn то гонится нормально. Проблема только с ipsec. Или он ещё более низкоуровневый?

По идее, да. Он вполне вероятно более низкоуровневый. Ну и вообще tap. А всякие /proc/sys/net/ipv4/conf/all/rp_filter — не могут тебе мешать? Посмотри на всякий случай.

Если это Check Point, то вероятнее всего твои сети, которые ты хочешь маршрутизировать в туннель до Check Point-a должны быть описаны в топологии твоего шлюза, который другой админ завёл на СР как Externally Managed Gateway, т.е. надо чтобы тот админ сделал следующее:In the Topology page, define the Topology and the VPN Domain using the VPN Domain information obtained from the peer administrator. If the VPN Domain does not contain all the IP addresses behind the Security Gateway, define the VPN domain manually by defining a group or network of machines and setting them as the VPN Domain.

Ну и попроси у него логи с SmartView Tracker-a.

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

Дык я не хочу соединить сети. Я хочу в одну сторону шлюзоваться посредством NAT. А он у меня даже не хочет локальный IP пинговать, который на этом компе клиентом получен.

rp_filter, если я правильно понял, не мешают.

ipsec это не udp/tcp, a protocol 50 если мне память не изменяет, загугли.

А ты не гадай, включи логирование.

echo 1 > /proc/sys/net/ipv4/conf/all/log_martians

В логах пусто. Буду подымать на реальной железке. О результатах отпишусь.

С некоторых пор пользуюсь duckduckgo, но не суть. Почитал. Протокол 50 такой же отдельный, как tcp/udp и icmp. Но у меня даже icmp не ходит. Причём не ходит он на ту же машину на интерфейс, который поднят и IP, который локально имеется. Т.е. localhost и этот IP в данном случае это одна и та же сущность. Только разные интерфейсы.

Что у вас за демон ike такой? В debian-пакетах не нашел. Это racoon? IPsec работает несколько иначе, нежели привычный вам OpenVPN. Я не знаю про racoon, и, вероятно, KLIPS, который предположительно у вас используется, но с обычным ядровым IPsec (netkey) новых интерфейсов не создается, и маршрутизация вся идет через тот интерфейс, который смотрит в другую сторону, только сразу шифруется.

Используйте ip xfrm для просмотра установленных соединений.

В 8-ке дебиана есть. Это shrew soft. Так создаётся tap0. За hint спасибо. Гляну.

Не работает на реальной железке. Вообще, у ipsec с nat проблемы, как я почитал. Как при использовании ipsec over nat, так и при использовании nat over ipsec.

Да, ipsec делали тогда, когда NAT не был так широко распространён.

Источник

Построение распределенной VPN сети на базе Check Point. Несколько типовых сценариев

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

Check Point использует стандартный IPSec

Это первое, что нужно знать про Site-to-Site VPN от Check Point. И этот тезис отвечает на один из самых частый вопросов относительно Check Point VPN:

— Можно ли его “подружить” с другими устройствами?
— Да, можно!

Так называемый 3rd party VPN. Поскольку используется стандартный IPSec, то и VPN можно строить с любым устройством, которое поддерживает IPSec. Лично я пробовал строить VPN с Cisco ASA, Cisco Router, D-Link, Mikrotik, StoneGate. Все работает, хотя и есть некоторые особенности. Главное правильно задать все параметры для первой и второй фазы. Поддерживаемые параметры для IPSec соединения:

Encryption Method: IKEv1, IKEv2

IKE Security Association (Phase 1)
— Encryption Algorithm: AES-128, AES-256, DES, 3DES, CAST
— Data Integrity: SHA1, SHA256, SHA384, MD5, AES-XCBC
— Diffie-Hellman group: Group 1, Group 2, Group 5, Group 14, Group 19, Group 20

IKE Security Association (Phase 2)
— Encryption Algorithm: AES-128, AES-256, AES-GCM-128, AES-GCM-256, DES, 3DES, DES-40CP, CAST, CAST-40, NULL
— Data Integrity: SHA1, SHA256, SHA384, MD5, AES-XCBC

Дополнительные параметры:
— Use aggressive mode (Phase 1)
— Use Perfect Forward Secrecy (Phase 2)
— Support IP Compression (Phase 2)

Т.к. VPN можно строить не только с Check Point-ом, то сразу появляется вопрос, что “ставить” в филиалах?

Какое оборудование использовать для филиалов?

Здесь всего два варианта. Рассмотрим их и попробуем описать плюсы и минусы каждого из них.

1. Check Point в филиале

Это самый простой вариант. Check Point устанавливается в центральном офисе (HQ) и в филиалах (Branch).

Плюсы. Главный плюс — удобство управления. Вы управляете политиками безопасности из одного места (Security Management Server). Все логи хранятся в одном месте. Есть возможность генерировать отчеты и видеть общую картину. Существенно упрощается администрирование распределенной сети. Возможно вам даже не понадобится система мониторинга, часть функций по умолчанию выполняет центральный менеджмент сервер. Настройка VPN ускоряется, нет необходимости в бесконечной правке access-list-ов. В грубом приближении это можно сравнить с DMVPN от Cisco (об этом чуть позже).

Минусы. Единственный минус — финансовые затраты. Безусловно, вопрос “дорого или недорого” немного философский и я не буду дискутировать на эту тему. Но даже самый маленький филиал (даже банкомат) потребует установки шлюза Check Point. Чуть позже мы обсудим конкретные модели для таких задач.

Кто использует подобный вариант (Check Point в филиале)? На самом деле практически все сегменты бизнеса: банки, ритейл, промышленность, здравоохранение, нефтегазовые компании.

Рис. 1. Check Point SmartConsole с отображением всех шлюзов филиалов

2. НЕ Check Point в филиале

Тоже довольно распространенный вариант. В центре (HQ) ставится Check Point, а в филиалах (Branch) — любое другое устройство, которое поддерживает IPSec VPN.

Плюсы. Пожалуй единственный плюс — минимальные финансовые затраты. Можно поставить самый дешевый Mikrotik или D-Link, VPN до центрального офиса будет прекрасно работать.

Минусы. Минусов гораздо больше. По сути вы лишаетесь всех плюсов, описанных в предыдущем варианте. Придется “ручками” править настройки на каждом из филиалов. Если их 2 — 3, то возможно это не такая большая проблема. Но если их больше 5-10, то встанет серьезный вопрос дальнейшего масштабирования. Управление конфигурациями, политики доступа, мониторинг, все это придется организовывать на основе сторонних решений (возможно open source). Еще один большой минус — невозможно организовать резервирование VPN канала.
Кто использует подобный вариант (НЕ Check Point в филиале)? Как правило это малый бизнес с небольшим количеством филиалов.

Тип выхода в Интернет для филиалов. Самостоятельный или централизованный?

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

1. Самостоятельный выход в Интернет

Используется чаще всего. VPN канал используется исключительно для доступа к ресурсам центрального офиса (где стоит Check Point).

Плюсы. Выход в Интернет не зависит от VPN канала и оборудования в центральном офисе. Т.е. есть если в центральном офисе все “упало”, филиал сохранит выход в Интернет, просто потеряет доступ к некоторым корпоративным ресурсам.

Минусы. Существенно усложняет управление политиками безопасности. По сути, если у вас стоит задача обезопасить филиалы, то вы должны применять там такие защитные меры как IPS, потоковый антивирус, URL-фильтрацию и т.д. Отсюда вытекает куча проблем с управлением и мониторингом ИБ.

Рекомендации. При таком варианте конечно же лучше использовать Check Point-ы на филиалах. Вы сможете управлять всем этим “хозяйством” централизованно. Можно создать одну типовую политику доступа в Интернет и “раскатать” ее на все филиалы. Мониторинг тоже существенно упрощается. Вы будете видеть все инциденты ИБ в одном месте с возможностью корреляции событий.

2. Централизованный выход в Интернет

Этот вариант используется гораздо реже. Строится VPN до центрального офиса (где стоит Check Point) и туда заворачивается абсолютно весь трафик филиалов. Выход в Интернет возможен только через центральный офис.

Плюсы. В этом случае вам в принципе все равно, что стоит в филиале, главное строить VPN до центра. Больших проблем с конфигом тоже не должно быть, т.к. по сути там будет всего одно правило — “весь трафик в vpn”. Все политики безопасности и аксес-листы вы будете настраивать только в центральном офисе. Как вы понимаете, при таком варианте вы существенно экономите на покупке Check Point.

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

Рекомендации. Такой вариант отлично подходит при небольшом кол-ве филиалов (2-4). Конечно если вас устраивают озвученные риски (зависимость от центра). При выборе устройства Check Point для центрального офиса стоит учесть трафик филиалов и внимательно рассчитать нужную производительность. По сути вы получите централизованное управление трафиком филиалов при минимальных финансовых затратах. Однако при большом кол-ве филиалов (и “серьезном” трафике) такая схема крайне не рекомендуется. Слишком большие последствия в случае отказа. Траблшутинг будет усложняться, а для центрального офиса потребуется весьма мощное железо, которое может в итоге стать дороже, чем если бы в филиалах стояли собственные шлюзы Check Point.

Возможная экономия на лицензиях

Если вы решили использовать Check Point в филиалах и вам нужен только VPN (например при централизованном выходе в Интернет), то можно существенно сэкономить на лицензиях. Blade IPSec VPN никак не лицензируется. Купив устройство вы навсегда получаете функционал Firewall и VPN. Не нужно покупать для этого продление сервисов, все и так будет работать.

Единственное, что придется покупать — сервис технической поддержки, чтобы была возможность обращаться в саппорт и заменить устройство в случае поломки. Однако и здесь есть вариант сэкономить (хоть я его и не рекомендую). Если вы уверены в своих знаниях и что вам не придется обращаться в саппорт, то можно не покупать продление технической поддержки.

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

Модели Check Point для филиалов (SMB)

Бытует мнение, что Check Point это вендор исключительно для больших компаний. Однако в модельном ряду представлено довольно много вариантов устройств и для SMB сектора. Особенно если данная “железка” будет использоваться для филиалов, находясь под управлением центрального Management Server-а в головном офисе.

Рис. 2. Модельный ряд Check Point

Мы уже публиковали отдельную статью по SMB решениям, поэтому я просто перечислю модели которые чаще всего используются для филиалов:

1. 5000-ая серия (5100, 5200) для больших филиалов (150-200 человек);
2. 3000-ая серия (3100, 3200) для средних филиалов (100-150 человек);
3. 1400-ая серия (1430, 1450, 1470, 1490) для малых филиалов (менее 100 человек).

Данные по кол-ву человек исключительно наше субъективное мнение основанное на опыте. Очень рекомендуем обратить внимание на серию 1400. Это относительно новые модели на базе ARM процессоров. У них есть некоторые технологические ограничения по сравнению с более старшими моделями (т.к. используется другая ОС — Gaia Embedded), однако при наличии Management Server-а эти ограничения незначительны, особенно для филиальных сетей.

VPN топологии (Start, Mesh)

Поговорим о более “технических” вещах и начнем с топологий VPN (VPN Community в терминологии Check Point). Как и у других вендоров у Check Point-а есть два типа:

1. Star. Название говорит само за себе. VPN-каналы от всех филиалов сходятся в центр. При такой топологии даже если филиалам понадобится общаться друг с другом, то трафик будет ходить через центр. Иногда это не совсем удобно и практично. Хотя на практике чаще всего используется именно эта топология.
2. Mesh. Топология “каждый с каждым”. Здесь уже нет центра. Все шлюзы помещенные в одно Mesh VPN Community могут строить туннели друг с другом.

Стоит отметить, что при этом вам никто не мешает комбинировать эти две топологии. Например связать два Start Community через одно Mesh:

Рис. 3. Star + Mesh

Два типа туннелей

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

1. Domain Based VPN

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

Рис. 4. Определение VPN Domain

Поскольку все шлюзы находятся под управлением одного менеджмент сервера, то эта информация “шарится” между всеми участниками VPN Community (будь то Star или Mesh). Таким образом, нет нужды править настройки VPN на каждом из шлюзов, они уже и так будут знать где, какая сеть и с какими IPSec параметрами строить VPN. Никакого прописывания peer-ов или access-list-ов. Настройка быстрая и весьма простая. На мой взгляд это даже удобнее чем DMVPN. Domain Based VPN на практике используется чаще всего.

2. Route Based

Данный тип VPN покажется очень знакомым для любителей Cisco. На шлюзах создается VTI (Virtual Tunnel Interface) и поднимается VPN канал с туннельными адресами. Шифруется тот трафик, который маршрутами заворачивается в туннель. При этом маршруты могут быть как статические, так и динамические. К примеру, вы можете поднять такой VPN со всеми филиалами и запустить OSPF. Таким образом все шлюзы будут знать про все доступные сети и автоматически “заворачивать” нужный трафик в нужный туннель. Думаю это можно сравнить с GRE туннелями.

Рекомендации

Route Based VPN используется гораздо реже, т.к. в большинстве случаев хватает Domain Based VPN, который проще в понимании и быстрее в настройке. При этом Domain Based VPN можно использовать и в случае стороннего оборудования (НЕ Check Point) в филиалах. Опять же, основываясь на личном опыте, могу порекомендовать использовать именно Domain Based VPN. Будет гораздо меньше проблем. Route Based лучше не использовать вообще (много ограничений, деградация в производительности). Хотя конечно все зависит от ваших задач и каждый случай нужно рассматривать отдельно.

VPN на сертификатах или Pre-shared key

Как и любое устройство с поддержкой IPSec, Check Point может строить VPN на основе Pre-shared key и на основе сертификатов. Не буду объяснять, в чем преимущество VPN канала на сертификатах. Просто скажу, что еще одно преимущество построения распределенной сети на решениях Check Point — наличие встроенного центра сертификации (CA). Этот CA по умолчанию всегда присутствует на Management Server-е и автоматически генерирует сертификаты на все шлюзы Check Point, которые находятся под его управлением. Не нужно “мучаться” со сторонним центром сертификации (хотя его тоже можно “прикрутить” к Check Point-у).

Отказоустойчивость VPN

Довольно часто забывают про эту возможность. А она есть. В филиале и центральном офисе может быть по два Интернет канала. Если в филиале тоже стоит Check Point, то мы можем настроить отказоустойчивый VPN (Domain Based). Не пренебрегайте этой возможностью Check Point, тем более что это настраивается буквально в пару кликов.

Лицензирование Management Server-а

Еще один важный момент, про который забывают при планировании распределенной сети. Security Management Server лицензируется по количеству шлюзов, которыми он может управлять. Есть лицензии на управление 5-ю шлюзами, 10, 25, 50, 150 и более. При этом цены очень сильно отличаются. Кластер считается как два шлюза! Будьте внимательней при планировании бюджета.

Дополнительные преимущества Check Point VPN

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

Источник