none
Вынесение роли EDGE Server в DMZ между Back-to-Back Firewall. RRS feed

  • Вопрос

  • Добрый день господа!

    Озадачился поставить у себя в сети Front-End и Back-end Firewall (TMG), между ними сделать зону DMZ и в нее уже поместить роль EDGE сервера для антиспам проверки MS Exchange 2010- сам почтовик будет находится за Back-End Firewall.

    Есть конечно статейка вот тут:http://www.isaserver.org/tutorials/Configuring-Domain-Members-Back-to-Back-ISA-Firewall-DMZ-Part1.html Но меня смущает , то что Fron-End ISA не должна быть в домене-это нормально ?

    Если я правильно понимаю эту статью, то по текущей схеме получается следующее:
    Back-End Firewall настроен как шлюз по умолчанию для всей доменной сети которая находится за ним изнутри и сама ISA как член домена настроена как пограничный Firewall для внутренней сети (то есть внутренний DNS сервер, который установлен вместе с AD делает Forward на Back-End ISA, а на самой ISA стоит локальный DNS-который так же форвардит на Frond-End ISA )?

     А вот далее как ? EDGE-который в DMZ и так же являющийся членом домена, так же  публикуется уже на Front-End  ISA?

     И как тогда пользователи внутренней сети будут получать интернет, сначала через Back-End ISA и далее в свою очередь ISA будет делать форвардинг так же на Front-End ISA ? 

    Вопрос:

    Хотелось бы разобраться в логике работы данной схемы по двум вопросам:

    1.Как правильно опубликовать MS Exchange через EDGE-который в DMZ ?

    2. Как правильно дать интернет пользователям по такой схеме?

    Спасибо!


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!


    • Изменено rеstless 12 сентября 2012 г. 5:52
    12 сентября 2012 г. 5:02

Ответы

  • учитывая что работа dns не имеет к TMG никакого отношения, то релизовать можно любой случай:
    1. доменные dns пересылают запросы напрямую в интернет(на корневые с рекурсией или на dns провайдера) и ответы получают оттуда же
    2. доменные dns шлют на кеширующий на backend, а он в интернет
    3. доменные на frontend, а он в интернет
    4. доменные на backend, он на frontend, а он в интернет

    первый самый простой, правильный и распространенный. по всем остальным надо придумать ответ на вопрос "а зачем?"

    Вообще говоря мы же тут рассматриваем схему именно использования двух ISA с DMZ, значит запрос в инет должен проходить через оба ISA, туда и обратно ?


     1. Вообще то по соображением безопасности, внутренний DNS который стоит вместе с AD не должен разрешать имена на прямую в интернет и тем более использовать рекурсию! 

       Если в DNS AD ввести айпи адреса ISP, то тогда какой толк от DMZ в котором будет стоять EDGE и через него должен будет ходить почтовый трафик-который в свою очередь должен сначала попадать на FrontEnd Firewall в первую очередь ? 

    2. Второй вариант более предпочтительнее!Об этом вообще то написано в книге Томаса В.Шиндера по ISA 2004, КОНЕЧНО С ПОМЕТКОЙ-как один из предлагаемых и так же правильных!


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    да что вы пристали к бедной исе с этим дурацким днс? ISA это firewall и proxy, никаких функций dns (ни сервера, ни форвардера) она не несет и нести не должна, ни в каких конфигурациях, даже если их будет 10 штук друг за другом стоять.
    поэтому для исы dns запрос не выглядит как запрос, а просто тупой коннект по udp53 от внутреннего ip на внешний ip, и ее задача сводится только к решению пустить коннект или нет. в текущей задаче достаточно на исе разрешить протокол dns от контроллеров наружу

    1. откуда эти соображения безопасности взялись? нет ничего опасного в том что внутренний dns отправит запрос наружу и получит ответ. вот в обратную сторону действительно нежелательно открывать - могут атаковать или заддосить.
    и причем тут вообще Edge и DMZ? они никакого отношения к теме прохождения dns трафика не имеют, можешь их мысленно выкинуть и считать что у тебя просто иса с доменом (количество ис на задачу не влияют).

    2. вариантов много, но чтобы городить эту ересь надо сначала обосновать - просто так нагружать ису ненужными сложностями опасно, это все таки средство защиты, а лишний сервис, такой как dns, это лишняя потенциальная дыра. кеширующие dns сервера используют, например, при очень большом количестве запросов, чтобы не нагружать контроллеры рекурсией, а в обычных случаях достаточно на контроллерах форвардить на ISP (особенно если он один и автономных систем нет)

    >>Просто в ISA нет же встроенного DNS Forwarder, в отличие от KERIO. Либо я что-то упускаю ?

    и не будет, не надо сравнивать корпоративный продукт с поделками для домохозяек типа керио или пластиковых вайфай роутеров. если нужно поставить кеширующий dns то ставить родной виндовый (или любой сторонний) dns сервер и все

    • Помечено в качестве ответа rеstless 13 сентября 2012 г. 4:57
    12 сентября 2012 г. 19:46
    Отвечающий

