Для системного администратора

Клиент SecureNAT – это любое устройство, настроенное с адресом шлюза по умолчанию, который может маршрутизировать Интернет-соединения через сервер ISA 2004. Т.е. в данном случае ISA-сервер выполняет роль маршрутизатора исходящего доступа. У клиента SecureNAT нет традиционных отношений клиент/сервер с ISA-сервером. Существует три наиболее распространенных варианта использования клиента SecureNAT:

• Простой
• Сложный
• VPN-клиент

Простой вариант – это использование только одной подсети, расположенной за ISA-сервером. Например, ваш ISA-сервер находится на границе сети, и один из его интерфейсов напрямую выходит в Интернет, а другой смотрит во внутреннюю сеть. Все компьютеры за ISA-сервером находятся в единственной подсети (например, 10.0.0.0/8). Во внутренней сети нет маршрутизаторов. На Рисунке 1 показан такой вариант сети.

Рисунок 1: Простой вариант использования SecureNAT

В этом случае клиент SecureNAT настроен так, что его шлюзом по умолчанию является IP-адрес внутреннего интерфейса ISA-сервера. Шлюз по умолчанию клиента SecureNAT можно настроить вручную или назначить его автоматически через DHCP. DHCP-сервер может быть самими ISA-сервером, или же это может быть отдельный сервер внутренней сети.

Сложный вариант используется в том случае, если внутренняя сеть по умолчанию состоит из нескольких подсетей, управляемых LAN-маршрутизатором или серией маршрутизаторов или коммутаторов 3-го уровня. В таком случае адрес шлюза по умолчанию для каждого клиента SecureNAT зависит от расположения компьютера клиента. Адресом шлюза по умолчанию клиента SecureNAT будет маршрутизатор, который разрешает доступ клиенту в другие сети внутри организации, а также в Интернет. Инфраструктура маршрутизации должна быть настроена на поддержку клиента SecureNAT так, чтобы запросы, связанные с Интернетом, переадресовывались на внутренний интерфейс ISA-сервера. На Рисунке 2 показан этот вариант сети.

Рисунок 2: Сложный вариант использования SecureNAT

Вариант VPN-клиент применяется к компьютерам, которые создают VPN-соединения с ISA-сервером.

При использовании сервера ISA 2000, когда компьютер VPN-клиента устанавливает соединения с VPN-сервером, таблица маршрутизации VPN-клиента меняется так, что адресом шлюза по умолчанию является адрес VPN-сервера. Если изменения в настройки по умолчанию не вносились, клиент не сможет соединиться с ресурсами Интернета, пока он соединен с VPN-сервером ISA-сервера.

Можно настроить VPN-клиента ISA-сервера 2000 как клиент брандмауэра или web-прокси и разрешить клиенту доступ к Интернету через ISA-сервер 2000. Также VPN-клиента сервера ISA 2000 можно настроить на разрешение разделенного туннелирования. Однако, учитывая крайне негативные результаты разрешения разделенного туннелирования, всегда рекомендуется не разрешать его.

В отличие от сервера ISA 2000, VPN-сервер серверов ISA 2004/06 не требует настройки VPN-клиента в качестве клиента брандмауэра или web-прокси для разрешения доступа в Интернет через тот же самый VPN ISA-сервер, с которым они соединяются. Поскольку VPN-клиенты не настроены как клиенты брандмауэра или web-прокси, они фактически являются клиентами SecureNAT. Таким образом, мы даем VPN-пользователям доступ в корпоративную сеть через VPN-соединение, и в то же время даем им доступ в Интернет через ISA-сервер. Риски, связанные с разделенным туннелированием, устраняются.

Обратите внимание, что вам не нужно глубоко понимать настройки таблицы маршрутизации VPN-клиентов или различия управления назначениями маршрутов по умолчанию между версиями VPN-клиента Windows. Помните, что когда VPN-клиент создает VPN-соединение с сервером ISA 2004 /VPN, этот клиент сможет соединяться с Интернетом через ISA-сервер только на основе правил доступа, настроенных вами.

