none
SecureNAT в ISA 2006 RRS feed

  • Вопрос

  • Требуется установить ИСУ на контроллер АД, он же днс-сервер, он же дшсп-сервер, он же шлюз локалки.
    Насколько я понял, чтобы заработал секуренат, достаточно всего лишь через dhcp выдать компьютеру адрес шлюза. На сервере ИСЫ создано правило типа "разрешить ваще всё ваще всем" (все пользователи, из домена пока все выведены). При этом пинги ходят куда пожелают, однако http и ftp режутся (Невозможно отобразить страницу в ИЕ и чистый лист в опере). Свойства соединения внешне выглядят так же, как без ИСЫ (шлюз на вин2003). Галки клиентов брандмауэра и прокси скинуты. Что я упустил из внимания?

    Если включить галку web-прокси  и настроить соответствующим образом ИЕ, все работает.

    Извините за ламерский вопрос, я не волшебник [админ], я только учусь )) Сейчас усиленно изучаю Шиндлера, но нужно реализовать промежуточное решение на несколько дней, для успокоения нервов начальства.
    5 ноября 2007 г. 18:50

Ответы

  • Запрет автоматических соединений Web-прокси для клиентов SecureNAT
    Бывают ситуации, в которых клиентам брандмауэра и клиентам SecureNAT (средства безопасного преобразования сетевых адресов) выгодно отказаться от сервиса Web-прокси. По умолчанию HTTP-соединения от клиентов брандмауэра и SecureNAT автоматически направляются на фильтр Web-прокси. Благодаря этой конфигура¬ции клиенты как SecureNAT, так и брандмауэра получают выигрыш от использова¬ния кэширования Web-прокси брандмауэра ISA (если кэширование разрешено в брандмауэре ISA).
    Проблема в том, что некоторые Web-сайты плохо написаны и не согласуются с CERN-совместимым (CERN compliant) Web-прокси. Можно решить эту проблему, настроив такие сайты на прямой доступ (Direct Access), а затем разорвав связь фильтра Web-прокси с HTTP-протоколом.
    Выполните следующие шаги, запрещающие автоматические соединения с Web-прокси для клиентов брандмауэра и SecureNAT.
    1. На консоли управления Microsoft Internet Security and Acceleration Server
    2004 (Сервер защищенного быстрого доступа к сети Интернет) раскройте окно,
    связанное с именем сервера, и щелкните кнопкой мыши узел Firewall Policy
    (Политика брандмауэра) на левой панели консоли.
    2. На панели задач щелкните кнопкой мыши вкладку Toolbox (Инструментальная
    панель). На этой вкладке щелкните кнопкой мыши папку Command Protocols
    (Протоколы команды) и дважды щелкните протокол HTTP.
    3. В диалоговом окне HTTP Properties (Свойства HTTP) щелкните кнопкой мыши
    вкладку Parameters (Параметры).
    . 4. На вкладке Parameters (Параметры) сбросьте флажок Web Proxy Filter (Фильтр Web-прокси). Щелкните мышью кнопку Apply (Применить) и затем кнопку ОК.
    5. Щелкните мышью кнопку Apply (Применить) для сохранения изменений и
    обновления политики брандмауэра.
    6. Щелкните мышью кнопку ОК в диалоговом окне Apply New Configuration
    (Применить новую конфигурацию).

    :WALL:

    Всем спасибо :red:

    12 ноября 2007 г. 10:44

