Моя цель довольно типична, поэтому я надеюсь, что кто-то другой, возможно, реализовал аналогичную установку раньше.
Внешний клиент Foo будет подключаться к Bar, который является сервером с соответствующим исключением брандмауэра, и, таким образом, будет виден во внутренней сети 192.168.1.0/24, где находится сервер приложений Baz (192.168.1.5). Baz предлагает приложение Java через JNLP.
Текущая настройка
xinetd работает на Bar на порте 8080, который перенаправляет через брандмауэр на внутренний порт Baz 443 системы, где запущен JNLP, и отправляет обратно клиенту Foo, где приложение Java запускается нормально, и все в порядке. Взаимодействие клиента Foo с файлом JNLP действительно использует то же соединение, которое «маршрутизируется» xinetd, поэтому с этой настройкой не происходит асимметической маршрутизации или чего-либо неприятного. Просто никакой защиты для приложения, что нежелательно.
Конфигурация xinetd:
service baz-app {
disable = no
type = UNLISTED
flag = IPv4
socket_type = stream
wait = no
user = root
port = 80
#Not functional yet.
#only_from = 127.0.0.1
redirect = 192.168.1.5 443
log_on_failure += USERID
}
Желаемая настройка
Некоторая аутентификация для защиты приложения. Мы успешно реализовали следующее:
Apache + mod_ssl + mod_proxy + mod_authz_ldap с принципалом Kerberos. Он работает на порту 443, и аутентификация работает нормально. Затем конфигурация должна прокси к порту 443 внутренней системы Baz, куда должен быть передан JNLP.
Вот соответствующая конфигурация Apache:
SSLProxyEngine on
ProxyPreserveHost on
<Location />
ProxyPass https://192.168.1.5/ # Baz's internal address.
ProxyPassReverse https://192.168.1.5/
.... all authentication options follow ....
</Location>
Эта проблема
Используя вышеупомянутую `` Желаемую настройку '', JNLP передается обратно, хотя, поскольку параметр ProxyPreserveHost включен, файл JNLP, который запускает Foo WebStart, ожидает подключения обратно к имени хоста Bar на порту 443 (который затем просто цикл), но, к сожалению, без опции ProxyPreserveHost, тогда Foo's WebStart пытается подключиться к внутреннему адресу Baz (который заблокирован брандмауэром для любого хоста, кроме Bar). Поразитесь отчаянной продолжительности моего положения.
Я пробовал много разных перестановок вышеуказанной конфигурации, даже бросил xinetd, чтобы остановить цикл, добавив еще один уровень перенаправления (что приводит к странным, недокументированным (вероятно) странностям, которые я даже не могу понять).
На данный момент мне трудно разглядеть лес за деревьями, и, кажется, я не могу выбраться из этой странной уловки 22.
Любые советы приветствуются.
ура
sc.