09.07.2012

7350

Exchange over Https, Relay in der DMZ welche Möglichkeiten habe ich?

Mein Chef hat bei einem Kunden (vor meiner Zeit) einen Exchangeserver eingerichtet. Nun will er exchange over https nutzen, damit Endgeräte für exchange nicht immer die vpn nutzen müssen.

Meine Frage bezieht sich auf eure Erfahrungen damit. Kennt jemand eine günstige / kostenlose Lösung ein Relay einzurichten, das dann in der DMZ sitzt und das exchange Zertifikat ohne es aufzulösen einfach nur durchreicht an den Exchange der hinter der DMZ sitzt?

http://lostcommunication.de/index.php/apache-reverse-proxy-fur-exchange ...
sowas zum Beispiel: wichtig ist halt nicht nur das https relay, sondern das weiterreichen vom exchange zertifikat ohne dieses aufzulösen.

Wäre über eure Anregungen sehr erfreut!

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

Content-ID: 187682

Url: https://administrator.de/forum/exchange-over-https-relay-in-der-dmz-welche-moeglichkeiten-habe-ich-187682.html

Ausgedruckt am: 22.12.2024 um 11:12 Uhr

18 Kommentare

Neuester Kommentar

Und was spricht jetzt gegen die von Dir gepostete Lösung mit dem Apache?

weil apache seit 3 jahren bei größeren rpc paketen einen bug hat der nicht gefixed wird ;/

nginx, oder der leichter zu konfigurierende pound kann das auch

vielen dank! ich werde die beiden proxy's morgen testen und berichten.

Moin,
also Apache würde ich gleich wieder vergessen! Da ist die Performance unter alter Sau!
Wir haben überall nginx im Einsatz und sind sehr zufrieden. Ob aber RPC inzwischen problemlos klappt bezweifel ich. Nginx supporter NTLM noch nicht...

Grüße,
Dani

Hallo,

das exchange Zertifikat ohne es aufzulösen einfach nur durchreicht

Was willst du damit denn sagen?
"einfach durchreichen" von Datenpaketen ist das, was jeder Router macht.
Nicht einfach durchreichen, sondern die Verbindung terminieren und eine neue aufbauen (und dabei auch neu verschlüssel [wofür man bei Wunsch aber das gleiche Zertifikat nehmen kann]) tut jeder Reverse-Proxy.

Gruß

Filipp

ok vielen Dank für eure Antworten. Ich habe mich nun für den Squid auf Ubuntu entschieden.

Da der Proxy kein Webproxy darstellen soll, sondern ausschließlich für rpc over https gedacht ist, damit der Exchange nicht mit einem Bein im Internet steht, habe ich mir eine entsprechende config file gesucht.

visible_hostname owa.Beispiel.local
extension_methods RPC_IN_DATA RPC_OUT_DATA

https_port 443 cert=/path/to/external/cert

key=/path/to/external/cert.key defaultsite=external.owa.domain.name

cache_peer ip.address.of.exchange parent 443 0 no-query originserver login=PASS

ssl sslflags=DONT_VERIFY_PEER sslcert=/path/to/exchange/cert.crt sslkey=/path/to/exchange/certkey.pem name=owaServer

acl OWA dstdomain external.owa.domain.name

cache_peer_access owaServer allow OWA

never_direct allow OWA

http_access allow OWA

http_access deny all

miss_access allow OWA

miss_access deny all

Da die OWA Lösung bereits über das VPN realisiert ist, möchte ich hier ausschließlich RPC darüber abwickeln. Daher würde ich die config abspecken, so dass auschließlich darüber rpc läuft. Kann mir jemand sagen, ob ich die owa Einträge damit einfach aus der o.g. config löschen kann?

Das Zertifikat (SSL) wird vom Exchange vorgegeben und daher brauche ich kein eigenes auf dem Squid zu erstellen.

visible_hostname owa.Beispiel.local
extension_methods RPC_IN_DATA RPC_OUT_DATA

cache_peer ip.address.of.exchange parent 443 0 no-query originserver login=PASS

ssl sslflags=DONT_VERIFY_PEER sslcert=/path/to/exchange/cert.crt sslkey=/path/to/exchange/certkey.pem name=owaServer

http_access deny all

miss_access allow OWA

miss_access deny all

Pardon falls dem einen oder anderen die Frage zu banal scheint, aber ich arbeite mich gerade erst wirklich ein - vorher habe ich mich kaum mit Proxys etc beschäftigen müssen.

Danke für eure Hilfe.

Moin,
funktioniert RPCoHTTPS mit dieser Konfiguration überhaupt?! Da wäre doch erstmal wichtig, danach kannst du die Konfiguration verkleinern.

Das Zertifikat (SSL) wird vom Exchange vorgegeben und daher brauche ich kein eigenes auf dem Squid zu erstellen.

Hmm... da wäre ich mir nicht sicher. Unser RevProxy benötigt ein eigenständiges gültiges Zertifikat.

Da die OWA Lösung bereits über das VPN realisiert ist, möchte ich hier ausschließlich RPC darüber abwickeln.

