Публикация почтового сервера с помощью ISA Server

Публикация почтового сервера с помощью ISA Server.

Один из большинства часто задаваемых вопросов "как сделать публикацию внутреннего почтового сервера". Вторым в списке FAQ является "почему не работает мое publishing rule ?". В этой статье мы рассмотрим данные вопросы

И в дополнение, Microsoft сделала нашу жизнь легче включением мастера публикации Secure Mail Server. Этот мастер в несколько шагов помогает создать публикацию вашего почтового сервера и автоматически создает правила публикации (publishing rules) необходимые для входящего доступа к вашему серверу.

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

• Конфигурация DNS.
• Конфигурация почтового сервера как клиента ISA Server.
• Внешние IP адреса

Каждый элемент этого списка должен иметь приоритет перед созданием правил публикации с помощью Мастера.

Конфигурация DNS.

Чтобы у внешних клиентов был доступ к вашему внутреннему почтовому серверу вам нужно дать запись на публично доступном DNS сервере, который "смотрит" на внешний интерфейс ISA сервера. Имя вашего сервера пока может быть любым, каким захотите, но вероятно вы захотите дать ему имя похожее на  "mail.domain.com" или "exchange.domain.com". Эта запись должна управляться вашим провайдером, или, если у вас есть собственные DNS-сервера, вы должны ввести MX-запись для своего домена на компьютерах.

Если у вас домен Windows 2000, то, скорее всего у вас различные внутренние и внешние имена. Внутренние имена являются приватными и к ним не может быть доступа из вне. Поэтому, запись в DNS для внутреннего почтового сервера, который вы хотите опубликовать должна быть в одном из ваших общедоступных доменов, чтобы внешние юзеры имели доступ к внутреннему почтовому серваку через правила публикации (publishing rules). Нельзя использовать серверное внутреннее имя домена, потому что юзеры Интернета не получат доступ к информации вашего внутридоменного именного пространства.

Но некоторые конторы все-таки используют одно и то же имя, как для внутренних, так и для внешних ресурсов. В этом случае вы также можете использовать две отдельные базы данных DNS-зон. Одна из этих БД будет доступна только внутренним клиентам, а другая - только внешним. Это, конечно, небольшое неудобство, но некоторые конторы просто не имеют другого выбора. Самое главное - сделать запись для вашего почтового сервера на общедоступном DNS сервере.

Другая важная деталь конфигурации DNS, это определить, КАК вы хотите, чтобы внутренний почтовый сервер сам по себе разрешал (resolve) интернетовские имена. Когда внутреннему почтовому серверу надо отправить письмецо наружу, ему надо "принять решение" какой почтовый сервер мог бы переправить письмо. Есть два способа, с помощью которых почтовый сервер может решить эту проблему:

• Разрешать почтовое доменное имя самостоятельно.
• Переправлять письмо на Smart Host.

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

Чтобы разрешить внутреннему почтовому серверу посылать запросы DNS-серверам в Инете, нужно создать Protocol Rule, которое позволит почтарю иметь доступ к DNS-запросам (в Protocol Definition). Этот руль является Outbound (исходящий) UDP 53. Но в любом случае, если у вас есть почтовый сервер  Exchange 2000 (который использует сервис IIS SMTP), вы должны также дать доступ для Outbound TCP 53. Для отправки DNS-запросов SMTP-сервис IIS 5.0 использует предпочтительно TCP, чем UDP.

Другой способ позволить почтовому серверу выполнять DNS-запросы - настроить его так, чтобы он посылал запросы на внутренний DNS-сервер, который сконфигурирован использовать Форвардер на Интернет. В этом случае доступ к Protocol Rule для исходящих (Outbound) DNS-запросов будет нужен только внутреннему DNS-серверу. Внутренний DNS-сервер получает ответ от Форвардера и будет пересылать ответ на внутренний почтовый сервер.

Если вы хотите освободить ваш почтовый сервер от работы по разрешению имен, то можно сконфигурировать сервер, чтобы он отсылал почту на Smart Host. В этом случае можно сконфигурировать сервер, указав IP-адрес Smart Host и уже этот самый Smart Host возьмет на себя заботу по разрешению почтового доменного имени. Потом Smart Host перешлет почту нужному почтовому серверу в Интернете.

В этом случае вам не нужно предпринимать каких-либо специальный действий, чтобы почтовый сервер разрешал имена внешних хостов, т.к. он будет форвардить всю почту на явно указанный IP-адрес. Однако вы также можете задействовать FQDN для имени Smart Host. В таком случае вам понадобится разрешить почтовому серверу выполнять DNS-запросы

Конфигурирование Mail Server как клиента ISA Server

Одно из самых больших преимуществ ISA Server - это то, что можно опубликовать внутренние сервера как SecureNAT-клиентов. С Proxy Server 2.0, все опубликованные сервера должны быть настроены как Firewall-клиенты. В соответствии с требованием по установке программного обеспечения Firewall Client (Winsock Proxy), вам также надо конфигурировать файл wspcfg.ini и поместить его в соответствующий каталог почтового сервера.

Можно, конечно, сконфигурировать ваш внутренний почтовый сервер как Firewall Client и использовать файл wspcfg.ini, который можно использовать в опубликовании ваших почтовых серверов на Proxy Server 2.0. Однако я настойчиво рекомендую, чтобы вы сделали свой почтовый сервер клиентом SecureNAT. Это сделает вашу жизнь гораздо беззаботнее

Внешние IP-адреса.

Серверные Правила публикаций не используют Destination Sets. Вместо использования Destination Sets вы используете IP-адрес внешнего интерфейса в Правиле публикации (publishing rule). Но есть проблема, если вы хотите опубликовать более одного почтового сервера во внутренней сети. Причина в том, что когда вы создаете публикацию, то ей назначается определенный соответствующий номер порта (такой как порт 25) для IP-адреса. Поэтому, вы не можете использовать этот номер порта в других Publishing rules для этого же IP-адреса. В этом и есть отличие от того, как работают правила публикации WEB (Web Publishing Rules), где можно опубликовать столько внутренних Web-серверов, сколько вы пожелаете, используя при этом единственный IP-адрес и номер порта.

Для устранения ("обмана") этого ограничения, вам придется связать множество IP-адресов с внешним интерфейсом ISA Server, либо добавить множество внешних интерфейсов и "подвязать" IP-адрес, который предназначен для входящей почты к каждому из них (интерфейсов). После добавления множества внешних IP-адресов, вы можете использовать их в Publishing Rules для публикации множества внешних почтовых серверов.

Важно заметить, что вы не можете выполнять перенаправление (редирект) портов, используя Publishing Rules. Например, вы могли бы захотеть опубликовать внутренний почтовый сервер по порту 2525 на внешнем интерфейсе ISA-сервера и затем перенаправлять сообщения, приходящие на этот порт, на 25-й порт внутреннего сервера. Это не будет работать ! Внешний номер порта ISA-сервера должен быть таким же, как и номер порта, используемого внутренним сервером.