Monday, December 11th, 2017

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

Published on Февраль 11, 2009 by   ·   Комментариев нет

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

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

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

Securenat

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

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

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

Securenat

Рисунок 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 в стандартном режиме.

Securenat

Рисунок 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.

Недостаток Объяснение
Невозможность аутентификации на сервере ISA 2004 Клиент SecureNAT не может отсылать пользовательские учетные данные (имя пользователя и пароль) на сервер ISA 2004. Таким образом становится невозможным использование жесткого контроля исходящего доступа на основе пользователей/групп. Единственный доступный метод контроля доступа для клиентов SecureNAT основан на IP-адресе клиента.
Невозможность использования сложных протоколов Сложным протоколам требуется несколько первичных и/или вторичных соединений. Интернет-игры, аудио/видео приложения и системы быстрого обмена сообщениями часть требуют поддержки сложных протоколов. Клиент SecureNAT не может получить доступ к Интернет-приложениям с помощью сложных протоколов без помощи фильтра приложений, установленного на ISA-сервере. Единственным исключением является включенная на клиенте SecureNAT поддержка SOCKS-прокси. В сервере ISA 2004 есть встроенный фильтр SOCKS 4.
Зависимость от существующей инфраструктуры маршрутизации Клиент SecureNAT не переадресует соединения прямо на сервер ISA 2004. Он зависит от инфраструктуры маршрутизации в организации. Каждый маршрутизатор на пути клиента SecureNAT к серверу ISA 2004 должен знать путь в Интернет через ISA-сервер. Может потребоваться перенастройка сетевых маршрутизаторов на использование новых шлюзов (шлюзов по умолчанию).
Информация о пользователе не включена в журналы брандмауэра и web-прокси Имя пользователя попадает в журналы брандмауэра и web-прокси только в том случае, если клиент отсылает эту информацию на ISA-сервер. Клиент всегда должен отсылать информацию о пользователе на брандмауэр, поскольку на 1-м уровне в 6 заголовках этой информации нет. Только клиенты брандмауэра и web-прокси могут отсылать информацию о пользователе на ISA-сервер и включать эту информацию в журналы. О соединениях клиента SecureNAT в журнал заносится только IP-адрес, а информация о пользователе никогда не сохраняется, если компьютер настроен только как клиент SecureNAT

Таблица 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.

Достоинства Объяснение
Дает поддержку дополнительных протоколов для операционных систем, отличных от Windows Операционные системы, отличные от Windows, не поддерживают клиента брандмауэра. Если вы хотите обеспечить поддержку протоколов, отличных от поддерживаемых клиентом web-прокси (т.е. HTTP/HTTPS/FTP), SecureNAT – единственная возможность для таких операционных систем, как Linux, UNIX и Macintosh.
Поддержка не-TCP/UDP протоколов Клиент SecureNAT – единственный клиент сервера ISA 2004, поддерживающий не-TCP/UDP протоколы. Ping, tracert и PPTP – вот некоторые из не-TCP/UDP протоколов, которым требуется клиент SecureNAT. Заметьте, вы не можете использовать жесткий контроль доступа на основе пользователей/групп для не-TCP/UDP, поскольку клиент SecureNAT не поддерживает аутентификацию пользователей.
Не требуется программное обеспечение для установки и настройки Клиенту SecureNAT не требуется никакой установки и настройки особого программного обеспечения на компьютере клиента. Единственным требованием является то, что адрес шлюза по умолчанию компьютера должен быть настроен так, чтобы он мог переадресовывать Интернет-запросы через сервер ISA 2004.
Наилучшая конфигурация для опубликованных серверов При публикации серверу часто требуется не только принимать соединения Интернет-узлов, но и создавать новые соединения. Лучшим примером является SMTP-ретранслятор, настроенный на входящую и исходящую ретрансляцию. Такому ретранслятору для получения входящих сообщений с удаленных SMTP-серверов не нужно быть настроенным в качестве клиента SecureNAT (поскольку вы можете заменить оригинальный IP-адрес Интернет-узла на IP-адрес ISA-сервера). Однако, для отправки исходящие почты на SMTP-серверы Интернета SMTP-ретранслятор должен быть настроен как клиент SecureNAT. Детально мы рассмотрим это проблему в Главе 10.

Таблица 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.

Securenat

Рисунок 4: Замыкание на себя клиента SecureNAT

Решение данной проблемы является использование инфраструктуры разделенной 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-сервера).

Securenat

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

