我的目标是相当典型的，所以我希望别人可能以前实施过类似的设置。
外部客户端Foo将连接到Bar，Bar是一个具有适当防火墙例外的服务器，因此可见到应用服务器Baz（192.168.1.5）所在的内部networking192.168.1.0/24。 Baz通过JNLP提供了一个Java应用程序。
当前设置
xinetd在端口8080上的Bar上运行，通过防火墙redirect到启动JNLP的内部系统Baz端口443，并且被反馈到客户端Foo，在那里Java应用程序踢得很好，一切都很好。 Foo客户端在JNLP文件上的交互确实使用了由xinetd“路由”的同一个连接，所以没有使用这个设置的不对称路由或者任何讨厌的事情。 只是没有保护的应用程序，这是不可取的。
xinetdconfiguration：
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 } 期望的设置
一些身份validation来保护应用程序。 我们已经成功实施了以下内容：
使用Kerberos主体的Apache + mod_ssl + mod_proxy + mod_authz_ldap。 这是运行在端口443，身份validation正常工作。 然后configuration应该代理内部系统Baz的端口443，JNLP应该传回。
这里是相关的Apacheconfiguration：
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>
问题
使用前面提到的'Desired Setup'，JNLP会得到传回，尽pipe当ProxyPreserveHost选项设置为on时，Foo的WebStart启动的JNLP文件，希望在端口443上连接回Bar的主机名只是一个循环），但不幸的是没有ProxyPreserveHost选项，那么Foo的WebStart会尝试连接到Baz的内部地址（在防火墙上被阻止到除Bar外的任何主机）。 惊叹于我的困境绝望的长度。
我已经尝试了很多上面的configuration排列，甚至投掷xinetd通过添加另一个层次的redirect来停止循环（这会导致奇怪的，无证的（可能）奇怪，我甚至无法理解）。
在这一点上，我发现很难看到树木的木材，似乎无法摆脱这个奇怪的捕捉22。
任何build议最受欢迎。
干杯
SC。