none
Не могу опубликовать сервер терминалов RRS feed

  • Вопрос

  • Идея такая - шлюзом выступает ИСА 2006 Стандарт. За ней в локалке спрятано несколько важных серверов. Хочу сделать терминальный доступ к сервакам путем публикации их на ИСЕ на разных портах. Т.е.

    rdp://isa:10001 - rdp://srv1:3389

    rdp://isa:10002 - rdp://srv2:3389

    rdp://isa:10003 - rdp://srv3:3389

    Делаю правила публикации не веб-протоколов - и не получается. В чем трабл? (сеть доменная)

    13 января 2007 г. 12:02

Ответы

  • Прошу простить мою невнимательность: вечная проблема человеческого взаимопонимания, когда "мне про Фому, а я вам про Ерёму"

    Просто моя сеть несколько "навороченная" по маршрутизации, и я не применяю на серверах ни FWC, ни SecureNAT. Тем не менее публикация работает прекрасно.

    FWC на сервере неудобно, потому что надо прописывать в конфигурации FWC все локальные сети, иначе трафик улетит на ISA и либо там умрет, либо надо ISA настраивать для роутинга внутренних сетей, но это не функция ISA - для этого есть роутеры backbone.

    Аналогично SecureNAT: надо ISA настраивать для роутинга внутренних сетей.

    Вариант для FWC и  SecureNAT поднять локально на сервере RIP или OSPF - опять же только жизнь осложнять: роутить должны опорные роутеры сети, а не сервер приложений.

     

    Поэтому применяю публикацию без FWC и  SecureNAT.

    Для этого нужно:

    1. Доступность внутренного интерфейса ISA с публикуемого сервера. Либо они в одной сети, либо это задача внутреннего роутинга локальной сети.
    2. Наличие правила на ISA, которое разрешает трафик с внутреннего интерфейса ISA на публикуемый сервер на публикуемый порт.
    3. Правило публикации на ISA созданное визардом.
    4. После создания в свойствах правила публикации на закладке "To" ставим режим Requests appear to come from the ISA Server computer 

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

     

    Такая конфигурация проще и надежнее, работает как в большой, сложной сети, так и в маленькой

    Хочу сказать, что вы безусловно правы: конфигурация с FWC/SecureNAT и опцией Requests appear to come from the original client  рабочая,

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

    16 января 2007 г. 5:20
    Модератор

