Squid, Apache und andere Proxy Server mit OWA

Zwar ist der Marktanteil des ISA-Servers schon recht hoch aber sehr viele Firmen setzen andere Proxy Systeme für den Zugriff auf das Internet und die Veröffentlichung von Webseiten ein. für den Outlook Webzugriff sind auch hier einige "Besonderheiten" zu beachten.

  • Link zu Apache als Reverse Proxy
  • OWA URL - URLs die von OWA und anderen Dienste genutzt werden.

Was tut ein Proxy

Die meisten Personen können HTTP nur als Protokoll zwischen dem Browser und einem Webserver und ein Proxy vermittelt zwischen den beiden Welten. Ganz so einfach ist es aber nicht, da mittlerweile Proxy Server an verschiedenen Stellen eingesetzt werden und die Kommunikation kontrollieren, filtern und absichern. Proxy Server können sowohl auf dem Weg vom Client in das Internet in ausgehender Richtung arbeiten als auch einen Webserver vor unerwünschten Zugriffen aus dem Internet sichern. Aber auch in umgekehrter Richtung als "Reverse Proxy" kann ein Proxy Server effektive Arbeit leisten

Die Hauptaufgaben eines Proxy Server sind daher

  • Authentifizierung
    Speziell in der ausgehenden Richtung kann der Zugriff auf bestimmte Personenkreise beschränkt werden. Aber auch in eingehender Richtung ist es oft der Fall, dass ein Proxy eine vorgelagerte Anmeldung erfordert, (z.B.:  auch mit Tokens), ehe der Zugriff auf das interne Netz erfolgen kann
  • Filterung
    Eine zweite wichtige Funktion ist die Filterung unerwünschter Inhalte. So kann eine Firma damit steuern, welche Webseiten die Mitarbeiter ansurfen dürfen bzw. welche Inhalte angezeigt oder herunter geladen werden dürfen.
    In eingehenden Richtung als Reverse Proxy  kann der Server als Filter für unerwünschte URL-Anfragen (z.B.: nach (/cgi-bin) oder andere URLs dienen, die auf dem internen Webserver zwar vorhanden sind aber nicht von extern erreicht werden dürfen.
  • Caching
    Ein Proxy Server kann in beide Richtungen zumindest statische Inhalte (Bilder, JavaScript-Dateien (js), StyleSheets (css) zwischenspeichern und damit in ausgehender Richtung die Internet Leitung entlasten (Traffic) und in eingehender Richtung den Webserver von diesen Anfragen entlasten.
  • Logging und Accounting
    Eine wichtige Funktion ist natürlich die Protokollierung der Zugriffe und eine dadurch mögliche Analyse des Nutzungsverhaltens bzw. auch eine Abrechnung der Nutzung.
  • Virtualisierung und Rerouting
    Zuletzt kann ein Proxy Server natürlich sogar einzelne URLs auf verschiedene Webserver verteilen. So kann z.B. aus dem Internet einfach "https://portal.firma.tld" veröffentlicht werden und abhängig von der Anmeldung und entsprechender Pfade werden die Daten zu verschiedenen Webservern verteilt. Nebenbei spart dies auch IP-Adressen im Internet und es reicht ein SSL-Zertifikat.

HTTP-Protokolle und Verben

Nun funktioniert HTTP eigentlich ganz einfach und einem SMTP-Prototokoll sehr ähnlich. Der Client verbindet sich per TCP auf den Port 80 oder 443 und stellt seine Anfrage. z.B.: ein "GET /" und der Webserver antwortet mit den Daten.

Nur allein ein "GET" reicht natürlich nicht für Outlook Webaccess. Um Daten zu senden wird oft der Befehl "POST" verwendet. Aber OWA nutzt noch einiges mehr. All das ist in RFCs und HTTP-Protokollen definiert.

Für einen Proxy und andere Firewalls ist es damit natürlich erforderlich, die von OWA verwendeten Erweiterungen auch zu unterstützen. Ansonsten wird OWA nicht oder nur mit eingeschränktem Funktionsumfang funktionieren

OWA und HTTP 1.x

Was nun genau OWA nutzt beschreibt Microsoft in seinen Dokumentationen sehr ausführlich. Da solche Verben auch im Rahmen einer Sicherung des Webservers mit URLSCAN blockiert werden können, ist der folgende Artikel zielführend:

  • 309508 IIS lockdown and URLscan configurations in an Exchange environment

Demnach gilt für den Zugriff auf OWA

  • Richtlinien für die URLs
    AllowHighBitCharacters=1
    AllowDotInPath=1
  • Erforderliche Verben
    [AllowVerbs]
    GET, POST
    SEARCH, POLL, SUBSCRIBE
    BMOVE, BCOPY, MOVE
    PROPFIND, PROPPATCH, BPROPPATCH
    DELETE, BDELETE, MKCOL

Und genau die Protokolle muss der Proxy auch durchlassen, damit Sie mit den Internet Explorer den "Rich OWA" erreichen können. Ansonsten sieht ihr OWA vielleicht so verstümmelt aus:

Für den Notfall können Sie aber mit OWA Formbased den "Classic-Mode" aktivieren. Dann nutzt Outlook einfach nur Standard HTTP ohne erweiterten Verben. Bei fremden Browsern erkennt OWA anhand des "User-Agent" ob der Client ein Internet Explorer ist und entsprechend auf den "Classic OWA" zurückschaltet.

Squid Proxy Server

Squid ist quasi ein Standard als Proxy Server und wird sehr breit eingesetzt. Damit ist Squid natürlich auch der häufigste Kandidat für Probleme beim Zugriff auf OWA oder der Veröffentlichung von OWA. Ich bin nun kein SQUID-Experte aber oftmals reicht schon folgende Tabelle über die Leistung von Squid:

Quelle: http://www.squid-cache.org/Doc/FAQ/FAQ.html#toc6.9 

6.9 Request methods
Squid recognizes several request methods as defined in RFC 2616.
Newer versions of Squid (2.2.STABLE5 and above) also recognize RFC 2518 ``HTTP Extensions für Distributed Authoring -- WEBDAV'' extensions

 method    defined    cachabil.  meaning
 --------- ---------- ---------- -------------------------------------------
 GET       HTTP/0.9   possibly   object retrieval and simple searches.
 HEAD      HTTP/1.0   possibly   metadata retrieval.
 POST      HTTP/1.0   CC or Exp. submit data (to a program).
 PUT       HTTP/1.1   never      upload data (e.g. to a file).
 DELETE    HTTP/1.1   never      remove resource (e.g. file).
 TRACE     HTTP/1.1   never      appl. layer trace of request route.
 OPTIONS   HTTP/1.1   never      request available comm. options.
 CONNECT   HTTP/1.1r3 never      tunnel SSL connection.

 ICP_QUERY Squid      never      used für ICP based exchanges.
 PURGE     Squid      never      remove object from cache.
 PROPFIND  rfc2518    ?          retrieve properties of an object.
 PROPATCH  rfc2518    ?          change properties of an object.
 MKCOL     rfc2518    never      create a new collection.#
 COPY      rfc2518    never      create a duplicate of src in dst.
 MOVE      rfc2518    never      atomically move src to dst.
 LOCK      rfc2518    never      lock an object against modifications.
 UNLOCK    rfc2518    never      unlock an object.

Also sollten Sie zum einen dafür sorgen, dass Sie einen möglichst aktuellen Squid einsetzen und natürlich die für Exchange relevante Verben auch frei schalten. Eine Gute Quelle nach Fehlern zu suchen ist die "cache.log" von Squid.

2005/03/11 09:28:21| parseHttpRequest: unsupported method 'SEARCH'
2005/03/11 09:28:21| clientReadRequest: FD 12 Invalid Request
2005/03/11 09:28:21| parseHttpRequest: unsupported method '<searchrequest'
2005/03/11 09:28:21| clientReadRequest: FD 12 Invalid Request
2005/03/11 09:28:21| clientSendMoreData: Deferring

Hier sehen Sie auf jeden Fall die geblockten Befehle, die SQUID noch nicht erlaubt. Die Konfiguration sollten Sie dann in der "squid.conf" entsprechend unter "extension_methods directive" anpassen.

extension_methods SEARCH SUBSCRIBE

Angeblich können Sie hier nur bis zu 20 Verben angeben. Zudem enthalten neuere Squid-Versionen oftmals schon weitere Verben als Voreinstellung. Mein Ratschlag ist daher in der CACHE.LOG die Fehler anzuschauen und entsprechend die erforderlichen Verben zu addieren.

SSL oder alternativer Port

Sehr viele Proxy Server lassen sich oft dadurch überlisten, dass der Webserver auf einem anderen Port betrieben oder SSL eingeführt wird. Entsprechend lassen einige Proxy Server dann alle Befehle transparent durch, da es sich anscheinend nicht um echten HTTP-Verkehr für den Abruf von Webseiten handelt.

Die Umschaltung auf SSL beruht darauf, dass der Proxy dann nicht die eigentlichen Daten sieht, sondern diese mit einem "CONNECT"-Befehl am Proxy verschlüsselt durchgegeben werden. Dies funktioniert aber dann nicht mehr, wenn der Proxy die SSL-Verbindung aufbricht und als SSL-Gateway arbeitet.

Loadbalancer als Reverse Proxy

Auch ein Loadbalancer kann, richtig konfiguriert, als Reverse Proxy angesehen werden. Ein richtiger Loadbalancer muss auch HTTPS auf Layer 7 annehmen und auf nachgelagerte HTTPS-Server verteilen können. Das Aufbrechen der HTTPS-Verbindung ist erforderlich, damit der Loadbalancer z.B. anhand der Anmeldedaten, Cookies o.ä. den Client bzw. die Verbindung identifizieren kann. Und ein Reverse Proxy ist eine sehr ähnliche Funktion. Und mittlerweile entwickeln sich die Loadbalancer weiter und erlauben schon Preauthentication etc.

Links