16.02.2016, aktualisiert um 23:32:02 Uhr

5578

Apache 2.4 als Reverseproxy - Weiterleitung auf Zielserver funktioniert nicht

Hallo Zusammen,

auf einem Windows Server 2012 R2 ist ein Apache 2.4.18 installiert. Beide sind neu installiert.
Der Apache soll als Reverseproxy (in der DMZ) fungieren.

Der Reverseproxy ist Lt. diversen Konfigurationsbeschreibungen und der Apache 2.4 Dokumentation aus dem WWW eingerichtet.

Problem ist, dass zwar die Apache-Standardwebsite angezeigt wird, jedoch die Weiterleitung auf den Zielserver (Exchange 2010, IIS) nicht passiert.

Wenn ich auf einem Client im Webbrowser https://owa.domäne.tld/owa eingebe, wird die Meldung "404 Not Found - The requested URL /owa was not found on this server." angezeigt.

Kennt jemand Ursachen des Problems und hat Tipps zur Abhilfe?

Danke für Eure Tipps/Hilfestellungen!

Gruß

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 296421

Url: https://administrator.de/forum/apache-2-4-als-reverseproxy-weiterleitung-auf-zielserver-funktioniert-nicht-296421.html

Ausgedruckt am: 11.04.2025 um 09:04 Uhr

18 Kommentare

Neuester Kommentar

Hallo,

poste doch mal Deine vhost.
Der Apache läuft auf port 80. Auf welchem Port der IIS?

Stefan

Zitat von @StefanKittel:

Hallo,

poste doch mal Deine vhost.
Der Apache läuft auf port 80. Auf welchem Port der IIS?

Wenn ich auf einem Client im Webbrowser https://owa.domäne.tld/owa

Da gehe ich mal von 443 aus

Hallo,

Zitat von @Excaliburx:
auf einem Windows Server 2012 R2 ist ein Apache 2.4.18 installiert.

Und deshalb hier alles ins Linux Bereich geschoben?

Der Apache soll als Reverseproxy (in der DMZ) fungieren.

Warum kein Linux als Grundlage?

Wenn ich auf einem Client

Wo sitzt der Client? Im LAN? Im Internet?

im Webbrowser https://owa.domäne.tld/owa eingebe

Und dein Client kennt jetzt den Ort (IP) wo dein owa.domäne.tld hinzeigt?

wird die Meldung "404 Not Found - The requested URL /owa was not found on this server." angezeigt.

Wer gibt dir diese Antwort?
Dein https://owa.domäne.tld/owa war vor dein ReverseProxy bauen von diesen Client sauber und korrekt erreichbar?

Gruß,
Peter

Da es hier um Apache geht, und nur in diesem Bereich Apache aufgeführt ist, habe ich es hier gepostet und nicht unter Windows Server.

Auf Grund der Administration des Betriebssystems ist der Apache unter Windows installiert. Denn in der Umgebung wird hauptsächlich Windows eingesetzt, wofür KnowHow da ist. Daher das Betriebssystem nicht unter Linux.

Ja, der Client zum Test sitzt im Internet.

Und im DNS beim Provider ist owa.domäne.tld eingetragen und verweist somit auf die öffentliche IP.

Von wem die 404 zurück kommt ist derzeit noch nicht genau bekannt.

Hier die vhost:
<VirtualHost "öffentliche IP-Adresse":443>

ServerName owa.domäne.tld
ServerAlias autodiscover.domäne.tld
ServerAdmin admin@domäne.tld

LogLevel debug
ErrorLog logs/errorvhosts443.log
CustomLog logs/accessvhosts443.log combined

Header always set X-Frame-Options SAMEORIGIN
Header set Server Apache
Header unset X-AspNet-Version
Header unset X-OWA-Version
Header unset X-Powered-By
RequestHeader unset Expect early

SetEnvIf User-Agent ".*MSIE.*" value BrowserMSIE
Header unset WWW-Authenticate
Header add WWW-Authenticate "Basic realm=owa.domäne.tld"

