Sunday, July 22nd, 2018

Проблемы с доступом к POP3 в ISA 2000

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

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

1. Резюме

В последнее время я расследовал то, что казалось на первый взгляд простой проблемой POP3 доступа. Пользователи жаловались, что их доступ к внешнему POP3 серверу часто неудачен. После сбора несколько большей информации стало очевидно, что я столкнулся с очень непонятной проблемой доступа, которая требует проведения более тщательного анализа. Кроме того, выяснилось, что эта проблема доступа не является специфичной проблемой POP3, а в действительности является потенциальной проблемой любого доступа, основанного на TCP и обрабатываемого Брандмауэрным клиентом. Если вы хотите знать, почему это может случиться и как разрешить эту проблему, то читайте эту статью.

2. Сценарий

Настройки сети имеют основную back-to-back брандмауэрную конфигурацию с Checkpoint в качестве внешнего, и ISA 2000 в качестве внутреннего брандмауэра. Сегмент между обоими брандмауэрами используется как DMZ, где расположен POP3 сервер. Этот POP3 сервер доступен внутренним и внешним клиентам. Внутренние клиенты все настроены как Web-прокси и Брандмауэрные клиенты, потому что весь исходящий доступ должен быть авторизован. ISA сервер имеет все заплатки и работающий ISA 2000 SP2 на Windows 2000 SP4 со всеми последними критичными обновлениями. POP3 сервер выполняет CommuniGate Pro на Windows 2003. Следующий рисунок описывает этот сценарий:

Нет соединения с pop сервером

Около 200 внутренних почтовых клиентов получают доступ каждые 5 минут к POP3 серверу в DMZ. Они используют смесь различных версий Outlook, Outlook Express и Eudora. Следовательно, мы можем исключить очень быстро любые проблемы с почтовыми клиентами. Получаемый Windows Sockets Error Code (Код ошибки сокетов Windows) был Connection timed out (WSAETIMEDOUT 10060) (Тайм-аут соединения). Также, DMZ содержит определенное количество других серверов, в основном — Web-серверы. Никаких данных о проблемах с доступом к этим серверам нет.

3. Причина

Для проведения расследования этой проблемы мы убедились, что мы имеем Windows XP SP2 host под нашим управлением с локальными правами администрирования. Мы закрыли все выполняемые программы и запустили следующий простой командный файл:


— Begin -
echo off
:Start
netsh diag connect iphost FQDN 110
GOTO Start
— End -

Этот простой командный файл только устанавливает TCP-соединение с POP3 сервером через порт 110. Когда соединение успешно установлено, это соединение нормально закрывается. Успех или неудача соединения отображается в командном окне. Очень скоро мы увидим некоторое количество неудачных соединений и это доказывает, что почтовые клиенты в самом деле не виновны.

Далее, мы запускаем Network Monitor для трассировки на самом POP3 сервере с параметрами: Buffer Size (Размер буфера) = 8 MБайт, Frame Size (Размер кадра) = 128 Байт и Capture Filter (Фильтр захвата) = от Внешнего интерфейса ISA к POP3 серверу. Мы запускаем снова наш простой командный файл и позволяем Network Monitor трассировать около 15 минут. Мы опять видим некоторое количество неудачных соединений. При анализе трассировки Network Monitor мы, в самом деле, обнаружили определенное количество запросов на соединение от Внешнего интерфейса ISA совсем без ответов со стороны POP3 сервера. Дальнейший анализ выявил, что номера портов источника, используемые Внешним интерфейсом ISA не соответствуют нормальному возрастающему шаблону, используемому обычным Windows host’ом. Более того, мы увидели, что ISA 2000 очень быстро повторно использует порты источника, использованные перед этим. Итак, мы заподозрили, что неудачные POP3 соединения — это те, для которых конечный socket остается в состоянии TIME_WAIT на POP3 сервере.

Примечание: для большей информации о протоколе TCP/IP и понимании состояния TIME_WAIT обратитесь к следующим ресурсам:

