☰

Reverse-Proxy auf 127.0.0.1 funktioniert lokal, aber nicht über das Netzwerk

tag-icon • tag-icon apache-2.2 reverse-proxy
Reverse-Proxy auf 127.0.0.1 funktioniert lokal, aber nicht über das Netzwerk

Zwei Webserver, gebunden an 127.0.0.1:8080 und 127.0.0.1:8081. Curl überprüft, ob sie wie erwartet funktionieren.

Apache mit folgenden 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>

Auf dem Server kann ich eine Verbindung zu den Hosts herstellen und erhalte die entsprechende Antwort. (curl 192.168.1.1 gibt mir die Webserver-Antwort von localhost:8080)

Remote-Hosts können überhaupt keine Verbindung zu 192.168.1.1 oder .2 herstellen. Was übersehe ich?

Betreff: Kommentare

Ja, die Standardverzeichnisdirektive ist weiterhin gültig.

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

Beim Versuch, 192.168.1.1 remote zu erreichen, werden keine Apache-Protokolle erstellt. Sie werden beim lokalen Curl-Aufruf erstellt.

Wenn ich die Webserver an *:8080 und *:8081 binde, anstatt sie an den lokalen Host zu binden, kann ich von einem Remote-Host über 192.168.1.1 und 192.168.1.2 auf sie zugreifen.

Bearbeitung 2:

ausführliche Ausgabe von curl: (ähnlich für den zweiten Webserver und für 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 aus der Anfrage lokal

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

Bei Anforderungen von Remoteclients wird kein Apache-Zugriffsprotokoll oder Fehlerprotokoll generiert.

Bearbeiten 3

curl und Protokolle zu beiden Hosts sind bis auf die verwendete IP-Adresse identisch. Ich arbeite mit Sicherheitsadministratoren zusammen, um die gesperrten Regeln für weitere Informationen zu erhalten.

Antwort1

Da ein Proxypass-Setup vollständig im (virtuellen) URL-Raum operiert, müssen Sie jedem virtuellen Host über eine Location-Direktive Zugriff gewähren:

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

Entfernen Sie außerdem die NameVirtualHosts, wenn Sie sie nicht verwenden. Ein Servername muss ein Hostname sein, es gibt kein Schema oder Port oder dergleichen. Nur ein Hostname.

Antwort2

können Sie bereitstellen:

  • Curl-Syntax/Ausgabe (ausführlich verwenden)
  • Protokolle von Apache
  • ifconfig-Ausgabe
  • Katze /etc/hosts
  • Firewall-Regelsatz
  • SELinux aktivieren/deaktivieren?

* AKTUALISIEREN *

außerdem ServerAliassollten Sie http://den Teil entfernen, da dieser nicht benötigt wird, ganz zu schweigen davon, dass er einfach nicht benötigt wird , da Ihr ServerNamedasselbe ist wie .ServerAliasServerAlias

verwandte Informationen