none
TMG - Доступ к некоторым внешним HTTP/HTTPS минуя прокси RRS feed

  • Общие обсуждения

  • Здравствуйте. Подскажите как правильно настроить в TMG доступ по HTTP/HTTPS на некоторые внешние сайты для всех пользователей.

    Сделано правило для All Users разрешающее HTTP/HTTPS протоколы из Internal на URL Set в котором прописано (как сказано здесь http://technet.microsoft.com/en-us/library/cc441706.aspx)

    extsite1.com/sub/*
    extsite2.com

    Попытки обращения напрямую по URL HTTPS://extsite2.com приводят к таймауту с таким трейсом на TMG

    Log type: Firewall service
    Status: The action cannot be performed because the session is not authenticated. 
    ...

    При этом если URL Set заменить на External то всё работает.
    Это баг URL Set или я что-то не так делаю?
    Или может быть есть какой-то другой способ разрешить прямой доступ к конкретному внешнему адресу типа HTTPS://extsite2.com/sub/* ?

    15 ноября 2011 г. 12:56

Все ответы

  • "Status: The action cannot be performed because the session is not authenticated.  "

    Оно же и пишет, что сессия не аутентифицорована (ибо в правиле аноним стоит - All Users)
    При указании конкретных URL и при External какие правила срабатывают ?
    Порядок расположения правил - там всё нормально ?

    15 ноября 2011 г. 18:11
  • насколько я помню, в url set надо писать с протоколом, то есть http://extsite1.com/sub/*
    15 ноября 2011 г. 20:26
    Отвечающий
  • Порядок насколько я понимаю правильный:

    1. Allow Web Access (bypass proxy) - All Users - правило с URL Set о котором идёт речь
    2. Allow Web Access - DomainInternetUsersGroup - общее правило доступа в интернет
    3. Deny Default rule - дефолтное запрещающее правило

    При использовании в первом правиле URL Set судя по трейсу срабатывает второе правило  Allow Web Access с указанным ранее статусом.

    При использовании в пермом правиле External вместо URL Set срабатывает первое правило и внешний сайт открывается.

    16 ноября 2011 г. 4:21
  • В начальном посте я указал ссылку по которой расписаны правила заполнения URL Set. Там сказано что протокол можно не указывать, хотя я пробовал одинаково безрезультатно использовать разные варианты.
    16 ноября 2011 г. 4:22
  • Указанный порядок правил приведен из какой "ветки" оснастки ТМГ ?
    Web Access Policy или Firewall Policy ?
    Просто если это первый вариант, то между WEB-правилами могут "вклиниваться", но не показываться другие общие правила из Firewall Policy.

    16 ноября 2011 г. 5:58
  • Насколько я понимаю если бы проблема была в порядке обработки правил то нужное мне правило не обрабатывалось бы в любом случае, однако оно начинает работать если URL Set заменить на External. Это было отмечено в самом начале.

    16 ноября 2011 г. 7:17
  • В URL Set необходимо указывать точное соответствие ресурса (напр. для www.yandex.ru - так и надо указывать, а не yandex.ru). Протокол можно опустить. www.yandex.ru - подразумевает www.yandex.ru/*

    URL Set использует reverse lookup DNS при сравнении правила:

    Name Resolution - http://technet.microsoft.com/en-us/library/cc441706.aspx 


    21 ноября 2011 г. 14:28
  • Это я понимаю, но мне от этого не легче :) Правило с URL Set попросту не работает. Если у кого-то используются похожие правила с URL Set и они реально работают, можно привести пример.

    21 ноября 2011 г. 18:24
  • Log type: Firewall service
    Status: The action cannot be performed because the session is not authenticated.

    Для какого протокола? не для DNS случайно (Dest Port: 53)? Если да, то добавьте первым или вторым сверху правило анонимного доступа для DNS.


    22 ноября 2011 г. 5:27
  • Нет. Не для DNS. Посмотрите мои ответы ранее. Правило разрешающее DNS разумеется есть и оно стоит ранее.

    22 ноября 2011 г. 5:34
  • Алексей, прошу прощения, но в данном посте я не нашел этой информации. 

    Все же - какой протокол блокируется?

    22 ноября 2011 г. 5:41
  • Ну батенька...я не знаю что вам тут сказать. Возможно поможет только репост.

    Общий порядок правил такой:

    1. Allow Web Access (bypass proxy) - All Users - правило с URL Set о котором идёт речь
    2. Allow Web Access - DomainInternetUsersGroup - общее правило доступа в интернет
    3. Deny Default rule - дефолтное запрещающее правило

    При использовании в первом правиле URL Set судя по трейсу срабатывает второе правило Allow Web Access с указанным ранее статусом.

    При использовании в пермом правиле External вместо URL Set срабатывает первое правило и внешний сайт открывается.

    Блокируется HTTPS.

    PS: Всё-таки никто не ответил. У кого-нибудь реально на практике работают правила с URL Set ?...


    22 ноября 2011 г. 6:45
  • Алексей, я имел ввиду про DNS - не увидел в посте, что правило по DNS стоит ранее. Про то, что блокируется HTTPS, по моему явно Вы тоже не указали. 

    Вы бы привели реальные URL которые блокируются и как они описаны в правиле, я бы проверил. И что в браузере набирается.

    Пример с www.yandex.ru, который я приводил - реально работает.

    (bypass proxy) - это просто название или под ним что-то скрывается?

    Если подозреваете, что баг - укажите TMG build#

     

    22 ноября 2011 г. 7:48
  • "Про то, что блокируется HTTPS, по моему явно Вы тоже не указали"

    Из первого моего сообщения:
    Попытки обращения напрямую по URL HTTPS://extsite2.com приводят к таймауту с таким трейсом на TMG

    "Вы бы привели реальные URL которые блокируются и как они описаны в правиле, я бы проверил. И что в браузере набирается."
    Реальная ситуация. Нужно организовать прямой доступ минуя прокси (без авторизации) к узлу https://tariff.eias.ru
    В первом правиле  Allow Web Access (bypass proxy) [это просто название правила] делаем настройки:

    Закладка General - поле Name = введено Allow Web Access (bypass proxy)
    Закладка Action = выбрано Allow
    Закладка Protocols = выбраны протоколы HTTP и HTTPS
    Закладка From = в окне источников выбрано Internal
    Закладка To = в окне мест назначения выбрано URL Set (тот самый о котором идёт речь)
    Закладка Users = выбрано All Users
    Malware Inspection выключено (не используется вообще)

    Теперь о текущей реальной настройке URL Set. Прописано одно значение tariff.eias.ru

    Пробовал прописать так:
    затем так
    результат одинаковый - не работает.

    Обращаемся через браузер с отключенными настройками прокси на адрес https://tariff.eias.ru
    Получаем таймаут ожидания открытия страницы а на стороне сервера видим трейсы этого обращения:

    Denied Connection TMG-SRV-02 11/22/2011 12:39:58 PM
    Log type: Firewall service
    Status: The action cannot be performed because the session is not authenticated. 
    Rule: Allow Web Access
    Source: Internal (192.168.1.10:53045)
    Destination: External (212.42.62.139:443)
    Protocol: HTTPS
    Additional information
    Number of bytes sent: 0 Number of bytes received: 0
    Processing time: 0ms Original Client IP: 192.168.1.10

    Таким образом делаем вывод что наша попытка подключения доходит до общего правила доступа в интернет, расположенного ниже нашего неработающего правила с URL Set.
    Если подозреваете, что баг - укажите TMG build#

    Forefront Threat Management Gateway
    Microsoft Corporation
    Version: 7.0.9193.500

    То есть SP2 установлен. Пробовал всё тоже самое и ранее (до установки SP2 - на SP1 SU1) - результат одинаковый.
    22 ноября 2011 г. 8:45
  • Вот теперь, Алексей, все понятно - спасибо за подробный вывод.

    Я добавил в URL Set tariff.eias.ru - тоже не заработало, но, если добавить еще saha.eias.ru - все отлично работает :)

     

    22 ноября 2011 г. 9:01
  • Я вижу по трейсу обращения только на mail.saha.eias.ru ...но даже если добавляю это значение в URL Set всё равно не работает...

    Denied Connection TMG-SRV-02 11/22/2011 2:14:19 PM
    Log type: Firewall service
    Status: The action cannot be performed because the session is not authenticated. 
    Rule: Allow Web Access
    Source: Internal (192.168.1.10:53160)
    Destination: External (mail.saha.eias.ru 212.42.62.139:443)
    Protocol: HTTPS
     Additional information
    Number of bytes sent: 0 Number of bytes received: 0
    Processing time: 0ms Original Client IP: 192.168.1.10

    22 ноября 2011 г. 10:15
  • У меня по трейсу идет обращение к saha.eias.ru. Видимо придется добавить все имена для 212.42.62.139

    22 ноября 2011 г. 10:50
  • Сейчас посмотрел 212.42.62.139 через IPTools.com ...каждый раз возвращается новое имя...видимо Round-robin

    Если даже прописать в URL Set *.eias.ru лучше не становиться.

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


    22 ноября 2011 г. 11:00
  • Отключено. Специально отключал для тестирования Вашего случая.

     


    22 ноября 2011 г. 12:07
  • Тогда вообще не понятно. Получается что у нас при равных условиях TMG себя ведёт по разному.

    Вот ещё задача из той-же темы. Как организовать прямой доступ всем компьютерам сети (минуя прокси и безо всяким там авторизаций) к вэб-узлу MS для возможности постоянного обновления списка отзыва root-сертификатов.

    22 ноября 2011 г. 12:19
  • Тогда вообще не понятно. Получается что у нас при равных условиях TMG себя ведёт по разному.

    Вот ещё задача из той-же темы. Как организовать прямой доступ всем компьютерам сети (минуя прокси и безо всяким там авторизаций) к вэб-узлу MS для возможности постоянного обновления списка отзыва root-сертификатов.


    прокси и авторизация вещи разные, авторизация это всего лишь разрешение, что ему разрешишь правилами то и будет, и не вайжно какой клиент, прокси или нет.
    прямой доступ это просто не настраивать клиентов на прокси и все.
    22 ноября 2011 г. 14:50
    Отвечающий
  • Ситуация довольно простая. При обращении к сайтам напрямую, а не через прокси, правила DNS и URL-Set не действуют. Вот и вся проблема. Либо указывайте явно подсети, либо пускайте через прокси-сервер.

    23 ноября 2011 г. 3:38
  • Ух-ты. А можно ссылку на первоисточник?

    23 ноября 2011 г. 4:02
  • Это же логично. Если клиент работает через SecureNAT, то он резолвит имя сам и дальше гонит уже запросы на конкретный айпи-адрес. Как ты его ограничишь правилами DNS? Если он работает через прокси, то он резолвит имя на сервере TMG и тут его можно прижучить :)

    23 ноября 2011 г. 4:24
  • Не согласен. Если что-то является логичным для вас, это не значит что кто-то из разработчиков TMG мыслит также. Поэтому я и прошу ссылку на первоисточник, где будет хотя-бы намёк на то что URL Set работает (исходя из того что вы утвержаете) только при явном использованиии его в механизме проксирования.


    23 ноября 2011 г. 4:46
  • Да, действительно, немного не разобрался в проблеме (все ошибаются). TMG пытается проверить по айпи-адресу обратную DNS запись и вытаскивает полное доменное имя. Поэтому я предлагаю использовать не URL-set *.eias.ru, как у Анатолия (здесь проходит из-за прокси), а DNS set *.eias.ru. Думаю, это поможет. Может быть придется перечислять все поддомены из раундробина, но надеюсь, что не потребуется.


    23 ноября 2011 г. 5:25
  • Кстати, заметил, что http проходит для technet.microsoft.com для SecureNAT, а https - нет, с ошибкой, что и у Алексея (в URL Set: *.eias.ru; *.microsoft.com).

    Заметил, что иногда срабатывает правило Allow all traffic из отключенной Web Access Policy.

    Алексей, включена ли у Вас Web Access Policy? Есть ли там правило, блокирующее HTTPS?

    Если Web Access Policy выключена - Enable Web Policy, Apply, Disable Web Policy, Apply

    Мне помогло.

     

    23 ноября 2011 г. 7:39
  • Web Access Policy у меня включена. Правил блокирующих HTTPS нет. Иначе как бы у меня прокси вообще работал...

    23 ноября 2011 г. 8:44