IPSec, NAT, брандмауэры и VPN
Автор (С): Альфред Брот
VРN могут строиться в соответствии c различными схемами, в рамках которых должно осуществляться взаимодействие между сетевыми компонентами. К их числу относятся, например, маршрутизаторы NAT, соединяющие домашний офис с сетью предприятия, или туннели, ведущие сквозь брандмауэр к клиенту IPSec. В таких ситуациях клиент IPSec организует свой туннель VPN к концентратору VPN либо непосредственно через провайдера Internet, либо напрямую через маршрутизатор DSL, либо через брандмауэр.
На практике с VPN на основе NAT и IPSec связаны определенные проблемы. Поэтому прежде всего мы рассмотрим основы NAT и IPSec и только после этого поговорим о предлагаемых решениях по обеспечению взаимодействия указанных компонентов.
Какой бы способ построения VPN не был выбран, следует помнить, насколько большое значение имеет согласованность используемых компонентов VPN и внешней сети, особенно если они лишь частично находятся под административной защитой какого-либо владельца VPN или же вообще не защищены. Неблагоприятная комбинация и/или неправильная конфигурация сетевых компонентов в соединении из конца в конец может привести к тому, что туннель VPN на базе IPSec можно будет использовать только условно. В статье рассматриваются возможные проблемы при создании подобных сетей.
Преобразование NAT
Применение NAT позволяет обойти существующие ограничения открытого адресного
пространства IРv4, поэтому данный протокол используется при решении многих сетевых
проблем. Определение NAT приведено в RFC 1631, где устанавливается, как можно
преобразовать IP-адреса из одного адресного блока IP в другой.
В большинстве случаев NAT преобразует IP-адреса из так называемого частного адресного пространства IP (10.0.0.0-10.255.255.255, 172.16.0.0-172.31.255.255, 192.168.0.0-192.168.255.255) в однозначное и зарегистрированное открытое адресное пространство IP. Согласно RFC 1918, частные IP-адреса нельзя передавать дальше в Internet, поэтому они могут свободно использоваться только для внутренних целей.
Статический и динамический NAT
Простой формой NAT является статическое преобразование адресного пространства
IP. При этом администратор либо устанавливает статическое однозначное соответствие
IP-адресов для каждого адреса, либо динамически распределяет их по пулу адресов
NAT. В данном случае пул адресов NAT предоставляет в распоряжение пользователя
адресное пространство IP такого же размера, как и частное адресное пространство
IP. Преобразование адресов хостов из частного адресного пространства IP в адреса
из пула NAT выполняется один к одному.
При подобной форме преобразования устройство NAT (например, маршрутизатор или брандмауэр) в зависимости от направления передачи заменяет IP-адрес отправителя и/или получателя в передаваемом пакете IP на IP-адрес из пула адресов и вносит запись в таблицу NAT, где фиксируется соответствие IP-адресов. Затем оно рассчитывает новую контрольную последовательность для заголовка IP (IP-Header), и измененный пакет IP с новым заголовком передается адресату.
Получив пакет IP, система сравнивает IP-адреса (получателя и/или отправителя) с записями в таблице NAT, соответствующим образом изменяет их, после чего создает контрольную последовательность для заголовка IP и передает измененный пакет адресату.
Преобразование портов в адресе
Нередко случается так, что имеющийся в распоряжении пользователя пул адресов
NAT существенно меньше частного адресного пространства IP, подлежащего преобразованию.
Например, для соединений с Internet часто используется только один открытый
IP-адрес. Вариант NAT, известный как Port Address Translation (PAT) или Network
Address Port Translation (NAPT), позволяет в такой ситуации одновременно задействовать
этот открытый IP-адрес для нескольких сетевых компонентов.
В случае PAT устройство NAT также вставляет в IP-пакет вместо адреса отправителя открытый IP-адрес. Чтобы можно было отличить IP-пакеты различных отправителей, оно заменяет (возможно, неоднозначный) порт TCP/UDP в заголовке TCP/UDP исходного пакета IP на другой, уникальный порт TCP/UDP и вносит соответствующую запись в таблицу NAT. В последующем таблица NAT становится основой для обратного преобразования IP-адресов.
При таком преобразовании система должна заново рассчитать контрольную последовательность не только заголовка IP, но и заголовка TCP/UDP. После этого она создает новый заголовок TCP/UDP и IP и передает пакет IP соответствующему адресату.
Протокол IPSec
IPSec устанавливает четыре основных признака безопасного соединения по IP и
надежной передачи данных: конфиденциальность данных (Confidentiality), их целостность
(Integrity), идентификацию другой стороны и данных (Aithentification) и фиксацию
авторства (от данных нельзя отказаться - Non-Repudiation).
В зависимости от требований безопасности можно создать комбинацию из различных алгоритмов шифрования и хэширования (Diffie-Hellman, DES, 3DES, MD5, SHA-1 и т. д.) и таким образом IPSec может быть реализован с определенным уровнем гибкости.
IPSec предлагает два способа передачи: транспортный и туннельный. При транспортном - реальный IP-заголовок (следовательно, и IP-адрес) остается нетронутым, а заголовок IPSec вставляется между заголовком IP и остальными заголовками или, соответственно, данными. При таком способе передачи изменения затрагивают только транспортный уровень пакета IP, а собственно данные могут быть аутентифицированы и/или зашифрованы.
При туннельном режиме изменяется весь пакет IP. Защита распространяется на заголовок IP и данные, причем вместо исходного создается новый заголовок IP с другими IP-адресами. IPSec включает в себя две формы преобразования или два протокола передачи - AH и ESP.
Authentication Header (АН) дает возможность с помощью цифровой подписи проверить аутентичность и целостность пакета IP. В то же время Encapsulating Security Payload (ESP) предназначен не только для проверки аутентичности и целостности, но и для кодирования данных. Оба протокола могут использоваться как совместно, так и отдельно друг от друга. Правда, их совместное применение связано со значительным увеличением объема данных и не дает заметных преимуществ.
Управление ключами и ассоциации безопасности
Протокол ассоциаций безопасности и управления ключами (Internet Security
Association and Key Management Protocol, ISAKMP) определяет в соответствии со
своим названием процедуру установления ассоциаций безопасности и функции управления
ключами.
Функции управления ключами - важная составная часть IPSec. Они предназначены для безопасного обмена ключами между партнерами IPSec. Такой обмен можно реализовать двумя способами: вручную или с помощью протокола обмена ключей (Internet Key Exchange, IKE).
Первый способ позволяет ответственным лицам самостоятельно вводить необходимые параметры.
IKE, напротив, автоматизирует большинство задач управления ключами. На первом этапе он осуществляет идентификацию партнеров IPSec и определяет способ кодирования, в соответствии с которым будет зашифровываться созданная ассоциация безопасности для транзакции IKE. На втором - происходит определение способа шифрования для ассоциации безопасности IPSec и собственно ее создание.
Проблемы и решения
Для обеспечения целостности данных (одного из четырех основных свойств IPSec)
запрещается какое-либо их изменение в процессе передачи. Это является основным
препятствием, с которым можно столкнуться при реализации NAT и IPSec. Поскольку
NAT изменяет заголовок IP, то это влияет на проверку целостности пакета IP в
случае использования протокола АН. При любом режиме (транспортном или туннельном)
протокол АН осуществляет аутентификацию всего пакета IP, включая и заголовок
IP.
Именно поэтому протокол АН и NAT совместно работать не могут. Следовательно, единственный вариант - использовать протокол ESP в транспортном или в туннельном режиме. ESP в туннельном режиме защищает данные и заголовок транспортного уровня. Заголовок IP остается нетронутым и может быть изменен, что и происходит при преобразовании NAT. Таким образом, этот процесс может функционировать до тех пор, пока речь не заходит о пакете TCP.
Однако, как только возникает необходимость в передаче пакета TCP с преобразованием портов в адресе, маршрутизатор NAT начинает работать с портами TCP и заново рассчитывает контрольную последовательность TCP. А поскольку заголовок TCP защищен протоколом ESP, можно ожидать следующих проблем.
Отсюда следует: NAT и ESP способны совместно функционировать в транспортном режиме только в том случае, если партнерами IPSec отменена проверка контрольной последовательности.
Но существует еще одна трудность: при использовании IKE с предварительной общей (Pre-shared) аутентификацией в большинстве реализаций IPSec происходит идентификация IP-адреса партнера по заранее заданному паролю. Изменение этого IP-адреса при использовании NAT может привести к сложностям с аутентификацией. Однако если идентификация партнера IPSec происходит на основе идентификационных данных (ID) пользователя или имени домена, то такая проблема не возникает.
IPSec поверх UDP
Вышеописанную проблему позволяет решить NAT Traversal (NAT-T) или "IPSec поверх
UDP". Речь идет о способе, основанном на проекте стандарта Internet от IETF
"Инкапсуляция пакетов IPSec в UDP" и не требующем никакого изменения устройств
на пути между партнерами IPSec. Пакет IP, защищенный IPSec, дополнительно упаковывается
в пакет UDP с заголовком UDP, в результате чего он избегает проверки идентичности
и целостности заголовка IP и TCP. Поскольку при этом используется тот же порт
UDP, что и для IKE (500), то обычно не требуется каких-либо изменений в настройке
брандмауэра, так как этот порт уже условно активизируется вследствие использования
VPN на базе IPSec.
Процесс настройки всех параметров в случае "IPSec поверх UDP" занимает больше времени, чем для "обычного" соединения IPSec. Он включает распознавание партнера IPSec для поддержки "IPSec поверх UDP", процесс обнаружения для установления факта преобразования в пути адреса (NAT) и, наконец, определение параметров, необходимых для передачи (туннельный режим с инкапсуляцией UDP или транспортный с инкапсуляцией UDP).
IPSec поверх TCP
А что происходит, если по причинам безопасности IKE и ESP (порт UDP 500 и протокол
IP 50) не могут функционировать на одном из брандмауэров? В этом случае создание
соединения IPSec и передача данных не состоятся ни в "чистом" туннельном режиме
ESP, ни в режиме NAT-Traversal или "IPSec поверх UDP".
Некоторые разработчики предлагают решения, основанные на тех же принципах, что и NAT-Traversal, но при этом пакеты IPSec упаковываются не в пакеты UDP, а в пакеты TCP. Коммуникационный порт TCP либо определен в программном обеспечении по умолчанию (например, порт TCP 80), либо выбирается произвольным образом. В последнем случае его можно установить для каждого партнера IPSec.
Выводы
Как следует из описания проблемы и множества представленных вариантов ее преодоления,
единственного решения для всех возможных ситуаций не существует. При реализации
VPN речь идет, чаще всего, о тщательном анализе предварительно заданных сетевых
компонентов, которые находятся на пути следования данных и чьи свойства играют
большую роль в процессе передачи. Окончательное решение придется принимать с
учетом некоторых возможных компромиссов, которые, конечно же, не должны влиять
на безопасность процесса.
