OPNsense Forum
International Forums => German - Deutsch => Topic started by: jinn on April 11, 2018, 05:51:36 pm
-
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)
-
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.
-
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)
-
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 ?
-
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 >_<
-
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.