Все ответы

  •  caveman2k написано:

    Идея такая - шлюзом выступает ИСА 2006 Стандарт. За ней в локалке спрятано несколько важных серверов. Хочу сделать терминальный доступ к сервакам путем публикации их на ИСЕ на разных портах. Т.е.

    rdp://isa:10001 - rdp://srv1:3389

    rdp://isa:10002 - rdp://srv2:3389

    rdp://isa:10003 - rdp://srv3:3389

    Делаю правила публикации не веб-протоколов - и не получается. В чем трабл? (сеть доменная)

    Наиболее частая ошибка, которую при этом допускают - это неправильный шлюз по умолчанию на публикуемых серверах или отсутствие на них ISA Firewall клиента.

    На публикуемых серверах шлюз по умолчанию должен указывать на ISA или быть установлен ISA Firewall клиент. Проверьте.

    13 января 2007 г. 16:09
  • Помимо правил публикации (publish) нужны правила доступа (access) - нужно разрешить соответствующий трафик.
    15 января 2007 г. 6:42
    Модератор
  •  PM-MCSE написано:
    ISA Firewall клиента 

    Все-таки наличие на публикуемом сервере FWC не есть хорошо. Лучше он будет SecureNAT.

     

    15 января 2007 г. 8:17
  • Вопрос был про publishing. Причем тут вообще FWC и SecureNAT?! Если бы спрашивали про access правила, то тогда внутренний сервер должен был быть настроен так, чтобы уметь посылать пакеты наружу. Публикация как раз избавляет от этого.
    15 января 2007 г. 8:42
    Модератор
  • To sie: Это как же так? =) Просветите меня. То есть пакет пришел через ИСА на публикуемый сервер, у которого ни маршрута в сторону ИСА ни FWC, и этот самый сервер вдруг сам догадается куда ему что слать в обратную сторону? =)
    15 января 2007 г. 8:49
  • На публикуемых серверах не обязателен FWC, но вот гейт по умолчанию должен быть корректным.

    2caveman2k
    что пишут логи по этому поводу?

    15 января 2007 г. 9:23
  •  Alexander Trofimov написано:
    To sie: Это как же так? =) Просветите меня. То есть пакет пришел через ИСА на публикуемый сервер, у которого ни маршрута в сторону ИСА ни FWC, и этот самый сервер вдруг сам догадается куда ему что слать в обратную сторону? =)

    При "публикации" обращение к внутреннему серверу делает сам ISA от своего внутреннего интерфейса, а внешний клиент терминируется на ISA на его внешнем интерфейсе. Таким образом публикуемому серверу должен быть только доступен внутренний интерфейс ISA: никаких FWC и ни обязательных маршрутов по умолчанию (SecureNAT) не требуется.

    Вот пример публикования DNS сервера http://support.microsoft.com/kb/837833 

     

    15 января 2007 г. 15:11
    Модератор
  • Вот статья о публиковании Terminal Server http://support.microsoft.com/kb/294720/ko

    Ее можно применить для решения поставленной автором темы задачи.

    15 января 2007 г. 15:14
    Модератор
  •  sie написано:

     Alexander Trofimov написано:
    To sie: Это как же так? =) Просветите меня. То есть пакет пришел через ИСА на публикуемый сервер, у которого ни маршрута в сторону ИСА ни FWC, и этот самый сервер вдруг сам догадается куда ему что слать в обратную сторону? =)

    При "публикации" обращение к внутреннему серверу делает сам ISA от своего внутреннего интерфейса, а внешний клиент терминируется на ISA на его внешнем интерфейсе. Таким образом публикуемому серверу должен быть только доступен внутренний интерфейс ISA: никаких FWC и ни обязательных маршрутов по умолчанию (SecureNAT) не требуется.

    Вот пример публикования DNS сервера http://support.microsoft.com/kb/837833 

     

    Вы не правы. Для публикования сервера необходимо наличие на внутреннем сервере default gateway на внутренний интерфейс ISA.

    Вот описание публикования sql сервера - первое что нашел. Особенно обращаю внимание

    No special configuration of the published server is required after you create the server publishing rule on the ISA Server computer. Note that ISA Server must be configured as the default gateway on the published server.

    15 января 2007 г. 15:20
  • Прошу простить мою невнимательность: вечная проблема человеческого взаимопонимания, когда "мне про Фому, а я вам про Ерёму"

    Просто моя сеть несколько "навороченная" по маршрутизации, и я не применяю на серверах ни FWC, ни SecureNAT. Тем не менее публикация работает прекрасно.

    FWC на сервере неудобно, потому что надо прописывать в конфигурации FWC все локальные сети, иначе трафик улетит на ISA и либо там умрет, либо надо ISA настраивать для роутинга внутренних сетей, но это не функция ISA - для этого есть роутеры backbone.

    Аналогично SecureNAT: надо ISA настраивать для роутинга внутренних сетей.

    Вариант для FWC и  SecureNAT поднять локально на сервере RIP или OSPF - опять же только жизнь осложнять: роутить должны опорные роутеры сети, а не сервер приложений.

     

    Поэтому применяю публикацию без FWC и  SecureNAT.

    Для этого нужно:

    1. Доступность внутренного интерфейса ISA с публикуемого сервера. Либо они в одной сети, либо это задача внутреннего роутинга локальной сети.
    2. Наличие правила на ISA, которое разрешает трафик с внутреннего интерфейса ISA на публикуемый сервер на публикуемый порт.
    3. Правило публикации на ISA созданное визардом.
    4. После создания в свойствах правила публикации на закладке "To" ставим режим Requests appear to come from the ISA Server computer 

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

     

    Такая конфигурация проще и надежнее, работает как в большой, сложной сети, так и в маленькой

    Хочу сказать, что вы безусловно правы: конфигурация с FWC/SecureNAT и опцией Requests appear to come from the original client  рабочая,

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

    16 января 2007 г. 5:20
    Модератор
  • To Sie: понял. Как-то не задумывался об этом. Скорее всего потому что всегда хотел знать кто и откуда на мой сервер лез, а со стороны, скажем, Web-server это выяснять удобнее, чем со стороны ISA. Но все равно спаибо за наводку =)

     

    16 января 2007 г. 7:04