none
Правильная публикация 2х Exchange EDGE через TMG RRS feed

  • Вопрос

  • Коллеги, добрый день.

    Есть вот такая инфраструктура:

    На каждом EDGE:

    В качестве шлюза указан Front-End DMZ NLB VIP (172.16.0.20).

    Прописан статический маршрут в сеть Internal через Back-End DMZ NLB VIP (172.16.0.100).

    На DMZ TMG-серверах прописаны 2 правила-проброса SMTP траффика:

    Если SMTP пришёл на Provider1_IP1 или Provider2_IP1, то всё редиректить на EDGE-01, с сохранением IP источника

    Если SMTP пришёл на Provider1_IP2 или Provider2_IP2, то всё редиректить на EDGE-02, с сохранением IP источника

    Также на DMZ TMG настроены 2 сетевых правила:

    Если запрос от EDGE-01 идёт в сеть External, то NAT'ить весть трафик через Provider1_IP1 или Provider2_IP1

    Если запрос от EDGE-02 идёт в сеть External, то NAT'ить весть трафик через Provider1_IP2 или Provider2_IP2

    На DMZ TMG включен ISP для этих двух провайдеров.

    Собственно, проблема:

    Подключения по 25му порту снаружи идут только к одному из серверов. При этом в логах на DMZ TMG видно, что входящий запрос "отвалился" по таймауту через 21 секунду:

    Failed Connection Attempt DMZ-02 03.09.2014 14:11:46 
    Log type: Firewall service 
    Status: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.  
    Rule: Publish SMTP to EDGE-02 
    Source: External (184.72.226.23:53214) 
    Destination: Internal (172.16.0.22:25) 
    Protocol: SMTP Server 
    Additional information 
    Number of bytes sent: 0 Number of bytes received: 0
    Processing time: 21094ms Original Client IP: 184.72.226.23

    Ко второму серверу, к любому из его 2х внешних IP всё корректно подключается.

    Если в правилах публикации SMTP выбрать вместо сохранения IP адреса источника, замену на IP адрес DMZ TMG сервера, то все SMTP запросы корректно доходят по всем 4м IP.

    Однако тогда не работает Анти-Спам, которому нужен IP источника для его проверки (SPF,MX,PTR,Greylisting, etc.)

    Вопрос: В чём может быть проблема?

    Нашёл похожую проблему:

    http://social.technet.microsoft.com/Forums/ru-RU/c7fba88f-f22c-4550-be01-68901802dd04/-smtp-mx-forefront-tmg-edge?forum=exchange2010ru

    Но подобные настройки мне не помогли, да и у меня нет внешнего VIP.

    Было предположение, что проблема в маршрутизации. Например, EDGE не знает через какой сервер ему пришёл запрос, и шлёт ответ на VIP DMZ серверов, а там срабатывает NLB, который кидает эти пакеты на другой DMZ-сервер. Исправил это сетевым правилом, которое заставляет DMZ TMG NAT'ить правильно.

    Да и Wireshark показывает, что входящий пакет пришёл корректно, без ошибок, а ответ с какой-то ошибкой:

    Header checksum: 0x0000 [incorrect, should be 0x4f09 (may be caused by "IP checksum offload"?)]

    [GOOD: False]

    [BAD: True]

    Expert Info (Error/Checksum): Bad checksum

    Message: Bad checksum

    Severity level: Error

    Group: Checksum

    Source: 172.16.0.22 (172.16.0.22)

    Destination: 184.72.226.23 (184.72.226.23)

    3 сентября 2014 г. 10:28

Ответы

