Доступ к WCF-сервису за брандмауэром из DMZ

Question

Я собираюсь разработать сервис для клиента. Служба будет расположена во внутренней сети за брандмауэрами и будет иметь собственную базу данных. Услуга будет использоваться другим веб-приложением, расположенным в демилитаризованной зоне. Теперь моя проблема в том, что компания придерживается своего рода строгой политики не открывать порты из DMZ в интрасеть.

1) Возможно ли, чтобы мое веб-приложение на DMZ получило доступ к WCF-сервису в интрасети без открытия порта?

2) Если нет, то существует ли какая-либо эталонная архитектура, описывающая, что открытие порта может быть выполнено и все же иметь безопасное решение? Возможно, в сочетании с сертификатами, какой-то формой авторизации и т. Д. Никакому другому приложению не нужно использовать сервис (по крайней мере, пока), поэтому вполне допустимо иметь конфигурацию, ограничивающую потребителей этим единственным веб-приложением.

С наилучшими пожеланиями / Valle

Answer 1

Мне пришлось немного «уточнить» свой предыдущий ответ, удалив все это:)

Итак, вот короткая, лучшая версия. Не самый лучший, но работает довольно хорошо. Чтобы упростить объяснение, давайте рассмотрим, что у вас есть один сервис и клиент, который хочет его использовать.

1. добавить приложение прокси-сервера, которое запускается за пределами брандмауэра и предоставляет 2 службы:
   первый идентичен исходному сервису (тот же адрес, обязательный, договор)
   вторая - дуплексная служба, которая имеет в качестве своего обратного вызова тот же контракт вышеуказанной услуги
2. добавить клиентское приложение прокси, которое работает внутри брандмауэра и использует вторую службу прокси-сервера, а также исходную службу
3. исходный клиент будет использовать прокси-сервер вместо исходного сервиса

Как это работает:

1. прокси-клиент подключается к прокси-серверу и регистрирует обратный вызов
2. прокси-клиент также подключается к исходному сервису
3. исходный клиент подключается к прокси-сервису
4. прокси-сервер перенаправляет все вызовы от сервиса на обратный вызов (помните, что контракты совпадают)
5. прокси-клиент перенаправляет все вызовы из реализации обратного вызова клиенту исходной службы (опять же, контракты совпадают)
6. Исходный сервис обрабатывает вызов и возвращает результат
7. ответы отправляются обратно в обратном порядке до первоначального клиента

Обратите внимание, что оригинальный клиент не знает, что он подключается к прокси-серверу, а не к исходной службе

Еще одно замечание: пересылка происходит в коде, что не очень приятно. WCF в .NET 4.0 имеет поддержку маршрутизации, но я не уверен, что вы можете маршрутизировать только канал обратного вызова, а не прямой.

Надеюсь, это поможет, Gicanu