ВНИМАНИЕ: Разделенное туннелирование представляет собой значительный риск системы безопасности. Данную функцию не следует внедрять на VPN-клиентах. Сервер ISA 2004/06 поддерживает SecureNAT-соединения VPN-клиентов с Интернетом через тот же самый сервер ISA 2004/06, с которым устанавливается соединение. Использование раздельного туннелирования становится ненужным. Помимо этого, сервер ISA 2004/06 усиливает поддержку клиента SecureNAT для VPN-клиентов с помощью включения контроля доступа, основанного на группах/пользователях для VPN-клиентов.

Недостатки клиента SecureNAT

Хотя клиент SecureNAT – это простейший в вопросах настройки тип клиента для серверов ISA 2004/06, он является наименее удобным и наименее защищенным из трех типов клиентов для ISA 2004/06. Ограничения клиента SecureNAT таковы:

• Невозможность аутентификации на сервере для жесткого контроля доступа, основанного на пользователях/группах
• Невозможность использования преимуществ сложных протоколов без помощи фильтра приложений (редактор NAT)
• Зависимость от инфраструктуры маршрутизации для доступа в Интернет
• Обязательная настройка на ISA-сервере определения протоколов для поддержки соединений, проходящих через ISA-сервер

Клиент SecureNAT не отсылает учетные данные ISA-серверу, поскольку для этого требуется специальное программное обеспечение. Протокол TCP/IP вместе с коммутатором 3-го уровня (модели DoD) не дает возможности использования аутентификации пользователя; для отправки пользовательских учетных данных требуется отдельное приложение.

Клиенты брандмауэра и web-прокси могут отсылать учетные данные, а клиент SecureNAT не может. Клиент брандмауэра использует свое программное обеспечение для отправки пользовательских учетных данных, а web-браузеры, настроенные на использование ISA-сервера в качестве web-прокси, обладают встроенной возможностью отправки учетных данных. Вы не сможете использовать жесткий контроль доступа на основе пользователей/групп на компьютерах, настроенных только как клиенты SecureNAT.

Клиенты SecureNAT не могут соединяться с Интернетом (или с любым другим ресурсом через ISA-сервер) с помощью сложных протоколов без помощи фильтра приложений, установленного на ISA-сервере. Сложным протоколом считается тот, который требует несколько первичных или вторичных соединений. Классическим примером сложного протокола является FTP в стандартном режиме (режим Порта).

Когда FTP-клиент, работающий в стандартном режиме, устанавливает соединение с FTP-сервером, начальное соединение (контрольный канал) устанавливается по TCP-порту 21. FTP-клиент и сервер переговариваются о номере порта, по которому FTP-клиент будет получать данные (файл для скачивания), а FTP-сервер возвращает данные со своего собственного порта TCP 20 на условленный порт. Это входящее соединение является запросом на новое первичное соединение и не является ответом на первичное исходящее соединение, выполненное FTP-клиентом при установлении сессии контрольного канала.

Брандмауэр должен знать о соединения между FTP-клиентом и FTP-сервером для того, чтобы правильные порты были доступны для запросов на новые входящие соединения к ISA-серверу. На ISA-сервере это достигается с помощью настраиваемого фильтра приложений FTP-доступа (FTP Access Application Filter). На Рисунке 3 изображены соединения клиента и сервера FTP в стандартном режиме.

Рисунок 3: FTP-соединение клиента/сервера в стандартном режиме

Ограничение SecureNAT, касающееся сложных протоколов, становится проблемой в вопросах, связанных с Интернет-играми и аудио/видео приложениями. Эти приложения обычно требуют несколько входящих и исходящих первичных соединений. Клиент SecureNAT не сможет использовать их, если вы не установите специальные фильтры приложений на ISA-сервере для их поддержки. Наоборот, клиенты брандмауэра легко справляются с приложениями, требующими несколько входящих и исходящих первичных соединений, без установки каких-либо дополнений на сервере.

Естественно, в каждом правиле есть исключения, есть они и здесь: поддержка сложных протоколов для клиентов SecureNAT возможна, если приложение, установленное на клиенте SecureNAT, разработано для работы с SOCKS-прокси. В этом случае, приложение явно настроено на соединение с фильтром приложений SOCKS 4 ISA-сервера. Фильтр приложений SOCKS 4 может управлять соединениями от лица приложения на компьютере клиента SecureNAT.

