none
Доступ по web-интерфейсу через TMG c вкл. ACL RRS feed

  • Вопрос

  •  Всем добрый день!

    В данной теме Не проходят пинги между двумя TMG обсуждался вопрос доступа из сети офиса в сеть филиала. Тема была закрыта, т.к все вопросы разобрали.

    Теперь возник новый вопрос)!

    Вот существующая схема работы:

    Создается заново сеть между офисом и филиалом! На сетевом оборудование Cisco 28 серии создан VPN-туннель между офисом и филиалом. За каждой из Cisco стоит TMG 2010 SP2 rollup4. Внутренним интерфейсом у  обеих TMG является внутренняя сеть, а внешним интерфейсом сеть между Cisco и TMG. На TMG филиала во внутреннюю сети входят следующие диапазоны адресов - 192,168,96,0/21, На TMG офиса во внутреннюю сеть входят следующие диапазоны адресов - 192,168,0,0/21.

    На Cisco прописаны правила не натировать во внутренние сети, только во внешние. На обеих TMG удалены сетевые правила натирования для того, что бы запросы приходили от IP-адресов клиентов. 

    Была проблема связанная с прозрачным проксированием HTTP- запросов из Филиала в Офис и из Офиса в Филиал. Данную проблему решили созданием протокола HTTP-new и отключением на нем фильтра веб-прокси. Так же необходимо было создать 2 правила, разрешающее протокол HTTP_new из внутренней сети в сеть филиала/офиса и запрещающее правило протокола HTTP из внутренней сети в сеть филиала/офиса. Без запрещающего правила не работает 100%!!! Теперь включили ACL на порту и доступ по web-интерфейсу пропал.

    Начали мониторить что происходит, оказывется что при запросе из сети офиса (192.168.4.0/24) в одну из сетей филиала (192.168.98.0/24) на TMG филиала видим запрос пришедший от источника с IP адресом офиса (входит в список разрешенных ACL) по протоколу HTTP_new без NAT, после этого долго нет ни одного запроса, и потом запрет соединения от того же источника с IP адресом офиса, только уже с NAT и адресом 192.168.100.1.

    Решается проблема добавлением IP адреса 192.168.100.1 (внутренний интерфейс TMG филиала) в список разрешенных ACL.

    Теперь собственно вопрос, как обойти этот костыль, т.е что бы в ACL списке были только IP-адреса администраторов!!!!

    ЗЫ: создавали подсеть с перекрестный диапазоном (в офисе - подсеть 192.168.98.0/24, в филиале - подсеть 192.168.0.0/24)  прямые и обратные правила  явно указывающие на доступ к этим подсетям, но ничего толкового так и не вышло.

    Ждем советов)! 

     
    28 апреля 2014 г. 14:20

Ответы

