IIS не может получить доступ к себе
Мы находимся в корпоративной сети, которая использует ISA, и у меня возникают проблемы, когда я пытаюсь не получать запросы через ISA.
- У меня есть IIS7 на моем локальном компьютере с Windows 7, на котором есть веб-сайты и сервисный уровень.
- Веб-сайты получают доступ к служебному слою с помощью адреса xxxx.servicelayer.local, который указан в моем файле HOSTS и указывает на 127.0.0.1.
- У меня есть клиент Windows Firewall, который я отключил.
- Я попытался добавить этот адрес в IE, чтобы он не проходил через ISA, а также полностью отключил этот раздел.
- Когда веб-сайт (который на самом деле IIS делает запрос самому себе) пытается получить доступ к уровню обслуживания, я получаю ошибку ISA, что проверка подлинности прокси не удалась.
Учитывая, что все, что я вижу для настройки, настроено так, чтобы не проходить через прокси, ISA, я не вижу, как это происходит на самом деле через прокси и выдает эту ошибку. Есть ли в Windows 7 что-то, что вызывает настройку прокси, какое-то кэширование или подобное?
2 ответа
Если это.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, потому что эти настройки предназначены для вашего пользователя, а не для сервера / службы.