Использование NAT в протоколе IPSec

Обзор

Вначале опишем изменения в фазе I IKE, необходимые для прохождения NAT. Это включает определение, поддерживает ли противоположная сторона прохождение NAT и определение, сколько преобразований NAT существует между участниками.

Далее опишем, какие следует вести переговоры в Quick Mode IKE об использовании UDP для инкапсуляции IPSec-пакетов. Также опишем, как при необходимости передавать исходные адреса отправителя и получателя противоположной стороне. Эти адреса используются в транспортном режиме для изменения TCP/IP контрольных сумм, чтобы они были правильными после преобразования NAT. (NAT не может сделать это, потому что контрольная сумма TCP/IP находится внутри UDP, инкапсулирующего IPSec-пакет.)

Базовым сценарием в данном документе является предположение, что Инициатор расположен за NA(P)T, а Получатель имеет фиксированный IP-адрес.

Фаза I

В фазе I выполняется определение поддержки прохождения NAT обоими участниками и определение того, что между участниками имело место преобразование NAT.

NAT может изменить UDP-порт источника в IKE-пакетах, поэтому Получатель должен уметь обрабатывать IKE-пакеты, чей порт источника отличается от 500. NAT не должен менять порт источника, если только один IPSec-хост расположен за NAT. Для первого IPSec-хоста NAT может оставить порт 500 и изменять номера портов только для последующих коммуникаций.

Получатель должен возвращать пакеты на адрес источника, указанный в пакете. Это означает, что Получатель, выполняющий повторные переговоры о ключах или посылающий оповещение Инициатору, должен посылать пакеты, используя тот же самый набор портов и IP-адресов, который использовался в последней IKE SA.

Например, когда Инициатор посылает пакет с портами источника и получателя 500, NAT может изменить их на порт источника 12312 и порт получателя 500. Получатель должен иметь возможность обработать пакет с портом источника 12312. Он должен ответить, указав в пакете порт источника 500 и порт получателя 12312. Затем NAT будет преобразовывать в данном пакете порт источника на 500 и порт получателя на 500.

Определение поддержки прохода NAT

Возможность прохождения NAT удаленным хостом определяется посредством обмена содержимыми ID производителя (VID). В первых двух сообщениях фазы I должно посылаться содержимое ID производителя для определения возможности прохождения NAT. Содержимым является хэш-код MD5, вычисленный для строки "RFC 3947".

Определение наличия NAT

В фазе I посылается содержимое NAT-D, которое не только определяет наличие NAT между двумя противоположными сторонами IKE, но и определяет, где находится NAT. Расположение NAT важно, так как поддержка инициируется участником, расположенным за NAT.

Для определения NAT между двумя хостами необходимо определить изменялись ли IP-адреса и порты при пересылке. Это делается посылкой в содержимом NAT-D хэшей IP-адресов и портов обоих участников друг другу. Если на обоих концах вычислены те же самые хэши, что и полученные в сообщениях NAT-D, то это означает, что между участниками нет NAT. Если хэши не совпадают, где-то была выполнена трансляция адреса или порта. Это означает, что для получения IPSec-пакетов необходимо выполнить прохождение NAT.

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

Содержимые NAT-D включаются в третий и четвертый пакеты Main Mode и второй и третий пакеты Aggressive Mode.

Хэш вычисляется для следующих значений:

HASH = HASH (CKY-I | CKY-R | IP | Port)

Первое содержимое NAT-D содержит IP-адрес и порт удаленной стороны, т.е. адрес получателя UDP-пакета. оставшиеся содержимые NAT-D содержат возможные IP-адреса и порты на локальной стороне, т.е. все возможные адреса источника UDP-пакета.

Если между участниками нет NAT, первое полученное содержимое NAT-D должно соответствовать одному из локальных содержимых NAT-D, а другое содержимое NAT-D должно соответствовать IP-адресу и порту удаленной стороны. Если первая проверка не проходит, т.е. первое содержимое NAT-D не соответствует ни одному локальному IP-адресу и порту, то это означает, что между участниками существует динамический NAT, и данная сторона должна начать посылать пакеты, учитывая наличие NAT.

CKY-I и CKY-R являются Cookie Инициатора и Получателя. Они добавлены в хэш, чтобы предотвратить атаки, связанные с заранее вычисленными IP-адресами и портами.

Приведем пример обменов фазы I с определением прохождения NAT в Main Mode с аутентификацией с помощью цифровых подписей.

Рис. 9.1. Main Mode с аутентификацией с помощью цифровых подписей и определением наличия NAT

Приведем пример обменов фазы I с определением прохождения NAT в Aggerissive Mode с аутентификацией с помощью цифровых подписей.

Рис. 9.2. Aggressive Mode с аутентификацией с помощью цифровых под-писей и определением наличия NAT

Символ "#" означает, что данные пакеты посылаются с измененным номером порта, если определено наличие NAT.

Изменение на новые порты

