pfSense, Squid, HAProxy und URL rewrite

Wie kann man mit pfSense und Squid einen URL rewrite bewerkstelligen.

Gestern kam noch eine Anforderung, dass via Reverseproxy noch ein URL Rewrite gemacht werden soll. Als Reverse setzten wir schon seit längerem auf pfSense mit Squid, welche bisher auch seinen Dienst mehr als genug erbracht hatte. Darüber schicken wir vom Filetransfersystem bis zur Applikation alles, damit kein Server mehr direkt mit Daten beladen in der DMZ stehen muss. Das spart vorallem öffentliche IPs, von denen es ja bekanntlich nicht mehr in allem Überfluss hat.

Die Anforderung grafisch gesehen sollte folgendes leisten:

01 request

 

Nun Squid selber könnte zwar URL Rewrites machen, aber unter dem Aspekt, dass das ganze noch via GUI administrierbar sein soll, muss hier ein anderer Weg eingeschlagen werden. Wenn es darum gehen würde vom Pfad / auf /service zu wechseln, würde ich einfach einen Redirect einrichten. Umgekehrt wird das hier jedoch ein wenig schwieriger.

Aber das Paket HAProxy bietet hier solche Rewrites und das ganze bleibt via GUI steuerbar, ohne das dazu in die configs eingegriffen werden muss, was für teils Leute nicht mehr ganz einfach ist. Der Workflow dazu sieht dann so aus:

02 workflow

Sprich der Datenverkehr wird von Squid an den HAProxy geschickt, welcher den Verkehr via Frontend aufnimmt und an den entsprechenden Backend weiterschickt.

Was wird auf Squid konfiguriert?

Hier mal den Peer, der zeigt auf die localhost-Adresse des Server und auf den zukünftigen Port. Kann man natürlich anders lösen, man muss einfach beachten, dass man keinen Portkonflikt verursacht.

03 squid peer 

Anschliessend das Mapping:

04 squid mappings

Bis hier ist alles ähnlich, ausser das der Peer auf den localhost zeigt.

Nun kommen wir zu den Einstellungen von HAProxy:

Da beginnen wir mit dem Backendserver:

05 haproxy back server

Der Backend zeigt am Schluss den definitiv zu erreichende Server, wo die Anfrage verschickt werden soll.

06 haproxy back health

Da HAProxy für Anwendungen im Bereich Hochverfügbarkeit ausgelegt ist, kann man den Backendserver prüfen, ob er erreichbar ist. In meinem Fall habe ich nicht auf eine HTTP Anfrage gesetzt, sondern über eine einfache Prüfung, ob der Socket geöffnet werden kann.

Nun weiter mit dem Frontend:

07 haproxy front server

Hier definieren wir nun die Annahmestelle, damit die Anfrage, welcher Squid an den localhost stellt, vom HAProxy entgegengenommen werden kann.

08 haproxy front acl

Und hier kommt nun genau das Interessante, die Definition, was mit der Anfrage passieren soll. Via ACL prüfen wir den Pfad, ob dieser mit /service startet, und wenn diese Bedingung eintrifft, wird unter Action definiert, dass der Pfad auf / gesetzt werden soll. Und damit ist wirklich gemeint, das ALLES ersetzt wird. Danach wird die Anfrage an den Backend verschickt, der vorher definiert wurde.

Wenn nur ein Teil davon ersetzt werden soll, kann man dies mit folgendem Parameter unter fmt erledigen: %[path,regsub(/service,/,g)]

Damit wird nur /service ersetzt durch / und die restliche URL bleibt stehen.

 

Wenn man nun HAProxy ein wenig weiter konfiguriert, kann man z.B. die HAProxy Statistikseite konfigurieren, damit man einen Überblick über die Anfrage erhält, oder via Mail verständigt wird, wenn die Statusüberwachung fehlschlägt und der Backend nicht mehr erreichbar ist, sofern man nicht bereits ein anderes Tool wie Icinga einsetzt.

 

Hier noch die Bildstrecke:

  • 01-request
  • 02-workflow
  • 03-squid-peer
  • 04-squid-mappings
  • 05-haproxy-back-server
  • 06-haproxy-back-health
  • 07-haproxy-front-server
  • 08-haproxy-front-acl

Drucken