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

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

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

Реализация IPsec в NSG Linux 2.0 основана на пакете OpenSWAN и включает в себя как встроенный стек IPsec в ядре Linux 2.6 и старше, так и его более раннюю реализацию KLIPS из пакета FreeS/WAN. Оба варианта соответствуют всем стандартам (IETF RFC), относящимся к IPsec, и совместимы как с открытыми Linux-системами, так и с проприетарными продуктами различных производителей.

ПРИМЕЧАНИЕ. Следует отметить, что, несмотря на детальную стандартизацию IPsec, далеко не все существующие реализации полностью совместимы друг с другом. И чем более подробные стандарты и спецификации пишутся — тем больше в них деталей, которые допускают неоднозначное толкование. Кроме того, эти стандарты не определяют некоторые смежные вопросы функционирования устройства. Различные разработчики могут — и, естественно, будут! — интерпретировать эти моменты по-разному. Такова жизнь, увы...

Процедура установления безопасных туннелей IPsec состоит из двух этапов:

1. Создание безопасной ассоциации (Securty Association, SA) — Main Mode. На этом этапе два хоста, пытающиеся установить туннель, должны идентифицировать и аутентифицировать друг друга. Ассоциация характеризуется списком хостов, входящих в неё, способом аутентификации (PSK, RSA-секрет, или сертификаты X.509) и, соответственно, реквизитами для этой аутентификации. Кроме того, для SA может быть установлено ограниченное время существования, по истечении которого она должна быть создана заново.
2. Установление туннеля в рамках существующей ассоциации — Quick Mode. Выполняется после того, как два VPN-шлюза признали друг друга членами одной безопасной ассоциации. Туннель характеризуется следующими основными настройками:
   • Описание трафика, направляемого в туннель (де-факто при этом также создаётся маршрут в удалённую приватную сеть).
   • Алгоритм(ы) защиты и аутентификации (контроля целостности) передаваемого трафика.
   • Публичные адреса обеих сторон, маршруты и другие реквизиты туннеля в публичной сети.

Туннель идентифицируется, в рамках данной SA, уникальным номером — SPI (Security Parameter Index). Для работы туннеля необходимы, в общем случае, два ключа: для аутентификации и для защиты трафика. Эти ключи могут назначаться двумя способами, которые взаимосвязаны с фактом существования туннеля:

• Постоянно существующий туннель. Создаётся немедленно после образования SA и существует до тех пор, пока не будет удален из конфигурации устройства. Все параметры туннеля — ключи, и алгоритм защиты трафика — назначаются администратором устройства вручную, статически, и должны быть установлены одинаковыми на обеих сторонах. Никакие способы автоматического разрыва туннеля или изменения его параметров в процессе его работы не предусмотрены.
• Динамически создаваемый туннель. Для создания такого туннеля используется процедура автоматического согласования ключей, определенная протоколом IKE (Internet Key Exchange). В результате образования SA подготавливаются условия для создания туннеля, но непосредственно создание туннеля происходит, как правило, тогда, когда на одной из сторон появляются данные для передачи по туннелю. (Создание туннеля немедленно после образования SA также возможно, но указывается дополнительными опциями.) Ключи, индекс туннеля (SPI) и конкретный алгоритм защиты трафика (из перечня разрешённых на одной и на другой стороне) согласовываются и пересогласовываются автоматически по мере необходимости.

  Созданный туннель может быть разорван любой из участвующих сторон в произвольный момент времени. В частности, это может произойти по следующим причинам:

  • Истечение установленного времени неактивности.
  • Истечение установленного срока жизни туннеля (по времени или объему переданного трафика).
  • Выход из строя удалённого шлюза, или потеря связи с ним, обнаруживаемые при помощи механизма DPD (Dead Peer Detection).
  • Вручную по инициативе администратора одного из VPN-шлюзов, при помощи соответствующей разовой команды.

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

Постоянные туннели IPsec в настоящее время используются крайне редко. Одна из причин состоит в необходимости вручную вводить длинные ключи. Другая, более существенная — в том, что ключи задаются статически, без ограничения срока действия. Они могут быть подобраны за конечное время (по крайней мере, теоретически), причём достаточно небольшое — при современных вычислительных мощностях и, тем более, при распределённой атаке с помощью сети (ботнета) из зомби-компьютеров. По этой причине NSG Linux 2.1 ориентирован на использование только динамических туннелей. Постоянные туннели, тем не менее, также могут быть реализованы с помощью дополнительных опций.

Технология IPsec по сути своей симметрична, т.е. не подразумевает разделения на клиент и сервер. Процедуры аутентификации, согласования параметров и установления туннеля могут выполняться с равным успехом в обе стороны, независимо от того, какая из сторон является инициатором. Однако в практических решениях полная симметрия имеет место достаточно редко. Чаще встречается ситуация, когда VPN-шлюзы функционально различны: мощный высокопроизводительный сервер в центральном офисе ожидает соединения от многих удалённых клиентов, а каждый из клиентов инициирует эти соединения по мере необходимости и обслуживает значительно меньшую часть приватной сети (удалённый офис, банкомат и т.п.) Как следствие, условия функционирования сервера и клиента также могут различаться по существу: сервер находится на высоконадёжном (Ethernet, Fiber Ethernet) соединении со статическим IP-адресом, в то время как клиенты могут использовать самые разные технологии доступа в Интернет, в том числе неустойчивые каналы связи, динамические адреса, с большой вероятностью — NAT на выходе из сети поставщика услуг в Интернет, и т.п.

Обратно в узел ipsec...