Преобразования NAT, которые знают о наличии IPSec, могут вызвать проблемы. Некоторые преобразования NAT не изменяют IKE-порт источника 500, даже если существует несколько клиентов позади NAT. Они могут также использовать IKE Cookies для пересылки пакетов нужному получателю за NAT вместо использования порта источника. Эти возможности обеспечивают определенную прозрачность NAT, в результате чего IKE трудно определить наличие NAT. Наилучшим подходом считается просто передавать IKE-трафик на порт 500 и по возможности избегать использова-ния NAT, которые могут учитывать наличие IPSec.

Рассмотрим случай, когда Инициатор расположен за NAT. Инициатор должен сразу же изменить порт на 4500 после того, как он определит наличие NAT, чтобы минимизировать проблемы, связанные с NAT, которые могут учитывать наличие IPSec.

В Main Mode Инициатор должен изменить порты при посылке содержимого ID, если между хостами есть NAT. Инициатор устанавливает оба UDP-порта (и источника, и получателя) в 4500. Кроме того, к IKE-данным добавляются с помощью UDP-инкапсуляции не-ESP маркеры, которые позволят доставить трафик получателю, расположенному за NAT.

Таким образом, IKE-пакет теперь выглядит следующим образом:

IP UDP(4500,4500) <non-ESP marker> HDR*, IDii, [CERT,]SIG_I

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

Когда Получатель получает данный пакет, он выполняет обычную об-работку различных содержимых. Если обработка завершается успешно, то Получатель должен изменить локальное состояние таким образом, чтобы все последующие пакеты (включая информационные уведомления) к про-тивоположной стороне использовали новый порт и возможно новый IP-адрес, полученные из входящего пакета. Обычно порт отличается, так как NAT отображает UDP (500, 500) на UDP (X, 500) и UDP (4500, 4500) на UDP (Y, 4500). IP-адрес редко отличается от изначально имеющегося IP-адреса. Получатель должен посылать всю последовательность IKE-пакетов, используя UDP (4500, Y).

Аналогично, если Получатель решает выполнить обновление ключей для фазы I SA, то переговоры об обновлении ключей должны начинаться с использованием порта 4500. В этом случае нет необходимости изменять что-то еще.

После того, как выполнено изменение порта, если какой-либо пакет получен на порт 500, то считается, что это старый пакет.

Приведем пример обмена фазы I с использованием прохождения NAT в Main Mode при аутентификации с использованием цифровых подписей и с изменением порта:

Рис. 9.3. Main Mode с определением наличия NAT и изменением портов

Рис. 9.4. Пример SA с содержимом VID для прохождения NAT

Рис. 9.5. Пример обмена с содержимым NAT-D

В Aggressive Mode последовательность аналогичная. После того, как определен NAT, Инициатор посылает

IPUDP (4500, 4500) <4 байта не-ESPмаркера>HDR*, [CERT,] NAT-D, SIG_I

Получатель выполняет обработку, аналогичную предыдущей, и, если она успешна, он должен изменить свои собственные IKE-порты. Получатель должен отвечать на все последующие IKE-пакеты, используя UDP (4500, Y).

Рис. 9.6. Сообщения фазы I при прохождении NAT

Если включена поддержка прохождения NAT, порт содержимого ID как в Main, так и в Aggressive режимах должен быть установлен в 0.

В большинстве случаев для Получателя, расположенного позади NAT, NAT выполняет простое преобразование адреса 1:1. В этом случае Инициатор все еще продолжает изменять оба порта на 4500. Получатель использует алгоритм, описанный выше, хотя в этом случае Y будет равен 4500, так как никакого преобразования порта не происходит.

Изменение порта на другое значение может привести к необходимости использовать нестандартные способы определения используемых портов. Например, если Получатель расположен за NAT, преобразующим порты, и Инициатору необходимо установить соединение в первый раз, то Инициа-тор должен определить используемые порты, обычно соединяясь с некото-рым другим сервером. После того, как Инициатор выяснит, какие порты используются для прохождения NAT, обычно UDP (Z, 4500), он начинает использовать эти порты. Это аналогично случаю, когда Получатель начи-нает новые переговоры о ключах, при которых используемые порты уже известны, и никаких дополнительных обменов нет.

Quick Mode

После завершения фазы I оба участника знают, есть ли между ними NAT. Окончательное решение об использовании прохождения NAT при-нимается в Quick Mode. Об использовании прохождения NAT ведутся переговоры в содержимых SA Quick Mode. В Quick Mode оба участника так-же могут послать исходные адреса IPSec-пакетов (в случае транспортного режима), поэтому каждый может фиксировать поле контрольной суммы ТСР/IP после преобразования NAT.

Переговоры об инкапсуляции для обхода NAT

Для переговоров о прохождении NAT добавлено два новых инкапсулирующих режима:

• UDP-Encapsulated-Tunnel
• UDP-Encapsulated-Transport

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

Если между хостами есть NAT, то обычная транспортная или туннельная инкапсуляция не работает. В этом случае следует использовать UDP-инкапсуляцию.

