VPN и IPSec на пальцах

В принципе, и о VPN, и о IPSec мы кое-что в журнале уже писали, причем на достаточно высоком техническом уровне. Но большой объем информации не всегда ведет к большей степени понимания и в умах начинается смятение, разброд и шатание. Лаконичное же объяснение зачастую - прямой путь к пониманию сути той или иной технологии. Вот, стало быть, вам ликбез - предлагаемая вашему вниманию статья предельно просто разъясняет достаточно сложные вещи.
VPN, или Virtual Private Network, что в переводе означает Виртуальная Частная Сеть - это криптосистема, позволяющая защитить данные при передаче их по незащищенной сети, такой, как Интернет. Несмотря на то, что данное описание подходит и для криптосистемы SSH, VPN имеет другое предназначение. SSH разрабатывался как средство, позволяющее пользователю безопасно зайти и удаленно управлять другим компьютером. Цель VPN - прозрачный доступ к ресурсам сети, где пользователь может делать все то, что он делает обычно независимо от того, насколько он удален. По этой причине VPN приобрел популярность среди дистанционных работников и офисов, которые нуждаются в совместном использовании ресурсов территориально разделенных сетей.

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

Хотя VPN-туннель всегда устанавливается между двумя точками, каждый peer может устанавливать дополнительные туннели с другими узлами. Для примера, когда трем удаленным станциям необходимо связаться с одним и тем же офисом, будет создано три отдельных VPN-туннеля к этому офису. Для всех туннелей peer на стороне офиса может быть одним и тем же. Это возможно благодаря тому, что узел может шифровать и расшифровывать данные от имени всей сети, как это показано на рисунке 1:


Рисунок 1. VPN-шлюз к сети.

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

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


Рисунок 2. Защищенная сеть на основе незащищенной сети.

Сеть A считается доменом шифрования VPN-шлюза A, а сеть B - доменом шифрования VPN-шлюза B, соответственно. Когда пользователь сети A изъявляет желание отправить данные в сеть B, VPN шлюз A зашифрует их и отошлет через VPN-туннель. VPN шлюз B расшифрует информацию и передаст получателю в сети B.
Всякий раз, когда соединение сетей обслуживают два VPN-шлюза, они используют режим туннеля. Это означает, что шифруется весь пакет IP, после чего к нему добавляется новый IP-заголовок. Новый заголовок содержит IP-адреса двух VPN-шлюзов, которые и увидит пакетный сниффер при перехвате. Невозможно определить компьютер-источник в первом домене шифрования и компьютер-получатель во втором домене.

Посмотрите на рисунок 1, иллюстрирующий типичное использование VPN, которая позволяет удаленным пользователям с переносыми компьютерами и пользователям, работающим из дома, иметь доступ к офисной сети. Чтобы эта схема заработала, пользователь должен иметь установленное ПО – VPN- клиент, который обеспечит создание VPN-туннеля к удаленному VPN-шлюзу. По сценарию используется режим туннеля, так как пользователь хочет получить доступ к ресурсам домена, а не самого шлюза. Единственной случай, когда включается режим транспорта - это если одному компьютеру нужно получить доступ к другому непосредственно.
Существует много вариантов VPN-шлюзов и VPN-клиентов. Это может быть аппаратное устройство или программное обеспечение, которое устанавливается на маршрутизаторах или на ПК. Скажем, ОС FreeBSD поставляется вместе с ПО для создания VPN-шлюза и для настройки VPN-клиента. Свои VPN-решения существуют и для ПО компании Microsoft.
К счастью, в Интернет есть много источников информации о VPN, технические статьи, FAQ и варианты настроек. Я могу порекомендовать Tina Bird's VPN Information, VPN Labs, и Virtual Private Network Consortium (VPNC).

Назависимо от используемого ПО, все VPN работают по следующим принципам:
1. Каждый из узлов идентифицирует друг друга перед созданием туннеля, чтобы удостовериться, что шифрованные данные будут отправлены на нужный узел.
2. Оба узла требуют заранее настроеной политики, указывающей, какие протоколы могут использоваться для шифрования и обеспечения целостности данных.
3. Узлы сверяют политики, чтобы договориться об используемых алгоритмах; если это не получается, то туннель не устанавливается.
4. Как только достигнуто соглашение по алгоритмам, создается ключ, который будет использован в симметричном алгоритме для шифрования/расшифровки данных.
Есть несколько стандартов, регламентирующих вышеописанное взаимодействие. Вы, должно быть, слышали о некоторых из них: L2TP, PPTP, и IPSec. Так как IPSec - наиболее широко поддерживаемый стандарт, оставшуюся часть статьи стоит посвятить именно ему.

