Назад | Перейти на главную страницу

IIS не может получить доступ к себе

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

  1. У меня есть IIS7 на моем локальном компьютере с Windows 7, на котором есть веб-сайты и уровень обслуживания.
  2. Веб-сайты обращаются к уровню обслуживания, используя адрес xxxx.servicelayer.local, который настроен в моем файле HOSTS на 127.0.0.1.
  3. У меня есть клиент брандмауэра Windows, который я отключил.
  4. Я пробовал как добавить этот адрес в IE, чтобы он не проходил через ISA, так и вообще отключил этот раздел.
  5. Когда веб-сайт (который на самом деле является IIS, выполняющим запрос к самому себе) пытается получить доступ к уровню обслуживания, я получаю сообщение об ошибке ISA, что проверка подлинности прокси не удалась.

Учитывая, что все, что я вижу для настройки, настроено так, чтобы не проходить через прокси, ISA, я не вижу, как это на самом деле проходит через прокси и выдает эту ошибку. Есть ли что-то в Windows 7, что вызывает настройку прокси, какое-то кеширование или что-то подобное?

Если это .Net - и вы не указали, что это за платформа - тогда вы можете попробовать добавить этот XML-блок конфигурации в web.config веб-приложения, а не службы). Он должен находиться непосредственно в корневом разделе:

<system.net>
  <defaultProxy enabled="false">
  </defaultProxy>
</system.net>

Точно так же - вы можете обнаружить, что где-то в конфигурации уже есть запись для system.net, которая направляет запросы на конкретный прокси-сервер, и в этом случае замените его этим.

ИЗМЕНИТЬ - В ответ на ваш комментарий

Из интереса - пытается ли сервисный уровень позвонить во внешний мир? Мне просто интересно, действительно ли вы получаете ошибку в методе службы, которая возвращается через службу обратно к коду веб-сайта - если это служба SOAP / wsHttp, тогда .Net вполне может сохранять ошибку авторизации прокси из уровень обслуживания обратно к вызывающему коду.

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

Последнее, последнее замечание Хорошо - значит, запрос идет в ISA - это не так IIS Делая это, это делает код или, по крайней мере, значения конфигурации, которые использует код. Если вы не можете отследить эти значения и отключить использование брандмауэра, то вы можете сделать одну вещь - переключить идентификацию пула приложений на использование сетевой службы - пока машине разрешено выходить из ISA, она будет успешно проходить аутентификацию через прокси, решив тем самым все проблемы.

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

Вы проверили, что IE на сервере может загружать сайт с помощью URL-адреса? Какое приложение вы используете (.net?)? Вы указали настройки прокси в этом приложении? Вы проверили привязки сайта, чтобы убедиться, что сайт также прослушивает 127.0.0.1?

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