Auch eine Möglichkeit...

Grüße,
Dani

Hallo Dani,

job Outlook Anywhere (RPCoHTTPS) funktioniert soweit mit Squid

siehe:
siehe: http://atlina.com/blog/?p=8

Das Problem ist bei diesen Lösungen ist immer OWA mit drin und ich suche halt nach einer configfile bzw. eine Befehlsreferenz zum Configfile, habe nicht wirklich bisher etwas passendes gesehen. Das Problem ist halt nicht das Verständnis, sondern die Quelle.

Probier's mal so:

acl OWA dstdomain external.owa.domain.name/rpc

Grüße,
Dani

Danke für die Antwort Dani und sorry ich musste mich um einen Notfall die letzten Tage kümmern, deswegen komme ich erst jetzt dazu hier zu lesen.
Wie meinst du das genau? Soll ich nur diese Zeile dort eintragen?

lieben Gruß

Einfach Zeile 12 mit meiner Zeile austauschen.

Grüße,
Dani

Ok nach gründlicher Recherche bin ich nun ein ganzes Stück weitergekommen. Trotzdem sind noch ein paar Fragen offen.

Da ich wie schon vorher erwähnt das erste mal mich mit Proxy Servern beschäftige fiel mir das Verständnis nicht ganz so leicht und die vielen Forenbeiträge im Internet verwirren bei dem Thema schon sehr. Ich bin zuerst davon ausgegangen, das der Squid in der Lage ist das SSL Zertifikat das vom IIS (auf dem Exchange) ausgestellt ist selber für die interne Verschlüsselung zu nutzen und auch dieses Zertifikat zu nutzen um die SSL Verschlüsselung zum Client zu gewährleisten. Dieser Gedanke ist an sich jedoch völlig falsch was sich dann gezeigt hat. Squid ist jedoch in der Lage mit der sogenannten Connect -request Methode sämtliche Protokolle 1:1 weiterzuleiten ohne die Verbindung zu terminieren.

http://www.warp9.de/pub/BO07RevProxy.pdf hier sagt jemand das es mit der Version 2.6 definitiv möglich ist RPCoHTTPS zu betreiben.

Ok. Soweit so gut nun habe ich mich an die ersten Schritte gemacht und nochmal bei 0 begonnen.

Zuerst ist es wichtig zu wissen, das Squid an sich in der Grundkonfiguration nicht SSL beinhaltet und man daher das Paket neu kompilieren muss.

1. installieren von OpenSSL und kompilieren des Squid Paketes mit dem Parameter --enable-ssl

apt-get install openssl

herunterladen von Squid,extrahieren und kompilieren.

su - 

passwort eingeben

wget http://www.squid-cache.org/Versions/v3/3.0/ 

cd /root

tar xvf *.gz

./configure --prefix=/usr --includedir=${prefix}/include --enable-ssl --mandir=${prefix}/share/man --infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --libexecdir=${prefix}/lib/squid3 --disable-maintainer-mode --disable-dependency-tracking --srcdir=. --datadir=/usr/share/squid3 --sysconfdir=/etc/squid3 --mandir=/usr/share/man --enable-inline --enable-async-io=8 --enable-storeio=ufs,aufs,diskd,null --enable-removal-policies=lru,heap --enable-delay-pools --enable-cache-digests --enable-underscores --enable-icap-client --enable-follow-x-forwarded-for --enable-auth=basic,digest,ntlm --enable-basic-auth-helpers=LDAP,MSNT,NCSA,SASL,SMB,YP,getpwnam,multi-domain-NTLM --enable-ntlm-auth-helpers=SMB --enable-digest-auth-helpers=ldap,password --enable-external-acl-helpers=ip_user,ldap_group --with-filedescriptors=65536 --with-default-user=proxy --enable-epoll --enable-linux-netfilter -with-openssl=/usr/include/openssl/

make

make install

2. Danach überprüft man, ob Squid nun SSl inkludiert hat.
squid -v

3. Nun macht man sich an die Configfile

Hier habe ich verschiedene Methoden gefunden ich hoffe das jemand nun dort Erfahrung hat und mir vielleicht noch helfen kann.

ein configfile das vielversprechend aussieht fand ich hier: http://wiki.squid-cache.org/ConfigExamples/Reverse/ExchangeRpc

# Publish the RPCoHTTP service via SSL
https_port ip_of_squid:443 accel cert=/path/to/clientcertificate defaultsite=rpc_domain_name

cache_peer ip_of_exchange_server parent 443 0 no-query originserver login=PASS ssl sslcert=/path/to/certificate name=exchangeServer

acl EXCH dstdomain .rpc_domain_name

cache_peer_access exchangeServer allow EXCH
cache_peer_access exchangeServer deny all
never_direct allow EXCH

# Lock down access to just the Exchange Server!
http_access allow EXCH
http_access deny all
miss_access allow EXCH
miss_access deny all

und eine andere hier: http://www.unixboard.de/vb3/showthread.php?49100-Squid-proxy-f%FCr-rpc- ...

