Apache, PHP... Wordpress Installation

[Bob.Dig]

@Helge01 Weißt Du zufällig, ob ich den HAProxy auch lokal ansprechen kann und wenn ja wie, also wie der entsprechende DNS-Eintrag aussehen müsste.

 

[Helge01]

Ausschließlich lokaler Zugriff mit DNS Auflösung würde entweder über den DNS-Resolver oder DNS-Forwarder der pfSense funktionieren. Je nach dem was im Einsatz ist, gibt es den Punkt Host Overrides. Da einen neuen Eintrag erstellen und bei
Host: www
Domain: example.com
IP Address: IP-Ubuntu-Server
eingeben. Danach wird die Anfrage www.example.com mit deiner lokalen IP-Adresse vom Ubuntu Server überschrieben. Dann einfach die Virtual Hosts auf dem Server anpassen:

<IfModule mod_ssl.c>
        <VirtualHost *:443>

                ServerAdmin webmaster@localhost
                ServerName www.example.com
                DocumentRoot /var/www/webserver/

        <Directory /var/www/webserver/>
                Options -Indexes
                AllowOverride All
        </Directory>

                SSLEngine on

                SSLCertificateFile      /Pfad zum Zertifikat/cert.pem
                SSLCertificateKeyFile   /Pfad zum Private Key/privkey.pem

                ErrorLog ${APACHE_LOG_DIR}/error.log
                CustomLog ${APACHE_LOG_DIR}/access.log combined

                <FilesMatch "\.(cgi|shtml|phtml|php)$">
                                SSLOptions +StdEnvVars
                </FilesMatch>
                <Directory /usr/lib/cgi-bin>
                                SSLOptions +StdEnvVars
                </Directory>

        </VirtualHost>
</IfModule>

Nun kannst du über den Domainnamen direkt auf deine Wordpress Installation zugreifen. Zum Test ist diese Variante vielleicht auch besser geeignet, wenn alles funktioniert kann das dann leicht geändert werden (z.B. über HA-Proxy).

 

[Bob.Dig]

Na ja ich würde mich halt lokal mit HAProxy verbinden wollen, aber das hab ich nicht hinbekommen, wordpress hin oder her. Geht das überhaupt? Welche IP hat HAProxy. Mit dem Gateway hat es jedenfalls nicht geklappt.

 

[Helge01]

Der HA-Proxy hängt am WAN Interface, da ist nichts mit lokalem Zugriff. Dafür ist er auf der pfSense auch nicht gedacht. Ist natürlich falsch, ich habe es noch nie anders im Einsatz gehabt Du kannst natürlich unter Listen address das entsprechende Interface auswählen, die IP Adresse ist die des Routers der jeweiligen Schnittstelle. Du musst aber aufpassen das es kein Port Konflikt gibt, wenn das Webinterface der pfSense auch auf Port 443 lauscht. Eins von beiden musst du dann ändern.

Hab es mal auf der Testumgebung ausprobiert, es funktioniert. Gib da einfach unter Listen address - LAN address an, dann kannst du mit der LAN IP Adresse des Routers auf den HA-Proxy zugreifen. Fuktioniert der Rest, dann würdest du deine Webseite sehen. Damit es über den Domain Namen geht, müsstest du noch in deiner Hosts Datei vom PC einen Eintrag setzen, oder wie oben beschrieben über den Resolver / Forwarder.

 

[Bob.Dig]

Hab mal auf Any gestellt und hat funktioniert, danke @Helge01. Wäre die Umgehungslösung, wenn alles andere nicht funktionieren sollte. Werde mich jetzt mal rekursiv an den Rest machen. 😉

 

[Bob.Dig]

...

Habe mal alles eingetragen, bis auf die Änderung der Wordpress config, und es funktioniert garnix. 🤪
Sicher, dass wir auf der selben Version von HAProxy sind (haproxy net 0.59_19)?
Ich muss zugeben, ich verstehe die config auch nicht, was aber auch kein Wunder ist.
Lokal komme ich auf den unverschlüsselten Server. Von extern weder über http noch https.

 

[Helge01]

Es fehlt noch ein Eintrag im HA-Proxy. Diesen hatte ich nicht angegeben, da ich nicht wusste, welche Version von HA-Proxy du nutzt.
Dieser Eintrag gilt nur für die haproxy-devel Version. Diese ist auch der normalen Version vorzuziehen, da sie schon einige Jahre reibungslos Funktioniert und bessere Sicherheitsmaßnahmen mitbringt.

Neuer Eintrag für SharedFrontend für https
Name: SharedFrontend-https
Status: aktiv
External address: WAN address (IPv4) Port 443 sonst keine weiteren Angaben!
Typ: http / https (offloading)
Default Backend: kein
SSL Offloading: das SAN / Wildcard Server Zertifikat auswählen und Haken bei:
Add ACL for certificate CommonName. (host header matches the "CN" of the certificate)
Add ACL for certificate Subject Alternative Names
Advanced ssl options (gilt nur für haproxy-devel Version, sonst muss der Cipher Eintrag angepasst werden!)
alpn h2,http/1.1 ssl-min-ver TLSv1.2 ciphers EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH
Speichern

Ich habe es im Ursprünglichen Post mit eingetragen.

Wenn du die normale Version nutzen möchtest, dann versuche es erst mal mit dem Example Beispiel, auch wenn dieser nicht mehr zeitgemäß ist.
no-sslv3 ciphers EECDH+aRSA+AES:TLSv1+kRSA+AES:TLSv1+kRSA+3DES

 

