none
не могу настроить NAT в ISA 2004 Standart RRS feed

  • Вопрос

  • День добрый, проблема в следующем заключается: не могу настроить NAT для исы, прокси и фаервол-клиенты работают, а вот нат не хочет. И после 3-4 часов работы отключается инет в принципе. Если очистить/обновить кэш распознавателя DNS на ISA сервере ipconfig-ом, то прокси и фаервол клиенты начинают работать, а нат все равно не работает.

    Оперативно-тактическая обстановка: ISA сервер стоит на 2003 Ent SP 2. ISA 2004 Standart SP3, на нем 2 сетевых адаптера 1 внутренний, 1 внешний (инет).
    DNS и DHCP серверы располагаются на другой машине, которая является PDC и находится в этой же подсети.
    Машина с ISA в домен не входит.

    P.S. Переодически встроенная IDS исы начинает писать об "All port scan" атаках со стороны PDC и об ошибках в конфигурации локального и внешних сетевых интерфейсов (оба интерфейса настроены вручную, и ошибок вроде нет).
    Настройки локального интерфейса: 
    IP 192.168.0.1
    Mask 255.255.255.0
    Gateway 192.168.0.1
    DNS 192.168.0.100 (PDC)

    Внешний сконфигурирован по настройкам провайдера.

    Заранее благодарен.

    28 февраля 2008 г. 9:33

Ответы

  • Проблема с работой NAT решилась, спасибо форуму!

    Запрет автоматических соединений 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
    (Применить новую конфигурацию).

    Может кому пригодиться!

    А что делать с кэшом DNS пока совершенно не понятно...


    28 февраля 2008 г. 10:42
  •  

    можно просто держать два http протокола на 80 порту один с фильтром другой без и правильно их в правилах применять Smile это работало и на 2004 и на 2006
    29 февраля 2008 г. 11:19
    Отвечающий
  • Кстати это вариант для ISA 2004! (для ISA 2006 это уже излишне, т.к. фильтрами можно управлять на каждом правиле независимо - это верно для всех фильтров)

     

    Т.е. создаете свой протокол (UserHTTP) с указанием порта 80 и его указываете в правиле, в котором не должен работать HTTP фильтр.

    29 февраля 2008 г. 11:38
    Модератор

Все ответы

  • Проблема с работой NAT решилась, спасибо форуму!

    Запрет автоматических соединений 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
    (Применить новую конфигурацию).

    Может кому пригодиться!

    А что делать с кэшом DNS пока совершенно не понятно...


    28 февраля 2008 г. 10:42
  •  

    ну это совсем радикальный метод, можно просто для отдельных сайтов запретить http а разрешить transparent http предварительно его создав Smile
    28 февраля 2008 г. 12:39
    Отвечающий
  • Так мне нужен NAT для всех сайтов, так что это не вариант... А как настроить прозрачный пхттп для отдельных узлов?
    28 февраля 2008 г. 12:56
  • При таком подходе к ISA возникает только один вопрос: а на кой вам ISA вообще?! Вам вполне подойдет обычный RRAS или даже Internet Connection Sharing.

    28 февраля 2008 г. 15:11
    Модератор
  • Раз стоит, значит нужен, логично? Wink Просто для некоторых необходим доступ через Secure NAT, а для кого-то нужен proxy или firewall-клиент, по существу хотелось бы услышать, если можно.
    29 февраля 2008 г. 9:25
  • Да мы тут все вокруг этого:

     

     Dmitriy Nikitin написано:

     

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

     

     

    Подключение и отключение HTTP filter на отдельных правилах работает только в ISA 2006, а в ISA 2004 можно только глобально включить или выключить HTTP filter.

    Поэтому вывод надо обновиться до ISA 2006.

     

    29 февраля 2008 г. 9:58
    Модератор
  • Эх, еще бы начальству это как-то донести...
    29 февраля 2008 г. 11:11
  •  

    Как я вас понимаю
    29 февраля 2008 г. 11:18
    Модератор
  •  

    можно просто держать два http протокола на 80 порту один с фильтром другой без и правильно их в правилах применять Smile это работало и на 2004 и на 2006
    29 февраля 2008 г. 11:19
    Отвечающий
  • Кстати это вариант для ISA 2004! (для ISA 2006 это уже излишне, т.к. фильтрами можно управлять на каждом правиле независимо - это верно для всех фильтров)

     

    Т.е. создаете свой протокол (UserHTTP) с указанием порта 80 и его указываете в правиле, в котором не должен работать HTTP фильтр.

    29 февраля 2008 г. 11:38
    Модератор