# Publish the RPCoHTTP service via SSL
https_port Proxy_IP:443  accel cert=/etc/squid3/cert/zertifikat.pem defaultsite=exchange.domain.de
cache_peer Exchange_IP parent 443 0 no-query originserver login=PASS ssl sslflags=DONT_VERIFY_PEER ssl sslcert=/etc/squid3/cert/Zertifikat.pem  name=exchangeServer
#cache_peer Exchange_IP parent 80 0 no-query originserver login=PASS front-end-https=on name=exchangeServer

acl localhost src 127.0.0.1/255.255.255.255
acl local src Netzwerk/255.255.255.0
acl to_localhost dst 127.0.0.0/8

#zugriff auf folgende URLs Erlauben, EXCH dient nur als frei wählbarer Parameter
acl EXCH url_regex -i ^https://exchange.domain.de/rpc/rpcproxy.dll.*$
acl EXCH url_regex -i ^https://exchange.domain.de/exchange.*$
acl EXCH url_regex -i ^https://exchange.domain.de/exchweb.*$
acl EXCH url_regex -i ^https://exchange.domain.de/owa.*$
acl EXCH url_regex -i ^https://exchange.domain.de/Microsoft-Server-ActiveSync.*$
acl EXCH url_regex -i ^https://exchange.domain.de/ecp.*$
acl EXCH url_regex -i ^https://exchange.domain.de/public.*$
acl EXCH url_regex -i ^https://exchange.domain.de/cert.*$

cache_peer_access exchangeServer allow EXCH
cache_peer_access exchangeServer deny all
never_direct allow EXCH

# Zugriffe für Parameter EXCH
http_access allow EXCH
http_access deny all
miss_access allow EXCH
miss_access deny all

#erweitertes Logging
debug_options ALL,1 33,2

Ok wie oben beschrieben gibt in dieser Konstellation der IIS vom Exchange das SSL Zertifikat vor. Damit haben wir 3 Zertifikate beim Server

root.cert
CA.cert
Client.cert

wenn man sich jetzt oben das configfile ansieht denkt man als erstes "ok ich muss nun das CA & Client.cert auf dem Squid hochladen und die Pfade angeben."

Das habe ich dann auch gemacht. Eine Abfrage vom Client mit Outlook gestartet. Sehe auf dem Router auch die eingehende Verbindung, jedoch leitet der Squid die Anfrage nicht weiter.

Dann habe ich nochmal recherchiert und bin auf die o.g. Methode gestoßen "Connect Method". Also das der Squid gar nichts mit den Zertifikaten an sich zu tun hat und im Grunde nur die Pakete an den Exchange durchreicht ohne dabei zu cachen bzw. zu loggen. (wäre mir auch nicht wichtig)
Im Grunde soll der Squid nur als Schutzschild dienen, damit der Exchange nicht das erste Glied der Kette ist.

Folgender Foren Beitrag hat mir dann die Connect request Methode gezeigt. http://debianforum.de/forum/viewtopic.php?t=65898

Squid also supports these encrypted protocols by ``tunelling'' traffic between clients and servers. In this case, Squid can relay the encrypted bits between a client and a server.

Normally, when your browser comes across an https URL, it does one of two things:

The browser opens an SSL connection directly to the origin server.
The browser tunnels the request through Squid with the CONNECT request method.

The CONNECT method is a way to tunnel any kind of connection through an HTTP proxy. The proxy doesn't understand or interpret the contents. It just passes bytes back and forth between the client and server.

Alles klar nun will ich diese Connect Request Methode testen und hoffe dort mehr Erfolg zu haben. Wenn jemand in der Lage ist mir hier zu helfen wäre ich ihm sehr dankbar. Ich werde auch gerne nach der erfolgreichen Arbeit ein PDF in diesem Forum hochladen das dann alles von Installation bis zur Configfile beschreibt, damit dann alle deutschen Admins die sowas machen wollen etwas davon haben.

Wie gesagt für weitere Hilfe bin ich sehr dankbar!

keine eine Idee? Ich brauche speziell eine kurze Erklärung für die Authentifizierung. Also muss ich NTLM nutzen? Oder muss der Squid sein eigenes Zertifikat haben?

Moin,
wenn es dir zu lansagem geht hast du zwei Möglichkeiten.

a) anderes Forum
b) TMG kaufen

Wir sind hier nicht beim kostenlosen Systemhaus support. Wir haben alle noch ein Hobby das uns 8-12 Stunden jeden Tag in Anspruch nimmt und selbst vllt. ein Proble zu lösen!

WArum hast du nochmal von vorne angefangen? Oben schreibst du das es funktioniert.

Grüße,
Dani

war eigentlich eher ein Push auf den Thread und kein Gehetze...

Ich habe oben geschrieben das es laut der Quelle funktioniert. Jedoch ist die Konstellation eine ganz andere dort (mit Apache als Webproxy dahinter)

Das einzige Problem was ich momentan noch habe ist die Fehlermeldung "Failed to acquire SSL certificate '/etc/squid3/cert/zertifitkat.cer' : error: 0906d06c:PEM routines:PEM_red_bio:no start line

Vielen Dank!

Liebe Grüße zurück!