none
ISA Доступ изнутри к публикуемому веб-сайту

    Вопрос

  • Добрый день!

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

    Все правила публикаций аналогичны и публикаются через один листнер.

    Жду предложений, заранее спасибо.
    10 ноября 2009 г. 14:42

Ответы

  • Попробуйте сделать следующим образом

    Берем тестовую машину внутри сети, у нее в файле hosts добавляем запись следующего вида

    проблемный_сайт.сom внутренний_ip_isa
    www.проблемный_сайт.сom внутренний_ip_isa

    тоже самое делаете на своем WEB сервере

    На ISA

    проблемный_сайт.сom внутренний_ip_web_servers
    www.проблемный_сайт.сom внутренний_ip_web_servers

    После этих изменений в всех трех машинах запускаете ipconfig /flushdns
    проверяете nslookup'oм, чтобы все првильно резолвилось, пытаетесь подключиться.
    27 ноября 2009 г. 14:07
  • Доброго утра!

    Проблема решилась.
    Всем спасибо за ответы.
    Как всегда , решение оказалось банальным до безобразия. В файле hosts на ISA сервере неправильно были прописаны IP адреса проблемного сайта.
    Вот.

    2 декабря 2009 г. 8:17

Все ответы

  • Снова добрый день!
    Задам вопрос несколько по-другому.
    Есть ли вероятность, что вышеописанное поведение может быть вызвано контентом и внутренней логикой сайта?
    Если да, то каким образом.
    Было бы интересно узнать истинные причины подобного поведения.
    Заранее спасибо.

    19 ноября 2009 г. 11:25
  • Добрый день!

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

    Все правила публикаций аналогичны и публикаются через один листнер.

    Жду предложений, заранее спасибо.

    Слишком мало конкретной информации...
    1. Проверьте в IIS свойства публикуемых сайтов - возможно, они различаются.
    2. Выполните проверку работоспособности всех правил публикации - в ISA в свойствах правила для этого есть кнопка.
    3. Проверьте корректность сертификатов и дополнительных имен в них, если используется https.
    4. Если испоьзуется разделный DNS и не используется преобразование ссылок в ISA - проверьте правильность созданных внешних имен на внутреннем DNS и соответствие назначенных адресов внутреннему адресу сервера, на котором находится контент.
    5. Поставьте все правила публикации ДО правил управления трафиком.
    19 ноября 2009 г. 13:46
  • Конкретизирую:
    1. Публикуется через Апач на другом серевере, настройки все идентичны.
    2. Проверка работоспособности выдает все зеленые галочки, что трактуется мною, что все ОК, при этом, сайт виден снаружи.
    3. Сертификаты не используются при публикации, т.е. только http
    4. Используется преобразование ссылок.
    5. Правила публикации идут первыми. А проблемное правило - САМЫМ первым.

    Еще раз поинтересуюсь на всякий случай:

    "Есть ли вероятность, что вышеописанное поведение может быть вызвано контентом и внутренней логикой сайта?
    Если да, то каким образом."

    Спасибо за внимание.

    23 ноября 2009 г. 7:58

  • "Есть ли вероятность, что вышеописанное поведение может быть вызвано контентом и внутренней логикой сайта?
    Если да, то каким образом."


    Думаю что может. В связи с этим еще такой наводящий вопрос. Есть ли на публикуемых сайтах разграничение доступа для различных пользователей? И каким образом организована и каким образом происходит авторизация при входе?
    23 ноября 2009 г. 9:13
  • Kf_GoldFish , хочу обратить Ваше внимание вот на это

    >> При проверке имитатором трафика, выбирая веб-доступ изнутри, наблюдаю картину, что все сайты и, соответственно, нормально работающий алиас подпадают под правило публикации, а проблемные имена - под правила доступа в Интернет.

    Daniil Khabarov ,

    Давайте рассказывайте как вы это публикуете на какие порты, какие IP (внешние и внутренние)?
    Где стоят ваши WEB (DMZ, внутрення или во внешней)?
    И по какой цепочке происходит доступ к сайту (что то типа Internet  =>  ISA ( айпи 83,123,123,123) => Apache (192,168,1,15 ) => Web server (10,10,1,25) )

    А то можно очень долго гадать.

    Может еще быть, то что апач не туда отфутболивает запрос или DNS не туды резолвит.
    23 ноября 2009 г. 10:08
  • Собственно.

    доступ к серверу происходит следующим образом: на внешний адрес inetserv(91.111.111.111:80)приходит запрос, далее, он мостом, со внутреннего интерфейса inetserv'a(192.168.10.1:80) перебрасывается на другой сервер и порт web(192.168.10.10:81), ибо на том сервере так же публикуется IIS , который нужен SCCM.
    Да, еще .. web - это имя кластера, как , соответственно , и его IP, при это, внутренний интерфейс обмена для кластера, соответственно, 10.0.0.0/24.
    Т.е.
    Inetserv смотрит одним интерфейсом внурь, а другим наружу
    web находится полностью во внетренней сети + кластеризует свое имя.

    Вот, собственно и все.
    Вебсервер - Apache.
    Проблемы именно с этим моментом не наблюдал.
    Отовсюда все имена проблемного веб-сайта корректно резольвятся, но проходят не по тому правилу, как я и писал выше. Точно так же корректно резольвится все внутренняя сетка. Проблем с DNS не наблюдалось в ближайшем прошлом.
    23 ноября 2009 г. 13:18
  • А при публикации вы как указываете имя WEB сервера, по FQD имени или IP адресу?
    Если по имени то DNS должен его резолвить во внутренний IP для этого можно воспользоваться файлом hosts на ISA.
    23 ноября 2009 г. 15:23
  • Хм...
    Знаете..
    Я пробовал все. В какой-то момент по IP все заработало. Так и работало , а потом , почему-то , перестало. Указывал и FQDN и просто сетевое имя...  Результат один и тот же.

    24 ноября 2009 г. 10:56
  • Даниил, ну, а если доступаться до сайтов минуя сервер ISA, то что?..
    24 ноября 2009 г. 13:58
  • А вот если попробовать подключиться мимо ISA, то если ввести FQDN -имя, то он подключается на другой, не проблемный сайт, а если по внутреннему IP, то он подключается именно к этому сайту.
    При изменении правила с указанием на внутренний IP то проблема не решается, и снова появляется ошибка превышения таймаута подключения.
    Вот.

    25 ноября 2009 г. 8:10
  • Давайте разберемся более конкретно.

    Если вы побликуете сайт из внутренней во внутреннюю у клиентов имя сайта должно разрешаться во внутренний ай пи ISA. У вас так?
    На клиенте поробуйте nslookup имя_проблемного_сайта в ответ должно выдать адрес исы.
    На исе та же комманда должна вернуть внутренний ай пи вебе сервера.
    Не поленитесь, проверьте.
    При создании правила публикации вам нужно разрешить прослушивать запросы из внутренней сети.

    Я такого не делал, но чисто теоретически у вас потом могут возникнуть проблемы то что запрос к веб серверу будет приходит через ISA а возвращаться непосредственно клиенту. Лучше этот сервер подцепить на отдельную сетевую (организовать DMZ).

    Вот один чувак описал, как можно проверить HTTP при помощи Telnet
    http://tmgblog.richardhicks.com/category/networking/




    25 ноября 2009 г. 10:30
  • Доброго вечера.

    Продолжая разбираться.
    Публикуются сайты у меня на "Везде".

    Nslookup изнутри у меня выдает внешний ip адрес ISA,а с ISA сервера он мне указывает опять же на внешний адрес ISA сервера.
    Самое интересное, что и на остальных сайтах, которые используют тот же самый прослушиватель я получаю такой же ответ, но разница в том, что те нормально отображается, а этот в локальной - нет.
    А еще я испытаваю сомнения, что он должен при nslookup'е с сервера должен выдавать адрес веб -сервера. Я сейчас подумаю над этим. Посмотрю.
    Ссылочку тоже изучаю.
    Запросы можно слушать из локальной сети.

    Еще раз: ошибка по таймауту. Не по запрету.

    26 ноября 2009 г. 14:33
  • >> А еще я испытаваю сомнения, что он должен при nslookup'е с сервера должен выдавать адрес веб -сервера.
    Я писал именно про ISA сервер - все в полне логично. Клиенты перенаправляются на ISA а она в свою очередь должна иметь возможность разрешить имя сайта в IP WEB сервера, а то такой редирект будет бесконечным :)

    В свое время наткнулся на отличную статью:
    http://isadocs.ru/articles/Creating-Configuring-Non-SSL-Web-Publishing-Rules-Part1.html
    http://isadocs.ru/articles/Creating-Configuring-Non-SSL-Web-Publishing-Rules-Part3.html
    27 ноября 2009 г. 7:40
  • Я читал эту статью и по ней было все настроено.
    Да, все логично. Но почему не работает - не понимаю.

    27 ноября 2009 г. 11:53
  • Попробуйте сделать следующим образом

    Берем тестовую машину внутри сети, у нее в файле hosts добавляем запись следующего вида

    проблемный_сайт.сom внутренний_ip_isa
    www.проблемный_сайт.сom внутренний_ip_isa

    тоже самое делаете на своем WEB сервере

    На ISA

    проблемный_сайт.сom внутренний_ip_web_servers
    www.проблемный_сайт.сom внутренний_ip_web_servers

    После этих изменений в всех трех машинах запускаете ipconfig /flushdns
    проверяете nslookup'oм, чтобы все првильно резолвилось, пытаетесь подключиться.
    27 ноября 2009 г. 14:07
  • Доброго утра!

    Проблема решилась.
    Всем спасибо за ответы.
    Как всегда , решение оказалось банальным до безобразия. В файле hosts на ISA сервере неправильно были прописаны IP адреса проблемного сайта.
    Вот.

    2 декабря 2009 г. 8:17