none
доступ к ресурсам, опубликованным на том же сервере Forefront TMG RRS feed

  • Вопрос

  • добрый день!

     

    после переезда приложений из одного ЦОДа в другой так получилось, что они стали по http ходить на тот же самый сервер Forefront TMG.

     

    1) с внешнего мира данный ресурс доступен

    2) с данного клиента доступен внешний мир

     

    но вот как-то вместе они не работают. как необходимо правильно публиковать ресурсы, чтобы из своей же локальной сети можно было к ним обращаться ? в форуме в ноябре, кажется, был такой же вопрос, там предлагали в listener прописать Localhost - пробовал, не помогает.

     


    Ilya Shipitsin
    13 декабря 2010 г. 10:03

Все ответы

  • а внутренний клиент обращается прямиком на внешний интерфейс исы или снаружи исы есть еще какая то железка и клиент попадает на нее?

    13 декабря 2010 г. 11:15
    Отвечающий
  • а внутренний клиент обращается прямиком на внешний интерфейс исы или снаружи исы есть еще какая то железка и клиент попадает на нее?

    внутренний клиент подключен в локальную сеть (Internal), шлюз по умолчанию - NLB кластер из 2-х серверов Forefront. На кластере куча VIP-ов. вот на них клиент и ходит. В смысле, на Foreffront и внешний и внутренний интерфейсы завязаны в NLB. Других железок нет.

    Ilya Shipitsin
    13 декабря 2010 г. 11:20
  • Илья, т.е. у Вас веб-сервер размещен на сервере с TMG?..

    13 декабря 2010 г. 12:25
    Отвечающий
  • Илья, т.е. у Вас веб-сервер размещен на сервере с TMG?..

    на TMG правило публикации (через Non-Web Server Publish, чтобы tcp напрямую прилетало на веб-сервер, без фильтров), а сервер в локальной сети.

    Ilya Shipitsin
    13 декабря 2010 г. 12:35
  • напрямую я не пробовал, но веб публикация работает нормально, у меня полтора десятка публикованных веб серверов, тоже nlb array на обоих интерфейсах, правда иса 2006, в правилах публикации слушается только external, но стоит разрешение из internal на localhost
    13 декабря 2010 г. 13:33
    Отвечающий


  • напрямую я не пробовал, но веб публикация работает нормально, у меня полтора десятка публикованных веб серверов, тоже nlb array на обоих интерфейсах, правда иса 2006, в правилах публикации слушается только external, но стоит разрешение из internal на localhost
    кроме разрешения, я так понимаю, необходимо еще "network rule" ? из LocalHost во все стороны стоит Route, из Internal в External стоит NAT (как обычно). веб публикация нам не подходмит, нам надо чтобы веб-сервер видел в tcp-соединении ip адрес клиента, т.е. обычный nat. вы никакие дополнительные network rule не делали ?

    Ilya Shipitsin
    13 декабря 2010 г. 13:38
  • веб сервер будет видеть адрес клиента если поставить галочку "... from the original client" на вкладке To

    больше никаких network rule у нас нет

    13 декабря 2010 г. 14:35
    Отвечающий
  • веб сервер будет видеть адрес клиента если поставить галочку "... from the original client" на вкладке To

    больше никаких network rule у нас нет

    в случае Web publish сервер может видеть IP клиента ?

    Ilya Shipitsin
    13 декабря 2010 г. 15:09
  • конечно, во всяком случае netstat видит и iis в свои логи пишет.

    я обычн остараюсь включать именно так, для диагностики полезнее если в логах будет ип клиента

    13 декабря 2010 г. 15:32
    Отвечающий
  • Илья, "non-web server publish" работает лишь в том случае, если осуществляется публикация сетевой службы, хост которой находится за NAT.

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

    13 декабря 2010 г. 18:37
    Отвечающий
  • Илья, "non-web server publish" работает лишь в том случае, если осуществляется публикация сетевой службы, хост которой находится за NAT.

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


    а так, собственно и есть, хост находится за NAT (он находится в Internal) и снаружи клиенты прекрасно на него ходят. это получается как бы внешнее доменное имя (и tcp порт), на котором опубликовано приложение. напрямую не совсем получится, дело в том,что

    1) в топологии других приложений указано доменное имя,по которому обращаться (и не все приложения знают, в одном ли ЦОДе они живут с другими сервисами)

    2) внутренний порт - бывает отличается от внешнего, а настройки для порта есть не у всех приложений

     

    внешний адрес и внешний порт - это более универсально, я считаю.

    а почему это не будет работать с Forefront-ом ? может спросить коллег из Штатов? есть какая-нибудь статья, из которой бы явно следовало, будет такое работать или нет? чисто теоретически - противоречий не вижу, на всех известных мне фаирволах (pf, ipfw, iptables) - это реализуется.


    Ilya Shipitsin
    13 декабря 2010 г. 19:53
  • никто и не говорил что работать не будет, просто это с точки зрения идеологии неправильно
    в принципе это работает, во всяком случае у меня всегда работало. насчет других файрволов это не всегда так, я не зря сначала спросил про внешние железки - cisco pix или asa такого никогда не позволят, именно поэтому мне когда то пришлось на внутренних днс завести зону-заглушку для внешнего домена и вписать там внутренние ипшники (для тех же целей - универсальные ссылки), причем когда необходима была именно публикация (например для тестирования или когда порты не совпадали) то вписал просто внешний ип исы (в схеме internal - isa - perimeter - asa - internet) и все работает
    13 декабря 2010 г. 21:21
    Отвечающий
  • никто и не говорил что работать не будет, просто это с точки зрения идеологии неправильно
    в принципе это работает, во всяком случае у меня всегда работало. насчет других файрволов это не всегда так, я не зря сначала спросил про внешние железки - cisco pix или asa такого никогда не позволят, именно поэтому мне когда то пришлось на внутренних днс завести зону-заглушку для внешнего домена и вписать там внутренние ипшники (для тех же целей - универсальные ссылки), причем когда необходима была именно публикация (например для тестирования или когда порты не совпадали) то вписал просто внешний ип исы (в схеме internal - isa - perimeter - asa - internet) и все работает
    а в чем противоречие с идеологией ? ну ходит клиент на xxx.yyy.ru:nnn, что этот клиент находится снаружи, что внутри, каким образом идеология это  запрещает ? и если это "должно"  работать, почему тогда пишет 10061 ? инициируете баг репорт ? похоже, есть все основания

    Ilya Shipitsin
    14 декабря 2010 г. 2:21
  • никто и не говорил что работать не будет, просто это с точки зрения идеологии неправильно
    в принципе это работает, во всяком случае у меня всегда работало. насчет других файрволов это не всегда так, я не зря сначала спросил про внешние железки - cisco pix или asa такого никогда не позволят, именно поэтому мне когда то пришлось на внутренних днс завести зону-заглушку для внешнего домена и вписать там внутренние ипшники (для тех же целей - универсальные ссылки), причем когда необходима была именно публикация (например для тестирования или когда порты не совпадали) то вписал просто внешний ип исы (в схеме internal - isa - perimeter - asa - internet) и все работает

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

    Ilya Shipitsin
    14 декабря 2010 г. 2:24
  • Илья, типовым и рекомендуемым сценариме считается т.н. "split DNS", т.е. когда внешним клиентам возвращаются внешние адреса, а клиентам внутренним - внутренние.

    Смотрите, что может произойти, и наверняка так оно и происходит, в Вашей схеме.
    Клиент пытается устанавливить соединение с внешним IP-адресом TMG. TMG либо терминирует, либо "перенаправляет" соединение к сетевой службе. Если не указано подменять IP-адрес клиента адресом TMG, то сервер "отвечает" клиенту минуя TMG ("напрямую"), т.е. не направляет пакеты на TMG, а направляет их на шлюз в сеть клиента. Иными словами, "запрос" и "ответ" проходят разными маршрутами. Таким образом нарушается TCP-соединение.

    Так что либо используйте "split DNS", либо подменяйте адрес клиента адресом TMG в правиле публикации.

    14 декабря 2010 г. 6:30
    Отвечающий
  • подменять ип клиента в правиле необязательно, но при этом иса должна внутреннего клиента выпускать на свой внешний адрес проксируя, то есть по сути на публикуемом серваке будет светится внешний адрес исы.

    с именами сайтов, в том числе с crl вопрос решается через split dns

    14 декабря 2010 г. 12:38
    Отвечающий

  • подменять ип клиента в правиле необязательно, но при этом иса должна внутреннего клиента выпускать на свой внешний адрес проксируя, то есть по сути на публикуемом серваке будет светится внешний адрес исы.

    с именами сайтов, в том числе с crl вопрос решается через split dns

    про split dns (и web publish) я понял, попробую реализовать. а насчет "выпускать внутреннего клиента на свой внешний адрес проксируя" - в терминах правил публикации и "network rules" можете пояснить на примере ? кстати, web publish очень странно реагирует, если поменять http-порт (то есть применить Web publish на нестандартном порту), начинает капризничать по поводу сертификатов (хотя галочка https не выбрана)

    Ilya Shipitsin
    14 декабря 2010 г. 13:40
  • подменять ип клиента в правиле необязательно, но при этом иса должна внутреннего клиента выпускать на свой внешний адрес проксируя, то есть по сути на публикуемом серваке будет светится внешний адрес исы.

    с именами сайтов, в том числе с crl вопрос решается через split dns

    через "server publish" реализована куча правил вида

    x.y.z.t:80 ---> ip1:778

    x.y.z.t:81 --> ip2:779

    x.y.z.t:82 --> ip3:780

     

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


    Ilya Shipitsin
    14 декабря 2010 г. 13:43
  • Илья, типовым и рекомендуемым сценариме считается т.н. "split DNS", т.е. когда внешним клиентам возвращаются внешние адреса, а клиентам внутренним - внутренние.

    Смотрите, что может произойти, и наверняка так оно и происходит, в Вашей схеме.
    Клиент пытается устанавливить соединение с внешним IP-адресом TMG. TMG либо терминирует, либо "перенаправляет" соединение к сетевой службе. Если не указано подменять IP-адрес клиента адресом TMG, то сервер "отвечает" клиенту минуя TMG ("напрямую"), т.е. не направляет пакеты на TMG, а направляет их на шлюз в сеть клиента. Иными словами, "запрос" и "ответ" проходят разными маршрутами. Таким образом нарушается TCP-соединение.

    Так что либо используйте "split DNS", либо подменяйте адрес клиента адресом TMG в правиле публикации.

    если вы имеете в виду галочку "From Forefront computer" или "From original client" - я ее пробовал менять, толку нет. или вы что-то другое имеете в виду ?

    Ilya Shipitsin
    14 декабря 2010 г. 14:41
  • про split dns (и web publish) я понял, попробую реализовать. а насчет "выпускать внутреннего клиента на свой внешний адрес проксируя" - в терминах правил публикации и "network rules" можете пояснить на примере ? кстати, web publish очень странно реагирует, если поменять http-порт (то есть применить Web publish на нестандартном порту), начинает капризничать по поводу сертификатов (хотя галочка https не выбрана)

    Ilya Shipitsin
    имелось ввиду что внутренний клиент идет на публикуемый веб сайт как web proxy клиент
    про капризы с портом и сертификатом - обновления для tmg посмотри, недавно тут проскакивало такое
    14 декабря 2010 г. 18:00
    Отвечающий
  • // подменять ип клиента в правиле необязательно

    Дим, даже если ISA выступает в качетсве reverse-proxy, т.е. клиент доступается на web-listener, то подменять адрес все же необходимо. ISA терминирует соединение на "приемнике", но создает соединение к серверу с адресом источника так, как указано в правиле публикации. Я ошибаюсь?..

    14 декабря 2010 г. 19:00
    Отвечающий
  • ну все так, но при этом адрес клиента на сервере виден.
    я имел ввиду, что если внутренний клиент обращается на внешний ип исы без nat или прокси то вполне реальна ситуация что иса его пошлет.
    15 декабря 2010 г. 13:34
    Отвечающий
  • ну все так, но при этом адрес клиента на сервере виден.
    я имел ввиду, что если внутренний клиент обращается на внешний ип исы без nat или прокси то вполне реальна ситуация что иса его пошлет.
    "вполне реальна" это как понимать )) она работает по вероятностным алгоритмам ?

    Ilya Shipitsin
    15 декабря 2010 г. 13:37
  • ну все так, но при этом адрес клиента на сервере виден.
    я имел ввиду, что если внутренний клиент обращается на внешний ип исы без nat или прокси то вполне реальна ситуация что иса его пошлет.
    "вполне реальна" это как понимать )) она работает по вероятностным алгоритмам ?

    Ilya Shipitsin

    я просто это не проверял, по умолчанию клиент идущий на внешние адреса проксируется или натится :)
    15 декабря 2010 г. 13:48
    Отвечающий
  • Угу, если адрес клиента транслируется - то нет проблем, сервер "обязан идти" тем же маршрутом, т.е. через ISA, иначе никакая публикация работать не будет, но если клиент пришел на внешний адрес и из сети, которая маршрутизируется с этим адресом без NAT, и сеть клиента маршрутизируется без NAT с сетью сервера, то очевидно, что сервер "пойдет" к клиенту "мимо" ISA. Эта ситуация типична, когда ISA не NAT'ит и при этом клиент с сервером могут общаться "напрямую" по более "выгодному" маршруту, нежели через ISA.

    Илья, чтобы ответить однозначно, необходимо ознакомиться с подробной топологией Вашей сети.
    Вы пробовали указать "использовать сервер ISA" в правиле?.. :)

    15 декабря 2010 г. 17:38
    Отвечающий
  • Угу, если адрес клиента транслируется - то нет проблем, сервер "обязан идти" тем же маршрутом, т.е. через ISA, иначе никакая публикация работать не будет, но если клиент пришел на внешний адрес и из сети, которая маршрутизируется с этим адресом без NAT, и сеть клиента маршрутизируется без NAT с сетью сервера, то очевидно, что сервер "пойдет" к клиенту "мимо" ISA. Эта ситуация типична, когда ISA не NAT'ит и при этом клиент с сервером могут общаться "напрямую" по более "выгодному" маршруту, нежели через ISA.

    Илья, чтобы ответить однозначно, необходимо ознакомиться с подробной топологией Вашей сети.
    Вы пробовали указать "использовать сервер ISA" в правиле?.. :)

    я про топологию все рассказал, что знал. спрашивайте, что конкретно непонятно.

    покажите на снимке экрана, что имеется в виду "использовать сервер ISA" ? у нас английский Forefront.


    Ilya Shipitsin
    16 декабря 2010 г. 20:55
  • Вкладка "To", "Request appear to come from ISA server".

    16 декабря 2010 г. 21:10
    Отвечающий
  • Вкладка "To", "Request appear to come from ISA server".

    пробовал

    Ilya Shipitsin
    17 декабря 2010 г. 4:42
  • Уважаемый пользователь!
    В вашей теме отсутствует активность в течение последних 5 дней. При отсутствии каких-либо действий в течение 2 последующих дней, тема будет переведена в разряд обсуждений. Вы можете возобновить дискуссию, просто оставив сообщение в данной теме.

    Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции корпорации Microsoft. Вся информация предоставляется "как есть" без каких-либо гарантий
    24 декабря 2010 г. 10:22
  • Уважаемый пользователь!
    В вашей теме отсутствует активность в течение последних 5 дней. При отсутствии каких-либо действий в течение 2 последующих дней, тема будет переведена в разряд обсуждений. Вы можете возобновить дискуссию, просто оставив сообщение в данной теме.

    Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции корпорации Microsoft. Вся информация предоставляется "как есть" без каких-либо гарантий
    ну я не знаю, почему активность отсутствует )) вопрос то не решен по сути. давайте уже активнее участвуйте чтоли.

    Ilya Shipitsin
    24 декабря 2010 г. 10:23
  • Ilia Chipitsine, чем у вас дело кончилось?
    Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции корпорации Microsoft. Вся информация предоставляется "как есть" без каких-либо гарантий
    11 января 2011 г. 15:12
  • Ilia Chipitsine, чем у вас дело кончилось?
    Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции корпорации Microsoft. Вся информация предоставляется "как есть" без каких-либо гарантий

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

    Ilya Shipitsin
    11 января 2011 г. 17:24
  • боюсь, что официальный ответ может дать только официальная поддержка.
    Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции корпорации Microsoft. Вся информация предоставляется "как есть" без каких-либо гарантий
    12 января 2011 г. 14:01
  • боюсь, что официальный ответ может дать только официальная поддержка.
    Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции корпорации Microsoft. Вся информация предоставляется "как есть" без каких-либо гарантий

    у вас в профиле слово Microsoft написано, что оно означает ? у меня почему-то было ощущение, что вы можете быть связаны с этой компанией. нет ?

    Ilya Shipitsin
    12 января 2011 г. 20:15
  • Илья, я не сотрудник Майкрософт, конечно, но Вам отвечу все же еще раз.
    Итак, TMG может публиковать web-сайт во внутренней сети для клиентов этой сети. В этот я могу Вас уверить на основе собственного опыта. Решение это, конечно, не самое красивое, но рабочее.
    В Вашем случае наблюдается, что TCP-соединение было отклонено. Причин этому может быть много, но очевидная, как я полагаю, для Вашей ситуации в том, что IP-пакеты идут от клиента к web-серверу и обратно разными маршрутами. Убедитесь, что клиент и сервер обмениваются IP-пакетами через один и тот же маршрут! При этом важно понимать, с какого из адресов "клиента" устанавливается соединение. В общем, смотрите логи web-сервара, узнавайте адрес клиента и трассируйте маршрут в обе стороны, т.е. со стороны адреса клиента из логов сервера и наоборот. Полагаю, что в логах адрес клиента будет из подсети "внутренней", т.е. не маршрутизируемой в вашем случае через ISA, а то и общей для сервера и клиента, а, стало быть, "ответы" на соединение пойдут мимо ISA и она не "увидит", что соединение устанавливаеися с web-listener'ом, т.е. "отклоняется" сервером по логике ISA, и выдает Вам ошибку. Вот.

    12 января 2011 г. 20:59
    Отвечающий
  • Илья, я не сотрудник Майкрософт, конечно, но Вам отвечу все же еще раз.
    Итак, TMG может публиковать web-сайт во внутренней сети для клиентов этой сети. В этот я могу Вас уверить на основе собственного опыта. Решение это, конечно, не самое красивое, но рабочее .
    В Вашем случае наблюдается, что TCP-соединение было отклонено. Причин этому может быть много, но очевидная, как я полагаю, для Вашей ситуации в том, что IP-пакеты идут от клиента к web-серверу и обратно разными маршрутами. Убедитесь, что клиент и сервер обмениваются IP-пакетами через один и тот же маршрут! При этом важно понимать, с какого из адресов "клиента" устанавливается соединение. В общем, смотрите логи web-сервара, узнавайте адрес клиента и трассируйте маршрут в обе стороны, т.е. со стороны адреса клиента из логов сервера и наоборот. Полагаю, что в логах адрес клиента будет из подсети "внутренней", т.е. не маршрутизируемой в вашем случае через ISA, а то и общей для сервера и клиента, а, стало быть, "ответы" на соединение пойдут мимо ISA и она не "увидит", что соединение устанавливаеися с web-listener'ом, т.е. "отклоняется" сервером по логике ISA, и выдает Вам ошибку. Вот.

    ваш опыт может быть неполным, или это где-то в документации про ису сказано, что она работает конкретно таким образом? с точки зрения логики работы NAT я допускаю, что разработчики могли равновероятно реализовать любой из сценариев - как с доступом на ресурсы, опубликованные на самой себе, так и без доступа. ваш личный опыт - это ваш личный опыт, а, например, мой опыт работы с ipfw,pf и iptables говорит, что теоретически никаких проблем для NAT-а на самого себя нет, хотите - напишу пример правил для каждого из этих фаирволов.

     

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

     

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


    Ilya Shipitsin
    12 января 2011 г. 21:14