Archiv der Kategorie: Server

HTTP_X_FORWARDED_FOR

Da ich zurzeit diverse Logfiles durchgehe, fiel auf, dass in allen von apache geführten Logs als Remote-IP 127.0.0.1 auftaucht – die IP von haproxy. Da sich solche Logfiles jedoch immer komisch lesen, hätte ich gern eine andere IP-Adresse als Info.

haproxy liefert diese Informationen weiter, wenn man
option forwardfor
aktiviert.

Für Apache2 gibt es ein passendes Modul, dass genau diese Option umdreht, also den HTTP_X_FORWARDED_FOR header wieder in REMOTE_ADDR einsetzt, sodass keine weiteren Anpassungen in Scripten notwendig sind. Das Modul „rpaf“ installiert sich mit apt-get install libapache2-mod-rpaf und gut ist die Hexenparty gewesen.
Apache neustarten und siehe da, es zeigt wieder richtige IP-Adressen an.

Wer rpaf konfigurieren will: rpaf Config

haproxy einrichten

Die Einrichtung von haproxy ist „relativ“ leicht zu erledigen. Programm aus den Quellen installieren und konfigurieren.

Dabei gab es einige Komplikationen: zuerst einmal benötige ich für Tests Websockets, die von Apache aber nicht unterstützt werden. Diese lassen sich über mehrere Optionen in haproxy filtern und mit einer separaten Regel belegen, sodass sie direkt zum Websocket-Server durchgetunnelt werden. http://blog.silverbucket.net/post/31927044856/3-ways-to-configure-haproxy-for-websockets
Oder: http://blog.exceliance.fr/2012/11/07/websockets-load-balancing-with-haproxy/

Möchte man nun auch SSL verwenden, um die Verbindung zu verschlüsseln, kann man den Ansatz eines vorgeschalteten SSL-Proxies wie stunnel verwenden: http://afitnerd.com/2012/08/14/websockets-over-ssl-stunnel-haproxy-node-js/In einer aktuelleren Version von haproxy ist SSL aber schon implementiert. Die Version muss nur noch Compiliert werden. http://blog.exceliance.fr/2012/04/13/enhanced-ssl-load-balancing-with-server-name-indication-sni-tls-extension/ Diese Installation gestattet auch, verschiedene Zertifikate für unterschiedliche (Sub-)Domains zu verwenden.

Zum Debuggen und lesen der Logs muss noch Hand angelegt werden: http://linuxadminzone.com/enable-or-fix-logging-for-haproxy-load-balancer/

Als Ergebnis kam dann folgende Configdatei heraus: haproxy.cfg

Anmerkung: die pem-files der Zertifikate unterstützen es scheinbar, die Zertifikat-Chain in die Datei hineinzuschreiben in folgender Form:

  • Server certificate
  • Intermediate CA 1 certificate
  • Intermediate CA 2 certificate
  • Intermediate CA n certificate
  • Root CA certificate
  • Private key

Scheint aber nur bei dem default-Zertifikat genommen zu werden, bei allen anderen Zertifikatfiles wird der Chain (scheinbar) nicht beachtet.

Also für das Default-Zertifikat auf jeden Fall ein gültiges Zertifikat mit Chain hinterlegen.

Edit: Beim Einrichten weiterer Server mit Zertifikaten fiel auf, dass die Chain wohl doch pro File geprüft wird, warum auch immer es beim letzten Test ignoriert wurde. De Facto blockieren die meisten Programme, die mit nicht vollständig gültigem SSL-Zertifikat betrieben werden (also self-signed, keine vollständige Supply-Chain, …) und werfen stattdessen mit Fehlermeldungen über ungültige Zertifikate um sich.

Haproxy und WordPress

Die Einrichtung dieses Blogs war insoweit problematisch, dass ich Haproxy verwende um SSL zu erzwingen und gleichzeitig der Webserver eigentlich nichts von dem SSL mitbekommt.
Die Installation von WordPress bereitete anfangs Probleme, da ein Login durch einen permanenten Redirect zwischen Haproxy auf https und WordPress auf http unmöglich gemacht wurde.

Die Lösung dazu: einen Forward-Header setzen und in der WordPress-config das Server-Array manipulieren, dass es so aussieht als wäre https beim Apache angekommen.

Fundquelle: http://trick77.com/2012/12/01/prevent-ssl-redirect-loop-using-wordpress-and-haproxy/