DNS для SecureNAT Объяснение
Разрешение внутренних и внешних имен Клиент SecureNAT должен уметь разрешать все имена узлов через локально настроенный адрес DNS-сервера. DNS-сервер должен разрешать имена узлов внутренней, а также внешней сети. Если DNS-сервер, который использует клиент SecureNAT, не может разрешить локальные или внешние имена, запрос на разрешение имени будет неудачным, и соединение оборвется.
Замыкание на себя через сервер ISA 2004 Клиенты SecureNAT не должны замыкаться на себя через сервер ISA 2004 при доступе к ресурсам внутренней сети. Обычно это происходит, если сервер внутренней сети опубликован для Интернета. Клиент SecureNAT настроен на использование DNS-сервера, который разрешает имя сервера в IP-адрес внешнего интерфейса сервера ISA 2004. Клиент SecureNAT посылает запрос на соединение на этот IP-адрес, и соединение не устанавливается. Решением является использование инфраструктуры разделенной DNS.
Организации с внутренними DNS-серверами Организации с внутренними DNS-серверами должны настроить свои серверы на разрешение имен внутренних и внешних узлов. Внутренние DNS-серверы являются основными для имен внутренней сети. DNS-серверы должны быть настроены либо на выполнение рекурсии DNS-серверов Интернета, либо на использование переадресации запросов для разрешения имен Интернет-узлов. Обратите внимание, что организация может выбрать использование различных серверов для разрешения локальных и внешних имен, но клиенты SecureNAT должны с помощью DNS разрешать и внутренние, и внешние имена.
Организации без внутренних DNS-серверов В небольших организациях может не быть DNS-серверов во внутренней сети. В этом случае для локального разрешения имен используются альтернативные методы, например WINS, широковещательное разрешение имен NetBIOS или локальные файлы HOSTS. Клиенты SecureNAT должны быть настроены на использование DNS-сервера, расположенного в Интернете (например, DNS-сервер провайдера) или же на DNS-сервер, работающий только в режиме кэширования, на сервере ISA 2004.
У клиента SecureNAT нет связи с Интернетом Основной причиной того, что клиент SecureNAT не может соединиться с Интернетом, является ошибка разрешения имен. Проверьте настройки DNS-сервера на клиенте SecureNAT. Для тестирования разрешения имен можно воспользоваться утилитой nslookup на компьютере клиента SecureNAT.
У клиента SecureNAT нет связи с серверами внутренней сети Основной причиной того, что клиент SecureNAT не может соединиться с внутренними ресурсами по их DNS-именам, является ошибка разрешения имен. Проверьте настройки DNS-сервера клиента SecureNAT. Обратите внимание, что если клиент SecureNAT настроен на использование DNS-сервера, находящегося в Интернете (например, DNS-сервер провайдера), клиент SecureNAT не сможет разрешать имена внутренних узлов. Проблему можно решить настройкой клиента SecureNAT на использование внутреннего DNS-сервера, который может разрешать имена внутренних и внешних узлов, или с помощью альтернативных методов разрешения имен, например, локальных файлов HOSTS.
Клиенты SecureNAT должны быть настроены на использование внутреннего DNS-сервера Хотя в небольших организациях может и не быть DNS-сервера, ответственного за разрешение имен узлов внутренней сети, следует избегать использования открытых DNS-серверов клиентами SecureNAT. Вместо этого настройте ваш ISA-сервер как DNS-сервер, работающий только в режиме кэширования, а клиентов SecureNAT настройте на использование этого DNS-сервера на ISA-сервере. Настройте DNS-сервер, работающий только в режиме кэширования, на использование доверенного DNS-сервера, например, DNS-сервера провайдера, для переадресации. Таким образом вы сократите риски, связанные с разрешением клиентам SecureNAT напрямую соединяться с DNS-серверами Интернета. DNS-сервер, работающий только в режиме кэширования, на ISA-сервере может быть настроен на недопущение распространенных атак на DNS, таких, как подмена кэша.

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

Резюме

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

www.isaserver.org


Смотрите также:

Tags: , , , , , , ,

Readers Comments (Комментариев нет)




Да человек я, человек! =)

Exchange 2007

Проведение мониторинга Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 3)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Проведение мониторинга Exchange 2007 с помощью диспетчера System ... [+]

Практическое рассмотрение перехода с Exchange 2003 на Exchange 2007 (часть 1)

Введение В этой статье из нескольких частей я хочу показать вам процесс, который недавно использовал для перехода с существующей среды Exchange 2003 ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 2)

Если вы пропустили первую часть этой серии, пожалуйста, прочтите ее по ссылке Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (Часть ... [+]

Мониторинг Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 2)

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Мониторинг Exchange 2007 с помощью диспетчера System Center Operations ... [+]

Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 5)

Если вы пропустили предыдущие части этой серии статей, перейдите по ссылкам: Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 1) ... [+]

Установка и настройка Exchange 2007 из командной строки (Часть 3)

If you missed the previous parts in this article series please read: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 1)

Инструмент ExRCA Текущий выпуск инструмента предоставляется только в целях тестирования и оснащен 5 опциями: Тест подключения Outlook 2007 Autodiscover Тест подключения Outlook 2003 RPC ... [+]

Развертывание сервера Exchange 2007 Edge Transport (часть 5)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Развертывание сервера Exchange 2007 Edge Transport (часть 1) Развертывание ... [+]

Установка и настройка Exchange 2007 из командной строки (часть 2)

Если вы пропустили первую статью данного цикла, пожалуйста, перейдите по ссылке: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование интегрированных сценариев Using Exchange Server 2007 – часть 2: генерирование отчетов агента Transport AntiSpam Agent

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Использование интегрированных сценариев Using Exchange Server 2007 – часть ... [+]