Все ответы

  • День добрый.

    Вопрос, почему вы не балансируете трафик средствами MX записей?

    Просто не вижу причин для использования балансировщиков для SMTP трафика EDGE EXCHANGE.

    Хорошый сборник по настройкам балансировщиков разных производителей для Exchange.

    Exchange Server 2010 load balancer deployment

    Антиспам не работаел у меня когда был не настроен SNAT пример ниже.

    Server Load Balancing Design

    Issues With Load Balancing SMTP Traffic


    MCITP, MCSE. Знание - не уменьшает нашей глупости. Все данные приведены в виде примера и не адаптированы для вашей системы. Выполнения командлетов и внесения изменений в систему, делаете ВЫ. Все вопросы по привязке примера к вашей ситуации или адаптации решения, рассматриваются, только через заявку или кейс в техническую поддержку.

    3 сентября 2014 г. 14:21
    Модератор
  • Олег, добрый день.

    Балансируем, но несколько иначе:

    Есть 4 внешних A-записи, вида mail.domain.com. Каждая со своим IP.

    Эта запись используется для OWA, для Outlook Anywhere, для ActiveSync, и вот, теперь, и для приёма/отправки почты.

    Т.е. когда пытаются определить MX-запись для нашего домена, определяют её как mail.domain.com

    А затем, уже DNS Round Robin'ом определяются разные IP для этой записи.

    Т.е. принципиально ничего бы не поменялось, если бы мы использовали 4 MX записи - соединение по 25му порту всё равно идёт только на один из серверов.

    Спасибо за ссылки! Почитаю, сообщу о результатах.

    4 сентября 2014 г. 4:18
  • Не понятна фраза.

    Т.е. принципиально ничего бы не поменялось, если бы мы использовали 4 MX записи - соединение по 25му порту всё равно идёт только на один из серверов

    Да идет на один из серверов, но можно же сделать косты одинаковыми и распределения будет на все 4 IP адреса равноправно последовательно.

    На FW можно же сделать проброс SMTP 25 с 4 внешних IP в 4 внутренних IP EDGE, порт в порт IP в IP. Вам же это ничего не мешает сделать, при этом минуя балансировщик.

    При этом OWA, AS - HTTPS 443 отправлять на балансировщик.


    MCITP, MCSE. Знание - не уменьшает нашей глупости. Все данные приведены в виде примера и не адаптированы для вашей системы. Выполнения командлетов и внесения изменений в систему, делаете ВЫ. Все вопросы по привязке примера к вашей ситуации или адаптации решения, рассматриваются, только через заявку или кейс в техническую поддержку.


    4 сентября 2014 г. 5:47
    Модератор
  • Олег,

    Балансировщиком являются сами DMZ TMG.

    Т.е. на них приходит SMTP траффик извне, и они же его редиректят Порт-в-Порт на серверы EDGE.

    Если честно, не понимаю принципиальной разницы между 4мя MX-записями, и 1 MX записью, которая разрешается в 4 разных IP при каждом обращении к ней.

    Технически, с точки зрения подключений через TMG, это будет одно и то же.

    Я пробовал и без балансировщика, указывая в качестве шлюза по-умолчанию на каждом EDGE "свой" DMZ TMG сервер. Т.е. EDGE1-DMZTMG1, EDGE2-DMZTMG2. Но эффект тот же. Подключения по SMTP идут только к одному из серверов.

    Думаю проблема в DMZ TMG серверах, т.к. если выключить тот, через который подключения проходят, то начинают работать подключения через второй DMZ TMG сервер, через который не работали. Если снова включить первый сервер, то подключения через второй опять перестают работать.

    4 сентября 2014 г. 6:31
  • Ок.

    Вопрос по публикации. Вы публикуете SMTP на серверве Configuring SMTP routes? Пробовали пробрасывать SMTP без публикации (Publishing SMTP Services in Forefront TMG 2010)?


    MCITP, MCSE. Знание - не уменьшает нашей глупости. Все данные приведены в виде примера и не адаптированы для вашей системы. Выполнения командлетов и внесения изменений в систему, делаете ВЫ. Все вопросы по привязке примера к вашей ситуации или адаптации решения, рассматриваются, только через заявку или кейс в техническую поддержку.

    4 сентября 2014 г. 6:55
    Модератор
  • Олег,

    Пробовал и так и так.

    В первом случае внешние подключения вообще не проходят, т.к. TMG "не слушает порт 25".

    Во втором случае та ситуация, которую я описывал - подключения идут только к одному из серверов.

    Вот как сейчас настроена публикация SMTP:

    На DMZ TMG созданы 2 правила публикации через Wizard: Non-Web Server Protocol Publishing Rule

    Первое: Если идут запросы с IP1 или IP2, то отправлять их на EDGE1, сохраняя IP источника

    Второе: Если идут запросы с IP3 или IP4, то отправлять их на EDGE2, сохраняя IP источника

    Если включить NAT, и "не сохранять IP источника", а "заменять IP источника адресом TMG сервера", то все подключения по всем адресам начинают работать корректно. Однако, теряя IP источника мы теряем половину полезных Анти-Спам функций: SPF,GreyListing, проверка MX и PTR записей, и т.п.

    4 сентября 2014 г. 7:05
  • Ок.

    Еще вопрос. То есть вы настраивали ENAT?

    TMG Enhanced NAT – considerations when using the Default IP Address


    MCITP, MCSE. Знание - не уменьшает нашей глупости. Все данные приведены в виде примера и не адаптированы для вашей системы. Выполнения командлетов и внесения изменений в систему, делаете ВЫ. Все вопросы по привязке примера к вашей ситуации или адаптации решения, рассматриваются, только через заявку или кейс в техническую поддержку.

    4 сентября 2014 г. 7:29
    Модератор
  • Олег,

    Почитал ссылку, там описывается настройка NAT средствами сетевых правил TMG (Networking->Network Rules). Т.к. DMZ TMG и EDGE сервера находятся в одной подсети, то приходящие на DMZ TMG сервера пакеты просто Route'ятся на любые сервера в той же подсети. Это Default'ное правило.

    В моём случае, я выбирал NAT в самом правиле публикации:

    4 сентября 2014 г. 7:40
  • Ок.

    Еще бы попробовал сбросить настройку SkipAsSource

    TMG sources outgoing packets with Secondary IP addresses

    или

    Use PowerShell to Change IP Behavior with SkipAsSource

    Source IP Address Preference with Multiple IPs on a NIC (с сылками на hotfix)

    PS. Пока идеи закончились.


    MCITP, MCSE. Знание - не уменьшает нашей глупости. Все данные приведены в виде примера и не адаптированы для вашей системы. Выполнения командлетов и внесения изменений в систему, делаете ВЫ. Все вопросы по привязке примера к вашей ситуации или адаптации решения, рассматриваются, только через заявку или кейс в техническую поддержку.

    4 сентября 2014 г. 7:46
    Модератор
  • Олег, спасибо за помощь!

    Попробую, отпишусь)

    Знаете, занимательный факт...

    Проверил сейчас статистику по письмам на OFR, которые стоят на каждом из EDGE, оказывается письма-то ходят через оба сервера.

    Один раз, во время тестов, мне удалось наблюдать странную картину: с одних внешних IP-адресов удавалось подключиться к первому серверу, но не получалось ко второму. А с других наоборот.

    Мистика какая-то.

    Очень похоже ISP, но только ISP рассчитывает хэш-сумму по-моему для внутренних адресов, а не для внешних...

    4 сентября 2014 г. 8:08
  • Олег, а можете уточнить про Анти-Спам. Правильно ли я понимаю, что он у вас работает через Source NAT? Т.е. вы не знаете IP источника? Или всё-таки как-то иначе?

    Я всё ещё бьюсь с моей проблемой, и есть предположение, что у меня причина в ISP.
    Вот нашёл интересную заметку:

    http://technet.microsoft.com/ru-ru/library/ee796231.aspx

    ISP redundancy does not support e-mail protection
    Issue: When e-mail protection using Forefront Protection for Exchange (FPE) is used in Forefront TMG, the e-mail traffic will not fail over to an alternate ISP link even if the ISP redundancy functionality is configured in Forefront TMG.
    Cause: The ISP redundancy feature requires a NAT relationship with the external network in order to fail over the connection to an alternate ISP. SMTP listeners on the external NIC cannot take advantage of the ISP redundancy functionality as there is no address translation in mail traffic.
    Solution: No solution. To take advantage of the ISP redundancy functionality, use the SMTP publishing feature to publish the internal SMTP servers.

    22 сентября 2014 г. 12:48
  • Алексей, ISP TMG не поддерживает SMTP, это давно известно и понятно.
    SNAT меня сконофигурировано по данной статье.

    Configuring SNAT and DNAT for VMware vCloud Hybrid Service through VMware vCloud Director (2051351)

    При DNAT конфигурации антивирус/антиспам работал не корректно.


    MCITP, MCSE. Знание - не уменьшает нашей глупости. Все данные приведены в виде примера и не адаптированы для вашей системы. Выполнения командлетов и внесения изменений в систему, делаете ВЫ. Все вопросы по привязке примера к вашей ситуации или адаптации решения, рассматриваются, только через заявку или кейс в техническую поддержку.

    22 сентября 2014 г. 13:06
    Модератор
  • Олег, да, я в ISP давно ещё нашёл затык, но всё думал это обойти...

    Спасибо, буду копать в сторону настройки SNAT через TMG/Hyper-V

    22 сентября 2014 г. 13:31
  • Вроде бы решил проблему.

    Отключил NLB на DMZ серверах, и всё заработало. Там, где шлюзом был DMZ VIP я указал IP соответствующих серверов. TMG BE1 - DMZ FE1; EDGE1 - DMZ FE1, etc.

    ISP не отключал.

    Думаю проблема была в том, что NLB собирал на один из DMZ серверов все подключения. К сожалению настройка NLB в TMG весьма скудная, а стандартная оснастка NLB в Windows Server не даёт настраивать NLB кластер из-за ограничений RPC-фильтра TMG.

    Попробую позже поковырять RPC-фильтр чтобы разрешил работу NLB оснастки, или собрать NLB не через мастер TMG, а через, например, PowerShell.

    23 сентября 2014 г. 5:56
  • Алексей, рад что получилось. Рекомендую детально задокументировать и выложить в WIKI Technet.

    Давно отказался от использования NLB в сложных решения. NLB работает в простых, не высокнагруженых решениях, с минимальной сложной инфраструктурой. В более сложных решениях использую сторонние балансировщики.


    MCITP, MCSE. Знание - не уменьшает нашей глупости. Все данные приведены в виде примера и не адаптированы для вашей системы. Выполнения командлетов и внесения изменений в систему, делаете ВЫ. Все вопросы по привязке примера к вашей ситуации или адаптации решения, рассматриваются, только через заявку или кейс в техническую поддержку.

    23 сентября 2014 г. 6:33
    Модератор
  • Олег, спасибо Вам за помощь!

    Выделю время, и напишу в WiKi.

    Встроенный NLB хорош своей "бесплатностью". Решение из коробки.

    Однако те же CAS'ы балансирую RoundRobin'ом, т.к. зная "глючность" NLB решил не рисковать)

    23 сентября 2014 г. 7:43