17
Microsoft Exchange Server 2019 x Apache2 reverse Proxy - Weiterleitung zur internen URI unterbinden?
Servus!
Ich habe eine Problem bei der Installation eines Exchange Servers. Der Server läuft wie gewohnt auf einem Windows Server 2022 und ich wollte die OWA per Domain öffentlich zur Verfügung stellen.
Deshalb hatte ich Apache2 genutzt und reverse proxy konfiguriert. Das sieht dann so aus:
Diese Konfiguration gibt mir auch Zugriff auf die OWA, jedoch nur intern, da mich die Domain zur internen IP weiterleitet. (domain.example -> 10.0.120.50)
Weiß möglicherweise jemand weiter?
Beste Grüße
Philipp
Ich habe eine Problem bei der Installation eines Exchange Servers. Der Server läuft wie gewohnt auf einem Windows Server 2022 und ich wollte die OWA per Domain öffentlich zur Verfügung stellen.
Deshalb hatte ich Apache2 genutzt und reverse proxy konfiguriert. Das sieht dann so aus:
ProxyPass / https://10.0.120.50:443/ nocanon
ProxyPassReverse / https://10.0.120.50:443/Diese Konfiguration gibt mir auch Zugriff auf die OWA, jedoch nur intern, da mich die Domain zur internen IP weiterleitet. (domain.example -> 10.0.120.50)
Weiß möglicherweise jemand weiter?
Beste Grüße
Philipp
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 6389379529
Url: https://administrator.de/contentid/6389379529
Ausgedruckt am: 24.11.2024 um 10:11 Uhr
17 Kommentare
Neuester Kommentar
DNS und Reverse DNS passt?
Wie sieht der Rest der Konfig aus? Sicher dass du ohne FQDN in der Konfig arbeiten willst?
Wie sieht der Rest der Konfig aus? Sicher dass du ohne FQDN in der Konfig arbeiten willst?
DNS und rDNS passt und ist soweit richtig konfiguriert.
Der Rest der Konfig sieht folgendermaßen aus:
Der Rest der Konfig sieht folgendermaßen aus:
<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerName mail.domain.example
ServerAdmin admin@domain.example
AllowEncodedSlashes NoDecode
SSLProxyEngine on
SSLProxyVerify none
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
SSLProxyCheckPeerExpire off
ProxyPass / https://10.0.120.50:443/ nocanon
ProxyPassReverse / https://10.0.120.50:443/
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
SSLCertificateFile /path/to/crt
SSLCertificateKeyFile /path/to/key
</VirtualHost>
</IfModule>
Das sieht sehr wenig aus. Es geht nur um OWA?
Was passiert genau, wenn es von extern nicht geht?
Kannst du HTTP-Header mitschneiden und auswerten?
Was passiert genau, wenn es von extern nicht geht?
Kannst du HTTP-Header mitschneiden und auswerten?
Hi,
Apache2 ist dagegen sehr langsam und arg unflexibel.
Just 2 cents.
Viel Erfolg, Grüße
Apache2
Auch wenn es nicht gefragt ist: ich würde Dir nginx ans Herz legen. Lightweight, schnell und ideal als Reverseproxy.Apache2 ist dagegen sehr langsam und arg unflexibel.
Just 2 cents.
Viel Erfolg, Grüße
Das wichtigste wäre erstmal OWA. Trotzdem sollte es wegen dem Proxy jeglichen Traffic umleiten.
Ich habe mir aber erstmal den HTTP-Header angesehen und folgendes entnommen:
Das ist natürlich auf das wichtigste zugeschnitten. Falls du mehr benötigst, sag einfach Bescheid.
Ich habe mir aber erstmal den HTTP-Header angesehen und folgendes entnommen:
Request:
Request URL: https://owa.domain.example/
Request Method: GET
Status Code: 302 (Welcher hier schon auf einen Fehler hindeutet)
Response:
location: https://10.0.120.50/owa
server: cloudflare (DNS läuft bei Cloudflare)
x-feserver: ws12050 (hostname exchange server)Das ist natürlich auf das wichtigste zugeschnitten. Falls du mehr benötigst, sag einfach Bescheid.
Und der externe öffentliche Client bekommt dann auch diese private IP genannt?
So ist es. Dem Gerät, das darauf eben zugegriffen hat, wurde auch die interne IP übermittelt.
Der Externe, der kein VPN hat, bekommt eine interne IP genannt? Und das vom CF DNS?
Nein, der externe Client bekommt von Cloudflare die externe, öffentliche IP mitgeteilt. So wie ich das sehe, leitet der Exchange Server selbst an die interne IP weiter.
Wo hast du wie den Header mitgeschnitten?
In dem Fall relativ Simpel mit den Chrome DevTools. Falls benötigt könnte ich auch versuchen, am Server den Header zu catchen.
Wenn jemand im öffentlichen Internet, eine private IP aufruft, würde der erste ISP Router das nicht routen. Daher die Frage.
Vielleicht habe ich auch einen Kurzschluss im Kopf, daher noch einmal die Frage.
Vielleicht habe ich auch einen Kurzschluss im Kopf, daher noch einmal die Frage.
Nein, der DNS Eintrag ist so gesetzt, dass er auf die öffentliche IP zeigt. Der Apache2 Server erkennt die Verbindung auch, jedoch leitet irgendwas und irgendwie schlussendlich auf die interne weiter.
Warum auf die IP? Cname/Alias macht Sinn.
Du solltest klären, warum der Client die IP bekommt. Ich tippe auf die Konfig des Indianers mit der IP.
Mit IPs arbeiten ist meistens schlecht, besonders wenn es nicht lokale Sachen sind.
DNS muss perfekt sitzen.
Du solltest klären, warum der Client die IP bekommt. Ich tippe auf die Konfig des Indianers mit der IP.
Mit IPs arbeiten ist meistens schlecht, besonders wenn es nicht lokale Sachen sind.
DNS muss perfekt sitzen.
Da fehlen einige Direktiven, unter anderem diese:
Apache als Reverse Proxy für Exchange Server (Teil 1)
Apache als Reverse Proxy für Exchange Server (Teil 2)
Cheers briggs
Apache als Reverse Proxy für Exchange Server (Teil 1)
Apache als Reverse Proxy für Exchange Server (Teil 2)
Cheers briggs
Moin,
Gruß,
Dani
P.S. Ein Reverse Proxy, der die Verbindungen 1:1 durchreicht, schützt dich bzw. dein Exchange Server vor keinem Angriffsvektor.
Request URL: https://owa.domain.example/
Request Method: GET
Status Code: 302 (Welcher hier schon auf einen Fehler hindeutet)
undRequest Method: GET
Status Code: 302 (Welcher hier schon auf einen Fehler hindeutet)
mail.domain.example
sind zwei paar Stiefel. Das würde ad-hoc erst einmal bedeuten, dass es von owa.domain.example zu mail.domain.example eine Weiterleitung gibt. Damit wäre der HTTP Code 302 erst einmal richtig.Nein, der DNS Eintrag ist so gesetzt, dass er auf die öffentliche IP zeigt. Der Apache2 Server erkennt die Verbindung auch, jedoch leitet irgendwas und irgendwie schlussendlich auf die interne weiter.
Geh doch hin, nimm einem Client im Netzwerk und manipuliere die hosts Datei. Und zwar dahingehend, dass du dort den FQDN mail.domain.example hinzufügst. Als IP-Adresse nimmst du die des Servers auf dem der Apache2 läuft. Somit kannst du dein Setup verifizieren, ohne dass euere Firewall oder CF Einfluss hat.Gruß,
Dani
P.S. Ein Reverse Proxy, der die Verbindungen 1:1 durchreicht, schützt dich bzw. dein Exchange Server vor keinem Angriffsvektor.
Zitat von @6247018886:
Da fehlen einige Direktiven fehlen unter anderem diese:
Apache als Reverse Proxy für Exchange Server (Teil 1)
Apache als Reverse Proxy für Exchange Server (Teil 2)
Cheers briggs
Da fehlen einige Direktiven fehlen unter anderem diese:
Apache als Reverse Proxy für Exchange Server (Teil 1)
Apache als Reverse Proxy für Exchange Server (Teil 2)
Cheers briggs
Danke für die hilfreichen Links! Daraus habe ich nun die Konfiguration entnommen und anstatt jede Verbindung (also /) umzuleiten, hat es tatsächlich geholfen, nur die jeweiligen Links anzusprechen. Nun habe ich von außen Zugriff!
Ich danke auch @2423392070 und @Dani für die Unterstützung!
Ich wünsche ein schönes Wochenende!
Grüße
Philipp