ВНИМАНИЕ: Хотя клиенты SecureNAT с запущенными приложениями SOCKS 4 могут поддерживать сложные протоколы для приложений, настроенных на использование SOCKS-прокси, SOCKS-прокси не разрешит клиенту использовать аутентификацию на основе пользователей/групп. Фильтр приложений SOCKS 4–прокси на ISA 2004 не принимает пользовательские учетные данные, необходимые для контроля доступа на основе пользователей/групп. Однако, если вам необходимо использовать аутентификацию SOCKS-клиентов, обратитесь к программе Surrogate Socket 5.0 от Cornerpost.

Клиент SecureNAT зависит от инфраструктуры маршрутизации организации. В отличие от клиентов брандмауэра и web-прокси, которые отсылают запросы на Интернет-соединения напрямую на сервер ISA 2004 (и потому, им необходимо знать только маршрут к внутреннему интерфейсу ISA-сервера), клиент SecureNAT при переадресации Интернет-запросов на внутренний интерфейс ISA-сервера зависит от инфраструктуры маршрутизации. Если соединение на своем пути встречает маршрутизатор, который не маршрутизирует Интернет-соединения через ISA-сервер, попытка соединения не удается.

СОВЕТ: На ISA-сервер необходимо создать определения протоколов для каждого протокола, к которому нужен доступ клиенту SecureNAT. Это нужно сделать даже в том случае, если вы создаете правило доступа, разрешающее доступ клиента SecureNAT ко всем протоколам. Для клиента SecureNAT «все протоколы» означает все протоколы, к которым есть определения протоколов. При этом при настройке для клиента брандмауэра правила доступа, где «все протоколы» означает все протоколы TCP и UDP, вне зависимости от того, есть ли для них определение или нет.

Из-за ограничений SecureNAT компьютер следует настраивать только как клиент SecureNAT только в том случае, если выполняется как минимум одно из следующих условий:

• Компьютер не поддерживает программное обеспечение клиента брандмауэра (не-Windows клиенты) и требует поддержки протоколов, отличных от тех, которые предоставляются клиентом web-прокси (протоколы, отличные от HTTP/HTTPS и FTP).
• Компьютеру необходим исходящий доступ к ICMP и PPTP.
• По административным или политическим причинам вы не можете установить клиента брандмауэра на компьютерах, которым требуется доступ к протоколам, отличным от тех, которые предоставляются клиентом web-прокси.

Все недостатки SecureNAT сведены в Таблицу 1.

Таблица 1: Недостатки клиента SecureNAT

Достоинства клиента SecureNAT

Не смотря на ограничения, описанные в предыдущем разделе, не следует считать, что клиент SecureNAT никуда не годится. На самом деле, некоторые слабые стороны клиента SecureNAT также являются и его сильными сторонами. Достоинства клиента SecureNAT таковы:

• Поддержка операционных систем, отличных от Windows
• Поддержка не-TCP/UDP протоколов (таких, как PPTP [GRE] и ICMP)
• Нет необходимости установки и настройки программного обеспечения для клиента

Основной целью использования клиента SecureNAT является поддержка доступа операционных систем не от компании Microsoft к широкому диапазону протоколов, отличных от тех, которые поддерживает клиент web-прокси. Клиент брандмауэра работает только с операционными системами Windows. Без клиента SecureNAT единственными доступными протоколами для операционных систем не от компании Microsoft являются те, которые поддерживаются клиентом web-прокси (т.е HTTP/HTTPS и FTP).

Помимо этого, клиент SecureNAT находит применение и при работе с операционными системами Microsoft. Клиент брандмауэра перехватывает исходящие TCP- и UDP-соединения, устанавливаемые Winsock-приложениями, и переадресует их на сервер ISA 2004. Однако, клиент брандмауэра не перехватывает не-TCP/UDP соединения. Сетевые протоколы, например, ICMP (используемый для команды ping и других утилит диагностики сети) и GRE (используется в VPN-протоколе PPTP), не используют в качестве транспортных протоколов UDP или TCP. Для поддержки доступа через ISA-сервер с помощью этих протоколов вы должны настроить компьютер как клиент SecureNAT.

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