ProxyRequests Off
ProxyPreserveHost On

SSLProxyEngine On

ProxyPass /owa https://owa.domäne.tld/owa
ProxyPassReverse /owa https://owa.domäne.tld/owa
ProxyPass /iisadmpwd https://owa.domäne.tld/iisadmpwd
ProxyPassReverse /iisadmpwd https://owa.domäne.tld/iisadmpwd
ProxyPass /ecp https://owa.domäne.tld/ecp
ProxyPassReverse /ecp https://owa.domäne.tld/ecp
ProxyPass /ECP https://owa.domäne.tld/ECP
ProxyPassReverse /ECP https://owa.domäne.tld/ECP
ProxyPass /Ecp https://owa.domäne.tld/Ecp
ProxyPassReverse /Ecp https://owa.domäne.tld/Ecp
ProxyPass /ews https://owa.domäne.tld/ews
ProxyPassReverse /ews https://owa.domäne.tld/ews
ProxyPass /EWS https://owa.domäne.tld/EWS
ProxyPassReverse /EWS https://owa.domäne.tld/EWS
ProxyPass /Ews https://owa.domäne.tld/Ews
ProxyPassReverse /Ews https://owa.domäne.tld/Ews
ProxyPass /exchange https://owa.domäne.tld/exchange
ProxyPassReverse /exchange https://owa.domäne.tld/exchange
ProxyPass /Exchange https://owa.domäne.tld/Exchange
ProxyPassReverse /Exchange https://owa.domäne.tld/Exchange
ProxyPass /exchweb https://owa.domäne.tld/exchweb
ProxyPassReverse /exchweb https://owa.domäne.tld/exchweb
ProxyPass /public https://owa.domäne.tld/public
ProxyPassReverse /public https://owa.domäne.tld/public
ProxyPass /oab https://owa.domäne.tld/oab
ProxyPassReverse /oab https://owa.domäne.tld/oab
ProxyPass /OAB https://owa.domäne.tld/OAB
ProxyPassReverse /OAB https://owa.domäne.tld/OAB
ProxyPass /Microsoft-Server-ActiveSync https://owa.domäne.tld/Microsoft-Server-ActiveSync connectiontimeout=600
ProxyPassReverse /Microsoft-Server-ActiveSync https://owa.domäne.tld/Microsoft-Server-ActiveSync
ProxyPass /autodiscover https://owa.domäne.tld/autodiscover
ProxyPassReverse /autodiscover https://owa.domäne.tld/autodiscover
ProxyPass /Autodiscover https://owa.domäne.tld/Autodiscover
ProxyPassReverse /Autodiscover https://owa.domäne.tld/Autodiscover
ProxyPass /AutoDiscover https://owa.domäne.tld/AutoDiscover
ProxyPassReverse /AutoDiscover https://owa.domäne.tld/AutoDiscover

AddDefaultCharset ISO-8859-1

<Directory />
Order deny,allow
Deny from all
</Directory>

<Proxy *>
SetEnv proxy-nokeepalive 1
SetEnv force-proxy-request-1.0 1
Order deny,allow
Allow from all
</Proxy>

SSLEngine on
SSLCertificateFile "D:/Apache24/conf/ssl/server.crt"
SSLCertificateKeyFile "D:/Apache24/conf/ssl/server.key"

</VirtualHost>

Bisher ist noch das Apache selbst signierte Zertifikat eingebunden (für Tests), bis das SAN-Zertifikat gekauft und eingebunden wird.
Die Firewall lässt lediglich 443 in die DMZ zum Proxy.
Der IIS lässt auch 443 zu. Mit der internen URL funktioniert der owa Aufruf.

Moin,

https://owa.domäne.tld/owa

Ist das eure interner FQDN für den Exchange-Server?

Ja, der Client zum Test sitzt im Internet.

Nutzt für den Internetzugang aber nicht die selbe Firewall? Sonst könnte NAT ein Problem sein...

