Как настроить брандмауэр Linux, чтобы Exchange Server ActiveSync Direct Push работал без предупреждений

Я испытываю события EventID 3033 "Server ActiveSync" на нашем сервере Exchange 2003 с пакетом обновления 2 (SP2), описанные в KB905013 (см. Ниже), по-видимому, из-за тайм-аутов брандмауэра.

Сервер Exchange находится за межсетевым экраном Red Hat Enterprise Linux 5.4 iptables, но я не знаю, какие настройки нужно проверить, чтобы убедиться, что таймаут HTTP(S) установлен как минимум на 15 минут, как описано в статье.

Может кто-нибудь сказать мне, где настройки, которые влияют на тайм-ауты брандмауэра iptables в Linux и как я могу их изменить?

Ошибка в журнале событий:

Event Type: Warning
Event Source:     Server ActiveSync
Event Category:   None
Event ID:   3033
Date:       08/10/2009
Time:       10:42:35
User:       <REMOVED>
Computer:   <REMOVED>

Description:

The average of the most recent [200] heartbeat intervals used by clients is less than or equal to [540].  Make sure that your firewall configuration is set to work correctly with Exchange ActiveSync and direct push technology. Specifically, make sure that your firewall is configured so that requests to Exchange ActiveSync do not expire before they have the opportunity to be processed.  For more information about how to configure firewall settings when using Exchange ActiveSync, see Microsoft Knowledge Base article 905013, "Enterprise Firewall Configuration for Exchange ActiveSync Direct Push Technology" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=905013).

1 ответ

Проведя некоторое исследование, насколько я вижу, тайм-аут сетевого фильтра Linux по умолчанию для "установленных" TCP-подключений при использовании модуля "state", чтобы разрешить ESTABLISHED-соединения через 5 дней, намного выше рекомендованных Microsoft 15 минут:

http://www.frozentux.net/ipsysctl-tutorial/chunkyhtml/netfilterreference.html

3.7.8. ip_ct_tcp_timeout_established Переменная ip_ct_tcp_timeout_established сообщает нам значение времени ожидания по умолчанию для отслеживаемых соединений в состоянии ESTABLISHED. Все соединения, которые завершили первоначальное трехстороннее рукопожатие и не видели каких-либо пакетов FIN, считаются УСТАНОВЛЕННЫМИ. Другими словами, это более или менее состояние по умолчанию для TCP-соединения.

Поскольку мы никогда не хотим, чтобы соединение было потеряно по обе стороны брандмауэра netfilter, это время ожидания установлено очень высоким, поэтому мы случайно не удаляем записи, которые все еще используются. По умолчанию для переменной ip_ct_tcp_timeout_established установлено значение 432000 секунд или 5 дней.

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

Спасибо тем, кто все равно помог!

Другие вопросы по тегам