Nun bin ich endlich auf die Lösung gestoßen. Beim Mozilla Firefox ist es erforderlich, die Konfigurationseinstellung “security.enable_ssl2” zu aktivieren. Dazu gibt ruft man im Browser die Adresse “about:config” auf und gibt im Filter “security.enable_ssl2″ ein. In der rechten Spalte der entsprechenden Zeile steht der aktuelle Wert der Option (“false”). Durch einen Doppelklick auf die Zeile oder durch Auswählen der Aktion “Umschalten” im Kontextmenü der Maus wird die Option aktiviert (“true“).

Nach einem Neustart des Browsers sollte die Verbindung mit dem VMware-Webinterface wieder möglich sein. Die gelegentlich auftretenden Anzeige-Probleme bleiben zwar bestehen, aber die lästigen Verbindungsabbrüche scheinen damit beseitigt zu sein. Für die Rest kann ich empfehlen, im Fehlerfall den Cache des Browsers zu löschen.

Preface:

Ich betreibe u.a. einen DHCP-Server, einen Proxy-Server und einen Webserver.
Was liegt also näher, als diese drei Dienste miteinander zu koppeln, mit dem Ziel, die Information “Proxy-Server” automatisch zu verteilen, anstatt jedem Browser und jedem System im Netzwerk manuell einen Proxy-Server einzutragen. Außerdem betreibe ich auf verschiedenen Systemen “netz-interne” Webserver, die ich direkt aufrufen möchte, ohne den Proxy zu verwenden.

Hier also die Beschreibung des Zusammenspiels:

Ich arbeite hier mit Diensten unter Linux. Das Ergebnis (die automatische Verteilung der Proxy-Konfiguration) funktioniert für Linux und Windows. Möglicherweise bzw. bestimmt funktioniert das auch für den Mac, aber ich mache hier keine Aussagen zu etwas, das ich nicht selbst getestet habe.

Ziel:

• Verwendung eines Proxy-Servers für alle oder ausgewählte Systeme/Browser
• Subnetz-abhängige Verwendung des Proxy-Servers

Voraussetzungen:

• Linux-System (z.B. openSUSE)
• DHCP-Server (ISC)
• Proxy-Server (z.B. Squid)
• Webserver (z.B. Apache)

Wie diese Voraussetzungen geschaffen werden, ist nicht Teil dieser Anleitung. Ich gehe davon aus, dass diese Dienste eingerichtet sind und funktionieren. Mein Webserver heißt “wpad.mein.privates.netz.de” und der Proxy-Server läuft auf Port 3128 und trägt den Namen “proxy.mein.privates.netz.de”.

Erstellung der WPAD-Datei:

Diese Datei enthält einen “Fahrplan” für den Browser, damit er entscheiden kann, ob und wenn ja, welchen Proxy-Server er verwenden soll. Eine genaue Beschreibung des Aufbaus und der Funktionen einer WPAD-Datei findet sich hier.

Meine sieht folgendermaßen aus:

Das bedeutet: kein Proxy für den eigenen Rechner und kein Proxy für Webserver im eigenen Subnetz.

Diese Datei unter dem Namen “wpad.dat” (case-sensitive) auf dem Webserver abgelegt. Wichtig ist an dieser Stelle, dass die Datei direkt im Web-Root und nicht in einem Unterverzeichnis liegt

Konfiguration des DHCP-Servers:

Ich verteile den Proxy-Verweis für das gesamte Subnet, wer möchte, kann das natürlich auch anders (z.B. pro Host) machen.

Hier die Auszüge aus der /etc/dhcpd.conf:

Ganz besonders wichtig ist das Leerzeichen bei der Pfadangabe “…/wpad.dat ”.

Es existiert unter Umständen das Problem, dass der Internet Explorer beim Verarbeiten des Pfades das letzte Zeichen abschneidet und so die Datei nicht mehr gefunden werden kann. Das Leerzeichen am Ende stellt also einen Workaround dar.

Da nicht alle Browser die DHCP-Optionen abfragen können, ist es sinnvoll, im Nameserver einen Host namens “wpad” anzulegen, dessen Webserver die WPAD-Datei bereitstellt. Somit können “DHCP-unfähige” Browser dennoch eine Proxy-Konfiguration beziehen, denn der Hostname “wpad” wird dabei als Standard verwendet. Leider ist es mit dieser Variante nicht möglich, für Subnetze oder gar einzelne Hosts verschiedene WPAD-Dateien anzubieten. Der gemeinsame Nenner wäre hier das Domain-Suffix des Clients.

Ich habe mittels Wireshark zwei bei mir installierte Browser überprüft:
Der Internet Explorer 7 lässt sich Lease-Informationen vom DHCP-Server geben, um dort die entsprechende WPAD-Option zu erhalten, falls gesetzt. Der Firefox 2.0.0.8 sucht nach einem Gerät mit dem Namen “wpad” im Netz. Dabei werden die auf dem lokalen PC eingetragenen DNS-Suchsuffixe nacheinander abgearbeitet.

Browser-/Systemkonfiguration:

Nun muss dem Browser / dem System nur noch beigebracht werden, dass er die Proxy-Einstellungen automatisch beziehen soll. Im Internet-Explorer wird das über das Aktivieren der Option “Automatische Suche der Einstellungen” bei “Extras -> Internetoptionen… -> Verbindungen -> LAN-Einstellungen” erledigt. Beim aktuellen Firefox geschieht das über “Einstellungen -> Erweitert -> Netzwerk -> Einstellungen (Verbindung) -> Die Proxy-Einstellungen für dieses Netzwerk automatisch erkennen”.

Nachdem DHCP-Server und Browser neu gestartet wurden, kann man nun überprüfen, ob alles wie erwartet funktioniert. Der erste Schritt wäre, eine beliebige URL aufzurufen und im Webserver-Log zu überprüfen, ob die Datei “wpad.dat” erfolgreich vom surfenden Rechner abgerufen wurde. Ist das der Fall, kann man nun anhand des Proxy-Logfiles erkennen, ob der Proxy oder eine direkte Verbindung vom Browser genutzt wird. Dazu werden einfach interne und externe URLs aufgerufen.

Wichtiger Hinweis: Wenn die WPAD-Datei nicht abgerufen werden konnte, arbeiten Mozilla, Firefox und Internet-Explorer stillschweigend mit einer direkten Verbindung.

Nachwort:

Falls jemand diese Anleitung gebrauchen kann/konnte oder einen Fehler gefunden hat, würde ich mich über ein Feedback freuen.

UPDATE:

Bei Problemen mit WPAD und RSS-Feeds könnte eventuell diese Seite helfen.