Unabhängig davon als Refernz n Artikel vom .

Gruß,
Dani

Nein, das ist nicht der intern verwendete FQDN, sondern separat für extern der FQDN. Die URLs sind so im Exchange eingetragen.

Nein, der Client nutzt nicht die selbe Firewall, sondern kommt frei über einen anderen Router / Anschluss ins Internet.

Nein, das ist nicht der intern verwendete FQDN, sondern separat für extern der FQDN. Die URLs sind so im Exchange eingetragen.

Da sehe ich den Fehler. In der Konfiguration muss der FQDN des Exchange-Serves (z.B. ex2k13-rz1.domäne.local) eingeben werden. Dieses Adresse muss der Server in der DMZ anpingen können. Anderenfalls probier es mit der IP-Adresse des Mailservers. Gibt aber spätestens bei SSL Probleme...

Auch wenn ich den FQDN des Exchanges eingebe, wird im Webbrowser die selbe 404 Meldung angezeigt.
Das gleiche mit der IP des Exchanges.

Ping (ICMP) vom Exchange zum Apache und umgekehrt sind möglich.

Hallo,

Zitat von @Excaliburx:
Auch wenn ich den FQDN des Exchanges eingebe

Kennt denn dein Reverse Proxy die IP hinter dein FQDN?

Das gleiche mit der IP des Exchanges.

Sicher das ein Portfowarding gegeben ist?

Ping (ICMP) vom Exchange zum Apache und umgekehrt sind möglich.

Nur das ein HTTP oder HTTPS kein ICMP ist. Was pingbar ist muss noch lange nicht von anderen Protokollen erreicht werden können.

Gruß,
Peter

Auch wenn ich die IP des Exchanges eingebe (im Proxypass und ProxypassReverse des Apache) anstatt den FQDN, funktioniert die Weiterleitung nicht.
Das Windowssystem kann die den FQDN zur IP auflösen und umgekehrt.
Muss ich die Namensauflösung ggf. auch noch separat in einer Apache Konfig.-Datei einstellen?

Ja, es ist ein NAT mit Portmapping eingerichtet.

Wenn ich im Webbrowser auf dem Reverseproxy den FQDN/owa eingebe oder die IP/owa vom Exchange, dann wird die OWA-Site per https problemlos angezeigt.

Muss auch zum Test zwingend das selbstsignierte Exchangezertifikat exportiert und in den Apache ReverseProxy eingebunden werden, damit die Weiterleitung (ReverseProxy -> Exchange und zurück) funktioniert?

Hallo Excaliburx,

blöde Frage: Das Proxy-Modul im Apache hast du aber aktiviert, oder?

Was sagen denn die Logfiles des Apache?

Beste Grüße!

Berthold

Ja, es sind folgende Module aktiviert:
LoadModule access_compat_module modules/mod_access_compat.so
LoadModule actions_module modules/mod_actions.so
LoadModule alias_module modules/mod_alias.so
LoadModule allowmethods_module modules/mod_allowmethods.so
LoadModule asis_module modules/mod_asis.so
LoadModule auth_basic_module modules/mod_auth_basic.so
LoadModule auth_digest_module modules/mod_auth_digest.so
LoadModule authn_core_module modules/mod_authn_core.so
LoadModule authn_file_module modules/mod_authn_file.so
LoadModule authnz_ldap_module modules/mod_authnz_ldap.so
LoadModule authz_core_module modules/mod_authz_core.so
LoadModule authz_groupfile_module modules/mod_authz_groupfile.so
LoadModule authz_host_module modules/mod_authz_host.so
LoadModule authz_user_module modules/mod_authz_user.so
LoadModule autoindex_module modules/mod_autoindex.so
LoadModule cgi_module modules/mod_cgi.so
LoadModule dir_module modules/mod_dir.so
LoadModule env_module modules/mod_env.so
LoadModule headers_module modules/mod_headers.so
LoadModule include_module modules/mod_include.so
LoadModule info_module modules/mod_info.so
LoadModule isapi_module modules/mod_isapi.so
LoadModule ldap_module modules/mod_ldap.so
LoadModule log_config_module modules/mod_log_config.so
LoadModule mime_module modules/mod_mime.so
LoadModule negotiation_module modules/mod_negotiation.so
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule rewrite_module modules/mod_rewrite.so
LoadModule setenvif_module modules/mod_setenvif.so
LoadModule socache_shmcb_module modules/mod_socache_shmcb.so
LoadModule ssl_module modules/mod_ssl.so
LoadModule status_module modules/mod_status.so
LoadModule proxy_ajp_module modules/mod_proxy_ajp.so
LoadModule deflate_module modules/mod_deflate.so
LoadFile bin/libxml2.dll
LoadModule xml2enc_module modules/mod_xml2enc.so
LoadModule proxy_html_module modules/mod_proxy_html.so

