Red Line Software - мы помогаем вам управлять эффективностью работы вашего офиса.

Часто задаваемый вопрос на досках объявлений — как пропускать IPSec VPN клиента через ISA сервер. Это может быть сделано, если (и только если) IPSec реализация поддерживает возможность под названием NAT Traversal. Продолжайте читать, если Вы хотите знать почему, как это работает, и как Вы можете передавать это через ISA сервер.

1. Резюме

Тема, которая часто поднимается на досках объявлений — как конфигурировать ISA сервер для IPSec транзитной пересылки. Хотя ISA сервер поддерживает транзитную пересылку PPTP из блока, нет никакой встроенной поддержки для IPSec транзитной пересылки. Причиной этого является то, что IPSec протоколы не являются NAPT совместимыми (Network Address & Port Translation-сетевая трансляция адреса и порта). IPSec протоколы разработаны для того, чтобы подтверждать подлинность и/или шифровать информацию в пакете. Когда NAPT устройство (т.е. ISA сервер) попытается изменить информацию в пакете, это вызовет или то, что пакет будет сочтён недопустимым в соответствии с IPSec протоколом, или будет невозможно выполнить трансляцию, потому что информация, к которой NAPT устройство должно обратиться, зашифрована.

К счастью для нас, IETF (Internet инженерная целевая группа) наконец устранила проблему. Рабочая группа IPSec Working Group уже выработала решение под названием NAT Traversal или, сокращённо, NAT-T. Начиная с января 2005, решение полностью стандартизировано в RFC 3947 и 3948. Единственной проблемой остаётся то, что пока не все поставщики реализовали последнюю версию RFC, только какую-либо довольно раннюю версию из проектов, по большей части версию 2 или 3. Поэтому Вы можете ожидать, что получите некоторые небольшие вариации в различных реализациях. Это может привести к некоторым проблемам во взаимодействии, если Вы хотите смешивать и сочетать решения от различных поставщиков.

2. IPSec NAT Traversal

Хорошо известен факт, что IPSec протокол был разработан, не имея в виду существование NAPT. Использование IPSec протокола обычно не является проблемой в шлюз-шлюзовом(gateway-to-gateway) VPN сценарии, потому что VPN шлюзы установлены на границе сетей, которые нужно связать. Однако, одним из очень популярных применений VPN-ов является обеспечение дистанционного доступа в корпоративную сеть Intranet. Сегодня NAPT-ы широко развёрнуты в домашних шлюзах, так же как и в других местоположениях, вероятно, чтобы использоваться удалёнными сотрудниками. Результатом является то, что IPSec-NAPT несовместимости стали главным барьером на пути развёртывания IPSec протокола в клиент-шлюзовом (client-to-gateway) VPN сценарии.

Описание точных технических подробностей об известных несовместимостях между NAPT и IPSec протоколами выходит за пределы этой статьи. Если Вы заинтересованы в таком уровне подробностей, то Вам следует прочитать IETF информационный RFC 3715 «Требования совместимости IPSec-NAPT» (IPsec-NAT Compatibility Requirements), написанный Бернардом Адоба(Bernard Aboba) и Уильямом Диксоном(William Dixon) из Microsoft.

