Главная > Windows > Как работает ipSec.  Осваиваем VPN: настройка IPSec на Cisco Туннельный и транспортный режим ipsec


Как работает ipSec.  Осваиваем VPN: настройка IPSec на Cisco Туннельный и транспортный режим ipsec




0 В этой статье предлагается обзор средств IPSEC (IP Security - система защиты на уровне IP) и соответствующих протоколов IPSec, доступных в продуктах Cisco и используемых для создания виртуальных частных сетей (VPN). В данной статье мы определим, что такое IPSEC, а также какие протоколы и алгоритмы защиты лежат в основе IPSEC.

Введение

IP Security - это комплект протоколов, касающихся вопросов шифрования, аутентификации и обеспечения защиты при транспортировке IP-пакетов; в его состав сейчас входят почти 20 предложений по стандартам и 18 RFC.

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

  • Конфиденциальность данных . Отправитель данных IPSec имеет возможность шифровать пакеты перед тем, как передавать их по сети.
  • Целостность данных . Получатель данных IPSec имеет возможность аутентифицировать сообщающиеся с ним стороны (устройства или программное обеспе¬чение, в которых начинаются и заканчиваются туннели IPSec) и пакеты IPSec, посылаемые этими сторонами, чтобы быть уверенным в том, что данные не были изменены в пути.
  • Аутентификация источника данных . Получатель данных IPSec имеет возмож¬ность аутентифицировать источник получаемых пакетов IPSec. Этот сервис за¬висит от сервиса целостности данных.
  • Защита от воспроизведения . Получатель данных IPSec может обнаруживать и от¬вергать воспроизведенные пакеты, не допуская их фальсификации и проведе¬ния атак внедрения посредника.

IPSec представляет собой основанный на стандартах набор протоколов и алгоритмов защиты. Технология IPSec и связанные с ней протоколы защиты соответствуют открытым стандартам, которые поддерживаются группой IETF (Internet Engineering Task Force - проблемная группа проектирования Internet) и описаны в спецификациях RFC и проектах IETF. IPSec действует на сетевом уровне, обеспечивая защиту и аутентификацию пакетов IP, пересылаемых между устройствами (сторонами) IPSec - такими как маршрутизаторы Cisco, брандмауэры PIX Firewall, клиенты и концентраторы Cisco VPN, а также многие другие продукты, поддерживающие IPSec. Средства поддержки IPSec допускают масштабирование от самых малых до очень больших сетей.

Ассоциации защиты (Security Association ,SA)

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

Ассоциация защиты (Security Association - SA) представляет собой согласованную политику или способ обработки данных, обмен которыми предполагается между двумя устройствами сообщающихся сторон. Одной из составляющих такой политики может быть алгоритм, используемый для шифрования данных. Обе стороны могут ис¬пользовать один и тот же алгоритм как для шифрования, так и для дешифрования. Действующие параметры SA сохраняются в базе данных ассоциаций защиты (Security Association Database - SAD) обеих сторон.

Два компьютера на каждой стороне SA хранят режим, протокол, алгоритмы и ключи, используемые в SA. Каждый SA используется только в одном направлении. Для двунаправленной связи требуется два SA. Каждый SA реализует один режим и протокол; таким образом, если для одного пакета необходимо использовать два протокола (как например AH и ESP), то требуется два SA.

Протокол IKE (Internet Key Exchange - обмен Internet-ключами) является гибридным протоколом, обеспечивающим специальный сервис для IPSec, а именно аутентификацию сторон IPSec, согласование параметров ассоциаций защиты IKE и IPSec, а также выбор ключей для алгоритмов шифрования, используемых в рамках IPSec. Протокол IKE опира¬ется на протоколы ISAKMP (Internet Security Association and Key Management Protocol - протокол управления ассоциациями и ключами защиты в сети Internet) и Oakley, которые применяются для управления процессом создания и обработки ключей шифрования, используемых в преобразованиях IPSec. Протокол IKE применяется также для формирования ассоциаций защиты между потенциальными сторонами IPSec.
Как IKE, так и IPSec используют ассоциации зашиты, чтобы указать параметры связи.
IKE поддерживает набор различных примитивных функций для использования в протоколах. Среди них можно выделить хэш-функцию и псевдослучайную функцию (PRF).

Хэш-функция – это функция, устойчивая к коллизиям. Под устойчивостью к коллизиям понимается тот факт, что невозможно найти два разных сообщения m1 и m2, таких, что

H(m1)=H(m2), где H – хэш функция.