Im error-logfile steht folgendes:
AH00558: httpd.exe: Could not reliably determine the server's fully qualified domain name, using "fe80::....". Set the 'ServerName' directive globally to suppress this message
[Wed Feb 17 00:06:13.844991 2016] [auth_digest:notice] [pid 2844:tid 464] AH01757: generating secret for digest authentication ...
[Wed Feb 17 00:06:13.954361 2016] [ssl:warn] [pid 2844:tid 464] AH01909: localhost:443:0 server certificate does NOT include an ID which matches the server name
[Wed Feb 17 00:06:14.391867 2016] [mpm_winnt:notice] [pid 2844:tid 464] AH00354: Child: Starting 64 worker threads.
[Wed Feb 17 00:06:15.407493 2016] [mpm_winnt:notice] [pid 2500:tid 464] AH00364: Child: All worker threads have exited.

Im logfile des vhosts sind keine weiteren Fehler ersichtlich, sondern lediglich Infomeldungen.

Moin,

Muss auch zum Test zwingend das selbstsignierte Exchangezertifikat exportiert und in den Apache ReverseProxy eingebunden werden, damit die Weiterleitung (ReverseProxy -> Exchange und zurück) funktioniert?

Möglich...

[Wed Feb 17 00:06:13.954361 2016] [ssl:warn] [pid 2844:tid 464] AH01909: localhost:443:0 server certificate does NOT include an ID which matches the server name

Die Meldung macht mich etwas stutzig... er kann den Servername der Apache-Webseite nicht im Zertifikat finden.

Im logfile des vhosts sind keine weiteren Fehler ersichtlich, sondern lediglich Infomeldungen.

Aber wenn du von außen zugreifst, solltest du doch sehen, welche Seiten er versucht zu öffnen und weiterzuleiten. So ist es mal unter Nginx...

Wie sieht denn Das Netzwerkdesign vom Internet bis zum Exchange aus?

Gruß,
Dani

Hi,

also IMHO muss in die config-file auf jeden fall der interne FQDN oder die IP eingetragen werden. Sonst kann der Reverse-Proxy garnicht funktionieren.
Bedenke auch, dass du den Apache nach der Konfigurationsänderung neustarten musst (oder zumindest einen reload ausführen... restart ist aber besser...)
Ansonsten solltest du wirklich mal die access-logs checken und schauen, wie der Zugriff denn genau erfolgt.

Beste Grüße!

Berthold

Wie ist für die Zertifikatsübernahme genau vorzugehen?
Denn der Reverseproxy soll normalerweise ein öffentliche SAN-Zertifikat bekommen.
Wie kann parallel das Exchangezertifikat eingebunden werden?

Die Meldung erscheint, da der Apache derzeit noch die standardmäßigen selbstsignierten Zertifikate verwendet. Und in diesen ist nicht der server name genannt.

Nein, in den logfiles sind keine weiteren Hinweise zu sehen, welche Websites versucht werden aufzurufen.

