Если вы хотите ознакомиться с остальными частями этой статьи, пожалуйста, прочитайте:
В первых двух частях этой серии статей, посвященной прерыванию соединений клиентов VPN перед ISA Firewall, мы начали обсуждение различных вопросов относительно места завершения VPN соединения, и также рассмотрели различные сценарии подключения VPN клиентов к Интернет и внутренней сети с помощью этого соединения. Во второй части мы выполнили некоторые действия по настройке ISA Firewall для предоставления VPN клиентам доступа к внутренней сети позади ISA Firewall и Интернет.
Вкратце о том, что мы нам нужно было сделать с ISA Firewall перед созданием правил доступа:
В этой статье мы закончим настройку программы-клиента VPN, после чего создадим подключение к внешнему устройству NAT. Мы подключимся к внутренней сети, находящейся под защитой ISA Firewall и к Интернет, используя это соединение. После этого мы рассмотрим несколько особых случаев с настройкой конфигурации Web proxy и клиента брандмауэра для большей безопасности.
Сперва я думал описать совокупный набор правил брандмауэра, вводящий минимум полномочий между зоной DMZ и внутренней сетью. Я также собирался предоставить информацию о доступе с минимумом полномочий между внутренней сетью, зоной DMZ и Интернет. Однако позже мне пришло на ум, что раз уж мы решили прервать VPN соединение перед ISA Firewall, а не у него, безопасность отходит на второй план, поскольку прервать соединение у ISA Firewall было бы куда более эффективно с точки зрения защищенности. Принимая во внимание этот факт, я собираюсь создать единственное правило, которое будет контролировать доступ как в зону DMZ, внутреннюю сеть и Интернет, так и из них.
Вы можете увидеть это правило на рисунке, приведенном ниже. Оно допускает:
Я бы настоятельно рекомендовал вам заблокировать политики брандмауэра, которые я здесь описал. Например, внутренним пользователям совершенно не нужен доступ ко всем протоколам и сайтам в Интернет. То же самое верно и для зоны DMZ – клиенты VPN, способные подключаться к VPN серверу, расположенному перед ISA Firewall, являются хостами DMZ, так что если вы хотите контролировать доступ этих клиентов к чему-либо во внутренней сети, вам нужно создать больше ограничивающих правил, определяющих доступ пользователей VPN, расположенных в зоне DMZ, к внутренней сети.
Дайте мне знать, если вам нужно руководство по созданию большего числа заблокированных политик брандмауэра. Если вам это интересно, я напишу следующую статью о политике брандмауэра с минимумом полномочий.
Запомните, что вы можете использовать клиент брандмауэра на компьютерах VPN клиентов и получить тем самым контроль доступа по пользователям/группам для доступа VPN пользователей во внутреннюю сеть. Это происходит из-за того, что наша сеть DMZ может быть настроена как прослушиватель клиента брандмауэра. Я расскажу об этом позже.
Рисунок 1
Настройка программы-клиента VPN будет различаться в зависимости от того, с каким типом программы вы работаете. В этом примере мы будем использовать Windows программу-клиент VPN, поскольку мы прерываем VPN соединение у сервера RRAS NAT перед ISA Firewall. Тип используемой вами программы важен, поскольку разные клиенты VPN имеют разные возможности. Точно так же дела обстоят и с VPN сервером, что вы используете – он может поддерживать функции, не поддерживаемые сервером RRAS, и VPN сервер RRAS может поддерживать такие функции, которые не поддерживает VPN сервер, используемый вами.
После создания нового подключения клиента VPN откройте его и нажмите на кнопку Properties. На вкладке General вы увидите IP адрес или же полностью уточненное имя домена, установленное вами для клиента, для которого создается VPN соединение. Пример показан на рисунке ниже.
Рисунок 2
В диалоговом окне Properties, выберите вкладку Networking. На ней вы увидите, что параметром Type of VPN, данным по умолчанию, является Automatic. Это означает, что VPN клиент сперва будет пытаться подключиться по L2TP/IPSec, и если это не сработает, совершит попытку по PPTP. Наш VPN сервер RRAS в данный момент поддерживает лишь PPTP, так что VPN клиент будет использовать именно его для подключения.
На вкладке Networking, выберите запись Internet Protocol (TCP/IP) и нажмите кнопку Properties.
Рисунок 3
Это вызовет диалоговое окно Internet Protocol (TCP/IP) Properties. Отметьте, что по умолчанию дано то, что VPN клиент использует автоматическое назначение адресов от VPN сервера, что является частью процесса IPCP (протокол межсетевого взаимодействия). Нажмите на кнопку Advanced.
Рисунок 4
В диалоговом окне Advanced TCP/IP Settings на вкладке General, у вас есть единственная опция: Use default gateway on remote network. При включении этой опции (дано по умолчанию), раздельное туннелирование для клиента выключено. Когда оно выключено, все запросы к удаленным сетям, включая Интернет, посылаются через канал связи VPN. Если раздельное туннелирование включено (галочка из поля Use default gateway on remote network убрана), тогда трафик, предназначающийся для корпоративной сети посылается сквозь VPN туннель, а трафик, предназначенный для Интернет, посылается прямо в Интернет через действительный интерфейс клиента, не через VPN интерфейс.
Рисунок 5
Решение, разрешать ли раздельное туннелирование или нет, зависит от ваших требований к безопасности, равно как и от возможностей и настроек вашего в VPN клиента и VPN сервера. Вообще-то раздельного туннелирования лучше избегать, поскольку оно является большой проблемой с точки зрения защищенности, позволяя нарушителям с легкостью устанавливать соединения через компьютер VPN клиента во внутреннюю сеть. С другой стороны, вы можете включить раздельное туннелирование, чтобы уменьшить использование пропускной способности вашего корпоративного соединения с Интернет.
Некоторые вещи, которые стоит принять во внимание при принятии решения насчет включения раздельного туннелирования:
Наиболее простым решением является включение раздельного туннелирования, но это же будет и наименее безопасным решением. Вторым по простоте решением будет использование обратных запросов VPN сервера для подключения к Интернет; однако это не очень-то хорошее решение с точки зрения защищенности, поскольку вы не можете ввести политики брандмауэра для этих соединений. Наиболее сложным решением является конфигурация клиентов как клиентов Web proxy и брандмауэра – это позволяет вам контролировать действия, совершаемые VPN клиентами при подключении к вашей корпоративной сети через канал связи VPN.
В оставшейся части этой статьи мы обсудим, как вам настроить вашу инфраструктуру и клиентов для поддержки конфигураций клиентов Web proxy и брандмауэра применительно к клиентам VPN, подключающимся к VPN серверу, расположенному перед ISA Firewall.
Раздельное DNS, раздельное DNS, раздельное DNS, всем необходимо раздельное DNS!
Цель раздельного DNS в том, чтобы сделать разрешение имен было открытым, независящим от расположения пользователя. В большинстве случаев мы используем раздельное DNS для поддержки пользователей, перемещающихся между корпоративной сетью и Интернет с тем, чтобы одни и те же имена могли использоваться и когда пользователь находится в Интернет, и когда он в корпоративной сети. Раздельное DNS гарантирует, что одно и то же имя будет разрешено как разный IP адрес, зависящий от местоположения пользователя.
В случае с VPN клиентом он не является хостом, располагающимся в Интернет, поскольку имеет IP адрес, действительный для сети DMZ. В этом случае нам нужно создать раздельный DNS, так чтобы записи WPAD и имя ISA Firewall разрешались как разные IP адреса, зависящие от местоположения пользователя.
Например, если имя ISA Firewall будет isa2006se.msfirewall.org, нам нужно, чтобы пользователи из внутренней сети разрешали данное имя как внутренний адрес ISA Firewall. Однако мы хотим, чтобы клиенты VPN разрешали имя isa2006se.msfirewall.org как IP адрес внешнего интерфейса ISA Firewall. Это тот IP адрес, который сеть DMZ ISA Firewall Network прослушивает и Web proxy прослушивателем, и прослушивателем клиента брандмауэра.
Чтобы все это заработало, нам нужно создать для имени ISA Firewall две записи WPAD Host (A) и две записи Host (A), как это показано на рисунке ниже. По одной записи WPAD и Host (A) для имени ISA Firewall для разрешения внутреннего адреса, и по одной записи WPAD и Host (A) для внешнего. Внутренние пользователи будут разрешать имя как внутренний IP адрес, клиенты VPN будут разрешать имя как внешний IP адрес.
Рисунок 6
Вы, наверно, спросите себя, как вы сможете заставить клиентов VPN разрешать имена как внешний IP адрес, а внутренних клиентов – как внутренний IP адрес? Ответ заключается в использовании DNS сервером распределения масок сети. При включении данной опции, если есть несколько записей для одного имени, к клиенту будет возвращена запись, наиболее совпадающая с сетевым идентификатором источника запроса.
Вы можете настроить распределение масок сети в диалоговом окне DNS сервера Properties. Выберите вкладку Advanced в диалоговом окне Properties, отметьте поле Enable netmask ordering и нажмите OK.
Рисунок 7
Для поддержки автоопределения на базе WPAD прослушивателей клиентов Web proxy и брандмауэра, клиент должен полностью определить имя WPAD. Если компьютер не настроен должным образом, чтобы полностью уточнять имя WPAD, тогда неуточненное имя будет послано DNS серверу и попытка разрешения имени окончится неудачей. Если VPN клиенты являются компьютерами, присоединенными к домену, то у вас не будет проблем, так как они полностью уточнят запрос автоматически, используя имя вашего домена Active Directory.
Однако, если ваши клиенты не являются членами домена, им придется добавлять в свои DNS запросы то самое имя домена, которое используется доменом Active Directory domain во внутренней сети.
Вы можете добавлять имена DNS, не будучи частью домена, открыв диалоговое окно System Properties и выбрав вкладку Computer Name. В ней нажмите кнопку Change.
Рисунок 8
В диалоговом окне Computer Name Changes нажмите кнопку More.
Рисунок 9
В диалоговом окне DNS Suffix and NetBIOS Computer Name введите в поле Primary DNS suffix on this computer имя внутреннего Active Directory DNS и нажмите OK.
Рисунок 10
Вам придется перезагрузить компьютер, чтобы изменения подействовали.
ISA Firewall должен быть настроен так, чтобы позволять соединения клиента Web proxy. Это достигается включением прослушивателя Web proxy. Дважды щелкните на строчку DMZ в консоли ISA Firewall и выберите вкладку Web proxy. Отметьте поля Enable Web Proxy client и Enable HTTP. Порт, данный для прослушивателя Web proxy по умолчанию, 8080, и вам стоит оставить его, как есть. Меняйте его, только если у вас есть очень веские причины, чтобы сделать это.
Рисунок 11
Сделайте тоже самое и с пунктом Internal. В диалоговом окне Internal Properties выберите вкладку Web Proxy и отметьте поля Enable Web Proxy clients и Enable HTTP, оставив порт прослушивания данным по умолчанию — TCP 8080.
Рисунок 12
Теперь, когда прослушиватели Web Proxy брандмауэра ISA Firewall включены, следующим шагом будет конфигурирование клиентов VPN как клиентов Web proxy. В этом примере мы сделаем это вручную, но в продуктивном окружении вы можете воспользоваться программой Connection Manager Administration Kit (CMAK) для создания VPN соединений. CMAK дает вам возможность указать значение Web proxy для клиентов VPN, так что вы сможете повторить то, что мы тут делаем.
В программе Internet Explorer откройте диалоговое окно Internet Properties и выберите вкладку Connections. Заметьте, что ваше соединение VPN появляется в окне Dial-up and Virtual Private Network settings. Выберите ваше VPN соединение и нажмите кнопку Settings.
Рисунок 13
В диалоговом окне VPN Settings отметьте поле Automatically detect settings. При установлении клиентом соединения с VPN сервером, клиент пошлет WPAD запрос тому серверу DNS, за которым он закреплен VPN сервером. Это позволит VPN клиенту автоматически обнаружить прослушиватель Web proxy, который должен использоваться подобными клиентами. Нажмите OK, чтобы сохранить изменения.
Рисунок 14
На рисунке, приведенном ниже, показано то, что должно быть в консоли наблюдения ISA Firewall при подключении клиента VPN к прослушивателю Web proxy. В этом примере VPN клиенту назначен IP адрес 10.0.1.104, и он соединен с Web proxy прослушивателем сети DMZ ISA Firewall Network, расположенном по адресу 10.0.1.2 через TCP порт 8080.
Рисунок 15
Заметьте, что при конфигурации хостов как клиентов Web proxy вы можете создавать правила доступа на базе аккаунтов пользователей или их членства в каких-либо группах, контролирующие, к чему пользователи могут иметь доступ в Интернет или внутренней сети. Я не буду рассказывать о подробностях этой конфигурации, так как эта статья направлена на изучение прерывания VPN соединений перед ISA Firewall, а не прерывания у ISA Firewall. Однако, применительно к этим клиентам VPN можно ввести ограничительную политику для доступа в Интернет.
Системы клиента брандмауэра нуждаются в подключении прослушивателя клиента брандмауэра к ISA Firewall. Прослушиватель сделан на основе сети ISA Firewall Network. В консоли ISA Firewall дважды нажмите на внутреннюю сеть и выберите вкладку Firewall Client.
Отметьте поле Enable Firewall client support for this network.
В окне Firewall client configuration введите полностью уточненное доменное имя ISA Firewall в поле ISA Server name or IP address. Мы должны ввести FQDN (полностью уточненное доменное имя), а не IP адрес, поскольку мы хотим воспользоваться возможностями нашего раздельного DNS, а раздельный DNS основывается на разрешении DNS имен. При использовании автообнаружения WPAD система клиента разрешит имя wpad.domainname.com как IP адрес ISA Firewall, и имя ISA Firewall будет возвращено клиенту брандмауэра. То имя, что вы вводили в поле ISA Server name or IP address на вкладке клиента брандмауэра для сети ISA Firewall Network, клиент брандмауэра будет использовать для соединения с прослушивателем клиента брандмауэра ISA Firewall.
В окне Web browser configuration on the Firewall client computer отметьте поле Use a Web proxy server. При подключении клиента брандмауэра к ISA Firewall это установит для клиента конфигурацию Web proxy. Однако это не будет иметь эффекта для соединений клиента VPN, поскольку сервер Web proxy, используемый клиентом VPN, настроен для соединений VPN. Изменения, сделанные вами на этой вкладке влияют лишь на данный сетевой интерфейс, не на канал связи VPN. Тем не менее, чтобы предотвратить совпадения имен Web proxy и любые другие нежелательные последствия, лучше ввести действительное FQDN брандмауэра ISA Firewall в поле ISA Server name or IP address, расположенное под строкой Use a Web proxy server.
Рисунок 16
Если вам показалось, что в объяснении выше не хватает аргументов, вы правы. Я знаю, что автоматическое обнаружение будет использоваться VPN клиентом для обнаружения прослушивателя Web proxy, поскольку мы настроили это в браузере. Однако я не знаю, что может случиться при совпадении имен серверов Web proxy, если одно имя используется в настройках VPN клиента, а второе установлено для данного сетевого интерфейса. Если хотите, проверьте это сами. Дайте мне знать, что получится!
Повторите процесс, описанный выше, для сети DMZ ISA Firewall Network. Помните, что даже если мы используем одно и то же имя для внутренних клиентов и клиентов VPN, это имя будет разрешено как разные адреса, в зависимости от расположения клиента. Клиенты VPN будут подключаться к прослушивателю через внешний интерфейс ISA Firewall, а внутренние – через внутренний.
Рисунок 17
Я хочу подчеркнуть, что это нестандартное использование клиента брандмауэра и его прослушивателя. Этот сценарий, в котором клиенты VPN подключаются к прослушивателю через внешний интерфейс ISA Firewall. похож на случай с использованием клиентом брандмауэра единственного сетевого интерфейса ISA Firewall. Да, это так, это не поддерживаемая конфигурация (официально не поддерживаемая PSS), но она работает, и нет технических причин, чтобы она не работала. Однако команда разработчиков ISA Firewall не тестировала эту конфигурацию, и поэтому они не могут оказывать поддержку, поскольку они не уверены, что будет, а что не будет работать в тысячах пользовательских конфигураций.
Еще одной интересной находкой является то, что при «отбросе» VPN клиентов от внешнего интерфейса прослушивателя клиента брандмауэра, ISA Firewall видит клиентов как приходящих из сети DMZ. Однако, когда клиенты Web proxy “отскакивают” от внешнего интерфейса прослушивателя Web proxy, они видны как клиенты из сети локального хоста или же внутренней сети, даже если записи в журнале покажут, что они члены сети DMZ.
Это важно, поскольку вам не нужно создавать сетевого правила, соединяющего сеть DMZ с Интернет для клиентов Web proxy. Уже есть правила, позволяющие членам внутренней сети и сети локального хоста выходить в Интернет. Тем не менее, поскольку клиенты брандмауэра считаются членами сети DMZ ISA Firewall Network, вам нужно создать сетевое правило, соединяющее сеть DMZ с Интернет.
На рисунке, приведенном ниже, показана настройка сетевого правила, соединяющего сеть DMZ с Интернет. Вам нужно установить параметр Source Network как DMZ и параметр Destination Network как External. Параметр Network Relationship должен быть установлен как Network Address Translation (NAT).
Рисунок 18
При конфигурировании клиентов VPN как клиентов брандмауэра вы можете использовать конфигурацию клиента брандмауэра для создания правил доступа, ставящих ограничения для пользователей в доступе к выбранным сайтам или протоколам, по отдельному пользователю или по группам. В сущности, клиент брандмауэра поддерживает любой протокол UDP or TCP, используемый приложениями Winsock, так что клиент брандмауэра улучшает защиту, предоставляемую настройкой клиента Web proxy. Есть также потенциальная поддержка сложных протоколов, хотя я уже отмечал, что в той конфигурации, что я использовал в этой статье, режим PORT протокола FTP не работает.
VPN клиенты, прерываемые перед ISA Firewall, которые не настраиваются как клиенты брандмауэра или клиенты Web proxy, являются по определению клиентами SecureNET брандмауэра ISA Firewall. Тем не менее они действуют как клиенты SecureNET только в тех случаях, когда они получают доступ к ресурсам, расположенным позади ISA Firewall. Для доступа в Интернет они рассчитывают либо на возможность VPN сервера осуществлять «обратные запросы» для клиента в Интернет через сервер VPN, либо на конфигурацию с раздельным туннелированием у клиента или сервера.
Заметьте, что когда вы используете только конфигурацию клиента SecureNET, доступ к ресурсам под защитой ISA Firewall должен предоставляться на анонимной основе – у вас не будет контроля за пользователями/группами, вводимого для клиентов VPN при их подключении к ресурсам во внутренней сети позади ISA Firewall.
Теперь давайте проверим соединение и посмотрим, что произойдет. На рисунке внизу показана область уведомлений панели задач до установления соединения с VPN клиентом. Вы можете видеть, что иконка клиента брандмауэра показывает, что он отключен, поскольку он не может разрешить имя прослушивателя клиента брандмауэра ISA Firewall.
После того, как соединение VPN будет установлено, вы увидите иконку соединения в области уведомлений и заметите, что красный крестик пропал с иконки клиента брандмауэра. Это означает, что клиент брандмауэра нашел ISA Firewall. Когда клиент подключится к ISA Firewall для передачи информации, на его иконке появится зеленая стрелка, направленная вверх.
При двойном нажатии на иконку клиента брандмауэра вы увидите диалоговое окно Microsoft Firewall Client for ISA Server. Выберите вкладку Settings. На ней нажмите кнопку Detect Now. Это заставит клиент брандмауэра попытаться вновь найти ISA Firewall, и результат появится в диалоговом окне Detecting ISA Server. Затем вы увидите, как в этом окне появится полностью уточненное имя домена. Это то значение, что вы ввели на вкладке клиента брандмауэра в свойствах сети DMZ ISA Firewall Network.
Рисунок 19
Выделенная строка на рисунке, приведенном ниже, показывает соединение клиента Web proxy с прослушивателем Web proxy через внешний интерфейс ISA Firewall. Адрес клиента VPN 10.0.1.102, а прослушиватель Web proxy расположен на внешнем интерфейсе ISA Firewall по адресу 10.0.1.2.
Рисунок 20
После того, как соединение Web proxy будет установлено, вы сможете увидеть запрос от клиента VPN к Интернет. Выделенная строка на рисунке ниже показывает http соединение к нужному IP адресу 207.46.198.60. Нижний регистр записи http отмечает, что соединение было сделано через подключение клиента Web proxy – иначе говоря, даже если строчка в записи выглядит так, будто соединение было от клиента VPN к нужному веб-серверу, запрос на самом деле сделан через канал клиент Web proxy/сервер через TCP порт 8080.
Неплохой пример того, как это работает, показан в зеленой строчке внизу окна. Зеленая запись в журнале показывает, что клиент VPN делает запрос к необходимому веб-серверу, используя протокол http, что на самом деле является HTTP запросом, сделанным через канал клиент Web proxy/сервер. Действительное соединение HTTP идет от ISA Firewall к нужному веб-серверу, что вы можете видеть в журнальной записи, приведенной в рисунке ниже. Верхний регистр HTTP указывает на не-Web proxy соединение, которое происходит при пересылке брандмауэром ISA Firewall запроса от клиента Web proxy.
Рисунок 21
Давайте теперь взглянем на соединение клиента брандмауэра. На рисунке, приведенном ниже, я открыл окно командной строки и установил соединение Telnet с SMTP сервером.
Рисунок 22
Сверяясь с журналом ISA Firewall, вы можете видеть, что SMTP подключение было установлено от IP адреса клиента VPN к адресу нужного SMTP сервера. Вы можете видеть подключение к каналу контроля клиента брандмауэра через TCP порт 1745 на следующей строчке после SMTP соединения.
Возможно, вы поинтересуетесь, откуда я узнал, что это соединение именно клиента брандмауэра. Есть два обстоятельства, указывающих на это. Во-первых, посмотрите на столбец Client Username в записи для SMTP соединения. Там написано tshinder (?), что означает имя пользователя, установившего соединение. Только клиент брандмауэра может сообщить имя пользователя ISA Firewall при использовании не-Web proxy соединений.
Вторая подсказка видна в окне диагностики записей ISA Firewall (Эй! Откуда тут эта диагностика? J). В нижней части окна видна запись Client agent, показывающая, кто использовалась программа telnet.exe 3.5.1. Только клиент брандмауэра может послать информацию об агенте пользователя ISA Firewall при использовании не-Web proxy соединений.
Рисунок 23
На рисунке ниже показаны типы сессий, совершаемых клиентами VPN. Вы увидите, что были сделаны сессии всех трех типов: Web proxy, клиента брандмауэра и клиента SecureNET. Запись о клиенте SecureNET несколько неверна, поскольку она представляет собой подключения клиента VPN к прослушивателям клиентов Web proxy и брандмауэра.
Рисунок 24
В этой серии статей мы обсудили политики и процедуры, связанные с прерыванием соединения VPN клиента перед ISA Firewall. Хоть прерывание подобного соединения у ISA Firewall было бы более безопасным, у многих компаний может быть установленное решение VPN клиент/сервер, от которого они не хотят отказываться. В таком случае, у вас есть возможность прервать соединение VPN клиента перед ISA Firewall и использовать ISA Firewall для предоставления доступа к внутренней сети, находящейся под защитой ISA Firewall, а также к Интернет. Эта статья окончилась рассказом о том, как использовать конфигурацию клиентов брандмауэра и Web proxy применительно к клиенту VPN для большей безопасности ваших удаленных VPN соединений.
www.isaserver.org
Tags: dns, domain, ftp, ISA Server, l2tp, nat, proxy, vpn