Жаль, что две прекрасные статьи (из Microsoft Technet Webcast) «IPsec и NAT-T: Наконец в гармонии? (Уровень 400)»(IPsec and NAT-T: Finally in Harmony? (Level 400)) и «Демистификация IPsec (Уровень 400)»(Demystifying IPsec (Level 400)), предоставленные Стивом Райли(Steve Riley's website), больше не доступны на сайте Microsoft Webcast. Однако, на вебсайте Стива Райли (Steve Riley’s website) Вы, должно быть, сможете найти прекрасную powerpoint-презентацию «IPsec и NAT: Наконец в гармонии» (Steve Riley's website you should be able to find the excellent powerpoint presentation IPsec and NAT: Finally in harmony.

Чтобы включить развёртывание IPSec протокола в клиент-шлюзовом(client-to-gateway) VPN сценарии, IETF наконец-то выработала решение, названное NAT Traversal. Так как одним из главных применений IPSec является удалённый доступ к корпоративным сетям Intranet, NAT-T решение должно поддерживать прохождение NAPT устройства или через IPSec туннельный режим или через L2TP над IPSec транспортным режимом. Это включает поддержку для прохождения(traversal) более чем одного NAPT устройства между удалённым клиентом и VPN шлюзом. Ключевые элементы решения NAT Traversal:

• Использование IPSec AH протокола не поддерживается.
• Согласование NAT Traversal-а в IKE.
• UDP инкапсуляция (формирование пакета) IPSec пакетов.

2.1. Использование IPSec AH протокола не поддерживается

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

Примечание: изменяемыми полями в пределах IP заголовка являются Type of Service(тип сервиса)(TOS), Fragment Offset(смещение фрагмента), Flags(флаги), Time to Live(время жизни) (TTL), IP header checksum(контрольная сумма IP заголовка).

2.2. Согласование NAT Traversal в IKE

IETF RFC 3947 «Согласование NAT-Traversal в IKE»(Negotiation of NAT-Traversal in the IKE) описывает, как обнаружить поддержку для NAT Traversal в IPSec хостах, как обнаружить одно или больше NAPT устройств по пути(along the path) и как согласовать использование UDP инкапсуляции IPSec пакетов через NAPT блоки. Это сделано посредством определения некоторых изменений и расширений в IKE протоколе (Internet Key Exchange-Internet ключевой обмен). Чтобы лучше понимать, что происходит за сценой, позвольте нам пройти через процесс согласования с точки зрения связи.

VPN клиент (инициирующий IPSec peer(peer-равный по положению)) начинает IKE согласование, как обычно, с назначения IP адреса VPN шлюза (отвечающий IPSec peer) и хорошо известного порта UDP 500. Из-за того, что NAPT устройство по пути может изменить IKE UDP исходный порт, получатель должен быть способен обрабатывать IKE пакеты, у которых исходный порт отличается от UDP 500(исходный порт по умолчанию). Это подразумевает также, что ответчик должен послать все ответы обратно на тот же самый исходный IP адрес и номер UDP порта принятого IKE пакета.

Важно то, что присутствие NAPT устройства по пути обнаруживается в самом начале IKE процесса согласования. Это делается за два шага:

• Первым шагом является обнаружение того, что IPSec peer-ы способны к выполнению NAT-T. Каждый IPSec (NAT-T способный) peer должен добавить новую Vendor-ID (VID) полезную нагрузку к первому IKE сообщению (Security Association-ассоциация защиты), содержащую хорошо известное значение хэш-функции. NAT Traversal исследование будет продолжаться только если оба, и инициатор, и ответчик, послали и приняли эту определённую VID полезную нагрузку. Во всех других случаях выполняются нормальные IPSec согласования и IPSec защита.
• Вторым шагом является добавление одной или более новых NAT-Discovery (NAT-D) полезных нагрузок ко второму IKE сообщению (ключевой обмен). Каждая NAT-D нагрузка содержит значение хэш-функции IP адреса и номер UDP порта. В течение главного режима согласования каждый IPSec peer посылает две NAT-Discovery полезных нагрузки, одну для IP адреса назначения и номера UDP порта (по умолчанию 500), а другую для исходного IP адреса и номера порта (по умолчанию 500). Путём сравнения хэш-функции реального исходного IP адреса и UDP номера порта полученного IKE сообщения с посланными (хэш-функцией и UDP номером порта) в пределах NAT-D полезной нагрузки, каждый получатель может определить, есть ли NAPT устройство по пути и какой peer расположен позади NAPT устройства. Если обнаружено хотя бы одно NAPT устройство, то IPSec peer-ы автоматически используют IPSec NAT-T, чтобы посылать IPSec-защищённый трафик через NAPT устройство. Во всех других случаях выполняются нормальные IPSec согласования и IPSec защита.

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

Первичная цель IPSec NAT Traversal состоит в том, чтобы иметь универсальное NAPT прозрачное решение. Общепринятой истиной является то, что на рынке существуют несколько IPSec-знающих NAPT устройств. Они используют некоторые специфические для каждого поставщика компиляторы(hacks), чтобы позволить прохождение IPSec трафика через их собственные устройства. Однако, делая так, они мешают прохождению правильного IKE трафика на UDP порт 500. Из-за того, что общее решение не может обнаруживать возможности любого NAPT устройства, разработчики IPSec NAT Traversal протокола решили просто переместить IKE трафик от UDP порта 500, чтобы избежать возникновения любых проблем с IPSec-знающими NAPT устройствами. Поэтому, как только использование IPSec NAT-T согласовано, должен быть использован новый UDP порт 4500. Обратите внимание, что любая реализация, которая поддерживает NAT Traversal, должна также поддерживать IKE согласования, которые запускаются на UDP порте 4500 вместо UDP порта 500 по умолчанию. Конечно, если согласование начинается немедленно на UDP порте 4500, то никакое изменение порта вообще не нужно.

В дополнение к изменению UDP порта, IKE данные должны быть дополнены не-ESP маркером, который позволяет получателю делать различие между IKE сообщением и UDP инкапсулированным ESP пакетом. Не-ESP маркер-это ничто иное как 4 нулевых октета (x’00’). Это прекрасно совмещается с SPI полем UDP инкапсулированного ESP пакета. Этот новый формат называется форматом с плавающим IKE заголовком(Floated IKE Header) и проиллюстрирован на рисунке ниже.

Единственной целью отсылки NAT-поддерживающих пакетов является сохранение UDP отображений в NAPT устройстве работоспособными на время соединения между IPSec peer-ами. NAT — поддерживающий пакет является стандартным UDP сообщением, которое использует тот же самый UDP порт 4500, что и IKE трафик, и содержит единственный октет (0xFF) в качестве полезной нагрузки. По умолчанию NAT-поддерживающий интервал установлен на 20 секунд бездеятельности на данном подключении. Обратите внимание, что никакие NAT-поддерживающие пакеты не посылаются на UDP порт 500.

2.3. UDP инкапсуляция IPSec пакетов

IETF RFC 3948 «UDP инкапсуляция IPsec пакетов»(UDP Encapsulation of IPsec Packets) определяет методы инкапсуляции и декапсуляции IP ESP пакетов (Encapsulating Security Payload-инкапсулированная полезная нагрузка безопасности) внутри UDP пакета с целью прохождения NAPT. UDP инкапсуляция используется всякий раз, когда применяется согласование с использованием Internet Key Exchange (IKE) протокола.

Наиболее важным пунктом здесь является вставка стандартного UDP заголовка между IP и ESP заголовком, как обозначено на вышеупомянутом рисунке. Номера UDP портов должны быть теми же самыми, что и те, которые используются для IKE пакетов после того, как IPSec NAT Traversal согласуется (UDP порт 4500). Это значит, что IKE и UDP инкапсулированные ESP пакеты используют те же самые номера UDP портов. Как уже упоминалось, чтобы различать IKE пакет и UDP инкапсулированный ESP пакет, получатель должен немедленно проверить первые 4 октета следующих за UDP заголовком, чтобы демультиплексировать трафик. Если они все равны нулю, то это IKE пакет (не-ESP маркер), иначе это UDP инкапсулированный ESP пакет. Поэтому значение SPI (индекс параметров безопасности) поля в ESP заголовке должно всегда быть отличным от нуля.

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

Так как одним из главных применений IPSec является клиент-шлюзовой(client-to-gateway) VPN сценарий, решение NAT Traversal явно поддерживает L2TP над IPSec в транспортном режиме и реализации IPSec туннельного режима. Теперь позвольте нам кратко рассмотреть полную пакетную структуру для этих двух случаев:

Примечание: типичным примером вышеуказанной реализации является Microsoft L2TP/IPSec VPN клиент. Для получения дополнительной информации по Microsoft VPN решениям просмотрите сайт Microsoft VPN site.

Примечание: Обсуждение всех «за» и «против» обеих реализаций выходит за пределы этой статьи. Однако, имейте в виду, что хотя IPSec структура пакета туннельного режима и выглядит простой, нет необходимости в лучшем решении для клиент-шлюзового(client-to-gateway) VPN сценария.

3. Конфигурирование ISA сервера

Теперь, когда мы понимаем, как работает IPSec NAT Traversal, по крайней мере, с точки зрения связи, нам должно быть не трудно перевести это знание в необходимые протокольные определения, протокольное правило и правило «сайт&контент» для ISA сервера.

Шаги конфигурации на ISA сервере:

• Создайте протокольное определение для IPSec IKE протокола:
  
• Создайте протокольное определение для IPSec NAT-T протокола:
  
• Создайте протокольное правило, разрешающее протоколы IPSec IKE и IPSec NAT-T:
  

Конечно, правило «сайт&контент» должно присутствовать в месте, разрешающем доступ к назначенному VPN шлюзу. Кроме того, может быть необходимо отключить IP фрагментную фильтрацию на ISA сервере (IP Packet Filter Properties-свойства IP пакетного фильтра), особенно если сертификаты используются в процессе VPN аутентификации.

4. Конфигурирование ISA клиентов

Чтобы понять, как должен быть сконфигурирован клиентский хост, Вы должны сначала понять, на каком уровне в TCP/IP протокольном стеке работают различные типы ISA клиентов и IPSec клиент. Для получения большей информации о различных типах ISA клиентов просмотрите прекрасные статьи Джима Харрисона(Jim Harrison) на http://www.isaserver.org/Jim_Harrison/.

Следующий рисунок показывает логическое представление TCP/IP протокольного стека:

Примечание: имейте в виду, что единичный хост может быть сконфигурирован как SecureNAT, Firewall и Web Proxy клиент без какого-либо неблагоприятного взаимодействия между клиентскими конфигурационными установками.

4.1. Web Proxy клиент

В отличие от Firewall клиента, Web Proxy клиент не является частью программного обеспечения, которую Вы должны устанавливать. Он относится к клиентским Web приложениям, которые сконфигурированы, чтобы использовать ISA сервер как Web Proxy сервер. В большинстве случаев он будет CERN-совместимым Web броузером.

Когда Web приложение конфигурируется, чтобы использовать Web Proxy сервис на ISA сервере, все HTTP/HTTPS запросы для адресатов, не установленных для прямого доступа, отсылаются к Web Proxy сервису на ISA сервере. Это означает, что такие запросы переадресовываются Web приложением непосредственно к выходному Web Proxy слушателю на ISA сервере. Другими словами, Web приложение будет запрашивать транспортный уровень, чтобы создать соединение к внутреннему IP адресу ISA сервера (LAT адресат) и TCP порту 8080, принимая заданную по умолчанию конфигурацию выходного Web Proxy слушателя.

Из-за того, что переадресация сделана непосредственно Web приложением, мы можем сказать, что Web Proxy клиент работает на прикладном уровне.

4.2. Firewall клиент

Firewall клиент является очень интересной частью программного обеспечения и работает рука об руку с Firewall сервисом на ISA сервере. На платформах, которые поддерживают Winsock 2.0, клиент осуществлён как многоуровневый сервис-провайдер (LSP). На других платформах установочное приложение клиента переименовывает оригинальную библиотеку Winsock DLL (wsock32.dll) и устанавливает свою собственную реализацию wsock32.dll. Firewall клиент связывается с Firewall сервисом, используя выделенное подключение, названное Firewall client control channel(клиентский контрольный канал брандмауэра). Подключение контрольного канала устанавливается по мере необходимости.

Когда клиентское приложение вызывает Winsock функцию, клиентская библиотека DLL прерывает вызов и решает, основываясь на указанном запросе и сервисных конфигурационных файлах брандмауэра, является ли запрос локальным или удалённым. Локальные запросы пропускаются к оригинальной Winsock реализации. Удалённые запросы переадресуются к сервису брандмауэра. Обычно все TCP/UDP запросы для не-LAT адресатов перенаправляются клиентским программным обеспечением брандмауэра к Firewall сервису на ISA сервере. Это делается путём перезаписи оригинального Winsock запроса и замещения некоторых параметров, таких как IP адрес назначения и номер порта назначения, на те, о которых договариваются вдоль контрольного канала Firewall клиента. Возьмите на заметку, что новый IP адрес назначения будет внутренним IP адресом ISA сервера.

Поскольку переадресация сделана программным обеспечением Firewall клиента на Winsock уровне, Firewall клиент определённо работает на транспортном уровне.

4.3. SecureNAT клиент

Любой компьютер, который понимает сети TCP/IP и имеет по умолчанию шлюзовую возможность маршрутизации Internet связанного(bound) трафика через внутренний интерфейс ISA сервера, называется SecureNAT клиентом. В простой немаршрутизированной внутренней сети шлюз по умолчанию на клиентах должен быть сконфигурирован с IP адресом ISA внутреннего интерфейса. Если Вы эксплуатируете более сложную маршрутизированную внутреннюю сеть, выпишите статью Джима Харрисона(Jim Harrison) Designing An ISA Server Solution on a Complex Network(Проектирование решения «ISA сервер» в сложной сети.

В отличие от Web Proxy и Firewall клиента, никакое переназначение(redirection) или специальная обработка на клиентском сайте вообще не делаются. Это значит, что SecureNAT запросы следуют нормальной пакетной обработке TCP/IP стека и что вся обработка должна быть сделана в сервисе брандмауэра на ISA сервере. Другими словами, IP адрес назначения будет IP адресом требуемого назначения, и протокол, и номер порта (если применимо) будут требуемые.

SecureNAT клиент принадлежит сетевому слою(layer), потому что он зависит от шлюзовой конфигурации и сетевой маршрутной инфраструктуры.

4.4. IPSec клиент

IPSec клиентские реализации могут быть классифицированы на две категории:

• OS интегрированная: Так как IPSec является протоколом сетевого слоя, он может быть осуществлён как часть сетевого слоя. IPSec слой нуждается в наличии сервисов IP слоя, чтобы создавать IP заголовок. Эта модель идентична реализации других протоколов сетевого слоя (типа ICMP). Примером такой реализации является L2TP/IPSec VPN client in Windows 2000 and above(L2TP/IPSec VPN клиент в Windows 2000 и выше).
• Возмущение(Bump) в стеке: Для компаний, обеспечивающих решения для VPN-ов, OS интегрированное решение имеет один серьёзный недостаток. На конечных хостах они должны работать со средствами, предоставляемыми поставщиками OS. Это может ограничить их возможности по предоставлению расширенных решений. Чтобы преодолеть это ограничение, IPSec осуществлён как прокладка, и вставлен между сетевым и слоем передачи данных. Это обычно именуется как BITS реализация (Bump in the Stack-возмущение в стеке). Я полагаю, что большинство IPSec клиентских реализации сторонних поставщиков следуют этому дизайну, включая клиент L2TP/IPSec VPN client for Windows 98, Windows Me and Windows NT 4.0, разработанный для Microsoft фирмой SafeNet, Inc. из Балтимора(Baltimore, MD).

С логической точки зрения, IPSec клиент можно рассматривать как систему переадресации. В общих чертах, он является IP адресом назначения оригинального IP пакета, который будет использован, чтобы решать, должен ли IP пакет быть переадресован для дальнейшей IPSec обработки. Это значит, что IPSec клиент должен иметь некоторый вид конфигурационной таблицы, или местно, или централизованно контролируемой, сообщающей IPSec механизму, для каких IP адресов назначения и/или сетевых ID пакеты должны быть переадресованы к конкретному удалённому VPN шлюзу. Другими словами, после применения необходимого IPSec преобразования, назначением IP пакетов будет внешний IP адрес удалённого VPN шлюза, но не IP адрес назначения оригинального IP пакета.

Мы можем сказать, что IPSec клиент работает на сетевом уровне, потому что переадресация и IPSec обработка делаются на IP уровне.

4.5. Конфигурационные проблемы

С вышеуказанными знаниями Вам должно быть очевидно, что следует тщательно конфигурировать различные типы ISA клиентов, чтобы иметь возможность пропускать IPSec трафик через ISA сервер в клиент-шлюзовом(client-to-gateway) VPN сценарии. Первая проблема, с которой Вы можете столкнуться, заключается в том, что сетевой ID назначения, которого Вы хотите достигнуть через VPN туннель, уже используется во внутренней сети. Это является общей проблемой VPN дизайна и единственное решение этой проблемы — перенумеровать Вашу внутреннюю сеть, чтобы больше не было IP адресного конфликта.

Если клиентский хост сконфигурирован как Web Proxy клиент, Вы должны убедиться, что назначения, достижимые через VPN туннель, не переадресованы к Web Proxy сервису на ISA сервере. Поэтому Вы должны конфигурировать эти назначения для прямого доступа. Как это сделать, очень хорошо объясняется в статье Configuring Web Proxy Clients for Direct Access(Конфигурирование Web Proxy клиентов для прямого доступа) от Тома Шиндера(Tom Shinder).

Если клиентский хост сконфигурирован как Firewall клиент, Вы должны убедиться, что назначения, достижимые через VPN туннель, не переадресованы к Firewall сервису на ISA сервере. Простейшим решением этой проблемы является отключение Firewall клиента в течение VPN сеанса. Если это решение не выполнимо в Вашем окружении, Вы должны усовершенствовать конфигурацию Firewall клиента. Точнее, Вы должны поместить сетевые ID так, чтобы они были достижимы через VPN туннель в LAT. Поскольку только очень малое число внутренних хостов должно быть вовлечено, я делал бы изменения конфигурации Firewall клиента только на клиентском хосте, а не глобально на ISA сервере. Иначе Вы не должны разрешать клиент-шлюзовой(client-to-gateway) VPN сценарий через ISA сервер, но идти путём шлюз-шлюзового(gateway-to-gateway) VPN сценария с ISA сервером в качестве VPN конечной точки.

Чтобы сделать изменения конфигурации Firewall клиента на клиентском хосте, используйте текстовый редактор, чтобы создать заказной(custom) клиентский LAT файл, называемый Locallat.txt, и поместите его в Microsoft Firewall клиентскую папку на клиентском компьютере. Вы можете добавить дополнительные IP адресные диапазоны, которые клиент распознаёт как часть внутренней сети. Firewall клиент использует и Msplat.txt, и Locallat.txt файлы, чтобы определить, какие IP адреса не должны быть переадресованы к Firewall сервису на ISA сервере. Для получения дополнительной информации изучите раздел Firewall Client components(клиентские компоненты брандмауэра) в ISA файле помощи.

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

5. Специфические реализации

Как было сказано ранее, не все поставщики уже реализовали последнюю версию проектов. Однако, согласно обсуждениям на досках объявлений, большинство недавних реализаций, кажется, поддерживают некоторую форму UDP инкапсуляции, но всё ещё ощущается недостаток в автоопределении NAPT устройства по пути и поэтому в согласовании использования UDP инкапсуляции IPSec пакетов через NAPT блоки(boxes). Итак, очень похоже на то, что использование UDP инкапсуляции должно быть явно сконфигурировано на VPN клиенте и шлюзе, включая UDP порт, который используется для инкапсуляции ESP пакетов.

Чтобы поддерживать эти нестандартные IPSec NAT Traversal реализации, Вам нужно знать, во-первых, как включить это средство на VPN клиенте и шлюзе, и знать точно UDP порты, используемые для UDP инкапсуляции. Любой VPN администратор, который знает свою работу, должен быть в состоянии предоставить Вам эту важную информацию. Иначе Вам придётся предпринять некоторые исследования и посетить веб-сайты VPN поставщиков или позвонить в их службы технической поддержки.

Здесь представлена некоторая информация, собранная из разных постов на досках объявлений для некоторых хорошо известных VPN клиентов.

5.1. Checkpoint

Если бы у Вас был установлен CheckPoint 4.1 SP6 или NG1 FP1 или выше, то он работал бы со следующими протокольными определениями:

• UDP 500 (послать(send)-принять(receive)) — для аутентификации
• UDP 2746 (send-receive) — для зашифрованного трафика
• TCP 264 (выходной(Outbound)) *опционально* — для обновления топологии

Для получения дополнительной информации, просмотрите тему CP SecuRemote Client can't get out (CP SecuRemote клиент не может выйти).

5.2. Cisco

Cisco VPN клиент версии 3.6 и старше, серия Cisco VPN Concentrator 3000 и Cisco PIX версии 6.3 или старше поддерживают IPSec NAT Traversal. Это также объяснено в статье HOW TO: Enable a Cisco IPSec VPN Client to Connect to a Cisco VPN Concentrator Through ISA Server 2000 (КАК?: Включение Cisco IPSec VPN клиента, чтобы подключиться к Cisco VPN концентратору через ISA Server 2000). Для устаревших версий Cisco VPN клиента и серии Cisco VPN Concentrator 3000 протокол NAT-T или UDP инкапсулированный ESP был сделан по умолчанию на UDP порте 10000 вместо UDP порта 4500.

Насколько я знаю, NAT-T включен по умолчанию в серии Cisco VPN Concentrator 3000. Однако, для Cisco PIX Вы должны включать NAT-T поддержку явно с помощью команды «isakmp nat-traversal [natkeepalive]». Поддержка (keep-alive) по умолчанию установлена на 20 секунд (диапазоны от 10 до 3600 секунд). Также, убедитесь, что средство Transparent Tunneling(прозрачное туннелирование) включено на концентраторе Cisco VPN Concentrator.

Некоторые люди пробовали использовать собственную опцию Cisco, чтобы инкапсулировать IPSec трафик над единственным TCP соединением через ISA сервер. Это средство было введено в версии 3.5 VPN клиента. Однако, документация Cisco предупреждает Вас, что оно не поддерживается через любой прокси-сервер. Поскольку ISA сервер удаляет оригинальные заголовки и создаёт новые, поэтому, действуя как прокси-сервер, TCP инкапсуляция не будет работать через ISA сервер. Это не является проблемой ISA сервера, это следствие того факта, что Cisco VPN Concentrator не обрабатывает MSS согласование, соответствующее RFC спецификациям.

Для получения дополнительной информации просмотрите тему Cisco VPN client ->ISA 2000-> Cisco VPN Concentrator.

5.3. Microsoft

И L2TP/IPSec VPN client for Windows 98, Windows Me and Windows NT 4.0 and the Updated L2TP/IPSec VPN client for Windows 2000 and XP имеют поддержку для IPSec NAT Traversal. Однако, имейте в виду, что Вам понадобится Windows 2003 server в качестве VPN шлюза для NAT-T поддержки. Хорошие новости — прохождение обоих L2TP/IPSec VPN клиентов через ISA сервер к Windows 2003 VPN шлюзу было успешно протестировано Томом Шиндером(Tom Shinder).

Насколько я знаю, L2TP/IPSec VPN клиент для Windows 98, Windows Me и Windows NT 4.0 является так называемой «Bump in the Stack»-реализацией. Это значит, что вся IPSec обработка делается ниже транспортного уровня. Поэтому внутренний хост, на котором установлен VPN клиент, должен быть сконфигурирован как SecureNAT клиент и Вы можете применить только выходной контроль доступа на основе адресного набора клиента для трафика к удалённому VPN шлюзу.

Однако, L2TP/IPSec VPN клиент для Windows 2000 и XP является так называемой OS интегрированной реализацией. Следующий рисунок, взятый с веб-сайта Microsoft, демонстрирует подробности реализации VPN клиента в Windows 2000 и XP:

Согласно этому рисунку, пакеты, кажется, проходят дважды через Winsock интерфейс и вся IPSec обработка, кажется, делается на транспортном уровне. Это предполагает то, что после IPSec обработки и NAT-T инкапсуляции, IPSec трафик, возможно, может быть переадресован Firewall клиентом к Firewall сервису на ISA сервере. Однако, этот сценарий уже был проверен Томом Шиндером и он не сработал. Поэтому даже для OS интегрированной реализации внутренний хост, на котором установлен VPN клиент, должен быть сконфигурирован как SecureNAT клиент и Вы можете применить только выходной контроль доступа на основе клиентского адресного набора для трафика к удалённому VPN шлюзу.

5.4. Netscreen

Насколько я знаю, Netscreen реализовал NAT Traversal начиная с ScreenOS 3.0.0 или старше и Netscreen Remote версии 6.0 или старше, хотя, кажется, то, что они поддерживают — это первая версия проектов. NetScreen Remote клиент автоматически определяет, использует ли VPN Peer (NetScreen блок) NAT Traversal и UDP инкапсулированные ESP пакеты посылаются ли на оригинальный IKE UDP порт 500 вместо нового UDP порта 4500.

Чтобы включить NAT-T для клиента, просто включите NAT-T опцию на экране шлюза, когда конфигурируете Пользователя(User) в NetScreen блоке. Также, убедитесь, что когда устанавливаете Phase 1 Proposal(предложение фазы 1) для NAT-T, опция UDP checksum(UDP контрольная сумма) отключена.

5.5. Nortel Contivity

Вы можете пропускать Nortel Extranet Access клиентское программное обеспечение через ISA сервер, если Nortel Contivity переключатель(switch) работает с одной из новейших прошивок версии 04_05.024 или старше и Вы используете новейшее клиентское программное обеспечение версии 4.65 или старше. Вот что Вам нужно сделать на Contivity переключателе(Switch):

• На левой стороне конфигурационной страницы кликните на «Services», затем «IPSEC». В направлении середины страницы находится установка «NAT Traversal». Проверьте, что она у Вас включена и установите её на UDP порт 4500 (строго рекомендуется).
• Как только вышеуказанный шаг сделан, зайдите в «Profiles», затем в «Groups». Под определяемой группой, в которой Вы хотите иметь NAT Traversal включенным, кликните на «Edit». Под секцией «IPSEC» кликните на «Configure». В самом низу страницы убедитесь, что «Auto-Detect NAT» выбрано и оставьте установку «NAT Keepalive» на значении 18 секунд.

Если VPN администратор установил NAT Traversal порт на нечто отличное от UDP порта 4500 (т.е. UDP порт 10001), Вам нужно принять соответственно IPSec NAT-T протокольное определение или создать новое и добавить его в IPSec протокольное правило транзитной пересылки.

5.6. Sonicwall

SonicWALL с прошивкой(firmware) 6.3, VPN клиент версии 8.0 и Global VPN клиент версии 1.0 поддерживают IPSec NAT Traversal. Поскольку это, кажется, недавние выпуски, я предполагаю, что они уже используют UDP порт 4500 для UDP инкапсуляции ESP пакетов и что реализация поддерживает автоопределение NAPT устройства по пути(along the path).

Я не нашёл большого количества постов на досках объявлений о SonicWALL VPN решении. Однако, один пост упоминал, что VPN клиент должен быть сконфигурирован для агрессивного режима (aggressive mode), иначе IKE согласование не захочет запускаться на стандартном UDP порте 500, только на UDP порте с более высоким номером.

6. Заключение

В этой статье мы прошли то, как Вы можете пропускать IPSec VPN клиент через ISA сервер. Имейте в виду, что это может быть сделано только если IPSec реализация поддерживает средство, названное NAT Traversal. Как это средство работает и как конфигурировать ISA сервер и клиентов для того, чтобы его поддерживать — полностью объяснено. Кроме того, даётся некоторое количество полезной информации, собранной из многих постов на досках объявлений.

Автор: Стефан Паусиль (Stefaan Pouseele)

Стефан Паусиль (Stefaan Pouseele) является сетевым инженером, работающим в Cevi NV в Бельгии. 1 октября 2002 он получил от Microsoft престижную премию Most Valuable Professional (MVP) Award 2003 (Наиболее Ценный Специалист) за его вклад в online сообщество, посвященное ISA Server. Стефан имеет более чем 25 летний опыт в проектировании, внедрении и отладке LAN и WAN сетей для заказчиков. Он также отвечал за большую частную WAN сеть на Западе и Востоке Flanders (Бельгия).