Чтобы действительно убедиться, что мы на правильном пути, мы на клиенте установили Ethereal и прекрасный WinsockTool от Jim’а. Затем мы запустили Ethereal для анализа Firewall Client Control Channel (Канала Управления Брандмауэрным Клиентом) и использовали WinsockTool для ручных соединений к POP3 серверу. Когда наступил тайм-аут запроса на соединение, мы выполнили на POP3 сервере команду netstat -an | find «IP-Address:» для получения списка всех соединений от Внешнего интерфейса ISA. Затем мы остановили захват Ethereal. Анализом Firewall Control Channel мы смогли легко определить, какой порт источника ISA сервера договаривался через его внешний интерфейс об этом соединении. Затем мы поискали этот номер порта источника в результате команды netstat на POP3 сервере. Каждый раз, когда мы получали ошибки соединения, конечная точка сокета на POP3 сервере все еще была в состоянии TIME_WAIT и это означает, что она не может быть повторно использована в это время. Это подтвердило, что быстрое повторное использование номеров портов источника Внешним интерфейсом ISA было, в самом деле, причиной неудач POP3 соединений.

Для дальнейшего сужения проблемы, мы выключили Брандмауэрного клиента, убедились, что клиент был также сконфигурирован как клиент SecureNAT и соответственно адаптировали Политику Брандмауэра. Затем мы запустили трассировку Network Monitor на самом POP3 сервере и выполнили заново наш простой командный файл на клиенте. На этот раз не было зарегистрировано ни одной ошибки. Более того, в трассировке Network Monitor мы увидели, что номера портов источника, используемые Внешним интерфейсом ISA, следуют нормальному возрастающему шаблону, используемому обычным Windows host’ом, и что нет быстрого повторного использования номеров портов источника Внешним интерфейсом ISA.

Как результат, мы можем сказать, что описанная выше проблема не ограничивается только POP3 доступом. В действительности, это является потенциальной проблемой для любого доступа, основанного на TCP, обрабатываемого Брандмауэрным клиентом. Она только неожиданно проявилась в POP3 доступе из-за того, что в почтовых клиентах внедрен настоящий механизм опроса и фактически они все подключаются к одному host’у назначения.

4. Обходной путь

Теперь мы, зная точную причину этой проблемы, сделали отчет для Microsoft PSS и начали искать обходные пути. Мы обнаружили следующие возможные обходные пути:

Мы изменили на POP3 сервере ключ реестра TcpTimedWaitDelay (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters) на минимальное значение в 30 секунд. Хотя это выглядит как смягчение проблемы, это не является полным ее решением. Более того, мы не считаем это хорошим решением, потому что вы не имеете во всех сценариях административного доступа к реестру и контроля над POP3 сервером.

Второй обходной путь — распространение некоторым способом пользовательского клиентского LAT файла, названного Locallat.txt и помещаемого в каталог Microsoft Firewall Client (Microsoft Брандмауэрного Клиента) на клиентском компьютере. Этот файл должен содержать IP-адрес POP3 сервера так, чтобы любой TCP запрос на это назначение не обрабатывался Брандмауэрным клиентом. Конечно, все внутренние host’ы должны затем тоже быть настроены как SecureNAT клиенты и в политики Брандмауэра должен быть разрешен анонимный доступ на POP3 сервер. Все внутренние клиенты были уже сконфигурированы, как клиенты SecureNAT, потому что внутренняя сеть была фактически маршрутной внутренней сетью. Однако мы не вводили это решение, потому что раздача пользовательского клиентского LAT файла была слишком громоздка в качестве временного решения.

Последний обходной путь был в изменении конфигурации Брандмауэрного клиента на самом ISA сервере. Из-за того, что все клиенты уже являются SecureNAT клиентами и что подавляющим большинством почтовых клиентов является Outlook, мы легко можем выключить Outlook в конфигурации Брандмауэрного клиента на самом ISA сервере. Для этого перейдите на Firewall Client Properties (Свойства Брандмауэрного Клиента) в ISA MMC и выберете вкладку Application Settings (Настройки приложений). Там вы выберете Application (Приложение) Outlook и измените ключ Disable (Запретить) на значение 1. После ручного обновления Брандмауэрного клиента или после максимум 6 часов, это период обновления по умолчанию для Брандмауэрного клиента, все клиенты получат обновленную конфигурацию. Конечно, политику Брандмауэра следует изменить для разрешения анонимного доступа на POP3 сервер. Это и есть обходной путь, который мы применили.

5. Решение

После пары дней мы получили следующий ответ от Microsoft PSS:

