O VirtualServer reverseproxy funciona localmente, mas não do cliente

2

Configuração: 2 Webservers apontaram para 127.0.0.1:8080 e: 8081. Curl confirma que eles funcionam conforme o esperado. Apache com os seguintes hosts virt:

NameVirtualHost 192.168.1.1:80

<VirtualHost 192.168.1.1:80>
  ServerAdmin [email protected]
  ProxyPass             /       http://127.0.0.1:8080/
  ProxyPassReverse      /       http://127.0.0.1:8080/
  ServerName 192.168.1.1
  ServerAlias http://192.168.1.1
</VirtualHost>

NameVirtualHost 192.168.1.2:80

<VirtualHost 192.168.1.2:80>
  ServerAdmin [email protected]
  ProxyPass             /       http://127.0.0.1:8081/
  ProxyPassReverse      /       http://127.0.0.1:8081/
  ServerName 192.168.1.2
  ServerAlias http://192.168.1.2
</VirtualHost>

No servidor, posso enrolar para o virtualhosts e receber respostas apropriadas. (O curl 192.168.1.1 me fornece a resposta dos servidores web do localhost: 8080, etc)

Os hosts remotos não podem se conectar a 192.168.1.1 ou .2. O que estou perdendo?

Re: comentários

Sim, o diretório padrão Diretiva ainda está em vigor.

# Deny access to root file system
<Directory />
        Options None
        AllowOverride None
        Order Deny,Allow
        deny from all
</Directory>

Nenhum log do apache é gerado ao tentar acessar o 192.168.1.1 remotamente. Eles são gerados quando se curvam de locais.

Se eu apontar os servidores web para *: 8080 e *: 8081 em vez de vincular ao host local, eu posso acessá-los de um host remoto via 192.168.1.1 e 192.168.1.2 se eu especificar as portas 8080 e 8081 (ambas as portas funcionam em ambos os IPs, que é o que eu estou tentando evitar com o proxy reverso do apache vinculado a 80 em cada interface)

Edit2:

saída detalhada curvada: (semelhante para o segundo servidor da Web e para o 127.0.0.1:portnum)

[user@host mingle_12_2_1]$ curl -v 192.168.1.1
* About to connect() to 192.168.1.1 port 80
*   Trying 192.168.1.1... connected
* Connected to 192.168.1.1 (192.168.1.1) port 80
> GET / HTTP/1.1
> User-Agent: curl/7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
> Host: 192.168.1.1
> Accept: */*
>
< HTTP/1.1 302 Found
< Date: Tue, 16 Oct 2012 16:22:08 GMT
< Server: Jetty(6.1.19)
< Cache-Control: no-cache
< Location: http://192.168.1.1/install
< X-Runtime: 130
< Content-Type: text/html; charset=utf-8
< Content-Length: 94
< Connection: close
Closing connection #0
<html><body>You are being <a href="http://192.168.1.1/install">redirected</a>.</body></html>

log da solicitação local

192.168.1.1 - - [16/Oct/2012:12:22:08 -0400] "GET / HTTP/1.1" 302 94

sem log de acesso do apache ou log de erros gerado quando solicitações de clientes remotos.

Editar3

curl e logs para ambos os hosts virtuais são literalmente idênticos, exceto pelo endereço IP usado. Trabalhando com administradores de segurança para obter as regras bloqueadas para mais informações. Eu aprecio o tempo de vocês.

    
por Yep 16.10.2012 / 17:58

2 respostas

1

Como uma configuração proxypass opera inteiramente no espaço URL (virtual), você precisa conceder acesso a cada vhost por meio de uma diretiva Location:

<VirtualHost 192.168.1.1:80>
  ServerAdmin [email protected]
  ProxyPass / http://127.0.0.1:8080/
  ProxyPassReverse / http://127.0.0.1:8080/
  ServerName 192.168.1.1
  <Location />
    Order allow,deny
    Allow from All
  </Location>
</VirtualHost>

Além disso, livre-se do NameVirtualHosts se você não estiver usando-o, e um ServerName deve ser um nome de host, não há esquema ou porta ou o que seja. Apenas um nome de host.

    
por 16.10.2012 / 18:28
0

você pode fornecer:

  • curl sintaxe / saída (use verbose)
  • registros do apache
  • saída do ifconfig
  • cat / etc / hosts
  • conjunto de regras de firewall
  • SELinux ativar / desativar?

* UPDATE *

também ServerAlias , você deve remover http:// part conforme necessário, sem mencionar que, como seu ServerName é o mesmo que ServerAlias , ServerAlias simplesmente não é necessário.

    
por 16.10.2012 / 18:17