Meu objetivo é bastante típico, por isso espero que outra pessoa tenha implementado uma configuração semelhante antes.
O cliente externo Foo se conectará ao Bar, que é um servidor com uma exceção de firewall apropriada e, portanto, visibilidade da rede interna 192.168.1.0/24 onde o servidor de aplicativos Baz (192.168.1.5) está instalado. Baz oferece um aplicativo Java via JNLP.
Configuração atual
O xinetd está rodando no Bar na porta 8080, que redireciona através do firewall para a porta Baz do sistema interno 443, onde o JNLP é iniciado, e é enviado de volta ao cliente Foo, onde o aplicativo Java começa bem e tudo está bem. A interação do cliente Foo no arquivo JNLP usa a mesma conexão que está sendo 'roteada' pelo xinetd, portanto nenhum roteamento assimétrico ou qualquer coisa desagradável acontecendo com esta configuração. Apenas sem proteção para o aplicativo, o que é menos que desejável.
configuração 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
}
Configuração desejada
Alguma autenticação para proteger o aplicativo. Nós implementamos com sucesso o seguinte:
Apache + mod_ssl + mod_proxy + mod_authz_ldap com o principal do Kerberos. Isso está sendo executado na porta 443 e a autenticação funciona bem. A configuração então deve Proxy para a porta 443 do sistema interno Baz, onde o JNLP deve ser passado de volta.
Aqui está a configuração relevante do 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>
O problema
Utilizando o 'Desired Setup' acima mencionado, o JNLP é passado de volta, embora a opção ProxyPreserveHost esteja ativada, o arquivo JNLP que o WebStart do Foo inicia, espera se conectar ao hostname da barra na porta 443 ( que então é apenas um loop), mas infelizmente sem a opção ProxyPreserveHost, o WebStart do Foo tenta se conectar ao endereço interno do Baz (que é bloqueado no Firewall para qualquer host que não seja Bar). Maravilhe-se com a duração desesperada da minha situação.
Eu tentei muitas permutações da configuração acima, até mesmo jogando o xinetd para parar o loop adicionando outro nível de redirecionamento, (o que resulta em estranhas estranhezas, não documentadas (provavelmente) que eu não consigo nem começar a entender. ).
Neste momento eu estou achando difícil ver a madeira para as árvores, e não consigo me livrar desse estranho Catch 22.
Qualquer conselho é muito bem-vindo.
felicidades
sc.
Tags apache-2.2 mod-proxy