Например, вы захотите разрешить все исходящие PPTP VPN-соединения для выделенной группы пользователей. Но это невозможно, поскольку PPTP требуется GRE; таким образом, клиент брандмауэра не используется, и информация о пользователе не передается на ISA-сервер. Если вы создадите правило доступа для исходящих PPTP-соединений, которое требует аутентификации пользователя, соединение не удастся. Единственным доступным методом контроля исходящих PPTP-соединении будет использование IP-адреса источника.

СОВЕТ: На ISA-сервер для каждого протокола, к которому нужен доступ клиенту SecureNAT, должно быть создано определение протокола, причем даже в том случае, если вы создали правило доступа, разрешающее клиенту SecureNAT доступ по всем протоколам. Для клиента SecureNAT «все протоколы» означает все протоколы, к которым есть определения протоколов. При этом при настройке для клиента брандмауэра правила доступа, где «все протоколы» означает все протоколы TCP и UDP, вне зависимости от того, есть ли для них определение или нет.

ЗАМЕЧАНИЕ: ICMP в основном используется утилитой ping, хотя и другие утилиты, например tracert, тоже используют ICMP. GRE требуется, если вы хотите разрешить клиентам исходящий доступ ко внешним VPN-серверам по VPN-протоколу PPTP. VPN-клиенты для исходящих соединений могут использовать протокол L2TP/IPSec с обходом NAT (NAT-T) и для этого SecureNAT не требуется. Протокол L2TP/IPSec NAT-T для исходящего доступа к VPN-серверам L2TP/IPSec NAT-T использует только UDP-порты 500 и 4500. Поэтому поверх L2TP/IPSec VPN-соединений вы можете использовать клиента брандмауэра для принудительного контроля доступа на основе пользователей/групп.

Возможно, самой распространенной причиной внедрения клиента SecureNAT является возможность устранения необходимости установки и настройки программного обеспечения клиента. Сетевые администраторы не склонны устанавливать много программ на компьютеры клиентов. Помимо этого, создается ощущение того, что установка и настройка клиентов брандмауэра и web-прокси отнимает очень много времени, хотя на самом деле это верно лишь в самых нестандартных ситуациях.

На самом деле, вероятность того, что программное обеспечение клиента брандмауэра будет влиять на работу сетевых компонентов других клиентов, крайне мала, а административные издержки значительно снижаются, если вы автоматизируете установку и настройку клиентов брандмауэра и web-прокси.

В Таблице 2 показаны достоинства клиента SecureNAT.

Таблица 2: Преимущества клиента SecureNAT

Разрешение имен для клиентов SecureNAT

Разрешение имен – это важная проблема не только установки серверного программного обеспечения, но и всех клиентов ISA-сервера. Каждый клиент ISA-сервера разрешает имена по-своему. Клиент SecureNAT разрешает имена узлов внутренней и внешней сети, используя адрес DNS-сервера, настроенный на сетевом интерфейсе самого клиента SecureNAT.

Тот факт, что клиент SecureNAT должен уметь разрешать имена на основе собственных настроек TCP/IP, может стать проблемой для организаций с выходом в Интернет, которым требуется доступ к ресурсам при соединении с корпоративной сетью как для узлов внутри корпоративной сети, так и работе этих узлов с сетью из удаленного места. Помимо этого существуют значительные трудности при попытке клиента SecureNAT «замыкания на себя» через ISA-сервер для доступа к ресурсам во внутренней или любой другой из защищенных сетей ISA-сервера.

Клиенты SecureNAT должны быть настроены на использование DNS-сервера, способного разрешать как имена во внутренней сети, так и в Интернете. В большинстве организаций есть свои DNS-серверы внутри корпоративной сети. В этом случае клиент SecureNAT должен быть настроен на использование внутреннего DNS-сервера, который может разрешать имена внутренних и внешних узлов.

Разрешение имен и «замыкание на себя» через сервер ISA 2004

Рассмотрим пример организации, которая использует в качестве имени домена internal.net для ресурсов, расположенных во внутренней сети за ISA-сервером. Организация использует это же имя для хранения ресурсов для удаленных пользователей и для публикации этих ресурсов во внутренней сети. Например, web-сервер компании расположен во внутренней сети, его IP-адресом во внутренней сети будет 192.168.1.10.

