tl; dr У меня проблемы с тем, чтобы TMG должным образом обратный прокси-сервер HTTPS-соединения извне на HTTP-соединение внутри.
У нас есть локальная сеть (10.0.7.0/24), в которой находится Windows Server 2008 с установленным Spiceworks. Spiceworks использует Apache и настроен для обслуживания как HTTP, так и HTTPS. Пока вы просматриваете его из локальной сети, он работает, никаких проблем.
У нас также есть DMZ (172.32.16.0/24), на которой размещен сервер Forefront TMG, имеющий доступ как к локальной сети, так и к Интернету. Итак, мы пытались настроить правило обратного прокси, которое позволяло бы пользователям получать доступ к экземпляру Spiceworks из Интернета.
Для HTTP он работает отлично - трафик проходит через TMG и ретранслируется на сервер Apache, groovy. Для HTTPS не так много. TMG устанавливает соединение, используя сертификат на своей стороне, но не может подключиться к серверу Apache по HTTPS и умирает с ошибкой тайм-аута.
Я не думаю, что это проблема сети, так как HTTP работает нормально. Это не проблема HTTPS для Spiceworks, поскольку просмотр в локальной сети работает нормально. Я подозреваю, что TMG испытывает проблемы с проверкой сертификата, который мы используем на сервере Apache, поэтому я получаю ошибку HTTP 500 «Токен, предоставленный функции, недействителен».
Сертификат, который использует TMG, - это тот же сертификат, что и на сервере Spiceworks (оба сертификата с подстановочными знаками GoDaddy) - может ли это иметь какое-то отношение к этому? Мы не можем заменить сертификат, поскольку он используется во многих местах, поэтому, если есть обходной путь или параметр конфигурации TMG, который я могу изменить, это было бы идеально.
Другой мой вариант - подключить TMG к прокси. https: //subdomain.domain.tld: 443 снаружи к http: //subdomain.domain.tld: 80 на внутренней стороне, и обойти этот вопрос SSL полностью, но не кости там, либо - TMG упорно отказывается переписать URL таким образом.