 |
|
|
|
IPSec через NAT: проблемы и решения
IPSec через NAT: проблемы и решения Исторически одной из проблем с развертыванием Layer Two Tunneling Protocol с Internet Protocol security (L2TP/IPSec) является то, что IPSec-узлы не могут быть расположены позади Network Address Translator (NAT). NAT чаще всего используется в корпоративных сетях, чтобы выходить в Интернет с единственного IP-адреса, тем самым эффективнее используя ограниченное адресное пространство IP-адресов. Однако NAT имеет проблемы с использованием сквозных протоколов типа IPSec. Новая технология, известная как IPSec NAT Traversal (NAT-T), находится в процессе стандартизации в IPSec Working Group. IPSec NAT-T описан в Internet drafts под названием «UDP Encapsulation of IPSec Packets» (draft-ietf-ipsec-udp-encaps-02.txt) и «Nego-tiation of NAT-Traversal in the IKE» (draft-ietf-ipsec-nat-t-ike-02.txt). IPSec NAT-T поддерживает различные методы передачи IPSec-защищенных данных. В процессе установления IPSec-подключения, IPSec NAT-T-узлы автоматически определяют:
Если оба эти условия выполняются, то узлы автоматически используют IPSec NAT-T, чтобы посылать IPSec-защищенный трафик через NAT. Если хотя бы один узел не поддерживает IPSec NAT-T или в пути между узлами нет NAT, то выполняется обычная стандартная IPSec-защита. IPSec NAT-T поддерживается Microsoft L2TP/IPSec VPN Client, который доступен для бесплатной загрузки, позволяя компьютерам с системами Windows 98, Me и NT 4.0 создавать L2TP/IPSec подключения. IPSec NAT-T будет включен в Windows .NET Server и поддерживается многими VPN-серверами. В этой статье мы исследуем проблемы, связанные с использованием IPSec через NAT, расскажем о способе решения проблем в IPSec NAT-T и закончим изменениями в Internet Key Exchange (IKE) согласования для Quick Mode и Main Mode. Обратите внимание!!! IPSec NAT-T определен только для ESP-трафика. Проблемы, связанные с использованием IPSec через NAT Ниже представлены проблемы использования IPSec через NAT:
TCP- и UDP-заголовки содержат контрольную сумму, которая рассчитывается из значения IP-адреса источника и адресата и номера портов. Когда NAT изменяет IP-адрес и/или номер порта в пакете, он обычно модифицирует TCP- или UDP- контрольную сумму. Когда же TCP- или UDP-контрольная сумма зашифрована в ESP, она не может быть модифицирована. Поскольку NAT изменяет адреса или порты, то обычно происходят сбои проверки контрольной суммы в адресате.
ESP-защищенный IPSec-трафик не содержит видимого TCP-или UDP-заголовка. ESP-заголовок расположен между IP-заголовком и зашифрованным TCP- или UDP-заголовком, и использует 50 IP-протокол. Из-за этого не может использоваться TCP- или UDP-номер порта, чтобы мультиплексировать трафик к различным хостам в частной сети. ESP-заголовок содержит поле, называемое Security Parameters Index (SPI). SPI используется вместе с IP-адресом адресата в открытом IP-заголовке и IPSec security protocol (ESP или AH) идентифицирует IPSec security association (SA). Для входящего NAT-трафика, IP-адрес адресата должен быть отображен к частному IP-адресу. Для множественных IPSec-узлов в частной NAT-сети, IP-адрес адресата прибывающего трафика для нескольких IPSec-ESP-потоков данных – один и тот же адрес. Чтобы отличать один IPSec-ESP-поток данных от другого, IP-адрес адресата и SPI должны или быть прослежены, или отображены к частному IP-адресу адресата и SPI. Поскольку SPI – 32-разрядное число, шанс использования одинаковых значений SPI между несколькими частными сетевыми клиентами крайне низок. Проблема состоит в том, что трудно определить, какое исходящее SPI-значение соответствует прибывающему SPI-значению. NATs не может отображать SPI, потому что ESP-трейлер содержит код идентификации сообщения, разбавленный цифровым мусором (hashed message authentication code, HMAC), который проверяет целостность модуля данных ESP-протокола (ESP protocol data unit, PDU), состоящего из ESP-заголовка, ESP-данных и ESP-трейлера, если SPI будет изменен, то недействительным окажется HMAC-значение.
Некоторые выполнения IPSec использует 500 UDP-порт как UDP-номер порта источника и адресата. Однако для IPSec-узла, расположенного позади NAT, NAT изменяет исходный адрес начального IKE-Main-Mode-пакета. В зависимости от выполнения, IKE-трафик от другого порта, кроме 500, будет отвергнут.
UDP-отображения в NAT часто удаляются очень быстро. Инициатор IKE-трафика создает отображение UDP-порта в NAT, который используется для продолжительных начальных Main-Mode- и Quick-Mode-IKE-согласований. Однако если респондент позже посылает IKE-сообщения инициатору, и не присутствует отображение UDP-порта, то такое сообщение будет отвергнуто.
Для Main Mode и Quick Mode согласований каждый IPSec-узел посылает идентификационные IKE-данные, которые включают внедренный IP-адрес для посылаемого узла. Поскольку исходный адрес посылаемого узла был изменен NAT, внедренный адрес не соответствует IP-адресу IKE-пакета. IPSec-узел, который проверяет правильность IP-адреса, отвергнет идентификационные IKE-данные и откажется от дальнейших IKE-согласований. Краткий обзор NAT-T изменений на IPSec Ниже представлены изменения IPSec для NAT-T:
UDP-заголовок помещен между внешним IP-заголовком и ESP-заголовком, инкапсулируя ESP PDU. Те же самые порты, которые используются для IKE, используются для UDP инкапсулированного ESP-трафика.
IPSec NAT-T IKE-заголовок содержит новое поле Non-ESP Marker, которое позволяет получателю различать UDP-инкапсулированное ESP PDU и IKE-сообщение. IPSec NAT-T узлы начинают использовать новый IKE-заголовок после того, как они решили, что присутствует промежуточное NAT-звено.
UDP-сообщение, которое использует те же самые порты, что и IKE-трафик, содержит один байт (0xFF), используемый для обновления отображения UDP-порта в NAT для IKE и UDP-инкапсулированного ESP-трафика к частному сетевому хосту.
Vendor ID IKE содержит известное значение хеш-функции, которое указывает, что узел способен выполнять IPSec NAT-T.
NAT-Discovery (NAT-D) IKE содержит значение хеш-функции, которое включает номер порта и адрес. Узел IPSec включает два NAT-Discovery в течение Main-Mode-согласования – один для адреса назначения и порта и один для исходного адреса и порта. Получатель использует NAT-Discovery, чтобы обнаружить, транслирован ли адрес или номер порта, и, основываясь на измененном адресе и порте, определять, какие узлы расположены позади NAT.
Эти два новых режима инкапсулирования определены в течение Quick Mode согласования, чтобы сообщить IPSec-узлу, что должно использоваться инкапсулирование UDP-пакета для ESP PDU.
NAT-Original Address (NAT-OA) IKE содержит непереведенный адрес IPSec-узла. Для UDP-инкапсулированного ESP транспортного режима каждый узел посылает NAT-OA IKE в течение Quick-Mode-согласования. Получатель хранит этот адрес в параметрах для SA. Пример IKE-согласования для Main Mode и SA Quick Mode, используя IPSec NAT-T Добавление новых NAT-D- и NAT-OA-значений и UDP-туннельных типов изменяет Main-Mode- и Quick-Mode-IKE-согласования. Следующая таблица показывает использование Vendor-ID и NAT-D IKE в течение Quick-Mode-согласования для Win-dows основанного IPSec-узла, использующего Kerberos идентификацию. Жирным шрифтом выделены особенности NAT-T. Таблица 1. Main Mode сообщения для Kerberos
Если оба узла – IPSec NAT-T, и присутствует не менее одного NAT между ними, они используют IPSec-NAT-T-варианты в Quick-Mode-согласовании. Принимая, что существует не менее одного NAT между этими двумя узлами, окончательные Quick-Mode-согласования показаны в следующей таблице. Таблица 2. Quick Mode сообщения
В конце Quick-Mode-переговоров оба IPSec-узла знают первоначальный адрес друг друга, посылают по мере необходимости NAT-Keepalive пакеты, и используют UDP-инкапсулирование для ESP PDU. Ссылки: |
ТАТЬЯНА АНТИПОВАКомментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