В организации также есть собственные открытые DNS-серверы, а базу DNS внесен IP-адрес 222.222.222.1 для имени www.internal.net. Внешние пользователи используют это имя, www.internal.net, для доступа к web-серверу компании. Web-сервер опубликован с помощью правила web-публикации ISA-сервера, и у внешних пользователей нет проблем с доступом к опубликованному серверу.

Проблемы возникают при попытке клиентов SecureNAT внутренней сети соединиться с этим web-сервером. Все попытки неудачны. Причина в том, что клиенты SecureNAT настроены на использование того же самого DNS-сервера, который используют внешние клиенты для разрешения имени www.internal.net. Это имя разрешается в открытый адрес внешнего интерфейса ISA-сервера, используемый в правиле web-публикации. Клиент SecureNAT разрешает имя www.internal.net в этот адрес и переадресует соединение на внешний интерфейс ISA-сервера. Далее, ISA-сервер переадресует запрос на web-сервер во внутренней сети.

Web-сервер отвечает напрямую на компьютер клиента SecureNAT. Дело в том, что IP-адрес источника в запросе, который переадресуется ISA-сервером на web-сервер во внутренней сети, это IP-адрес клиента SecureNAT. И получается, что web-сервер во внутренней сети распознает этот IP-адрес как адрес локальной сети, и потому отвечает напрямую клиенту SecureNAT. Компьютер SecureNAT отклоняет ответ web-сервера, поскольку он посылал запрос на открытый адрес ISA-сервера, а не на IP-адрес web-сервера во внутренней сети. Ответ отклоняется, поскольку клиент SecureNAT понимает этот ответ не как ответ на свой запрос.

На Рисунке 4 изображено замыкание на себя клиента SecureNAT через сервер ISA 2004.

Решение данной проблемы является использование инфраструктуры разделенной DNS. Практически во всех случаях, когда организации требуется удаленный доступ к ресурсам внутренней сети, инфраструктура разделенной DNS является решением проблем клиентов, меняющих свое место расположения (узлы, работающие как внутри, так и удаленно), и клиентов SecureNAT.

В инфраструктуре разделенной DNS клиент SecureNAT настроен на использование внутреннего DNS-сервера, который разрешает имена во внутренние адреса ресурсов. Удаленные узлы могут разрешать те же самые имена, но разрешают их в IP-адрес внешнего интерфейса ISA-сервера, на котором и опубликован данный ресурс. Таким образом устраняется замыкание на себя клиентов SecureNAT через ISA-сервер, и все соединения клиентов SecureNAT к опубликованным серверам становятся успешными.

На Рисунке 5 показан метод разрешения проблемы «замыкания на себя» с помощью разделенной инфраструктура DNS. В Таблице 3 приведены важные замечания по использованию DNS для клиентов SecureNAT.

ЗАМЕЧАНИЕ: Именно поэтому web-разработчики никогда жестко не привязывают IP-адреса или имена в ссылках, возвращаемых пользователям. Например, web-разработчик привяжет ссылку, которая указывает на адрес http://192.168.1.1/info в ответе пользователю. Клиенты внутренней сети получат доступ, поскольку этот IP-адрес является адресом web-сервера во внутренней сети, но удаленные пользователи не смогут соединиться с ресурсом, поскольку этот адрес недоступен из Интернета. Такими ошибками страдают большинство Java-приложений и даже приложения Microsoft, например SharePoint Portal Server (хотя некоторые из этих проблем можно решить с помощью функции Переводчика ссылок (Link Translator) ISA-сервера).

Рисунок 5: Разделенная DNS решает проблемы SecureNAT

Таблица 3: Замечания по использованию DNS для клиентов SecureNAT

Резюме

В данной статье мы рассмотрели работу клиента SecureNAT и то, как клиент SecureNET может быть использован в окружении ISA-сервера. Мы дали определение клиенту SecureNAT, показали достоинства и недостатки клиента, а также объяснили проблемы, связанные с работой DNS и клиентов SecureNAT. В двух словах, можно сказать, что клиент SecureNAT следует использовать только с операционными системами не от компании Microsoft и на тех компьютерах, которые используют не-TCP/UDP протоколы, например ICMP и GRE (PPTP). В окружении Windows более безопасным вариантом является использование клиентов брандмауэра и web-прокси.

Автор: Томас Шиндер (Thomas Shinder)
Источник: www.isadocs.ru