ID статьи: 996
Последнее обновление: 28 авг, 2024
Documentation: Product: NGFW Version: 7.1.0 Technology: VPN
VPN (Virtual Private Network — виртуальная частная сеть) — обобщенное название технологий, позволяющих создавать логические сети (туннели) поверх открытых публичных сетей для обеспечения безопасности коммуникаций. Для создания VPN необходимо как минимум два сетевых устройства, которые могут идентифицировать друг друга и зашифровать поток данных между собой. Типы VPN-подключенийUserGate NGFW позволяет создавать VPN-подключения следующих типов:
Варианты организации защищенных VPN-туннелейДля создания защищенных VPN-туннелей могут использоваться протоколы L2TP/IPsec(IKEv1), IPsec(IKEv2), IPSec(IKEv1), GRE/IPsec. L2TP/IPsec VPNПри создании VPN с помощью L2TP/IPsec, протокол L2TP (RFC 3931) создает туннель, в котором пакеты сетевого уровня передаются в кадрах PPP. Поскольку L2TP сам по себе не обеспечивает строгую аутентификацию, конфиденциальность и целостность передаваемых данных, для этих целей используется группа протоколов IPsec (RFC 6071). L2TP-туннель создается внутри защищенного IPsec-канала и для его установления необходимо сначала создать защищенное IPsec-соединение между узлами. IPsec в данном случае работает в транспортном режиме и использует протокол ESP (Encapsulating Security Payload) для шифрования L2TP-пакетов. VPN имеет два уровня инкапсуляции — внутреннюю инкапсуляцию L2TP и внешнюю инкапсуляцию IPsec. Внутренний уровень имеет заголовки L2TP и UDP дополнительно к кадру PPP. Внешний уровень добавляет заголовок и трэйлер IPsec ESP. Трейлер проверки подлинности IPsec Auth обеспечивает проверку целостности сообщений и аутентификацию. Процесс создания VPN состоит из следующих основных этапов: 1. Установление защищенного канала передачи данных. 2. Установление VPN-туннеля.
Установление защищенного канала передачи данныхДля установления защищенного канала передачи данных используется группа протоколов IPsec. В основе IPsec лежат три протокола:
Authentication Header (AH) обеспечивает целостность передаваемых данных, аутентификацию источника информации и защиту от повторной передачи данных. AH не обеспечивает конфиденциальность передаваемых данных, поскольку не осуществляет шифрование. Номер IP-протокола для AH — 51. Encapsulating security payload (ESP) обеспечивает конфиденциальность передаваемых данных с помощью шифрования, также поддерживается целостность передаваемых данных и аутентификация источника информации. Номер IP-протокола для ESP — 50. Internet Key Exchange (IKE) — это протокол обмена служебной информацией для согласования и установления ассоциации безопасности (Security Association — SA). Ассоциация безопасности содержит набор параметров защищенного соединения, которые могут использоваться обеим сторонами соединения для взаимной аутентификации и шифрования передаваемых данных. IKE работает по UDP-порту 500. IPsec может работать в двух режимах:
В туннельном режиме протоколом IPsec шифруется весь исходный IP-пакет вместе со своим заголовком. Далее он инкапсулируется внутри дополнительного пакета, который имеет собственный заголовок. Туннельный режим применяется, когда две частные сети передают данные через публичную незащищенную сеть. В транспортном режиме шифруется только полезная нагрузка IP-пакета, при этом исходный заголовок остается, в него добавляется дополнительная информация. Транспортный режим используется, когда между двумя узлами уже существует IP-связь, но она не обеспечивает защиту передаваемых данных. В сценарии установления VPN с помощью протоколов L2TP/IPsec туннель между узлами создается протоколом L2TP, при этом IPsec должен обеспечивать безопасность канала. В этом случае IPsec работает в транспортном режиме, а согласование ассоциаций безопасности и установление защищенного канала осуществляется с помощью протокола IKE версии IKEv1 в двух фазах. В фазе 1 происходит аутентификация соседних узлов, согласование ассоциации безопасности IKE SA и установление служебного защищенного канала между узлами для обеспечения обмена данными IKE. Согласуемыми параметрами IKE SA являются:
Для аутентификации узлов канала используется метод общих ключей — pre-shared keys. Согласование фазы 1 IKEv1 может происходить в двух режимах:
В основном режиме происходит обмен шестью сообщениями. Во время первого обмена (сообщения 1 и 2) происходит согласование алгоритмов шифрования и аутентификации для IKE SA. Второй обмен (сообщения 3 и 4) предназначен для обмена ключами Диффи-Хеллмана (DH). После второго обмена служба IKE на каждом из устройств создаёт основной ключ, который будет использоваться для защиты проверки подлинности. Третий обмен (сообщения 5 и 6) предусматривает аутентификацию инициатора соединения и получателя (проверка подлинности); информация защищена алгоритмом шифрования, установленным ранее. В агрессивном режиме происходит два обмена сообщениями (всего три сообщения). В первом сообщении инициатор передаёт информацию, соответствующую сообщениям 1 и 3 основного режима, т.е. информацию об алгоритмах шифрования и аутентификации, и ключ DH. Второе сообщение предназначено для передачи получателем информации, соответствующей сообщениям 2 и 4 основного режима, а также аутентификации получателя. Третье сообщение аутентифицирует инициатора и подтверждает обмен. Меньшее количество передаваемых сообщений в агрессивном режиме позволяет достичь более быстрого установления соединения, однако обмен идентификаторами узлов канала осуществляется открытым текстом. Основной режим считается более безопасным, поскольку данные идентификации в основном режиме зашифрованы. Результатом фазы 1 является согласование двунаправленной ассоциации безопасности IKE SA и установление защищенного служебного канала. Данный канал будет использоваться в фазе 2 для согласования параметров IPsec SA основного канала передачи данных. В фазе 2 по защищенному служебному каналу, установленному в фазе 1, происходит согласование IPsec SA для защиты данных, проходящих через канал IPsec. IKEv1 в фазе 2 имеет один режим, называемый быстрым режимом (Quick mode). Согласуемыми параметрами IPsec SA являются:
По результатам согласования IPsec SA создается защищенный канал для передачи данных, работающий в транспортном режиме IPsec с инкапсуляцией ESP, имеющий два однонаправленных SA в обе стороны канала. После его установления служебный канал, созданный в фазе 1, не пропадает – он используется для обновления SA основного. IPsec SA завершает работу при выключении VPN с одной из сторон соединения или по истечении времени жизни. Тайм-аут по времени жизни возникает при истечении времени жизни ключа или при достижении установленного порога байт данных, прошедших через канал. Когда SA завершает работу, ключи удаляются. Если для передачи данных требуются дополнительные IPsec SA, выполняется новая фаза согласования IKE. Установление VPN-туннеляНа этом этапе происходит согласование и установление туннеля L2TP между конечными точками SA. Фактическое согласование параметров происходит по защищенному каналу IPsec SA. Протокол L2TP использует UDP-порт 1701. Когда процесс установления VPN туннеля завершен, пакеты L2TP между конечными точками инкапсулируются с помощью IPsec. Поскольку сам пакет L2TP скрыт внутри пакета IPsec, исходный IP-адрес источника и назначения зашифрован внутри пакета. Кроме того, нет необходимости открывать UDP-порт 1701 на FW между конечными точками, поскольку внутренние пакеты не обрабатываются до тех пор, пока данные IPsec не будут расшифрованы, что происходит только на конечных точках туннеля. IPsec(IKEv2) VPNПри создании VPN с помощью IPsec(IKEv2) защищенный VPN-туннель создается только протоколами группы IPsec с протоколом IKE версии IKEv2 (RFC 7296, RFC 7427). В этом сценарии IPsec работает в туннельном режиме, исходные IP-пакеты целиком инкапсулируются и шифруются внутри нового пакета, который имеет свой собственный заголовок и трэйлеры. Подобно IKEv1, IKEv2 также имеет двухэтапный процесс установления защищенного соединения, но при этом происходит меньше обменов сообщениями. Первый этап известен, как IKE_SA_INIT. В двух сообщениях обмена IKE_SA_INIT между соседними узлами происходит согласование параметров ассоциации безопасности IKE SA и установление защищенного служебного канала. Согласуемые параметры IKE SA:
Каждый узел генерирует seed-key (SKEYSEED) — ключ, который используется для последующей генерации ключей, используемых в IKE SA. Все будущие ключи IKE создаются с помощью SKEYSEED. Второй этап называется IKE_AUTH. На этом этапе происходит проверка подлинности соседних узлов. Два сообщения обмена IKE_AUTH аутентифицируются и шифруются в рамках ассоциации безопасности IKE SA, созданной в обмене сообщениями этапа IKE_SA_INIT. В конце второго этапа согласования через IKE SA создается дочерняя ассоциация безопасности (CHILD SA) для защищенной передачи данных. CHILD SA — это термин IKEv2, подобный IPsec SA для IKEv1. IKEv2 работает через UDP-порты 500 и 4500 (IPsec NAT Traversal). Дополнительные CHILD SA могут создаваться для организации нового туннеля. Этот обмен называется CREATE_CHILD_SA, в нем могут быть согласованы новые значения групп Diffie-Hellman, новые комбинации алгоритмов шифрования и хэширования. Аутентификация узлов IPsec туннеля может происходить посредством сертификатов, использующих инфраструктуры открытых ключей (PKI) или с помощью протокола EAP (Extensible Authentication Protocol). IPsec(IKEv1) VPNПри создании VPN с помощью IPsec(IKEv1) защищенный VPN-туннель создается протоколами группы IPsec с протоколом IKE версии IKEv1. UserGate NGFW в таком сценарии может работать в качестве VPN-клиента и в качестве VPN-сервера. GRE/IPsec VPNGRE (RFC 2784) — это протокол туннелирования, позволяющий инкапсулировать пакеты протоколов различного типа внутри IP-туннелей, благодаря чему создается виртуальный канал «точка-точка» поверх IP-сети. GRE предназначен для управления процессом передачи многопротокольного и группового IP-трафика между двумя и более площадками, между которыми связь может обеспечиваться только по IP. При этом GRE не обеспечивает конфиденциальность и целостность передаваемых данных. Для этих целей совместно с GRE используются протоколы группы IPsec. При совместном использовании GRE и IPsec могут быть созданы 2 типа соединений: IPsec over GRE и GRE over IPsec. При использовании соединения IPsec over GRE происходит передача шифрованного трафика по незащищённому GRE-туннелю, т.е. сначала происходит инкапсуляция IPsec, а затем инкапсуляция GRE. Недостаток IPsec over GRE заключается в том, что не поддерживается передача многоадресных и широковещательных пакетов. Соединение GRE over IPsec позволяет использовать преимущества GRE (поддержка многоадресной и широковещательной рассылки) и IPsec (передача трафика в зашифрованном виде). При использовании соединения GRE over IPsec происходит инкапсуляция пакетов в GRE, а затем их передача по зашифрованному каналу связи (инкапсуляция IPsec). Для настройки GRE over IPsec необходимо выполнить следующие шаги:
Эта статья была:
Полезна |
Не полезна
Сообщить об ошибке
ID статьи: 996
Последнее обновление: 28 авг, 2024
Ревизия: 35
Просмотры: 1655
Комментарии: 0
Теги
|