Причиной, по которой брандмауэр не отвечает, является то, что внешний POP3 сервер не отвечает на синхро-пакеты Брандмауэра. Если приготовить трассировку для этой проблемы, то вы обнаружите, что пара внешнего порта используется предварительно только 2 минуты. Поэтому пара порта находится в синхронизированном состоянии ожидания на POP3 сервере. Вот установки реестра на ISA сервере для замедления повторного использования порта.

Следующие ключи реестра управляют пулом портов:
HKLM\System\CurrentControlSet\Services\FwSrv\Parameters

  • MinTickBeforePortReuse DWORD, по умолчанию 1200, значение является количеством миллисекунд перед повторным использованием. Как вы можете видеть, это намного меньше обычного TIME_WAIT.
  • MaxSocketsInAllPools DWORD, по умолчанию 6000, общее количество сокетов, которые могут храниться в пуле.
  • MaxTimeInFreePool DWORD, по умолчанию 60000, значение является числом миллисекунд, которые сокет может оставаться в пуле и не быть повторно использованным. Сокеты, которые остаются в пуле дольше, уничтожаются.

Дополнительная информация о ключах реестра:

  • MaxTimeInFreePool должно быть больше, чем MinTickBeforePortReuse. Но если заставить MaxSocketsInAllPools работать на вас, не пытайтесь изменить другие значения.
  • Оптимизация требуется только в случаях, где есть высокое количество соединений в секунду и низкий объем трафика. Она была добавлена для специального сценария измерения скорости, который тестирует количество соединений в секунду.
  • Для оптимизации работы должно выполниться следующее:
    Допустим R — это количество соединений в секунду
    MinTickBeforePortReuse / 1000 * R <= MaxSocketsInAllPools
    Если число сокетов меньше — возможно, что ни один из сокетов по возрасту не достигает достаточного значения и будет затребован новый сокет.
    При больших значениях R, количество сокетов тоже будет высоким и будет уничтожаться весь нестраничный пул.

Примерное решение:

  • Решение #1: Если MaxTimeInFreePool установлено в 0, то MinTickBeforePortReuse является запрещенным.
  • Решение #2: другой путь в установке MinTickBeforePortReuse в 4 минуты, что равно 240000.

Для внедрения этого примерного решения нам необходимо, во-первых, отменить примененный обходной путь. Затем мы пытаемся применить Решение #1 добавлением специального ключа реестра MaxTimeInFreePool = 0 и перегрузкой сервера. После выполнения нашего простого командного файла на клиенте и трассировки Network Monitor на POP3 сервере, мы все еще видим тайм-ауты соединений. Более того, в трассировке Network Monitor мы все еще наблюдаем неправильный шаблон портов источника. Следовательно, это решение не разрешает проблему целиком. Итак, мы переходим к Решению #2, удаляя ключ MaxTimeInFreePool, добавляя MinTickBeforePortReuse = 240000 и перегружая сервер. После выполнения нашего простого командного файла на клиенте и трассировки Network Monitor на POP3 сервере не было зарегистрировано ни одной ошибки. Более того, в трассировке Network Monitor мы увидели, что номера портов отправителя, используемые Внешним интерфейсом ISA, следуют нормальному возрастающему шаблону, используемому обычным Windows host’ом, и что не было быстрого повторного использования номеров портов отправителя Внешним интерфейсом ISA.

Итоговое решение, которое работало у нас:
HKLM\System\CurrentControlSet\Services\FwSrv\Parameters

  • создать или изменить MinTickBeforePortReuse DWORD и присвоить ему значение 240000.
  • удалить MaxSocketsInAllPools, если он есть.
  • удалить MaxTimeInFreePool, если он есть.

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

6. Заключение

В этой статье мы расследовали кажущуюся простой на первый взгляд проблему POP3 доступа. Однако оказалось, что эта проблема доступа не является специфичной для POP3, а, на самом деле, является потенциальной проблемой для любого доступа, основанного на TCP и обрабатывающегося Брандмауэрным клиентом. Она в основном проявлялась при POP3 доступе, так как в почтовых клиентах реализован настоящий механизм опроса и они все подключаются на один и тот же порт назначения. После консультации с Томом Шиндером (Tom Shinder), я думаю, что мы можем решить проблему со старыми POP3, которым досаждала ISA 2000, пока была на стадии бета-версии.

Источник 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 – часть ... [+]