IPSec
Стандарт IPSec был разработан для повышения безопасности IP-протокола. Это достигается за счет дополнительных протоколов, добавляющих к IP- пакету собственные заголовки. Т.к. IPSec - стандарт Интернет, то для него существуют RFC (Requests For Comments). Если есть интерес покопаться во внутренностях IPSec, то следующие RFC могут оказаться полезными:
- RFC 2401 IPSec;
- RFC 2402 AH;
- RFC 2406 ESP;
- RFC 2409 IKE.
Приведем краткое описание каждого дополнительного протокола. Начнем с сокращений, а затем посмотрим, как они укладываются в общую картину создания виртуальной частной сети.

AH (Authentication Header) - протокол заголовка идентификации. Обеспечивает целостность путем проверки того, что ни один бит в защищаемой части пакета не был изменен во время передачи. Не будем вдаваться в подробности, какая часть пакета защищается и где находятся данные AH-заголовка, так как это зависит от используемого типа шифрования и в деталях, с диаграммами описывается в соответствующем RFC. Отметим лишь, что использование AH может вызвать проблемы, например, при прохождении пакета через NAT-устройство. NAT меняет IP-адрес пакета, чтобы, например, разрешить доступ в Интернет с закрытого локального адреса. Так как пакет в таком случае изменится, контрольная сумма AH станет неверной. Также стоит отметить, что AH разрабатывался только для обеспечения целостности. Он не гарантирует конфиденциальности путем шифрования содержимого пакета.

ESP (Encapsulating Security Protocol) - инкапсулирующий протокол безопасности, который обеспечивает и целостность и конфиденциальность. В режиме транспорта ESP-заголовок находится между оригинальным IP-заголовком и заголовком TCP или UDP. В режиме туннеля заголовок ESP размещается между новым IP-заголовком и полностью зашифрованным оригинальным IP-пакетом.

Так как оба протокола - AH и ESP - добавляют собственные заголовки, они имеют свой ID протокола, по которому можно определить, что последует за заголовком IP. Каждый тип заголовка имеет собственный номер. Например, для TCP это 6, а для UDP - 17. При работе через firewall важно не забыть настроить фильтры, чтобы пропускать пакеты с ID AH-и/или ESP-протокола. Для AH номер ID - 51, а ESP имеет ID протокола равный 50. При создании правила не перепутайте случайно ID протокола с номером порта.

Третий протокол, используемый IPSec - это IKE или Internet Key Exchange protocol. Как следует из названия, он предназначен для обмена ключами между двумя узлами VPN. Насмотря на то, что генерировать ключи можно вручную, лучшим и более масштабируемым вариантом будет автоматизация этого процесса с помощью IKE. Помните, что ключи должны часто меняться, и вам наверняка не хочется полагаться на свою память, чтобы найти время для совершения этой операции вручную. Главное - не забудьте настроить правило на файрволе для UDP-порта с номером 500, так как именно этот порт используется IKE.

SA (Security Association), что можно приближенно перевести как "связь или ассоциация безопасности" - это термин IPSec для обозначения соединения. При настроенном VPN, для каждого используемого протокола создается одна SA-пара (то есть одна для AH и одна для ESP). SA создаются парами, так как каждая SA - это однонаправленное соединение, а данные необходимо передавать в двух направлениях. Полученные SA-пары хранятся на каждом узле. Если ваш узел имеет SA, значит VPN-туннель был установлен успешно.

Так как каждый узел способен устанавливать несколько туннелей с другими узлами, каждый SA имеет уникальный номер, позволяющий определить, к какому узлу он относится. Это номер называется SPI (Security Parameter Index) или индекс параметра безопасности.
SA хранятся в базе данных c названием - кто бы подумал ;) - SAD (Security Association Database) или БД ассоциаций безопасности.
Каждый узел IPSec также имеет вторую БД - SPD или Security Policy Database (БД политики безопасности). Она содержит настроенную вами политику узла. Большинство VPN-решений разрешают создание нескольких политик с комбинациями подходящих алгоритмов для каждого узла, с которым нужно установить соединение.