Все ответы

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

    Разделите вопросы. Мухи отдельно, котлеты отдельно. Интернет пользователям это одно, а Edge SMTP это другое.

    Рекомендация по Edge.

    1. Работчая группа, а не домен. Суфикс правильно прописать надо.

    2. Обратить внимание на требование к портам для роли Edge.

    Exchange Network Port Reference

    3. Далее простая установка и настройка маршрутизации и портов. Настройка синхронизации с HUB и AD.

    Пример.

    Exchange 2010 Edge Transport Server Introduction


    MCITP. Знание - не уменьшает нашей глупости.


    12 сентября 2012 г. 7:28
  • по edge вроде все сказали, теперь по остальному:
    1. никакие dns на tmg не нужны - dns на контроллерах будут просто ходить в инет за разрешением имен и все. ну если очень хочется то можно поставить локальный dns на tmg, но смысла в этом никакого.

    2. что подразумевается под словом форвардинг?
    3. внутренние клиенты настроены шлюзом по умолчанию, прокси и fwc на backend, у него в свою очередь шлюз по умолчанию на frontend, при желании можно сделать web chaining, но надо подумать над смыслом этого )

    12 сентября 2012 г. 9:25
    Отвечающий
  • Publishing Exchange through TMG Back-end\Front-end configuration

    MCITP. Знание - не уменьшает нашей глупости.

    12 сентября 2012 г. 9:42
  • по edge вроде все сказали, теперь по остальному:
    1. никакие dns на tmg не нужны - dns на контроллерах будут просто ходить в инет за разрешением имен и все. ну если очень хочется то можно поставить локальный dns на tmg, но смысла в этом никакого.

    2. что подразумевается под словом форвардинг?
    3. внутренние клиенты настроены шлюзом по умолчанию, прокси и fwc на backend, у него в свою очередь шлюз по умолчанию на frontend, при желании можно сделать web chaining, но надо подумать над смыслом этого )

      По первому ответу: 

    Почему локальный DNS на BackEnd-просто потому и спрашиваю, можно ли реализовать схему со стороны внутренней сети с BackEnd , почти как с пограничным брандмауэром, то есть когда локальный DNS на Active Directory работает в качестве forward (сервер пересылки) и пересылает все запросы на другой локальный DNS который установлен на  BackEnd firewall и который будет как DNS-кэш (то есть просто настроен с зонами заглушки). Просто как BackEnd Firewall будет пересылать запросы в интернет ?-через FronEnd, или напрямую ? Вот в чем вопрос.

     По второму ответу: Я написал уже в выше (сервер пересылок)

      В остальном все ясно!

    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!


    • Изменено rеstless 12 сентября 2012 г. 12:31
    12 сентября 2012 г. 10:50
  • учитывая что работа dns не имеет к TMG никакого отношения, то релизовать можно любой случай:
    1. доменные dns пересылают запросы напрямую в интернет(на корневые с рекурсией или на dns провайдера) и ответы получают оттуда же
    2. доменные dns шлют на кеширующий на backend, а он в интернет
    3. доменные на frontend, а он в интернет
    4. доменные на backend, он на frontend, а он в интернет

    первый самый простой, правильный и распространенный. по всем остальным надо придумать ответ на вопрос "а зачем?"

    12 сентября 2012 г. 14:41
    Отвечающий
  • учитывая что работа dns не имеет к TMG никакого отношения, то релизовать можно любой случай:
    1. доменные dns пересылают запросы напрямую в интернет(на корневые с рекурсией или на dns провайдера) и ответы получают оттуда же
    2. доменные dns шлют на кеширующий на backend, а он в интернет
    3. доменные на frontend, а он в интернет
    4. доменные на backend, он на frontend, а он в интернет

    первый самый простой, правильный и распространенный. по всем остальным надо придумать ответ на вопрос "а зачем?"

    Вообще говоря мы же тут рассматриваем схему именно использования двух ISA с DMZ, значит запрос в инет должен проходить через оба ISA, туда и обратно ?


     1. Вообще то по соображением безопасности, внутренний DNS который стоит вместе с AD не должен разрешать имена на прямую в интернет и тем более использовать рекурсию! 

       Если в DNS AD ввести айпи адреса ISP, то тогда какой толк от DMZ в котором будет стоять EDGE и через него должен будет ходить почтовый трафик-который в свою очередь должен сначала попадать на FrontEnd Firewall в первую очередь ? 

    2. Второй вариант более предпочтительнее!Об этом вообще то написано в книге Томаса В.Шиндера по ISA 2004, КОНЕЧНО С ПОМЕТКОЙ-как один из предлагаемых и так же правильных!


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!








    • Изменено rеstless 12 сентября 2012 г. 18:03
    12 сентября 2012 г. 15:57
  • День добрый.

    Разделите вопросы. Мухи отдельно, котлеты отдельно. Интернет пользователям это одно, а Edge SMTP это другое.

    Рекомендация по Edge.

    1. Работчая группа, а не домен. Суфикс правильно прописать надо.

    2. Обратить внимание на требование к портам для роли Edge.

    Exchange Network Port Reference

    3. Далее простая установка и настройка маршрутизации и портов. Настройка синхронизации с HUB и AD.

    Пример.

    Exchange 2010 Edge Transport Server Introduction


    MCITP. Знание - не уменьшает нашей глупости.


     Про EDGE все понятно!

    Я хочу одно понять, как раздавать интернет в текущей топологии с двумя ISA. Просто в ISA нет же встроенного DNS Forwarder, в отличие от KERIO. Либо я что-то упускаю ?

    клиент->DNS с функцией пересылки Active Directory->DNS с функцией пересылки  BackEnd ISA->DNS с функцией пересылки  FrontEnd ISA->ISP.


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!


    • Изменено rеstless 12 сентября 2012 г. 18:04
    12 сентября 2012 г. 17:21
  • Пока не увидел аргументов для устанвки TMG в режиме FrontEnd BackEnd. Нет сервисов приложений, которые требовалось разносить. Нет потока данных, которые требовалось тунелировать и форматировать из DMZ во внутренюю сеть. Если действительно надо разграничить сети, то где сервера перекладчики, где конверторы форматов ввода/вывода данных.


    MCITP. Знание - не уменьшает нашей глупости.

    12 сентября 2012 г. 19:41
  • учитывая что работа dns не имеет к TMG никакого отношения, то релизовать можно любой случай:
    1. доменные dns пересылают запросы напрямую в интернет(на корневые с рекурсией или на dns провайдера) и ответы получают оттуда же
    2. доменные dns шлют на кеширующий на backend, а он в интернет
    3. доменные на frontend, а он в интернет
    4. доменные на backend, он на frontend, а он в интернет

    первый самый простой, правильный и распространенный. по всем остальным надо придумать ответ на вопрос "а зачем?"

    Вообще говоря мы же тут рассматриваем схему именно использования двух ISA с DMZ, значит запрос в инет должен проходить через оба ISA, туда и обратно ?


     1. Вообще то по соображением безопасности, внутренний DNS который стоит вместе с AD не должен разрешать имена на прямую в интернет и тем более использовать рекурсию! 

       Если в DNS AD ввести айпи адреса ISP, то тогда какой толк от DMZ в котором будет стоять EDGE и через него должен будет ходить почтовый трафик-который в свою очередь должен сначала попадать на FrontEnd Firewall в первую очередь ? 

    2. Второй вариант более предпочтительнее!Об этом вообще то написано в книге Томаса В.Шиндера по ISA 2004, КОНЕЧНО С ПОМЕТКОЙ-как один из предлагаемых и так же правильных!


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    да что вы пристали к бедной исе с этим дурацким днс? ISA это firewall и proxy, никаких функций dns (ни сервера, ни форвардера) она не несет и нести не должна, ни в каких конфигурациях, даже если их будет 10 штук друг за другом стоять.
    поэтому для исы dns запрос не выглядит как запрос, а просто тупой коннект по udp53 от внутреннего ip на внешний ip, и ее задача сводится только к решению пустить коннект или нет. в текущей задаче достаточно на исе разрешить протокол dns от контроллеров наружу

    1. откуда эти соображения безопасности взялись? нет ничего опасного в том что внутренний dns отправит запрос наружу и получит ответ. вот в обратную сторону действительно нежелательно открывать - могут атаковать или заддосить.
    и причем тут вообще Edge и DMZ? они никакого отношения к теме прохождения dns трафика не имеют, можешь их мысленно выкинуть и считать что у тебя просто иса с доменом (количество ис на задачу не влияют).

    2. вариантов много, но чтобы городить эту ересь надо сначала обосновать - просто так нагружать ису ненужными сложностями опасно, это все таки средство защиты, а лишний сервис, такой как dns, это лишняя потенциальная дыра. кеширующие dns сервера используют, например, при очень большом количестве запросов, чтобы не нагружать контроллеры рекурсией, а в обычных случаях достаточно на контроллерах форвардить на ISP (особенно если он один и автономных систем нет)

    >>Просто в ISA нет же встроенного DNS Forwarder, в отличие от KERIO. Либо я что-то упускаю ?

    и не будет, не надо сравнивать корпоративный продукт с поделками для домохозяек типа керио или пластиковых вайфай роутеров. если нужно поставить кеширующий dns то ставить родной виндовый (или любой сторонний) dns сервер и все

    • Помечено в качестве ответа rеstless 13 сентября 2012 г. 4:57
    12 сентября 2012 г. 19:46
    Отвечающий
  • Пока не увидел аргументов для устанвки TMG в режиме FrontEnd BackEnd. Нет сервисов приложений, которые требовалось разносить. Нет потока данных, которые требовалось тунелировать и форматировать из DMZ во внутренюю сеть. Если действительно надо разграничить сети, то где сервера перекладчики, где конверторы форматов ввода/вывода данных.


    MCITP. Знание - не уменьшает нашей глупости.

     Добрый день! Давайте так, это не аргументы, это то что я хочу попробовать, всего лишь тестовая сеть. И я определил работу некоторых ИТ-сервисов , которые будут работать  для этой сети: MS Exchange c разнесением ролей CAS и EDGE в сегмент DMZ, далее публикация OWA, VPN доступ, может еще WEB-сервер будет, который необходимо будет так же опубликовать и вынести в DMZ. Разве этого не достаточно ? Можно успешно и с одним пограничным ISA Firewall жить, как на данный момент живет наша инфраструктура и вынести роль EDGE просто на отдельный компьютер в не домена и можно даже сделать топологию 3-LEG! 

     Но я озадачился как раз на топологию Back-to-Back, что здесь еще необходимо аргументировать ? Согласен городить лишний раз нет необходимости, но Expiriens не помешает, не правда ли ? 

     то где сервера перекладчики, где конверторы форматов ввода/вывода данных.

     Позвольте, а что это вообще такое ?

     


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!



    • Изменено rеstless 13 сентября 2012 г. 4:45
    13 сентября 2012 г. 4:43
  • учитывая что работа dns не имеет к TMG никакого отношения, то релизовать можно любой случай:
    1. доменные dns пересылают запросы напрямую в интернет(на корневые с рекурсией или на dns провайдера) и ответы получают оттуда же
    2. доменные dns шлют на кеширующий на backend, а он в интернет
    3. доменные на frontend, а он в интернет
    4. доменные на backend, он на frontend, а он в интернет

    первый самый простой, правильный и распространенный. по всем остальным надо придумать ответ на вопрос "а зачем?"

    Вообще говоря мы же тут рассматриваем схему именно использования двух ISA с DMZ, значит запрос в инет должен проходить через оба ISA, туда и обратно ?


     1. Вообще то по соображением безопасности, внутренний DNS который стоит вместе с AD не должен разрешать имена на прямую в интернет и тем более использовать рекурсию! 

       Если в DNS AD ввести айпи адреса ISP, то тогда какой толк от DMZ в котором будет стоять EDGE и через него должен будет ходить почтовый трафик-который в свою очередь должен сначала попадать на FrontEnd Firewall в первую очередь ? 

    2. Второй вариант более предпочтительнее!Об этом вообще то написано в книге Томаса В.Шиндера по ISA 2004, КОНЕЧНО С ПОМЕТКОЙ-как один из предлагаемых и так же правильных!


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    да что вы пристали к бедной исе с этим дурацким днс? ISA это firewall и proxy, никаких функций dns (ни сервера, ни форвардера) она не несет и нести не должна, ни в каких конфигурациях, даже если их будет 10 штук друг за другом стоять.

    поэтому для исы dns запрос не выглядит как запрос, а просто тупой коннект по udp53 от внутреннего ip на внешний ip, и ее задача сводится только к решению пустить коннект или нет. в текущей задаче достаточно на исе разрешить протокол dns от контроллеров наружу

    1. откуда эти соображения безопасности взялись? нет ничего опасного в том что внутренний dns отправит запрос наружу и получит ответ. вот в обратную сторону действительно нежелательно открывать - могут атаковать или заддосить.
    и причем тут вообще Edge и DMZ? они никакого отношения к теме прохождения dns трафика не имеют, можешь их мысленно выкинуть и считать что у тебя просто иса с доменом (количество ис на задачу не влияют).

    2. вариантов много, но чтобы городить эту ересь надо сначала обосновать - просто так нагружать ису ненужными сложностями опасно, это все таки средство защиты, а лишний сервис, такой как dns, это лишняя потенциальная дыра. кеширующие dns сервера используют, например, при очень большом количестве запросов, чтобы не нагружать контроллеры рекурсией, а в обычных случаях достаточно на контроллерах форвардить на ISP (особенно если он один и автономных систем нет)

    >>Просто в ISA нет же встроенного DNS Forwarder, в отличие от KERIO. Либо я что-то упускаю ?

    и не будет, не надо сравнивать корпоративный продукт с поделками для домохозяек типа керио или пластиковых вайфай роутеров. если нужно поставить кеширующий dns то ставить родной виндовый (или любой сторонний) dns сервер и все

      да что вы пристали к бедной исе с этим дурацким днс? ISA это firewall и proxy, никаких функций dns (ни сервера, ни форвардера) она не несет и нести не должна, ни в каких конфигурациях, даже если их будет 10 штук друг за другом стоять.

     Здесь согласен, переборщил!

    откуда эти соображения безопасности взялись? нет ничего опасного в том что внутренний dns отправит запрос наружу и получит ответ. вот в обратную сторону действительно нежелательно открывать - могут атаковать или заддосить.
    и причем тут вообще Edge и DMZ? они никакого отношения к теме прохождения dns трафика не имеют, можешь их мысленно выкинуть и считать что у тебя просто иса с доменом (количество ис на задачу не влияют).

    Может наверное все таки так EDGE и CAS сервер будут находится в DMZ и будут публиковаться через ISA Firewall правилами доступа по протоколу SMTP.

    вариантов много, но чтобы городить эту ересь надо сначала обосновать - просто так нагружать ису ненужными сложностями опасно, это все таки средство защиты, а лишний сервис, такой как dns, это лишняя потенциальная дыра. кеширующие dns сервера используют, например, при очень большом количестве запросов, чтобы не нагружать контроллеры рекурсией, а в обычных случаях достаточно на контроллерах форвардить на ISP (особенно если он один и автономных систем нет)

    Давайте так, это не аргументы, это то что я хочу попробовать, всего лишь тестовая сеть. И я определил работу некоторых ИТ-сервисов , которые будут работать  для этой сети: MS Exchange c разнесением ролей CAS и EDGE в сегмент DMZ, далее публикация OWA, VPN доступ, может еще WEB-сервер будет, который необходимо будет так же опубликовать и вынести в DMZ. Разве этого не достаточно ? Можно успешно и с одним пограничным ISA Firewall жить, как на данный момент живет наша инфраструктура и вынести роль EDGE просто на отдельный компьютер в не домена и можно даже сделать топологию 3-LEG! 

     Но я озадачился как раз на топологию Back-to-Back, что здесь еще необходимо аргументировать ? Согласен городить лишний раз нет необходимости, но Expiriens не помешает, не правда ли ? 


    не надо сравнивать корпоративный продукт с поделками для домохозяек типа керио или пластиковых вайфай роутеров. если нужно поставить кеширующий dns то ставить родной виндовый (или любой сторонний) dns сервер и все

     Да не сказал бы конечно что уж kERIO для домохозяек, доводилось работать с KERIO где 200-300 пользователей было. Но конечно если вся инфраструктура построена на продуктах от определенного вендора, такого как Microsoft, то тут конечно куда лучьше и прозрачнее будет поставить именно ISA Firewall.

    В общем спасибо за ваши мнения высказанные вами, они идут только на пользу!

    В общем будем адекватно разбираться..



    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    13 сентября 2012 г. 4:54
  • по ересью я имел ввиду установку кеширующих dns на исы, а не концепцию dmz в целом. и раз уж действительно заморочился безопасностью и реализацией полноценной dmz, то намного логичнее следовать тем же принципам что и с почтовым трафиком - поставить кеширующий dns в dmz, например на тот же edge.
    можно и наоборот, в деле с edge соблюдать ту же логику что и с dns - установить edge на сам tmg, они прекрасно живут вместе и интегрируются )
    а експириенса тут будет мало - установка кеширующего dns дело двух щелчков мыши )
    13 сентября 2012 г. 8:37
    Отвечающий
  • по ересью я имел ввиду установку кеширующих dns на исы, а не концепцию dmz в целом. и раз уж действительно заморочился безопасностью и реализацией полноценной dmz, то намного логичнее следовать тем же принципам что и с почтовым трафиком - поставить кеширующий dns в dmz, например на тот же edge.
    можно и наоборот, в деле с edge соблюдать ту же логику что и с dns - установить edge на сам tmg, они прекрасно живут вместе и интегрируются )
    а експириенса тут будет мало - установка кеширующего dns дело двух щелчков мыши )

     Ок! Спасибо за совет.

     Будем пробовать. 


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    13 сентября 2012 г. 10:11