Если между хостами нет NAT, то UDP-инкапсуляция не используется.

Также Инициатор не должен включать в свои предложения одновременно как обычный туннельный или транспортный режим, так и UDP-инкапсулирующий туннельный или транспортный режим.

Посылка исходных адресов отправителя и получателя

Для возможности изменения контрольных сумм ТСР обоим участникам может понадобиться знать исходные IP-адреса, которые использовались участниками при создании пакета.

Исходные IP-адреса посылаются в содержимом NAT-OA.

Инициатор <---------> NAT <---------> Получатель
^                        ^               ^
Iaddr           NatPub      Raddr

Инициатор расположен за NAT, который в свою очередь взаимодействует с публично доступным Получателем. Инициатор и Получатель име-ют IP-адреса Iaddr и Raddr. NAT имеет публичный IP-адрес NatPub.

Инициатор:

NAT-OAi = Iaddr
NAT-OAr = Raddr

Получатель:

NAT-OAi = NATPub
NAT-OAr = Raddr

Инициатор <---> NAT1 <---> NAT2 <---> Получатель
^           ^          ^           ^
Iaddr    Nat1Pub     Nat2Pub  Raddr

Здесь NAT2 "публикует" Nat2Pub в качестве адреса Получателя и перенаправляет весь трафик с данного адреса к Получателю.

Инициатор:

NAT-OAi = Iaddr
NAT-OAr = Nat2Pub

Получатель:

NAT-OAi = Nat1Pub
NAT-OAr = Raddr

В случае транспортного режима обе стороны должны посылать друг другу исходные адреса Инициатора и Получателя. В туннельном режиме обе стороны не должны посылать друг другу исходные адреса.

Содержимое NAT-OA посылается в первом и втором пакетах в Quick Mode. Инициатор должен послать содержимое, если он предложил UDP-инкапсулирующий транспортный режим, Получатель должен послать содержимое, если он выбрал UDP-инкапсулирующий режим. Возможна ситуация, когда Инициатор посылает NAT-OA содержимое, но предлагает и транспортный, и туннельный UDP-инкапсулирующий режимы. Если Получатель выбирает туннельный UDP-инкапсулирующий режим, то он не посылаетNAT-OA содержимое.

Пример Quick Mode, использующий NAT-OA содержимые:

Рис. 9.7. Сообщения Quick Mode при прохождении NAT

Рис. 9.8. Пример задания параметров прохождения NAT в транспортном режиме (часть 1)

Рис. 9.9. Пример задания параметров прохождения NAT в транспортном режиме (2 часть)

Рис. 9.10. Пример дампа трафика с инкапсулирующим режимом UDP Transport

Уведомления начального взаимодействия

IP-адрес и порт отправителя в уведомлении INITIAL-CONTACT для хоста, расположенного за NAT, не важны, так как NAT может изменить их, поэтому IP-адреса и номера портов не должны использоваться для определения того, какие IKE/IPSec SA следует удалять. Для этих целей следует использовать содержимое ID. Например, когда посылается INITIAL-CONTACT уведомление, то получившая его сторона должна удалить все SA, связанные с этим содержимым ID

Восстановление при истечении таймаута преобразования NAT

В некоторых случаях NAT решает удалить записи о сессиях, которые с точки зрения NAT больше не существуют (например, когда интервал подтверждения жизнеспособности SA превышен или когда NAT перезапускают). В этом случае для восстановления участники, которые не расположены за NAT, должны использовать последний действительный UDP-инкапсулирующий IKE- или IPsec-пакет от противоположной стороны, чтобы определить, какой IP-адрес и порт следует использовать. Хост позади динамического NAT не должен делать этого, так как в этом случае он может стать уязвимым для DoS-атаки, так как IP-адрес или порт другого хоста не изменился, если он не расположен за NAT.

Для этих целей не может использоваться анализ жизнеспособности, так как он не аутентифицирован, но для определения того, был ли изменен IP-адрес или порт может использоваться любой аутентифицированный IKE-пакет или ESP-пакет.

Обсуждение безопасности

Аутентификационные механизмы, основанные на IP-адресах, не могут использоваться, если выполняется преобразование NAT. Аутентификация не может основываться на IP-адресах. Это означает, что аутентификация по pre-shared ключам не может использоваться в Main Mode без использования ключей, разделяемых всеми, расположенными за NAT. Использование групповых ключей создает большой риск, потому что позволяет любому из группы аутентифицироваться в качестве VPN-шлюза, после чего просматривать и модифицировать трафик всей группы.

Ни содержимое NAT-D, ни содержимое Vendor ID не аутентифициро-ваны ни в Main Mode, ни в Aggressive Mode. Это означает, что атакующий может удалить эти содержимые, модифицировать их или добавить. Это может привести к DoS-атакам. Вставляя пакеты NAT-D, атакующий может заставить обоих участников использовать UDP-инкапсулированные пакеты вместо простого туннельного или транспортного режимов.