[Bob.Dig]

Warum überhaupt SNI? Wenn ich doch eh in die Verbindung gucken kann, kann ich doch einfach die Adresse auslesen. Host matches ist doch eh alles was ich brauch oder? Dein Ansatz ist für mich vermutlich Overkill.
Ich werde noch mal ein eigenes Frontend machen, deine deaktivieren.

 

[Helge01]

WebserverSNI oder WebserverSubSNI ist ein von mir festgelegter Eintrag, der unter Access Control lists und Aktionen übereinstimmen muss, damit die Regel funktioniert. Das Sub steht für die Subdomain www und SNI für die Domain.

Wenn du Wordpress und Nextcloud über den HA-Proxy laufen lassen möchtest, kommst du um dieses Regelwerk nicht drum herum.

Eventuell würden Screenshots von deiner Konfig weiterhelfen.

 

[Bob.Dig]

Ich meine z.B. die Angabe der Ciphers (?) ist doch für eine Weiterleitung durch HAProxy nicht nötig? Ich werde meinen einfach HA-Proxy Setup anlegen aber dieses mal deine Wordpress Config nutzen, mal sehen ob das schon alles fixt, was ich an Problemen hatte. 😉

 

[Helge01]

Natürlich ist der Cipher wichtig, da dieser mit dem Zertifikat zusammen deine HTTPS Verbindung aufbaut.

Grundsätzlich ist es so, dass der HA-Proxy die HTTP/ HTTPS Verbindung zum Browser aufbaut. Dieser reicht diese Verbindung nicht einfach zum Apache auf deinem Server durch, sondern baut eine weitere Verbindung zu diesem auf. Diese kann dann verschlüsselt oder im Normalfall unverschlüsselt erfolgen.

 

[Bob.Dig]

Natürlich ist der Cipher wichtig, da dieser mit dem Zertifikat zusammen deine HTTPS Verbindung aufbaut.

Ok, vermutlich so sicherer aber defaultmäßig wird das vermutlich auch erst mal gehen.

Also die Verbindung timed jetzt immer out, egal ob http oder *s muss wohl ein größeres Problem sein, welches ich gerade nicht erkennen kann.

 

[Helge01]

Wenn beides nicht geht tippe ich auf die Verbindung vom HA-Proxy zum Apache. Ist dort auch die Virtual Hosts angepasst? Port wie im Backend 8080 und unverschlüsselt?

 

[Bob.Dig]

Nicht mal ein einfacher Port-Forward direkt auf den Server funktioniert, es macht keinen Spaß mehr.

 

[Helge01]

Sieht erstmal ok aus, erfolgt der Zugriff von Extern? Intern wird es ohne Änderung einer Einstellung im NAT nicht gehen.

Was passiert wenn du im intern im Browser http:// 192.168.1.127:8080 eingibst?

 

[Bob.Dig]

Ich kann von intern ohne Probleme zugreifen über Port 8080, von extern weiterhin kein Zugriff. Hab bisher aber noch gar kein Portmapping benutzt gehabt auf pfsense. Nicht, dass das auch noch komplizierter wäre als gedacht...

 

[Helge01]

Eigentlich müsste es gehen. Durch den NAT Eintrag wird auch eine Firewall Regel unter dem WAN Interface angelegt. Ist dieser korrekt? Es kann natürlich sein das der HA-Proxy und das NAT in die Quere kommen. Ändere testweise mal den Port vom NAT 80 zu 8080 ab und teste dann mal. Beides wird mit Sicherheit nicht gehen. Das liegt daran weil du als Interface Any eingestellt hast. Da lauscht der HA-Proxy auf allen Schnittstellen auf Port 80. Dadurch kann das NAT eigentlich nicht mehr funktionieren.

Sollte der Zugriff über NAT auch intern gehen, kannst du in der NAT Regel unter NAT Reflection "Aktivieren (Reines NAT)" einstellen. Das funktioniert zwar, ist aber eigentlich nicht der richtige Weg. Normal Mappt man die Domain auf die private IP-Adresse vom Server.

 

[Bob.Dig]

Ja, hatte ich gepostet.

Was mich aber ankotzt, beim Testen von intern kriege ich jetzt teilweise mit dem FF Timeouts, mit Chromium aber geht es... Da ich die default Apache Site angezeigt bekomme (auch extern), habe ich den Eindruck, dass Wordpress ohne TLS von extern gar nicht mehr funktioniert. Das würde vielleicht einige der Fehler, die ich hier erlebe, erklären.

Wie auch immer, habe jetzt genug davon und werde das "Projekt" canceln. War eindeutig zu hoch für mich.

 

[Helge01]

@Bob.Dig
Vielleicht wolltest du auch auf einmal zuviel. An deiner Stelle würde ich den HA-Proxy erstmal weg lassen und 2 Virtual Hosts auf dem Apache für HTTP / HTTPS anlegen. Dann machst du jeweils eine Weiterleitung darauf und kümmerst dich um die Konfiguration von Wordpress. Wenn das über HTTPS richtig funktioniert, kanst du dir den HA-Proxy nochmals anschauen.

 

[Bob.Dig]

Wobei https wollte ich ja nicht selbst machen auf dem backend bzw. hatte ich ja schon am laufen...
Ich will ja nicht wirklich Server administrieren können, das wäre zu viel Aufwand das alles im Selbststudium zu lernen um es dann nur einmal zu benutzen.