Все ответы

  • не совсем понял результаты мониторинга: вроде источником дожен быть офис, откуда в качестве адреса мог взяться 100,1 если он принадлежит филиалу. или вы как-то не так описали

    28 апреля 2014 г. 16:54
    Отвечающий
  • Добрый день!

    Вы все правильно подметили: IP адрес источника (192.168.4.0/24-сеть офиса) а IP адрес назначения (192.168.98.0/24-сеть филиала), вроде бы все как надо. Но в журнале есть еще колонка "Адрес NAT", вот там как раз и вылезает (во втором запросе которого долго нет) этот IP адрес (192.168.100.1 - внутренний интерфейс TMG  филиала).

    Мы реально не можем понять по чему он именно NAT, т.к на TMG он в принципе отключен, допускаем что это прозрачное проксирование протокола  HTTP. Но как с этим бороться пока не знаем(((

    Да, и это только в том случае когда включен ACL. Когда он отключен - все работает)!
    • Изменено zavoruev 29 апреля 2014 г. 6:43
    29 апреля 2014 г. 6:34
  • Чтобы убрать прозрачное проксирование на TMG, нужно отключить от протокола HTTP фильтр веб-прокси: http://support.microsoft.com/kb/838708

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


    Слава России!

    29 апреля 2014 г. 9:19
  • я не пойму почему в качестве nat адреса вылезает адрес tmg филиала если запрос идет из головного офиса.
    что в этом запросе указано в качестве источника и назначения и на каком tmg эта запись появляется?

    покажите созданные правила на каждом tmg

    29 апреля 2014 г. 9:31
    Отвечающий
  • Чтобы убрать прозрачное проксирование на TMG, нужно отключить от протокола HTTP фильтр веб-прокси: http://support.microsoft.com/kb/838708


    Слава России!

    у автора отключено проксирование созданием нового протокола - стандартный workaround для таких случаев
    29 апреля 2014 г. 9:32
    Отвечающий
  • Обходное решение у автора, как я понял - нестандартное: просто создан дополнительный протокол для порта 80 и запрещен протокол HTTP

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


    Слава России!


    • Изменено M.V.V. _ 29 апреля 2014 г. 9:44
    29 апреля 2014 г. 9:41
  • да, но оно работает еще со времен 2004 исы (только в в 2004 до выхода sp3 не надо было создавать запрещающее правило). а если полностью отключить фильтр http то пропадет нужный функционал который обычно используют для обычного интернет трафика.
    29 апреля 2014 г. 10:03
    Отвечающий
  • Извините что долго не отвечал)))

    Коллеги,  все что у нас сделано подробно описано! Создан протокол HTTP_new И на нем отключен фильтр приложений, и в теме которая указаны в первом посте, мы с Вами M.V.V этот вопрос разбирали.

    По чему при включении ACL блокируются запросы не понятно, но одно знаю что при добавлении в ACL IP-адреса 192.168.100.1 все работает. Могу предположить, что TMG принимает запросы от источника сеть офиса - 192.168.4.0/24 (при чем при обычном HTTP эти запросы отбивальсь, так TMG филиала ни чего не знала о внешнем интерфейсе TMG офиса) к назначению сеть филиала 192.168.98.0/24. А уже во внутреннюю сеть филиала запрос транслируется (каким образом не понятно - прозрачное проксирование, NAT) с IP-адресом внутреннего интерфейса TMG филиала.

     


    29 апреля 2014 г. 12:32
  • Согласен, полностью отключать фильтр на стандартном протоколе HTTP, значит урезать функционал TMG для прямого проксирования.
    29 апреля 2014 г. 12:34
  • Извините что долго не отвечал)))

    Коллеги,  все что у нас сделано подробно описано! Создан протокол HTTP_new И на нем отключен фильтр приложений, и в теме которая указаны в первом посте, мы с Вами M.V.V этот вопрос разбирали.

    По чему при включении ACL блокируются запросы не понятно, но одно знаю что при добавлении в ACL IP-адреса 192.168.100.1 все работает. Могу предположить, что TMG принимает запросы от источника сеть офиса - 192.168.4.0/24 (при чем при обычном HTTP эти запросы отбивальсь, так TMG филиала ни чего не знала о внешнем интерфейсе TMG офиса) к назначению сеть филиала 192.168.98.0/24. А уже во внутреннюю сеть филиала запрос транслируется (каким образом не понятно - прозрачное проксирование, NAT) с IP-адресом внутреннего интерфейса TMG филиала.

    29 апреля 2014 г. 12:35
  • вот правила межсетевого экрана

    29 апреля 2014 г. 12:47
  • сетевые правила

    29 апреля 2014 г. 12:51
  • Вот что в журнале наблюдения при запросе и офиса в филиал и включенном ACL

    29 апреля 2014 г. 13:17
  • Уважаемые Dmitry Nikitin и M.V.V._ проблема еще актуальна, есть ли у Вас еще желание в ней по участвовать!???
  • 192.168.100.1 это чей адрес? офиса или склада? пробовали выключать прокси в браузере?
    Отвечающий
  • 192.168.100.1 это адрес TMG склада (филиала). Да, пробовали, но сам фильтр приложений отключить нельзя (по крайней мере у нас не получилось, чекбокс не активен, в отличии от других фильтров приложений). Пробовали отключать веб-фильтр, а фильтр веб-прокси на новом протоколе HTTP_new  и так выключен!!

    Попробовать выключить фильтр веб-прокси на стандартном HTTP протоколе????!


    • Изменено zavoruev 5 мая 2014 г. 17:55
  • Именно! Это же написано в статье MS KB, ссылку на которую я давал.

    Потому что фильтр приложения применяется вне зависимости от правил к любому соединению, которое подходит под параметры (IP-протокол и порты) протокола, к которому он подсоединен.

    Трафик веб-прокси клиентов в качестве протокола в любом случае будет считаться идущим по протоколу HTTP (потому что он указан в URL запроса к прокси по CERN Proxy protocol), а фильтрация для них осуществляется независимо от подключения фильтра приложений к протоколу HTTP - просто в GUI до ее настроек добраться будет не так легко.


    Слава России!

  • Именно! Это же написано в статье MS KB, ссылку на которую я давал.

    Потому что фильтр приложения применяется вне зависимости от правил к любому соединению, которое подходит под параметры (IP-протокол и порты) протокола, к которому он подсоединен.

    Трафик веб-прокси клиентов в качестве протокола в любом случае будет считаться идущим по протоколу HTTP (потому что он указан в URL запроса к прокси по CERN Proxy protocol), а фильтрация для них осуществляется независимо от подключения фильтра приложений к протоколу HTTP - просто в GUI до ее настроек добраться будет не так легко.


    Слава России!

    Просто до этого Вы приводили для решения проблемы предыдущей моей темы Не проходят пинги между двумя TMG вот эту статью http://support.microsoft.com/kb/884505 , по которой мы собственно и действовали. После того как создали протокол HTTP_new без фильтра веб-прокси, и запретили стандартный HTTP в подсеть филиала, доступ по HTTP заработал.

    Как только включили ACL, доступ по HTTP пропал, и оказывается что надо полностью отключать фильтр приложений веб-прокси, как в этой статье http://support.microsoft.com/kb/838708 .

    Т.е как я понимаю, изначально надо просто отключить фильтр веб-прокси, и не создавать новый протокол HTTP и не городить правила доступа!!!???

    Так?!

     
  • Да, надо отключать фильтр веб-прокси на протоколе HTTP.


    Слава России!

    • Помечено в качестве ответа zavoruev 6 мая 2014 г. 9:45