Какие настройки включает в себя политика?
1. Симметричные алгоритмы для шифрования/расшифровки данных.
2. Криптографические контрольные суммы для проверки целостности данных.
3. Способ идентификации узла. Самые распространненные способы - это предустановленные ключи (pre-shared secrets) или RSA-сертификаты. 4. Использовать ли режим туннеля или режим транспорта.
5. Какую использовать группу Diffie Hellman.
6. Как часто проводить переидентификацию узла.
7. Как часто менять ключ для шифрования данных.
8. Использовать ли PFS.
9. Использовать ли AH, ESP или оба вместе.

При создании политики, как правило, возможно создание упорядоченного списка алгоритмов и Diffie Hellman-групп. В таком случае будет использована первая совпавшая на обоих узлах позиция. Запомните, очень важно, чтобы все в политике безопасности позволяло добиться этого совпадения. Если за исключением одной части политики все остальное совпадает, узлы все равно не смогут установить VPN-соединение. При настройке VPN между различными системами уделите время изучению того, какие алгоритмы поддерживаются каждой стороной, чтобы иметь выбор наиболее безопасной политики из возможных.

Фаза Один и Фаза Два
Теперь давайте посмотрим как все это работает вместе. Установка и поддержка VPN-туннеля происходит в два этапа. На первом этапе (фазе) два узла договариваются о методе идентификации, алгоритме шифрования, хэш-алгоритме и группе Diffie Hellman. Они также идентифицируют друг друга. Все это может пройти в результате обмена тремя нешифрованными пакетами (так называемый агрессивный режим) или через обмен шестью нешифрованными пакетами (стандартный режим - main mode). При успешном завершении операции создается SA первой Фазы - Phase 1 SA (также называемый IKE SA) и процесс переходит к Фазе Два.

На втором этапе генерируются данные ключей, узлы договариваются насчет используемой политики. Этот режим, называемый быстрым режимом (quick mode), отличается от первой фазы тем, что может установиться только после первого этапа, когда все пакеты второй фазы шифруются. Такое положение дел усложняет решение проблем в случае неполадок на второй фазе при успешном завершении первой. Правильное завершение второй фазы приводит к появлению Phase 2 SA или IPSec SA, и на этом установка туннеля считается завершенной.

Когда же это все происходит? Сначала на узел прибывает пакет с адресом назначения в другом домене шифрования, и узел инициирует Фазу Один с тем узлом, который отвечает за другой домен. Допустим, туннель между узлами был успешно установлен и ожидает пакетов. Однако, узлам необходимо переидентифицировать друг друга и сравнить политику через определенное время. Это время известно как время жизни Phase One или IKE SA lifetime. Узлы также должны сменить ключ для шифрования данных через другой отрезок времени, который называется временем жизни Phase Two или IPSec SA lifetime. Phase Two lifetime короче, чем у первой фазы, так как ключ необходимо менять чаще. Типичное время жизни Phase Two - 60 минут. Для Phase One оно равно 24 часам.

Ваша задача заключается в том, чтобы сконфигурировать оба узла с одинаковыми параметрами времени жизни. Если этого не произойдет, то возможен вариант, когда изначально туннель будет установлен успешно, но по истечении первого несогласованного промежутка времени жизни связь прервется. Странные проблемы могут возникнуть и в том случае, когда время жизни Фазы Один меньше аналогичного параметра Фазы Два. Если настроенный ранее туннель виснет, то первая вещь, которая нуждается в проверке - это время жизни на обоих узлах. В заключение стоит упомянуть, что при смене политики на одном из узлов, изменения вступят в силу только при следующем наступлении Фазы Один. Чтобы изменения вступили в силу немедленно, надо убрать SA для этого туннеля из SAD. Это вызовет пересмотр соглашения между узлами с новыми настройками политики безопасности.



Dru Lavigne, инструктор Marketbridge Technologies в Оттаве и администратор Open Protocol Resource. Перевод by techtonik.