Redirecionamento do Apache mod_proxy + xinetd para o host com firewall + esperando que o JNLP retorne ao cliente

1

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.

    
por swisscheese 13.02.2013 / 13:12

0 respostas