2
Frage zu einer Konfiguration im HAProxy
Moin,
ich versuche herauszufinden, was diese 3 Regeln im HAProxy zu bedeuten haben.
Welcher Sinn steckt dahinter?
In vielen Konfigurationen sieht man diese Einträge.
Hier ein Beispiel einer Konfig:
acl clienthello req_ssl_hello_type 1
acl serverhello rep_ssl_hello_type 2
stick on payload_lv(43,1) if clienthello
ich versuche herauszufinden, was diese 3 Regeln im HAProxy zu bedeuten haben.
Welcher Sinn steckt dahinter?
In vielen Konfigurationen sieht man diese Einträge.
Hier ein Beispiel einer Konfig:
acl clienthello req_ssl_hello_type 1
acl serverhello rep_ssl_hello_type 2
stick on payload_lv(43,1) if clienthello
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 583590
Url: https://administrator.de/forum/frage-zu-einer-konfiguration-im-haproxy-583590.html
Ausgedruckt am: 22.12.2024 um 20:12 Uhr
2 Kommentare
Neuester Kommentar
In den 3 Zeilen stecken mehrere Dinge.
Das "acl" bedeutet "Access Control List", das "clienthello" ist sowas wie der Name dieser Liste. req_* und rep_* sind von HAproxy vordefinierte Funktionen, die eine Ganzzahl zurückgeben. Bei "req_*" wird geprüft, ob der Client eine komplette sogenannte "SLL hello message" gesendet hat.
Dss "rep_*" fragt den Server dazu ab.
Normalerweise liefern diese Funktionen dann 0 (kein SSL), 1 (TLS SessionTicket vorhanden) oder 2 (TLS SessionTicket ist "ausgefüllt").
Die "payload"-Zeile macht auch wieder mehrere Dinge:
Die Anweisung bzw. Funktion "payload_lv(43,1)" lädt quasi aus dem empfangenen Puffer der SSL-Daten einen Teil - ab Offset 43 ein Byte. Das "stick" ist u.a. für ein Loadbalancing verantwortlich. Damit wird ein Anwender, z.B. Webbrowser, einem Server zugeordnet. Die Option "stick" ist ziemlich komplex in der Anwendung.
Übersetzt würden die drei Zeilen in etwa bedeuten:
Wenn der Client ein TLS SessionTicket überträgt, dann nimm das 43. Byte aus dem Puffer und benutze es, um darüber den einen Client immer mit dem einen Server zu verbinden. Oder so ähnlich.
Ich hab auch nicht alles von HAproxy verstanden - ist eine eigene Welt
Du findest aber irgendwo immer Beispiele, wenn Du danach suchst. Oder nimm halt die Anleitung, z.B. unter https://cbonte.github.io/haproxy-dconv/2.2/configuration.html
Und - aus meiner Sicht das Wichtigste: VIELE haproxy.cfg, die man im Internet findet, sind "Copy&Paste". Die pflanzen sich gerne so fort und werden immer wieder und wieder kopiert, ohne dass diejenigen, die sie nutzen, tatsächlich alles verstehen.
Bei HAproxy empfiehlt es sich, mit einer kleinen, leeren haproxy.cfg anzufangen, um es zu lernen. Und dann nach und nach die benötigten Optionen nachzuziehen.
Das "acl" bedeutet "Access Control List", das "clienthello" ist sowas wie der Name dieser Liste. req_* und rep_* sind von HAproxy vordefinierte Funktionen, die eine Ganzzahl zurückgeben. Bei "req_*" wird geprüft, ob der Client eine komplette sogenannte "SLL hello message" gesendet hat.
Dss "rep_*" fragt den Server dazu ab.
Normalerweise liefern diese Funktionen dann 0 (kein SSL), 1 (TLS SessionTicket vorhanden) oder 2 (TLS SessionTicket ist "ausgefüllt").
Die "payload"-Zeile macht auch wieder mehrere Dinge:
Die Anweisung bzw. Funktion "payload_lv(43,1)" lädt quasi aus dem empfangenen Puffer der SSL-Daten einen Teil - ab Offset 43 ein Byte. Das "stick" ist u.a. für ein Loadbalancing verantwortlich. Damit wird ein Anwender, z.B. Webbrowser, einem Server zugeordnet. Die Option "stick" ist ziemlich komplex in der Anwendung.
Übersetzt würden die drei Zeilen in etwa bedeuten:
Wenn der Client ein TLS SessionTicket überträgt, dann nimm das 43. Byte aus dem Puffer und benutze es, um darüber den einen Client immer mit dem einen Server zu verbinden. Oder so ähnlich.
Ich hab auch nicht alles von HAproxy verstanden - ist eine eigene Welt
Du findest aber irgendwo immer Beispiele, wenn Du danach suchst. Oder nimm halt die Anleitung, z.B. unter https://cbonte.github.io/haproxy-dconv/2.2/configuration.html
Und - aus meiner Sicht das Wichtigste: VIELE haproxy.cfg, die man im Internet findet, sind "Copy&Paste". Die pflanzen sich gerne so fort und werden immer wieder und wieder kopiert, ohne dass diejenigen, die sie nutzen, tatsächlich alles verstehen.
Bei HAproxy empfiehlt es sich, mit einer kleinen, leeren haproxy.cfg anzufangen, um es zu lernen. Und dann nach und nach die benötigten Optionen nachzuziehen.
1
Moin yoppi1,
erst mal vielen Dank für deine ausführliche Antwort. Ich denke, du hast mir weitergeholfen.
Ich hatte natürlich schon vorher und auch nach dem Einstellen dieser Frage nochmal intensiv geforscht.
Das hatte ich bis jetzt herausgefunden:
Zu den ersten beiden Zeilen:
acl clienthello req_ssl_hello_type 1
acl serverhello rep_ssl_hello_type 2
Um das zu verstehen, muss man sich erst einmal mit dem Thema TLS beschäftigen.
Zuerst sendet der Client ein Hallo (clienthello) an den Webserver, mit dem er kommunizieren möchte.
Der Server sendet ebenfalls ein Hallo (serverhello) mit einem SSL-Zertifikat und einem öffentlichen Schlüssel.
Mit der ersten Regel wird abgefragt, ob der Client ein clienthello sendet.
Mit der zweiten Regel wird überprüft, ob der Server ein serverhello gesendet hat.
Zuerst wusste ich nicht, was man mit diesen Informationen anfangen kann. Ich könnte mir vorstellen, dass man sich
diese Abfrage zu Nutze macht, damit erkennen kann, ob der Client eine http-seite aufruft (kein clienthello) oder
eine https-Seite. Würde der Client eine http-Seite aufrufen, könnte man den Client auf den richtigen Backend
umleiten oder gleich auf https umleiten.
Bei der Abfrage serverhello kann ich ja feststellen,ob der Webserver überhaupt SSL kann. Vielleicht kann man hier
feststellen, dass der SSL-Datenverkehr dann wirklich funktioniert.
Bei der dritten Zeile glaube ich ungefähr zu wissen, was da passiert.
stick on payload_lv(43,1) if clienthello
Hier glaube ich, dass diese Zeile dazu dient, dass sich der Client nach einem Abbruch wieder mit dem gleichen Server
verbindet. Hier liegt nämlich beim Offset von 43, also ab 44 die Session-ID. Wenn ein Client sich wieder mit dem
Server verbinden will, dann sendet der Client eine Session-ID mit. Der Server überprüft das in seiner Tabelle.
Findet er den Wert, wird die Verbindung wiederhergestellt. Der TLS-Handshake findet nur verkürzt statt.
Naja un der Begriff sticky oder stick lautet ja übersetzt klebrigkeit.
Derzeit versuche ich die Parameter "on" und "match" bei stick zu unterscheiden. Das muss ich mir noch genau durchlesen.
Somit wäre das auch mein Kenntnisstand, so wie du mir diese 3 Regeln auch beschrieben hast. Dann dürfte das wohl passen.
Wobei bestimmt die meisten Leute wahrscheinlich nicht wissen, was jede Zeile wirklich macht.
Eine gute Idee. Das werde ich mal machen. Damit kann man gut jede Zeile einzeln testen.
Vielleicht noch ergänzend: Auf dieses Buch bin ich bei meinen Recherchen gekommen:
https://books.google.de/books?id=vzIeBgAAQBAJ&printsec=frontcover&am ...
Ich finde das sehr gut. Vielleicht kaufe ich mir das. Ist auch nicht teuer.
Der HAproxy ist ein spannendes Projekt, bei dem man viele Arbeitsstunden versenken kann.
Vielleicht wird da mal noch eine weitere Frage kommen.
erst mal vielen Dank für deine ausführliche Antwort. Ich denke, du hast mir weitergeholfen.
Ich hatte natürlich schon vorher und auch nach dem Einstellen dieser Frage nochmal intensiv geforscht.
Das hatte ich bis jetzt herausgefunden:
Zu den ersten beiden Zeilen:
acl clienthello req_ssl_hello_type 1
acl serverhello rep_ssl_hello_type 2
Um das zu verstehen, muss man sich erst einmal mit dem Thema TLS beschäftigen.
Zuerst sendet der Client ein Hallo (clienthello) an den Webserver, mit dem er kommunizieren möchte.
Der Server sendet ebenfalls ein Hallo (serverhello) mit einem SSL-Zertifikat und einem öffentlichen Schlüssel.
Mit der ersten Regel wird abgefragt, ob der Client ein clienthello sendet.
Mit der zweiten Regel wird überprüft, ob der Server ein serverhello gesendet hat.
Zuerst wusste ich nicht, was man mit diesen Informationen anfangen kann. Ich könnte mir vorstellen, dass man sich
diese Abfrage zu Nutze macht, damit erkennen kann, ob der Client eine http-seite aufruft (kein clienthello) oder
eine https-Seite. Würde der Client eine http-Seite aufrufen, könnte man den Client auf den richtigen Backend
umleiten oder gleich auf https umleiten.
Bei der Abfrage serverhello kann ich ja feststellen,ob der Webserver überhaupt SSL kann. Vielleicht kann man hier
feststellen, dass der SSL-Datenverkehr dann wirklich funktioniert.
Bei der dritten Zeile glaube ich ungefähr zu wissen, was da passiert.
stick on payload_lv(43,1) if clienthello
Hier glaube ich, dass diese Zeile dazu dient, dass sich der Client nach einem Abbruch wieder mit dem gleichen Server
verbindet. Hier liegt nämlich beim Offset von 43, also ab 44 die Session-ID. Wenn ein Client sich wieder mit dem
Server verbinden will, dann sendet der Client eine Session-ID mit. Der Server überprüft das in seiner Tabelle.
Findet er den Wert, wird die Verbindung wiederhergestellt. Der TLS-Handshake findet nur verkürzt statt.
Naja un der Begriff sticky oder stick lautet ja übersetzt klebrigkeit.
Derzeit versuche ich die Parameter "on" und "match" bei stick zu unterscheiden. Das muss ich mir noch genau durchlesen.
Somit wäre das auch mein Kenntnisstand, so wie du mir diese 3 Regeln auch beschrieben hast. Dann dürfte das wohl passen.
Ich hab auch nicht alles von HAproxy verstanden - ist eine eigene Welt
Dann sind wir schon zu zweit! Wobei ich noch ergänzen muss, dass das Teil sehr mächtig ist.Und - aus meiner Sicht das Wichtigste: VIELE haproxy.cfg, die man im Internet findet, sind "Copy&Paste". Die pflanzen sich gerne so fort und werden immer wieder und wieder kopiert, ohne dass diejenigen, die sie nutzen, tatsächlich alles verstehen.
Stimme ich mit dir zu 100% überein. Man findet zu 90% nur 1:1 kopierte Anleitungen. Sogar die Kommentare sind überall gleich.Wobei bestimmt die meisten Leute wahrscheinlich nicht wissen, was jede Zeile wirklich macht.
Du findest aber irgendwo immer Beispiele, wenn Du danach suchst. Oder nimm halt die Anleitung, z.B. unter https://cbonte.github.io/haproxy-dconv/2.2/configuration.html
Diese Seite ist bei mir daueroffen!Bei HAproxy empfiehlt es sich, mit einer kleinen, leeren haproxy.cfg anzufangen, um es zu lernen. Und dann nach und nach die benötigten Optionen nachzuziehen.
Eine gute Idee. Das werde ich mal machen. Damit kann man gut jede Zeile einzeln testen.
Vielleicht noch ergänzend: Auf dieses Buch bin ich bei meinen Recherchen gekommen:
https://books.google.de/books?id=vzIeBgAAQBAJ&printsec=frontcover&am ...
Ich finde das sehr gut. Vielleicht kaufe ich mir das. Ist auch nicht teuer.
Der HAproxy ist ein spannendes Projekt, bei dem man viele Arbeitsstunden versenken kann.
Vielleicht wird da mal noch eine weitere Frage kommen.
