HAproxy als Reverse Proxy

[jinn]

ich habe mich jetzt schon durch einige Beiträge hier im Forum und Netz geschlagen, leider habe ich aber meine Lösung noch nicht gefunden, daher versuche ich es nochmal mit einem eigenen Thread.

Folgende Ausgangslage: OPNSense 18.1.6 (LibreSSL)

WAN Netz: 86.167.153.104/29
.105 & .106 sind durch die Telekom blockiert, somit bleiben mir aktuell folgende IP Adressen:
86.167.153.107 (Zugang ins Internet funktioniert bereits)
86.167.153.108 (hierüber sollen zwei Websites erreicht werden, https://file.domain.com und https://wiki.domain.com)
86.167.153.109 (vorerst nicht benötigt)
86.167.153.110 (vorerst nicht benötigt)
(ich nutze bewusst nicht pro domain eine IP, da es sich hier um ein LAB handelt und wir später auch mehrere Domains pro IP haben)


Zugriff soll so ablaufen

Zugriff per Browser auf 86.167.153.108 per HTTPS (HTTP redirect HTTPS) -> OPNsense -> HAProxy -> Server (Port 80)


Folgendermaßen habe ich versucht den Zugriff einzurichten:
Firewall - Rules - WAN
Source *
Port *
Destination 86.167.153.108/29
Port 443

Source *
Port *
Destination 86.167.153.108/29
Port 80

Firewall - Virtual IPs - Settings
Virtual IP address 86.167.153.108/29
Interface WAN
Type IP Alias

HAProxy
Real Servers
Name file
FQDN or IP file.locale.lan
Port 80

Name wiki
FQDN or IP wiki.locale.lan
Port 80

Backend Servers
Enabled (x)
Mode: HTTP (Layer 7)
Servers: file
Rules: file-rule

Enabled (x)
Mode: HTTP (Layer 7)
Servers: wiki
Rules: wiki-rule

Public Services
Enabled (x)
Listen Addresses: file.domain.com:443 file.domain.com:80 86.167.153.108:443 86.167.153.108:80
Type: HTTP/HTTPS (SSL offloading)
Default Backend Pool: file
SSL Certificate: *.domain.com (gekauftes Wildcard Zertifikat)
Select Rules: file-rule

Enabled (x)
Listen Addresses: wiki.domain.com:443 wiki.domain.com:80 86.167.153.108:443 86.167.153.108:80
Type: HTTP/HTTPS (SSL offloading)
Default Backend Pool: wiki
SSL Certificate: *.domain.com (gekauftes Wildcard Zertifikat)
Select Rules: wiki-rule


Rules & Checks
Condition
Name: file-condition
Condition type: Host starts with
Host Prefix: file

Name: wiki-condition
Condition type: Host starts with
Host Prefix: wiki

Rules
Name: file-rule
Test type: IF
Select condition: file-condition
Execute function: Use specified Backend Pool
Use backend pool: file

Name: wiki-rule
Test type: IF
Select condition: wiki-condition
Execute function: Use specified Backend Pool
Use backend pool: wiki

Im Log erhalte ich nur folgende Mitteilung
haproxy[95545]: Connect from 1.2.3.4:21630 to 86.167.153.108:443 (wiki.domain.com/HTTP)

[BeNe]

Ich habe es in etwas so bei mir konfiguriert. Rules beim Backendserver raus und nur ein Frontend Server,
da es nur an eine IP-Adresse gebunden ist. Regeln dann auf den Frontend Server:

Backend Servers
Enabled (x)
Mode: HTTP (Layer 7)
Servers: file
Rules:

Enabled (x)
Mode: HTTP (Layer 7)
Servers: wiki
Rules:


Public Services
Enabled (x)
Listen Addresses: 86.167.153.108:443 86.167.153.108:80
Type: HTTP/HTTPS (SSL offloading)
Default Backend Pool: none
SSL Certificate: *.domain.com (gekauftes Wildcard Zertifikat)
Select Rules: file-rule wiki-rule


Rules & Checks
Condition
Name: file-condition
Condition type: Host matches
Host Prefix: file.domain.tld

Name: wiki-condition
Condition type: Host matches
Host Prefix: wiki.domain.tld

Rules
Name: file-rule
Test type: IF
Select condition: file-condition
Execute function: Use specified Backend Pool
Use backend pool: file

Name: wiki-rule
Test type: IF
Select condition: wiki-condition
Execute function: Use specified Backend Pool
Use backend pool: wiki

Wenn das dann klappt - können wir das HTTP -> HTTPS redirect angehen. Ist dann noch eine zusätzlich ACL.

[jinn]

Leider klappt es immer noch nicht

Ich habe bei der Condition auch mit "SNI TLS extension matches" getestet, leider hat auch das nicht funktioniert.

Im HAProxy Log bekomme ich nur folgenden Eintrag:
haproxy[69631]: Connect from 1.2.3.4:3514 to 86.167.153.108:443 (publicservice/HTTP)

Ich habe die Condition zum testen mal auf darauf geändert, dass die Source IP abgefragt wird und hier die externe IP vom Smartphone aus dem Telekom Netz eingetragen. Auch jetzt sehe ich im Log keinen anderen Eintrag.
Anscheinend wird die Regel in gar keiner Form abgefragt?
e: mein Fehler, der Haken bei SSL Offload war nicht gesetzt, jetzt wird es soweit aufgelöst, dass ich bei beiden Domains "/accounts/login?next=/" erhalte, also grundsätzlich die file-regel genommen wird (noch ist die match-ip condition aktiv, also kein problem) - im Log bekomme ich jetzt diesen Fehler:

1.2.3.4:4286 [12/Apr/2018:09:22:09.501] publicservice/86.167.153.108:80: SSL handshake failure

e: das wiki funktioniert! beim file springt er immer auf http anstatt https zu nutzen


Ein weiteres Problem bei der Konfiguration seh ich jetzt allerdings im letsencrypt plugin, dieses verlangt ja pro domain einen service (ggf kann es ja jetzt auch mit wildcard arbeiten, was passiert aber, wenn wir auch unterschiedliche Domains pro IP nutzen? (können wir glücklicherweise umgehen, dennoch wäre das in der Zukunft vlt ein Problem)

[BeNe]

Mit deinen Edit komme ich nicht so ganz klar.

e: das wiki funktioniert! beim file springt er immer auf http anstatt https zu nutzen

Das heißt, das es schon mal funktioniert da du zwischen wiki und file anfragen unterscheidest ?
Kann es sein das die WebAnwendung hinter file automatisch auf http umsetzt ?

Ein weiteres Problem bei der Konfiguration seh ich jetzt allerdings im letsencrypt plugin, dieses verlangt ja pro domain einen service (ggf kann es ja jetzt auch mit wildcard arbeiten, was passiert aber, wenn wir auch unterschiedliche Domains pro IP nutzen? (können wir glücklicherweise umgehen, dennoch wäre das in der Zukunft vlt ein Problem)

Verstehe die Frage nicht so ganz. Alle deine Zertifikate, für welche Domain auch immer, kommen auf den Frontend Server drauf. Mit einer IP kannst Du verschiedene Domains mit Zertifikaten laufen lassen.
Oder was meist du genau ?

[jinn]

Mit deinen Edit komme ich nicht so ganz klar.

e: das wiki funktioniert! beim file springt er immer auf http anstatt https zu nutzen

Das heißt, das es schon mal funktioniert da du zwischen wiki und file anfragen unterscheidest ?
Kann es sein das die WebAnwendung hinter file automatisch auf http umsetzt ?

Genau,

https://wiki.domain.com klappt
https://file.domain.com leitet um auf http://file.domain.com und landet dann natürlich in einem Fehler, woran das liegt weiß ich immer noch nicht - sieht aber eher nach extern aus, da die Anfrage bei HAproxy (laut log) bereits per Port 80 ankommt

Ein weiteres Problem bei der Konfiguration seh ich jetzt allerdings im letsencrypt plugin, dieses verlangt ja pro domain einen service (ggf kann es ja jetzt auch mit wildcard arbeiten, was passiert aber, wenn wir auch unterschiedliche Domains pro IP nutzen? (können wir glücklicherweise umgehen, dennoch wäre das in der Zukunft vlt ein Problem)

Verstehe die Frage nicht so ganz. Alle deine Zertifikate, für welche Domain auch immer, kommen auf den Frontend Server drauf. Mit einer IP kannst Du verschiedene Domains mit Zertifikaten laufen lassen.
Oder was meist du genau ?

Mein Fehler, habe bisher nicht wahr genommen, dass man pro Frontend Server mehrere Zertifikate nutzen kann und dieser dann das richtige nutzt
Auch bei dem LetsEncrypt Plugin bin ich weiter nachdem ich mir das mal genauer angesehen habe, die Freigabe von extern klappt zwar noch nicht, da bin ich aber dran.

Vielen dank bisher! Ich versuche jetzt erstmal die bisherigen Probleme zu beheben und kümmer mich am schluss dann noch um das redirect auf Port 443. Hatte dazu auch schon 1-2 Beiträge im Forum gefunden.


e: liegt vermutlich am Server dahinter, https://file.domain.com/ leitet weiter zu http://file.domain.com/accounts/login/?next=/

https://file.domain.com/accounts/login/?next=/ direkt klappt aber sofort

Nach dem einloggen geht es dann weiter nach http://file.domain.com/ und die Verbindung ist wieder weg. Mit https://file.domain.com/ komm ich dann aber rein >_<

[jinn]

Noch kurz, damit es auch komplett ist, die Konfiguration bzgl. redirect von port 80 auf 443, da ich hier noch eine Frage habe:

Public Service:
Kopie von der SSL Konfiguration (Diese hat nur noch 86.167.153.108:443 als Listen Addresses)

folgende Änderungen:
Listen Addresses: 86.167.153.108:80
Enable SSL offloading ( )  -   (nicht aktiviert)
Select Rules (redirect_acme_challenges; rul_http_redirect_to_https)

Condition
con_http_redirect_to_https
Condition type: SSL/TLS connection established
Negate condition (X)

Rules
rul_http_redirect_to_https
Test type: IF (default)
Select conditions: con_http_redirect_to_https
Logical operator: AND (default)
Execute function: http-request redirect
HTTP Redirect: scheme https code 301

Damit komme ich jetzt auch auf den file.domain.com obwohl dieser an irgendwelchen stellen immer wieder auf Port 80 wechselt (die Software dahinter wird sowieso schnellstmöglich ersetzt, daher lohnt sich der aufwand nicht da weiter zu prüfen)


Eine Frage habe ich jetzt allerdings noch, was passiert, wenn mehrere condition treffen?
z.B. redirect_acme_challenges und http_redirect_to_https (anfragen über das letsencrypt plugin kommen bisher immer über port 80 rein)
Bei meinem einzigen Test hat es zwar funktioniert, dass die condition vom Plugin genutzt wird, wie kann ich mir aber sicher sein, dass das immer passiert?

Die Reihenfolge scheint kein Indiz zu sein, da diese nach dem Alphabet sortiert wird.

e: Ein Zertifikat erneuern funktioniert Problemlos wenn beide Regeln aktiv sind. Will ich aber ein Zertifikat für eine neue Domain anfordern erhalte ich Fehlermeldungen.
Erst wenn ich die regel "rel_http_redirect_to_https" aus dem public_services entferne funktioniert es.