Все ответы

  • А распознавание имен на клиентах работает?

    И чем вас не устраивает вариант "Если включить галку web-прокси  и настроить соответствующим образом ИЕ, все работает."?

    6 ноября 2007 г. 12:09
    Модератор
  • Если имеется в виду ДНС, то да.
    Во-первых, пока не пойму, что еще надо разрешить, чтобы заработало автораспознавание прокси.
    Во-вторых, фтп через веб-прокси не работает.
    В-третьих, я не понял, как это случилось, но после выходных шлюз не хочет пропускать пинг о_О Ася и оутлук работают
    И в-четвертых, самое главное, хочется все-таки понять, как и что устроено ))
    6 ноября 2007 г. 13:31
  • Почитайте здесь http://www.microsoft.com/technet/isa/default.mspx

     

    По поводу автонастроек - создайте cname с именем wpad указывающую на адрес машины где установден ISA с включенной функцией autodiscovery по стандартному порту 80.

     

    Уже описывалось http://forums.microsoft.com/TechNet-RU/ShowPost.aspx?PostID=2239570&SiteID=40

     

    ( Configurations -> Networks -> Internal Properties -> Autodiscovery and Firewall Client )

    6 ноября 2007 г. 21:22
  • Sergey Bezpalov
    Трабла была в том, что я не знал, куда этот wpad.dat положить )) (c:\inetpub\wwwroot) У Шиндлера, МС и в описаниях wpad этого нет, нашел на каком-то совершенно дешевом форуме )
    И второе - на 80 порту висел IIS, спасибо за ссылку )

    А вот НАТ, тем не менее, по шттп и фтп работать отказывается. Что интересно, после экспериментов методом научного тыка и откатов вылезают разные заморочки. На этот раз пошли пинги, но трасерт стал обзывать ип шлюза локалхостом, nslookup на раб. станциях тоже пишет Server: localhost. Раньше он был просто Unknown Big Smileunno:

    ЗЫ. Еще раз прошу, не судите строго, админская карма у меня пока не сформировалась, поэтому все работает через пень-колоду )
    9 ноября 2007 г. 18:21
  • Нужно смотреть как это все настроено, стоит уделить внимание проблеме авторизации и как она настроена.

     

    Можно, к примеру, показать список правил (скриншет) и результат netdiag.

     

    Есть пинг до ya.ru (внешнего адресатра) с рабочей станции из сети.

    9 ноября 2007 г. 19:33
  • Настроено - разрешить из защищенных во внешнюю весь траф, всем пользователям. Результаты команд могу только в пнд скинуть... А по авторизации отдельная тема. Но это уже совсем другая история, завтра буду рыть инет

    Ася 384224101 , если у кого будет желание, стучите ))
    9 ноября 2007 г. 23:17
  • Эммм, что есть netdiag?
    12 ноября 2007 г. 9:50
  • Нужно установить support tools с дистрибутива Windows Server 2003 (первый диск если у вас R2)

     

    http://support.microsoft.com/kb/892777

    12 ноября 2007 г. 9:56
  • Запрет автоматических соединений Web-прокси для клиентов SecureNAT
    Бывают ситуации, в которых клиентам брандмауэра и клиентам SecureNAT (средства безопасного преобразования сетевых адресов) выгодно отказаться от сервиса Web-прокси. По умолчанию HTTP-соединения от клиентов брандмауэра и SecureNAT автоматически направляются на фильтр Web-прокси. Благодаря этой конфигура¬ции клиенты как SecureNAT, так и брандмауэра получают выигрыш от использова¬ния кэширования Web-прокси брандмауэра ISA (если кэширование разрешено в брандмауэре ISA).
    Проблема в том, что некоторые Web-сайты плохо написаны и не согласуются с CERN-совместимым (CERN compliant) Web-прокси. Можно решить эту проблему, настроив такие сайты на прямой доступ (Direct Access), а затем разорвав связь фильтра Web-прокси с HTTP-протоколом.
    Выполните следующие шаги, запрещающие автоматические соединения с Web-прокси для клиентов брандмауэра и SecureNAT.
    1. На консоли управления Microsoft Internet Security and Acceleration Server
    2004 (Сервер защищенного быстрого доступа к сети Интернет) раскройте окно,
    связанное с именем сервера, и щелкните кнопкой мыши узел Firewall Policy
    (Политика брандмауэра) на левой панели консоли.
    2. На панели задач щелкните кнопкой мыши вкладку Toolbox (Инструментальная
    панель). На этой вкладке щелкните кнопкой мыши папку Command Protocols
    (Протоколы команды) и дважды щелкните протокол HTTP.
    3. В диалоговом окне HTTP Properties (Свойства HTTP) щелкните кнопкой мыши
    вкладку Parameters (Параметры).
    . 4. На вкладке Parameters (Параметры) сбросьте флажок Web Proxy Filter (Фильтр Web-прокси). Щелкните мышью кнопку Apply (Применить) и затем кнопку ОК.
    5. Щелкните мышью кнопку Apply (Применить) для сохранения изменений и
    обновления политики брандмауэра.
    6. Щелкните мышью кнопку ОК в диалоговом окне Apply New Configuration
    (Применить новую конфигурацию).

    :WALL:

    Всем спасибо :red:

    12 ноября 2007 г. 10:44