Das Netzwerkdesign sieht wie folgt aus:
WWW <-> DMZ (Firewall) <-> Reverseproxy <-> LAN (Firewall) <-> LAN: Exchange.

Auch wenn in der Konfig. der FQDN des Exchange drin steht, funktioniert es nicht. Error 404 erscheint.
Den Apache habe ich nach jeder Konfig. Änderung neugestartet.

Leider zeigen die Access-Logs keine weiteren Hinweise an.

Zitat von @Excaliburx:

Wie ist für die Zertifikatsübernahme genau vorzugehen?
Denn der Reverseproxy soll normalerweise ein öffentliche SAN-Zertifikat bekommen.
Wie kann parallel das Exchangezertifikat eingebunden werden?

Du kannst für jeden vHost ein eigenes Zertifikat definieren...

Die Meldung erscheint, da der Apache derzeit noch die standardmäßigen selbstsignierten Zertifikate verwendet. Und in diesen ist nicht der server name genannt.

Nein, in den logfiles sind keine weiteren Hinweise zu sehen, welche Websites versucht werden aufzurufen.

Das Netzwerkdesign sieht wie folgt aus:
WWW <-> DMZ (Firewall) <-> Reverseproxy <-> LAN (Firewall) <-> LAN: Exchange.

Auch wenn in der Konfig. der FQDN des Exchange drin steht, funktioniert es nicht. Error 404 erscheint.
Den Apache habe ich nach jeder Konfig. Änderung neugestartet.

Aber wie soll der Apache denn den Weg zum Exchange finden, wenn du den externen FQDN des Exchange in der Konfig angibst? Wie soll der denn dann zum Exchange-Server aufgelöst werden? Es müsste eben der interne FQDN oder die IP sein. Der interne FQDN müsste dann auch durch den Apache aufgelöst werden können.

Hast du denn deinen neuen vHost auch aktiviert? (Stichwort sites-available / sites-enabled)

Soll das ganze per SSL-Offloading funktionieren oder nicht?

Hast du mal einen einfach vhost mit einer Weiterleitung auf einen anderen Host angelegt? (nur HTTP, keine Verschlüsselung) Hat der Reverse-Proxy dann funktioniert?

Leider zeigen die Access-Logs keine weiteren Hinweise an.

Es gibt nur einen vHost - den für Port 443.
Und diesem würde an das SAN-Zertifikat, welches ich kaufen werde, zuweisen.
Ich gehe davon aus, dass wenn dann der vHost das öffentliche SAN-Zertifikat verwendet, auch der Exchange die Zertifikatskette bis zur öffentlichen CA auslösen kann und er somit dem Apache vHost vertraut.

Da öffentliche CAs zunehmen wohl keine Zertifikate mehr für interne Servernamen ausstellen, hatte ich ursprünglich die externe URL owa.domäne.tld/owa in ProxyPass und ProxyReverse eingetragen, denn nur dieser Namen wird später auch im SAN-Zertifikat enthalten sein.

Der Apache soll den Weg zum Exchange entweder per DNS-Auflösung aus der Hosts-Datei oder der internen DNS-Server finden.
Die Weiterleitung des Reverseproxy funktioniert jedoch auch mit IP oder internem FQDN des Exchange nicht.
Greift der Apache auf die DNS.Namensauflösung des Windows Servers zu oder verwendet dieser eine eigene?

Muss die externe URL im Exchange auch zwingend die IP des Exchange beinhalten, so den selben Wert wie im Reverseproxy bei ProxyPass und ProxyPass Reverse eintragen ist?

Nien, der vHost ist nicht aktiviert, da ich diese Einträge/Dateien bisher auf Apache für Windows im Gegensatz Apache zu Linux nicht gefunden habe. Wo ist dies bei Apache für Windows zu tun?

Ja, SSL-Offloading wäre sinnvoll.

Nein, dies werde ich nun testen, wie es sich mit einer Weiterleitung auf einen anderen Host verhalt.