Руководство клиента SecureNAT (SecureNET) по вселенной

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

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

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

Рис. 1. Сценарий простой сети SecureNAT

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

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

Рис. 2. Сценарий сложной сети SecureNAT

Сценарий VPN-клиента применяется к машинам, которые создали VPN-соединение с брандмауэром ISA.

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

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

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

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

ПРЕДУПРЕЖДЕНИЕ:
Раздельное туннелирование представляет собой серьезную угрозу безопасности и никогда не должно быть включено на ваших VPN-клиентах. ISA 2004/06 поддерживает подключения VPN-клиентов SecureNAT к Интернету через тот же брандмауэр 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) не обеспечивает аутентификацию пользователя и требует, чтобы компонент приложения отправлял учетные данные пользователя.

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

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

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

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

Рис. 3. Обмен данными между клиентом и сервером в стандартном режиме FTP

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

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

ПРЕДУПРЕЖДЕНИЕ:
Хотя клиенты SecureNAT, работающие с приложениями SOCKS 4, могут поддерживать сложные протоколы для приложения, настроенного на использование прокси-сервера SOCKS, прокси-сервер SOCKS не позволит клиенту воспользоваться преимуществами проверки подлинности пользователя/группы. Фильтр прокси-приложений SOCKS 4 на брандмауэре ISA 2004 не принимает учетные данные пользователя, которые позволили бы управлять доступом на основе пользователей/групп. Однако, если вам требуется аутентификация пользователя для клиентов SOCKS, вы можете рассмотреть приложение Cornerpost Software Surrogate Socket 5.0.

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

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

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

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

Недостатки конфигурации SecureNAT приведены в таблице 1.

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

Преимущества клиента SecureNAT

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

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

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

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

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

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

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

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

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

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

В таблице 2 подробно описаны преимущества конфигурации клиента SecureNAT.

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

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

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

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

Разрешение имен и «петля» через брандмауэр ISA 2004

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

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

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

После этого веб-сервер отвечает непосредственно клиентскому компьютеру SecureNAT. Причина этого в том, что исходный IP-адрес в запросе, пересылаемом брандмауэром ISA на веб-сервер во внутренней сети, является IP-адресом клиента SecureNAT. Это заставляет веб-сервер во внутренней сети распознавать IP-адрес как адрес в своей локальной сети и напрямую отвечать клиенту SecureNAT. Клиентский компьютер SecureNAT отбрасывает ответ от веб-сервера, потому что он отправил запрос на общедоступный IP-адрес брандмауэра ISA, а не на IP-адрес веб-сервера во внутренней сети. Ответ отбрасывается, так как клиент SecureNAT рассматривает его как ответ на соединение, которое он не запрашивал.

На рис. 4 изображен клиент SecureNAT, возвращающийся через брандмауэр ISA 2004.

Рисунок 4: SecureNAT «обратная петля»

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

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

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

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

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

Резюме

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