Что касается псеводслучайных функций, то в настоящее время вместо специальных PRF используется хэш функция в конструкции HMAC (HMAC - механизм аутентификации сообщений с использованием хэш функций). Для определения HMAC нам понадобится криптографическая хэш функция (обозначим её как H) и секретный ключ K. Мы предполагаем, что H является хэш функцией, где данные хэшируются с помощью процедуры сжатия, последовательно применяемой к последовательности блоков данных. Мы обозначим за B длину таких блоков в байтах, а длину блоков, полученных в результате хэширования - как L (L
ipad = байт 0x36, повторённый B раз;
opad = байт 0x5C, повторённый B раз.

Для вычисления HMAC от данных "text" необходимо выполнить следующую операцию:

H(K XOR opad, H(K XOR ipad, text))

Из описания следует, что IKE использует для аутентификации сторон HASH величины. Отметим, что под HASH в данном случае подразумевается исключительно название Payload в ISAKMP, и это название не имеет ничего общего со своим содержимым

Инфраструктура IPSec

Сети VPN на основе IPSec могут быть построены с помощью самых разных устройств Cisco - маршрутизаторов Cisco, брандмауэров CiscoSecure PIX Firewall, программного обеспечения клиента CiscoSecure VPN и концентраторов Cisco VPN серий 3000 и 5000. Маршрутизаторы Cisco имеют встроенную поддержку VPN с соответствующими богатыми возможностями программного обеспечения Cisco IOS, что уменьшает сложность сетевых решений и снижает общую стоимость VPN при возможности построения многоуровневой защиты предоставляемых сервисов. Брандмауэр PIX Firewall является высокопроизводительным сетевым устройством, которое может обслуживать конечные точки туннелей, обеспечивая им высокую пропускную способность и прекрасные функциональные возможности брандмауэра. Программное обеспечение клиента CiscoSecure VPN поддерживает самые строгие требования VPN удаленного доступа для операций электронной коммерции, а также приложений мо¬бильного доступа, предлагая законченную реализацию стандартов IPSec и обеспечивая надежное взаимодействие маршрутизаторов Cisco и брандмауэров PIX Firewall.

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


IPSec опирается на ряд технологических решений и методов шифрования, но действие IPSec в общем можно представить в виде следующих главных шагов:
  • Шаг 1. Начало процесса IPSec. Трафик, которому требуется шифрование в соответствии с политикой защиты IPSec, согласованной сторонами IPSec, начинает IКЕ-процесс.
  • Шаг 2. Первая фаза IKE . IKE-процесс выполняет аутентификацию сторон IPSec и ведет переговоры о параметрах ассоциаций защиты IKE, в результате чего создается защищенный канал для ведения переговоров о параметрах ассоциаций защиты IPSec в ходе второй фазы IKE.
  • Шаг 3. Вторая фаза IKE . IKE-процесс ведет переговоры о параметрах ассоциации защиты IPSec и устанавливает соответствующие ассоциации защиты IPSec для устройств сообщающихся сторон.
  • Шаг 4. Передача данных . Происходит обмен данными между сообщающимися сторонами IPSec, который основывается на параметрах IPSec и ключах, хранимых в базе данных ассоциаций защиты.
  • Шаг 5. Завершение работы туннеля IPSec . Ассоциации защиты IPSec завершают свою работу либо в результате их удаления, либо по причине превышения предельного времени их существования.
В следующих разделах указанные шаги будут описаны подробнее.

IPsec (IP security) - набор протоколов для безопасной передачи трафика через IP сеть. Пожалуй, самый сложный и разветвленный стек протоколов из поддерживаемых системой VPNKI.

Включает в себя три основных протокола:

  • AH (Authentication Header) - управление целостностью передаваемых данных и аутентификацию
  • ESP (Encapsulating Security Payload) - шифрование данных
  • ISAKMP (Internet Security Association and Key Management Protocol) - управление установкой соединения, взаимную аутентификации конечными узлами друг друга и обмен секретными ключами

Основные используемые порты и номера протоколов

  • Протокол UDP, port 500 (IKE, управление ключами)
  • Протокол UDP, port 4500 (IPSEC NAT-Traversal mode)
  • Протокол ESP, значение 50 (for IPSEC)
  • Протокол AH, значение 51 (for IPSEC)

Вообще, набор протоколов IPsec непрост с точки зрения возможностей его использования, которые весьма многогранны. Однако, базовой особенностью всего взаимодействия по этому протоколу является понятие SA (Security Association) - это набор параметров о том как стороны будут в дальнейшем использовать те или иные свойства протоколов из состава IPsec.

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

Аутентификация

Взаимодействие двух узлов начинается с установления SA. Точнее с двух ассоциаций - для протокола AH и ESP причем в одну и в другую стороны. SA начинается с аутентификации и затем стороны согласовывают будущие параметры сессии:

  • для протокола AH - используемый алгоритм аутентификации, ключи, время жизни ключей и другие параметры,
  • для протокола ESP - алгоритмы шифрования и аутентификации, ключи, параметры инициализации, время жизни ключей и другие параметры.

Здесь же стороны договариваются о туннельном или транспортном режиме работы IPsec.

К завершению процесса у вас должны быть установлены несколько SA, но... чуть подробнее как это на самом деле.

Фаза 1 и Фаза 2

В IPsec все происходит по Фазам.

На фазе 1 происходит установление SA первой фазы. В первой фазе стороны договариваются о методе идентификации, алгоритме шифрования, алгоритме хэшировнаия и группе Diffie Hellman. Эта фаза может пройти путем обмена тремя нешифрованными пакетами (агрессивный режим) или шестью нешифрованными пакетами - стандартный режим. Если все прошло успешно, то создается SA фазы 1 под названием IKE SA и осуществляется переход ко второй фазе.

На фазе 2 стороны договариваются о политике и создаются сами ключи. Эта фаза, в отличии от первой полностью шифруется и она наступает только в случае успешного окончания первой фазы. В связи с тем, что трафик этой фазы полностью шифрован становится сложно осуществлять поиск неполадок, однако если все прошло успешно, то создается SA фазы 2 под названием IPSec SA. В этот момент можно сказать, что туннель установлен.

Компрессия данных

В составе IPsec нет собственного механизма компрессии данны, однако можно использовать механизм IPcomp который компрессирует содержимое IP пакета до его передачи в процесс IPsec. Некоторые демоны IPsec поддерживают включение этого механизма из файлов настроек ipsec.conf (например пакет Strongswan)

Автоматическая проверка работоспособности VPN соединения

Внутри IPsec нет штатного средства для проверки работоспособности соединения (типа ping), поэтому работу туннеля можно проверять внешними средствами.

Разрыв VPN соединения и смена ключей

Согласованные на двух фазах ключи должны работать оговоренное политикой время. Это означает, что сторонам возможно предстоит пережить процедуру смены ключей (rekeying), а иначе согласованные SA распадутся. Как было сказано выше, у сторон есть ключи в рамках процесса фазы 1 (IKE) и фазы 2 (IPsec). Процедуры их смены различны, как и таймеры, которые за это отвечают. Для того, чтобы не было перерыва связи в процессе смены ключей стороны сначала согласовывают параметры новой SA и лишь после этой успешной процедуры уничтожают старую SA.

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

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

    Шаг 1. Начало процесса IPSec . Трафик, которому требуется шифрование в соответствии с политикой защиты IPSec, согласованной сторонами IPSec, начинает IКЕ-процесс.

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

    Шаг 3. Вторая фаза IKE . IKE-процесс ведет переговоры о параметрах ассоциации защиты IPSec и устанавливает соответствующие ассоциации защиты IPSec для устройств сообщающихся сторон.

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

    Шаг 5. Завершение работы туннеля IPSec . Ассоциации защиты IPSec завершают свою работу либо в результате их удаления, либо по причине превышения предельного времени их существования.

Режимы работы ipSec

Существует два режима работы IPSec: транспортный и туннельный.

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

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

Согласование преобразований IPSec

В ходе работы протокола IKE ведутся переговоры о преобразованиях IPSec (алгоритмах защиты IPSec). Преобразования IPSec и связанные с ними алгоритмы шифрования являются следующими:

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

    Протокол ESP (Encapsulating Security Payload -- включающий защиту полезный груз). Протокол защиты, обеспечивающий конфиденциальность и защиту данных, а также (в качестве опции) сервис аутентификации и выявления воспроизведения. Поддерживающие IPSec продукты Cisco используют ESP для шифрования полезного груза IP-пакетов. Протокол ESP может использоваться самостоятельно или совместно с АН.

    Стандарт DES (Data Encription Standard -- стандарт шифрования данных). Алгоритм шифрования и дешифрования данных пакетов. Алгоритм DES используется как в рамках IPSec, так и IKE. Для алгоритма DES используется 56-битовый ключ, что означает не только более высокое потребление вычислительных ресурсов, но и более надежное шифрование. Алгоритм DES является симметричным алгоритмом шифрования, для которого требуются идентичные секретные ключи шифрования в устройствах каждой из сообщающихся сторон IPSec. Для создания симметричных ключей применяется алгоритм Диффи-Хеллмана. IKE и IPSec используют алгоритм DES для шифрования сообщений.

    "Тройной" DES (3DES). Вариант DES, основанный на использовании трех итераций стандартного DES с тремя разными ключами, что практически утраивает стойкость DES. Алгоритм 3DES используется в рамках IPSec для шифрования и дешифрования потока данных. Данный алгоритм использует 168-битовый ключ, что гарантирует высокую надежность шифрования. IKE и IPSec используют алгоритм 3DES для шифрования сообщений.

    AES (advanced encryption standard ). Протокол AES использует алгоритм шифрования Rine Dale4, который обеспечивает существенно более надежное шифрование. Многие криптографы считают, что AES вообще невозможно взломать. Сейчас AES яв­ляется федеральным стандартом обработки информации. Он определен как алгоритм шифрования для использования правительственными организациями США для защи­ты важных, но несекретных сведений. Проблема, связанная с AES, состоит в том, что для его реализации требуется большая вычислительная мощность по сравнению с аналогичными протоколами.

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

    Алгоритм MD5 (Message Digest 5). Алгоритм хэширования, применяемый для аутентификации пакетов данных. В продуктах Cisco используется вычисляемый с помощью MD5 код НМАС (Hashed Message Authentication Code -- хэшированный код аутентичности сообщения)- вариант кода аутентичности сообщения, которому обеспечивается дополнительная защита с помощью хэширования. Хэширование представляет собой процесс одностороннего (т.е. необратимого) шифрования, в результате которого для поступающего на вход сообщения произвольной длины получается вывод фиксированной длины. IKE, АН и ESP используют MD5 для аутентификации данных.

    Алгоритм SHA-1 (Secure Hash Algorithm-1 -- защищенный алгоритм хэширования 1). Алгоритм хэширования, используемый для аутентификации пакетов данных. В продуктах Cisco применяется вариант кода НМАС, вычисляемый с помощью SHA-1. IKЕ, АН и ESP используют SHA-1 для аутентификации данных.

В рамках протокола IKE симметричные ключи создаются с помощью алгоритма Диффи-Хеллмана, использующего DES, 3DES, MD5 и SHA. Протокол Диффи-Хеллмана является криптографическим протоколом, основанным на применении открытых ключей. Он позволяет двум сторонам согласовать общий секретный ключ, не имея достаточно надежного канала связи. Общие секретные ключи требуются для алгоритмов DES и НМАС. Алгоритм Диффи-Хеллмана используется в рамках IKE для создания сеансовых ключей. Группы Diffie-Hellman (DH) – определяют «силу» ключа шифрования, который используется в процедуре обмена ключами. Чем выше номер группы, тем «сильнее» и безопаснее ключ. Однако следует учитывать тот факт, что при увеличении номер группы DH увеличивается «сила» и уровень безопасности ключа, однако одновременно увеличивается нагрузка на центральный процессор, так как для генерации более «сильного» ключа необходимо больше времени и ресурсов.

Устройства WatchGuard поддерживают DH группы 1, 2 и 5:

    DH group 1: 768-bit key

    DH group 2: 1024-bit key

    DH group 5: 1536-bit key

Оба устройства, которые обмениваются данными через VPN должны использовать одну и ту же группу DH. Группа DH, которая будет использоваться устройствами, выбирается во время IPSec Phase 1 процедуры.

    pre-shared key : Два даемона racoon подключаются друг к другу, подтверждают, что они именно те, за кого себя выдают (используя секретный ключ, заданный вами, по умолчанию в файле /etc/racoon/psk.txt). Затем даемоны генерируют новый секретный ключ и используют его для шифрования трафика через VPN. Они периодически изменяют этот ключ, так что даже если атакующий сломает один из ключей (что теоретически почти невозможно) это не даст ему слишком много – он сломал ключ, который два даемона уже сменили на другой. Предварительный ключ(pre-shared key) не используется для шифрования трафика через VPN соединение это просто маркер, позволяющий управляющим ключами даемонам доверять друг другу. Права на файл psk.txt должны быть 0600 (т.е. запись и чтение только для root).

    IPsec состоит из двух протоколов:

    Encapsulated Security Payload (ESP), защищающей данные IP пакета от вмешательства третьей стороны путем шифрования содержимого с помощью симметричных криптографических алгоритмов (таких как Blowfish,3DES, AES).

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

ESP и AH могут быть использованы вместе или по отдельности, в зависимости от обстоятельств.

esp и ah - пакеты ipsec, формируются ядром после того как хосты, при помощи racoon, договорятся о ключе по протоколу isakmp (500/udp).

Режимы работы IPsec(транспортный, туннельный)

Существует два режима работы IPsec: транспортный режим и туннельный режим(когда в транспортном режиме работают только маршрутизаторы).

IPsec может быть использован или для непосредственного шифрования трафика между двумя хостами (транспортный режим); или для построения "виртуальных туннелей" между двумя подсетями, которые могут быть использованы для защиты соединений между двумя корпоративными сетями (туннельный режим). Туннельный режим обычно называют виртуальной частной сетью (Virtual Private Network, Что это такое VPN).

В транспортном режиме шифруется (или подписывается) только информативная часть IP-пакета. Маршрутизация не затрагивается, так как заголовок IP пакета не изменяется (не шифруется). Транспортный режим как правило используется для установления соединения между хостами. Он может также использоваться между шлюзами, для защиты туннелей, организованных каким-нибудь другим способом (IP tunnel, GRE туннели и др.).

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

Если используется IPsec совместно с GRE туннели , который инкапсулирует исходный пакет и добавляет новый IP заголовок, логично использовать транспортный режим.

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

Security Associations (SA) . Для возможности проводить инкапсуляцию/декапсуляцию стороны участвующие в процессе обмена должны иметь возможность хранить секретные ключи, алгоритмы и IP адреса. Вся эта информация хранится в Ассоциациях Безопасности (SA), SA в свою очередь хранятся в Базе данных Ассоциаций Безопасности (SAD). Конфигурирование Security Association , позволяет задать например mode transport | tunnel | ro | in_trigger | beet - режим безопасной ассоциации. Соответственно, может принимать одно из значений, означающих транспортный, тоннельный, beet (Bound End-to-End Tunnel), оптимизации маршрута (route optimization) или in_trigger режимы. (последние два используются в контексте mobile ipv6).

Security Policy (SP) - политика безопасности, хранится в SPD (База данных политик безопасности). SA специфицирует, как IPsec предполагает защищать трафик, SPD в свою очередь хранит дополнительную информацию, необходимую для определения какой именно трафик защищать и когда. SPD может указать для пакета данных одно из трёх действий: отбросить пакет, не обрабатывать пакет с помощью IPSec, обработать пакет с помощью IPSec. В последнем случае SPD также указывает, какой SA необходимо использовать (если, конечно, подходящий SA уже был создан) или указывает, с какими параметрами должен быть создан новый SA. SPD является очень гибким механизмом управления, который допускает очень хорошее управление обработкой каждого пакета. Пакеты классифицируются по большому числу полей, и SPD может проверять некоторые или все поля для того, чтобы определить соответствующее действие. Это может привести к тому, что весь трафик между двумя машинами будет передаваться при помощи одного SA, либо отдельные SA будут использоваться для каждого приложения, или даже для каждого TCP соединения.

IPSec (сеть-сеть) между серверами FreeBSD

    Шаг 1 : Создание и тестирование "виртуального" сетевого подключения.

    • Настройте оба ядра с device gif . В версии FreeBSD поддержка gif включена в ядро.

      Отредактируйте /etc/rc.conf на маршрутизаторах и добавьте следующие строки (подставляя IP адреса где необходимо). A.B.C.D - реальный IP первого маршрутизатора, W.X.Y.Z - реальный IP второго маршрутизатора. # IPsec №1 gateway > ee /etc/rc.conf ... # IPsec to S through ISP_V gif_interfaces="gif0" # gifconfig_gif0="local-ip(A.B.C.D) remote-ip (W.X.Y.Z)" gifconfig_gif0="194.x.x.x 91.x.x.x" ifconfig_gif0="inet 10.26.95.254 192.168.1.254 netmask 255.255.255.255" static_routes="vpn vpn1" route_vpn="-net 192.168.1.0/24 192.168.1.254" route_vpn1="-net 192.168.35.0/24 192.168.1.254" # IPsec №2 gateway > ee /etc/rc.conf ... # IPsec na G through ISPGate gif_interfaces="gif0" # gifconfig_gif0="W.X.Y.Z A.B.C.D" gifconfig_gif0="91.x.x.x 194.x.x.x" ifconfig_gif0="inet 192.168.1.254 10.26.95.254 netmask 255.255.255.255" static_routes="vpn" route_vpn="-net 10.26.95.0/24 10.26.95.254"

      Отредактируйте скрипт брандмауэра на обеих маршрутизаторах и добавьте # IPFW ipfw add 1 allow ip from any to any via gif0 # PF set skip on gif0

Теперь ping должны ходить между сетями.

    Защита соединения с помощью IPsec

    Шаг 2 : Защита соединения с помощью IPsec

    • Настройте оба ядра: > sysctl -a | grep ipsec

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

      # IPSEC for FreeBSD 7.0 and above options IPSEC options IPSEC_FILTERTUNNEL device crypto # IPSEC for FreeBSD 6.3 options IPSEC # IP security options IPSEC_ESP # IP security (crypto; define w/ IPSEC) options IPSEC_DEBUG # Необязательно. debug for IP security

      Устанавливаем порт ipsec-tools. > cd /usr/ports/security/ipsec-tools > make config > make install clean > ee /etc/rc.conf racoon_enable="YES" ipsec_enable="YES" > mkdir -p /usr/local/etc/racoon/cert > cp /usr/local/share/examples/ipsec-tools/racoon.conf /usr/local/etc/racoon/racoon.conf > cd /usr/local/etc/racoon/cert/

      Создаем SSL сертификаты на каждом хосте. Копируем с одной на другую файлики *.public. В принципе, имена ключей неважны, можно называть и по IP, с соответствующими расширениями.

      > openssl req -new -nodes -newkey rsa:1024 -sha1 -keyform PEM -keyout your.key1.private -outform PEM -out your.key1.pem > openssl x509 -req -in your.key1.pem -signkey your.key.private -out your.key1.public

    Создаем файл ipsec.conf. Настройка на шлюзе #1 (где есть публичный IP адрес A.B.C.D) для включения шифрования всего предназначенного W.X.Y.Z трафика. A.B.C.D/32 и W.X.Y.Z/32 это IP адреса и сетевые маски, определяющие сети или хосты, к которым будет применяться данная политика. В данном случае мы хотим применить их к трафику между этими двумя хостами. Параметр ipencap сообщает ядру, что эта политика должна применяться только к пакетам, инкапсулирующим другие пакеты. Параметр -P out сообщает, что эта политика применяется к исходящим пакетам, и ipsec – то, что пакеты будут зашифрованы.

Оставшаяся часть строки определяет, как эти пакеты будут зашифрованы. Будет использоваться протокол esp, а параметр tunnel показывает, что пакет в дальнейшем будет инкапсулирован в IPsec пакет. Повторное использование A.B.C.D и W.X.Y.Z предназначено для выбора используемых параметров безопасности, и наконец параметр require разрешает шифрование пакетов, попадающих под это правило.

Это правило соответствует только исходящим пакетам. Вам потребуется похожее правило, соответствующее входящим пакетам.

> ee /etc/ipsec.conf spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P out ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require; spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P in ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require;

Настройка на шлюзе #2 аналогична только меняются IP местами.

Настройка утилиты racoon

> ee /usr/local/etc/racoon/racoon.conf path include "/usr/local/etc/racoon"; path certificate "/usr/local/etc/racoon/cert/"; # following line activates logging & should deactivated later log debug; # если директива listen не задана, racoon слушает все доступные # адреса интерфейсов. listen { #isakmp::1 ; isakmp 202.249.11.124 ; #admin ; # administrative port for racoonctl. #strict_address; # requires that all addresses must be bound. } # описываем удалённый хост (на второй машине - идентично, # тока другой IP и ключи) remote 217.15.62.200 { exchange_mode aggressive,main; my_identifier asn1dn; peers_identifier asn1dn; # сертификаты этой машины certificate_type x509 "via.epia.public" "via.epia.private"; # сертификат удлённой машины peers_certfile x509 "test.su.public"; proposal { encryption_algorithm 3des; hash_algorithm sha1; authentication_method rsasig; dh_group 2 ; } } sainfo anonymous { pfs_group 2; encryption_algorithm 3des; authentication_algorithm hmac_sha1; compression_algorithm deflate; }

    Настройка пакетного фильтра PF, где esp_peers шлюз с которым создается шифрованный туннель. Разрешаем прохождение пакетов ESP и IPENCAP в обе стороны.

#pass IPSec pass in on $ext_if_a inet proto udp from { $esp_peers } to ($ext_if_a) port isakmp pass in on $ext_if_a inet proto esp from { $esp_peers } to ($ext_if_a) # pass out on $ext_if_a inet proto udp from { $esp_peers } to ($ext_if_a) port isakmp pass out on $ext_if_a inet proto esp from { $esp_peers } to ($ext_if_a)

Cмотрим логи /var/log/security и /var/log/messages.

Как только параметры безопасности установлены, вы можете просмотреть их используя setkey(8). Запустите

> /etc/rc.d/ipsec start > /usr/local/etc/rc.d/racoon start > setkey -D # список созданных защищенных каналов > setkey -DP # покажет список политик безопасности

на любом из хостов для просмотра информации о параметрах безопасности.

    Проверка работоспособности:

    ping между сетями должен работать

    Запускаем для прослушки физического интерфейса на котором построен туннель (а не виртуального gif0). В другом окне например ping -ем удаленную серую сеть (например, ping 192.168.1.11) tcpdump -i em0 -n host 91 .x.x.81 ... 16 :15 :54.419117 IP x.x.x.x >

tcpdump Linux примеры использования должен показывать ESP пакеты.

IPSec (сеть-сеть) между серверами Linux

# aptitude install ipsec-tools racoon

    Алгоритм настройки IPsec

    Настройка пакета racoon

    Создание политики безопасности

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

Ниже приведены конфиги для случая с предопределёнными ключами.

> nano /etc/racoon/racoon.conf path include "/etc/racoon"; path pre_shared_key "/etc/racoon/psk.txt"; #path certificate "/etc/racoon/certs"; remote 10.5.21.23 { exchange_mode aggressive,main; doi ipsec_doi; situation identity_only; my_identifier address; #Определяет метод идентификации, который будет использоваться при проверке подлинности узлов. lifetime time 2 min; initial_contact on; proposal { encryption_algorithm 3des; hash_algorithm sha1; authentication_method pre_shared_key; # Определяет метод проверки подлинности, используемый при согласовании узлов. dh_group 2; } proposal_check strict; } sainfo anonymous # Отмечает, что SA может автоматически инициализировать соединение с любым партнёром при совпадении учётных сведений IPsec. { pfs_group 2; lifetime time 2 min ; encryption_algorithm 3des, blowfish 448, des, rijndael ; authentication_algorithm hmac_sha1, hmac_md5 ; compression_algorithm deflate ; }

Создадим политику безопасности

> nano pol.cfg #!/sbin/setkey -f flush; spdflush; spdadd 10.5.21.24 10.5.21.23 any -P out ipsec esp/transport//require; spdadd 10.5.21.23 10.5.21.24 any -P in ipsec esp/transport//require; > chmod +x pol.cfg > ./pol.cfg

Создадим выполняемый файл для создания интерфейсов и запустим его.

>nano tun.sh #!/bin/sh ip tunnel del tun0 ip tunnel add tun0 mode ipip remote 10.5.21.23 local 10.5.21.24 dev eth0 # создаем интерфейс tun0 и устанавливаем туннель # между хостами (здесь нужно использовать реальные IP адреса сетевых интерфейсов). ifconfig tun0 10.0.9.1 pointopoint 10.0.9.2 # назначаем интерфейсу IP адреса, для текущего хоста и для другого конца # туннеля (не обязательно). ifconfig tun0 mtu 1472 ifconfig tun0 up # ниже можно прописать нужные нам маршруты, например так route add -net ... netmask 255.255.255.0 gw ... route add -net ... netmask 255.255.255.0 gw ... > ./tun.sh

Для автоматической загрузки правил файл tun.sh правильно поместить для Debian в директорию /etc/network/if-up.d

Все IPSec тунель между сетями настроен.

iptables IPSec

$IPT -A INPUT -p udp -m udp -s xxx.xxx.xxx.xxx -d xxx.xxx.xxx.xx --dport 500 -j ACCEPT $IPT -A INPUT -p esp -j ACCEPT $IPT -A INPUT -p ah -j ACCEPT $IPT -A INPUT -p ipencap -j ACCEPT $IPT -A INPUT -p udp -m udp -s xxx.xxx.xxx.xxx -d xxx.xxx.xxx.xx --dport 4500 -j ACCEPT

IPsec «узел-узел» без виртуальных интерфесов

Задача . При помощи IPSec (pre_shared_key) соединить два сервера (Debian 5 и Debian 7). У обоих реальные IP. Никаких сетей пробрасывать не надо. Должен шифроваться трафик между этими IP. То есть строим транспортный режим (между двумя хостами).

Настройка сводится к двум пунктам

    Настройка пакета racoon

    Создание политики безопасности: нужно указать режим transport и any spdadd x.x.x.x/32 y.y.y.y/32 any -P out ipsec esp/transport//require; spdadd y.y.y.y/32 x.x.x.x/32 any -P in ipsec esp/transport//require;

IPSec (GRE) (узел-сеть) между Debian и Cisco

Задача: построить IPsec в туннельном режиме. Описание RFC протокола SIP сигнализация между поставщиком (Cisco) и клиентом (Debian 5) шифруется IPsec, а RTP минуя туннель идет кратчайшим маршрутом через обычный Интернет.

    Клиент tunnel-endpoint is: 193.xxx.xxx.xxx

    Сервер tunnel-endpoint is: 62.xxx.xxx.xxx

    Клиент Sip Server is: 193.xxx.xxx.xxx

    Сервер SIP Servers are: 62.xxx.237.xxx/26 and 62.xxx.246.xxx/26

да и перед настрокой туннеля (перед auto tun0) прописать pre-up modprobe ip_gre

# modprobe ip_gre

Скрипт для создания GRE туннели туннеля в Debian:

#!/bin/sh -e modprobe ip_gre #ip tunnel del tun0 ip tunnel add tun0 mode gre remote 62.xxx.xxx.xxx local 193.xxx.xxx.xxx dev eth0 ifconfig tun0 mtu 1472 ifconfig tun0 up route add -net 62.xxx.237.xxx netmask 255.255.255.192 dev tun0 route add -net 62.xxx.246.xxx netmask 255.255.255.192 dev tun0

Утилиты

    Для управления можно использовать утилиту racoonctl racoonctl show-sa esp

    Cписок созданных защищенных каналов > setkey -D

    список политик безопасности > setkey -DP

Мониторинг IPsec

Мониторинг IPsec в Debian 5.0 2.6.26-2-686-bigmem i686. В уровень детализации логов log notify или log debug устанавливается в файле racoon.conf.

# tail -F /var/log/syslog | grep racoon

IPSec Openswan

OpenSWAN начал разрабатываться как форк прекратившего в настоящее своё существование проекта FreeS/WAN (Free Secure Wide-Area Networking), релизы продолжают выпускаться под свободной GNU General Public License. В отличие от проекта FreeS/WAN, OpenSWAN разрабатывается не только специально под операционную систему GNU/Linux. OpenSWAN обеспечивает стек протоколов IpSec: AH и ESP для ядра Linux,а также инструментарий для управления ими.

OpenSWAN для ветки ядра 2.6 предоставляет встроенную, NETKEY реализацию IpSec, так и собственную KLIPS.

CentOS 6.6 поддерживает только Openswan в основных пакетах.

Задача . Создать шифрованный туннель между CentOS 6.6 и Debian 7.8 Wheezy. GRE туннели + Openswan (type=transport)

    Openswan будет шифровать наш трафик в транспортном режиме(host-to-host), не вмешиваясь в маршрутизацию. Установим пакеты на обоих серверах yum install openswan aptitude install openswan

    На обоих концах туннеля настраиваем Правила iptables . Открыть 500 порт, по которому идет обмен сертификатам и ключами. iptables -A INPUT -p udp --dport 500 -j ACCEPT iptables -A INPUT -p tcp --dport 4500 -j ACCEPT iptables -A INPUT -p udp --dport 4500 -j ACCEPT # Более строго выпишем правила для IPSec IPT ="/sbin/iptables" $IPT -A INPUT -p udp -s x.x.x.x -d x.x.x.x --dport 500 -m comment --comment "IpSec" -j ACCEPT $IPT -A INPUT -p tcp -s x.x.x.x -d x.x.x.x --dport 4500 -m comment --comment "IpSec" -j ACCEPT $IPT -A INPUT -p udp -s x.x.x.x -d x.x.x.x --dport 4500 -m comment --comment "IpSec" -j ACCEPT

    Подготовка конфигурационных файлов. Используемые файлы и директории / etc/ ipsec.d/ / etc/ ipsec.conf

    Проверка системы на правильность окружения для IPsec ipsec verify

    Добавить в конец файла sysctl.conf

    # IPSec Verify Compliant # Разрешить пересылку пакетов между интерфейсами для IPv4 net.ipv4.ip_forward = 1 # отключаем icmp redirect net.ipv4.conf.all.send_redirects = 0 net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.default.send_redirects = 0 net.ipv4.conf.default.accept_redirects = 0

    Применим параметры ядра без перезагрузки

    Первым конфигурационным файлом является /etc/ipsec.conf. Задаем явно в разделе config setup config setup protostack =netkey plutoopts ="--perpeerlog" dumpdir =/ var/ run/ pluto/ nat_traversal =yes virtual_private =% v4:10.0.0.0/ 8 ,% v4:192.168.0.0/ 16 , % v4:172.16.0.0/ 12 ,% v4:25.0.0.0/ 8 ,% v6:fd00::/ 8 ,% v6:fe80::/ 10 oe =off #plutostderrlog=/dev/null

    В первую очередь вам необходимо сформировать ключи, используемые шлюзами для аутентификации. В Debian это ключ можно создать при инсталляции. Запускаем на обеих системах ipsec newhostkey, генерируя нужные нам ключи. ipsec newhostkey --output / etc/ ipsec.secrets ipsec showhostkey --left ipsec showhostkey --right

    Независимо от того, как вы сконфигурируете сервер, всегда рассматривайте вашу подсеть как расположенную «слева» (left), а подсеть, к которой доступ осуществляется дистанционно, сайт, как расположенный «справа» (right). Следующая конфигурация выполняется на сервере VPN на стороне Left. На другом сервере должен быть точно такие настройки для этого соединения. conn gagahost-to-miraxhost auto =start left =188 .x.x.x leftrsasigkey =0sN4vI6ooUyMyL ... right =91 .x.x.x rightrsasigkey =0sfAhuo4SQ0Qt ... type =transport scp / etc/ ipsec.conf admin@ 192.168.35.254:/ home/ admin/

Диагностика IPSec Openswan

Запуск сервиса и поиск возникающих проблем.

Openwan logs (pluto) : /var/log/auth.log /var/log/syslog /var/log/pluto/peer/a/b/c/d/a.b.c.d.log

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

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

# ip route via dev eth0 src default via dev eth0

    Команды проверки состояний соединений: ipsec verify service ipsec status ip xfrm state list - управления SAD, возможности шире, чем у setkey ipsec addconn --checkconfig - проверка конфигурации ipsec auto --status - подробное состояние ip xfrm monitor

    Политики ipsec, согласно которым принимается решение какой трафик направлять в туннель ip xfrm pol show

    tcpdump Linux примеры использования запускаем для прослушки физического интерфейса на котором построен туннель (а не виртуального GRE). В другом окне например ping -ем удаленную серую сеть (например, ping 192.168.1.11). tcpdump должен показывать ESP пакеты. tcpdump -i em0 -n host 91 .x.x.81 ... 16 :15 :54.419117 IP x.x.x.x > 91 .x.x.81: ESP(spi =0x01540fdd,seq =0xa20) , length 92 ...

Ссылки

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

Введение

VPN основанный на технологии IPsec можно разделить на две части:

  • Протокол Internet Key Exchange (IKE)
  • Протоколы IPsec (AH/ESP/both)

Первая часть (IKE) является фазой согласования, во время которой две VPN-точки выбирают какие методы будут использоваться для защиты IP трафика посылаемого между ними. Помимо этого IKE также используется для управления соединениями, для этого вводится понятие Security Associations (SA) для каждого соединения. SA направлены только в одну сторону, поэтому типичное IPsec соединение использует два SA.

Вторая часть – это те IP данные, которые необходимо зашифровать и аутентифицировать перед передачей методами, согласованными в первой части (IKE). Существуют разные протоколы IPsec, которые могут быть использованы: AH, ESP или оба.

Последовательность установления VPN через IPsec можно кратко описать как:

  • IKE согласовывает защиту уровня IKE
  • IKE согласовывает защиту уровня IPsec
  • защищаемые данные передаются через VPN IPsec

IKE, Internet Key Exchange

Для шифрования и аутентификации данных требуется выбрать способ шифрования/аутентификации (алгоритм) и ключи используемые в них. Задача Internet Key Exchange protocol, IKE, в этом случае сводится к распространению данных “ключей сессии” и согласованию алгоритмов, которыми будут защищаться данные между VPN-точками.

Основные задачи IKE:

  • Аутентификация VPN-точек друг друга
  • Организация новых IPsec соединений (через создание SA пар)
  • Управление текущими соединениями

IKE ведет учет соединений путем назначения каждому из них некого Security Associations, SA. SA описывает параметры конкретного соединения, включая IPsec протокол (AH/ESP или оба), ключи сессии, используемые для шифрования/дешифрования и/или аутентификации данных. SA является однонаправленной, поэтому используется несколько SA на одно соединение. В большинстве случаев, когда используется только ESP или AH, создаются только две SA для каждого из подключений, одна для входящего трафика, а вторая для исходящего. Когда ESP и AH используются вместе, SA требуется четыре.

Процесс согласования IKE проходит через несколько этапов (фаз). Данные фазы включают:

  1. IKE первой фазы (IKE Phase-1):
    — Согласовывается защита самого IKE (ISAKMP tunnel)
  2. IKE второй фазы (IKE Phase-2):
    — Согласовывается защита IPsec
    — Получение данных из первой фазы для формирования ключей сессии

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

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

IKE первой фазы – согласование защиты IKE (ISAKMP Tunnel)
На первой фазе согласования VPN-точки аутентифицируют друг друга на основе общего ключа (Pre-Shared Key). Для аутентификации используются хэш алгоритм: MD5, SHA-1, SHA-2.
Однако перед тем как аутентифицировать друг друга, чтобы не передавать информацию открытым текстом, VPN-точки выполняют обмен списками предложений (Proposals), описанный ранее. Только после того как устраивающее обеих VPN-точек предложение выбрано, происходит аутентификация VPN-точка друг друга.
Аутентификацию можно осуществлять разными способами: через общие ключи (Pre-Shared Keys), сертификаты или . Общие ключи являются наиболее распространенным способом аутентификации.
Согласование IKE первой фазы может происходить в одном из двух режимов: main (основной) и aggressive (агресивный). Основной режим более длительный, но зато и более защищенный. В его процесее происходит обмен шестью сообщениями. Агресивный режим происходит быстрее, ограничиваясь тремя сообщениями.
Основная работа первой фазы IKE лежит в обмене ключами Диффи-Хеллмана. Он основан на шифровании с открытым ключем, каждая из сторон шифрует аутентификационный параметр (Pre-Shared Key) открытым ключем соседа, который получив данное сообщение расшифровывает его своим закрытым ключем. Другой способо аутентификации сторон друг друга — использование сертификатов.

IKE второй фазы – согласование защиты IPsec
Во второй фазе осуществляется выбор способа защиты IPsec подключения.
Для работы второй фазы используется материал (keying material) извлеченный из обмена ключами Диффи-Хеллмана (Diffie-Hellman key exchange), произошедшего на первой фазе. На основе этого материала создаются ключи сессии (session keys), использующиеся для защиты данных в VPN-туннеле.

Если используется механизм Perfect Forwarding Secrecy (PFS) , то для каждого согласования второй фазы будет использоваться новый обмен ключами Диффи-Хеллмана. Несколько снижая скорость работы, данная процедура гарантирует, что ключи сессии не зависимы друг от друга, что повышает защиту, поскольку даже если произойдет компромат одного из ключей, он не сможет быть использован для подбора остальных.

Режим работы второй фазы согласования IKE только один, он называется quick mode — быстрый режим. В процессе согласования второй фазы происходит обмен тремя сообщениями.

По окончании второй фазы, устанавливается VPN-подключение.

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

  • Идентификация конечных узлов
    Каким образом узлы аутентифицируют друг друга. Наиболее часто используется общий ключ. Аутентификация основанная на общем ключе использует алгоритм Диффи-Хеллмана.
  • Локальная и удаленная сеть/хост
    Определяет трафик, который будет пускаться через VPN-туннель.
  • Режим туннеля или транспорта.
    IPsec может работать в двух режимах: туннельном и транспортном. Выбор режима зависит от защищаемых объектов.
    Туннельный режим применяется для защиты между удаленными объектами, т.е. IP-пакет полностью инкапсулируется в новый и для наблюдателя со стороны будет видно только соединение между двумя VPN-точками. Реальные IP-адреса источника и получателя будут видны только после декапсуляции пакета при приеме его на VPN-точке получения. Таким образом туннельный режим чаще всего используется для VPN-подключений.
    Транспортный режим защищает данные IP-пакета (TCP, UDP и протоколы верхних уровней), а сам заголовок оригинального IP-пакета будет сохранен. Таким образом для наблюдателя будет виден оригинальный источник и назначение, но не передаваемые данные. Данный режим наиболее часто используется при защите соединение в локальной сети между хостами.
  • Удаленный шлюз
    VPN-точка получатель защищенного соединения, которая будет расшифровывать/аутентифицировать данные с другой стороны и отправлять их к окончательному месту назначения.
  • Режим работы IKE
    IKE согласование может работать в двух режимах: основной и агрессивном .
    Разница между ними заключается в том, что в агрессивном режиме используется меньшее кол-во пакетом, что позволяет достичь более быстрого установления соединения. С другой стороны агрессивный режим не передает некоторые параметры согласования, такие как Диффи-Хеллман группы и PFS, что требует предварительной идентичной настройки их на точках участницах подключения.
  • IPsec протоколы
    Существует два протокола IPsec: Authentication Header (AH) и Encapsulating Security Payload (ESP), которые выполняют функции шифрования и аутентификации.
    ESP позволяет шифровать, аутентифицировать по отдельности или одновременно.
    AH позволяет только аутентифицировать. Разница с ESP аутентификацией в том, что AH аутентифицирует также и внешний IP заголовок, позволяя подтвердить, что пакет прибыл действительно от источника указанного в нем.
  • IKE шифрование
    Указывает используемый алгоритм шифрования IKE и его ключи. Поддерживаются разные симметричные алгоритмы шифрования, например: DES, 3DES, AES.
  • IKE аутентификация
    Алгоритм аутентификации используемый в IKE согласовании. Могут быть: SHA, MD5.
  • IKE Диффи-Хеллмана (DH) группы
    Используемая DF группа для обмена ключами в IKE. Чем больше группа тем больше размер ключей обмена.
  • Продолжительность жизни IKE подключения
    Указывается как по времени (секундах), так и по размеру переданных данных (килобайтах). Как только один из счетчиков достигнет порогового значения запускается новая первая фаза. Если с момента создания IKE соединения не было передано никаких данных, никаких новых подключений не будет создано до тех пор, пока одна из сторон не захочет создать VPN соединение.
  • PFS
    При отключенном PFS материал для создания ключей будет извлечен в первой фазе согласования IKE в момент обмена ключей. Во второй фазе согласования IKE ключи сессии будут созданы основываясь на полученном материале. При включенном PFS при создании новых ключей сессии материал для них будет использоваться каждый раз новый. Таким образом при компромате ключа, на основе него не возможно создать новые ключи.
    PFS может быть использован в двух режимах: первый PFS на ключах (PFS on keys), будет запускать новый обмен ключами в первой фазе IKE каждый раз, когда запускается согласование
    второй фазы. Второй режим PFS на идентификаторах (PFS on identities), будет удалять SA первой фазы каждый раз, после прохождения согласования второй фазы, гарантируя тем самым, что ни одно согласование второй фазы не будет зашифровано идентичным предыдущему ключом.
  • IPsec DH группы
    Данные DF группы аналогичны использующимся в IKE, только используются для PFS.
  • IPsec шифрование
    Алгоритм использующийся для шифрования данных. Используется в случае использования ESP в режиме шифрования. Пример алгоритмов: DES, 3DES, AES.
  • IPsec аутентификация
    Алгоритм используемый для аутентификации передаваемых данных. Используется в случае AH или ESP в режиме аутентификации. Пример алгоритмов: SHA, MD5.
  • Время жизни IPsec
    Время жизни VPN соединения указывается как по времени (секундах) так и по размеру переданных данных (килобайты). Счетчик первым достигнувший лимита запустит пересоздание ключей сессии. Если с момента создания IKE соединения не было передано никаких данных, никаких новых подключений не будет создано до тех пор, пока одна из сторон не захочет создать VPN соединение.

Методы аутентификации IKE

  • Ручной режим
    Самый простой из методов, при котором IKE не используется, а ключи аутентификации и шифрования, а также некоторые другие параметры задаются в ручную на обоих точках VPN подключения.
  • Через общие ключи (Pre-Shared Keys, PSK)
    Заранее введенный общий ключ на обоих точках VPN соединения. Отличие от предыдущего метода в том, что используется IKE, что позволяет аутентифицировать конечные точки и использовать меняющиеся ключи сессии, вместо фиксированных ключей шифрования.
  • Сертификаты
    Каждая точка VPN использует: свой приватный ключ, свой открытый ключ, свой сертификат включающий свой открытый ключ и подписанный доверенным центром сертификации. В отличие от предыдущего метода позволяет избежать ввода одного общего ключа на всех точках VPN соединения, заменяя его личными сертификатами, подписанными доверенным центром.

Протоколы IPsec

IPsec протоколы используются для защиты передаваемых данных. Выбор протокола и его ключей происходит при согласовании IKE.

AH (Authentication Header)

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

В режиме транспорта, AH встраивает свой заголовок после оригинального IP пакета.
В режиме туннеля AH встраивает свой заголовок после внешнего (нового) IP-заголовка и перед внутренним (оригинальным) IP заголовком.

ESP (Encapsulating Security Payload)

ESP протокол используется для шифрования, для аутентификации или и того, и другого по отношению к IP пакету.

В режиме транспорта ESP протокол вставляет свой заголовок после оригинально IP заголовка.
В режиме туннеля ESP заголовок находится после внешнего (нового) IP заголовка и перед внутренним (оригинальным).

Два основных различия между ESP и AH:

  • ESP помимо аутентификации предоставляет еще возможность шифрования (AH этого не предоставляет)
  • ESP в режиме туннеля аутентифицирует только оригинальный IP заголовок (AH аутентифицирует также внешний).

Работа за NAT (NAT Traversal)
Для поддержки работы за NAT была реализована отдельная спецификация. Если VPN-точка поддерживает данную спецификацию, IPsec поддерживает работу за NAT, однако существуют определённые требования.
Поддержка NAT состоит из двух частей:

  • На уровне IKE конечные устройства обмениваются друг с другом информацией о поддержке, NAT Traversal и версией поддерживаемой спецификации
  • На уровне ESP сформированный пакет инкапсулируется в UDP.

NAT Traversal используется только в том случае, если обе точки поддерживают его.
Определение NAT : обе VPN-точки посылают хеши своих IP адресов вместе с UDP портом источника IKE согласования. Данная информация используется получателем, для того чтобы определить был ли изменен IP адрес и/или порт источника. Если данные параметры не были изменены, то трафик не проходит через NAT и механизм NAT Traversal не нужен. Если адрес или порт были изменены, значит между устройствами находится NAT.

Как только конечные точки определят, что необходим NAT Traversal, согласование IKE перемещаются с порта UDP 500 на порт 4500. Делается это потому, что некоторые устройства некорректно обрабатывают IKE сессию на 500 порту при использовании NAT.
Другая проблема возникает из-за того, что ESP протокол – протокол транспортного уровня и располагается непосредственно поверх IP. Из-за этого к нему не применимы понятия TCP/UDP порта, что делает невозможным подключение через NAT более одного клиента к одному шлюзу. Для решения данной проблемы ESP запаковывается в UDP дейтаграмму и посылается на порт 4500, тот же самый, который использует IKE при включенном NAT Traversal.
NAT Traversal встроен в работу протоколов, его поддерживающих и работает без предварительной настройки.