☰

El proxy inverso en 127.0.0.1 funciona localmente, pero no a través de la red

tag-icon • tag-icon apache-2.2 reverse-proxy
El proxy inverso en 127.0.0.1 funciona localmente, pero no a través de la red

Dos servidores web, vinculados a 127.0.0.1:8080 y 127.0.0.1:8081. Curl valida que funcionan como se esperaba.

Apache con los siguientes hosts:

Host 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>

Host 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>

En el servidor puedo comunicarme con los hosts y recibir la respuesta adecuada. (curl 192.168.1.1 me da la respuesta del servidor web de localhost:8080)

Los hosts remotos no pueden conectarse a 192.168.1.1 o .2 en absoluto. ¿Qué me estoy perdiendo?

Re: comentarios

Sí, la directiva de directorio predeterminado todavía está vigente.

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

No se generan registros de Apache al intentar acceder a 192.168.1.1 de forma remota. Se generan cuando se enrollan desde local.

Si vinculo los servidores web a *:8080 y *:8081 en lugar de vincularlos al host local, puedo acceder a ellos desde un host remoto a través de 192.168.1.1 y 192.168.1.2.

Edición 2:

salida detallada de curl: (similar para el segundo servidor web y para 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>

iniciar sesión desde la solicitud local

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

no se genera ningún registro de acceso de Apache ni registro de errores cuando se realizan solicitudes de clientes remotos.

Editar 3

curl y los registros de ambos hosts son idénticos, excepto por la dirección IP utilizada. Trabajando con administradores de seguridad para obtener las reglas bloqueadas para obtener más información.

Respuesta1

Dado que una configuración de proxypass opera completamente en el espacio URL (virtual), debe otorgar acceso a cada vhost a través de una directiva de Ubicación:

<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>

Además, elimine los NameVirtualHosts si no los está utilizando, y un ServerName debe ser un nombre de host, no hay ningún esquema ni puerto ni nada por el estilo. Sólo un nombre de host.

Respuesta2

Puedes facilitar:

  • sintaxis/salida de curl (use detallado)
  • registros de apache
  • salida ifconfig
  • gato /etc/hosts
  • conjunto de reglas de firewall
  • ¿Selinux habilitar/deshabilitar?

* ACTUALIZAR *

También ServerAliasdebe eliminar http://la parte que no es necesaria, sin mencionar que, dado que ServerNamees igual ServerAlias, ServerAliassimplemente no es necesaria.

información relacionada