Apache Reverse Proxy Server - Keine Weiterleitung

[Stefan]

Hallo zusammen,

ich habe auf meinem Raspbery Pi einen Apache Reverse Proxy Server aufgesetzt.
Ich möchte hier meine zwei Server - Netxcloud und Jitsi Meet von aussen (internet) erreichen.

Meinen Apache Reverse Proxy Server habe ich so installiert und eingerichtet.

## install apache2 ##
apt-get update
apt-get install apache2 -y

## enable moduls ##
a2enmod proxy
a2enmod proxy_http
a2enmod proxy_ajp
a2enmod rewrite
a2enmod deflate
a2enmod headers
a2enmod proxy_balancer
a2enmod proxy_connect
a2enmod proxy_html
service apache2 restart

## create config for 1st client ##
nano /etc/apache2/sites-enabled/server1.conf

<VirtualHost *:80>
ServerName subdomain11.yourdomain.com
ProxyPreserveHost On
DocumentRoot /var/www/html
ProxyPass /.well-known !
ProxyPass / http://10.1.1.11:80/
ProxyPassReverse / http://10.1.1.11:80/
</VirtualHost>

## create config for 2nd client ##
nano /etc/apache2/sites-enabled/server2.conf
<VirtualHost *:80>
ServerName subdomain12.yourdomain.com
ProxyPreserveHost On
DocumentRoot /var/www/html
ProxyPass /.well-known !
ProxyPass / http://10.1.1.12:80/
ProxyPassReverse / http://10.1.1.12:80/
</VirtualHost>

## restart apache server ##
service apache2 restart

## install Let's Encrypt Certbot ##
apt-get install python-certbot-apache

## create certificates ##
certbot --apache

#--> certificate only lasts 90 days

#install crontab
crontab -e

0 1 * * * /usr/bin/certbot renew & > /dev/nul

Natürlich habe ich die /etc/apache2/sites-enabled/server1.conf und /etc/apache2/sites-enabled/server2.conf auf meine Dyndns Adressen angepasst und meine Lokalen IP eingetragen.

Die ssl Zertifizierung sollte für beide Domains auch funktionieren.

Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: No redirect - Make no further changes to the webserver configuration.
2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for
new sites, or if you're confident your site works on HTTPS. You can undo this
change by editing your web server's configuration.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
Redirecting vhost in /etc/apache2/sites-enabled/server1.conf to ssl vhost in /etc/apache2/sites-enabled/server1-le-ssl.conf
Redirecting vhost in /etc/apache2/sites-enabled/server2.conf to ssl vhost in /etc/apache2/sites-enabled/server2-le-ssl.conf

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Congratulations! You have successfully enabled https://.dyndns.org and
https:/mine.nu

Beispiel von mir:
/etc/apache2/sites-enabled/server2.conf

<VirtualHost *:80>
ServerName videomeet.dyndns.org
ProxyPreserveHost On
DocumentRoot /var/www/html
ProxyPass /.well-known !
ProxyPass / http://192.168.0.50:80/
ProxyPassReverse / http://192.168.0.50:80/
RewriteEngine on
RewriteCond %{SERVER_NAME} =videomeet.dyndns.org
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>

Ich habe in meiner Fitzbox die Ports 4430 und 80 auf den pi weitergeleitet.
Rufe ich meine Seite aber über das Internet auf erhalte ich diese Meldungen:

Fehler: Umleitungsfehler
Beim Verbinden mit videomeet.dyndns.org trat ein Fehler auf.
Dieses Problem kann manchmal auftreten, wenn Cookies deaktiviert oder abgelehnt werden

Ich habe die Cookies gelöscht von unterschiedlichen Rechner und Netzten probiert, leider bleibt diese Meldung.
Was kann ich machen? Kann mir einer behilflich sein.
Gruß

Stefan

[HZB]

Du hast lediglich den Port 80 konfiguriert aber ein LetEncrypt Zertifikat für Deine beiden Server erstellt.

Was Du Dir überlegen / anschauen solltest ist, die beiden Dienste per SSL erreichbar zu machen.
Als Ansatz: Der Proxy terminiert die SSL Sessions für die Dienste, und reicht die Anfragen an das interne Netz / Server weiter.
Weiterer Ansatz / Hilfestellung. Das was Du benötigst ist SSL SNI.

hth

[Stefan]

Hallo,

ich habe einmal zwei Grundsätzliche Angelegenheiten.
Zum einen hoffe das ich mich richtig ausgedrückt habe, ich möchte meine beiden Dienste Jistsi.Mett und Nextcloud die alle auf eigenen Systemen laufen über das Internet erreichbar machen.
Da beide Dienste den Port 443 nutzen wollte ich den Proxy Reverse dazwischen schalten und diese so einstellen, dass er bei dem Aufruf jitsi.dyndns,org auf den Server Linkt und beim Aufruf nextclou.dyndns.org auf den Nexctloud Server verweist.

Ich habe dazu ein Bild erstellt um das besser darzustellen.



Zum zweiten, steht in der Anleitung:

nano /etc/apache2/sites-enabled/server1.conf
Muss die Datei nicht unter
nano /etc/apache2/sites-available/server1.conf

Ich habe auf den Systemen Jitsi und nextcloud eigenen SSL Zertifikate erstellen lassen, ziel soll es sein das der Proxy diese Zertifikate erstellt und auch weiterleitet.

<VirtualHost *:443>
ServerName DEINEDOMAIN.TLD
DocumentRoot /var/www/html

SSLEngine on
SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem
SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key

Errorlog ${APACHE_LOG_DIR}/https_error.log
Customlog ${APACHE_LOG_DIR}/https_access.log combined
</VirtualHost>

Hatte auch so eine Version getestet, leider ohne Erfolg.
Hast du oder andere noch irgendwelche Ideen ?

[letzter3]

Ist die Signatur aktuell?

[HZB]

Die Zertifikate von Letsencrypt terminieren auf dem Reverse Proxy.

Option 1) Die Zertifikate von letsencrypt mittels task an Jitsi und Nextcloud weiterleiten und dort installieren
Option 2) Du belässt die selbsterstellten Sneakoil und sagst dem Proxy er braucht diese nicht zu validieren.

nur dann wird es mmn klappen.

[novalix]

Ich denke auch, Du solltest zunächst einmal überlegen, wo der SSL-Tunnel enden soll. Dabei kann man unterscheiden zwischen reinem routing und der notwendigen HTTP-Server-Logik.

Normalerweise sollte es nicht nötig sein, im Hinterzimmer (Deinem LAN) den Tunnel bis zur jeweiligen Maschine zu bohren. In diesem Fall sollten auf dem Proxy die SSL-Leitungen terminiert werden, d.h. auch die Zertifikate von Letsencrypt abgelegt werden. Das kann man mit dem Apache machen, üblicherweise werden dafür aber leichtgewichtigere Alternativen bevorzugt. Die coolen Kids nehmen heuer nginx, die Pros haproxy und die coole professionelle Leichtgewichtsfraktion sowas wie hitch.
Man kann aber ach z.B. mit balance den TCP-Traffic der entsprechenden Ports (80 und 443) auf die jeweiligen Maschinen leiten und dort die jeweiligen Endpoints und die jeweilige Zertifikatsverwaltung konfigurieren.

[Stefan]

Ist die Signatur aktuell?

Nein, Sorry die Signatur ist schon etwas älter

Die Zertifikate von Letsencrypt terminieren auf dem Reverse Proxy.

Option 1) Die Zertifikate von letsencrypt mittels task an Jitsi und Nextcloud weiterleiten und dort installieren
Option 2) Du belässt die selbsterstellten Sneakoil und sagst dem Proxy er braucht diese nicht zu validieren.

nur dann wird es mmn klappen.

Im Grunde würde ich alles gerne über den Proxy laufen lassen.

Ich denke auch, Du solltest zunächst einmal überlegen, wo der SSL-Tunnel enden soll. Dabei kann man unterscheiden zwischen reinem routing und der notwendigen HTTP-Server-Logik.

Normalerweise sollte es nicht nötig sein, im Hinterzimmer (Deinem LAN) den Tunnel bis zur jeweiligen Maschine zu bohren. In diesem Fall sollten auf dem Proxy die SSL-Leitungen terminiert werden, d.h. auch die Zertifikate von Letsencrypt abgelegt werden. Das kann man mit dem Apache machen, üblicherweise werden dafür aber leichtgewichtigere Alternativen bevorzugt. Die coolen Kids nehmen heuer nginx, die Pros haproxy und die coole professionelle Leichtgewichtsfraktion sowas wie hitch.
Man kann aber ach z.B. mit balance den TCP-Traffic der entsprechenden Ports (80 und 443) auf die jeweiligen Maschinen leiten und dort die jeweiligen Endpoints und die jeweilige Zertifikatsverwaltung konfigurieren.

Im Grunde ist es mir total egal ob ich das über das colle nginx, oder über ein Prof Tool laufen lasse,
Wenn ich es aber schon bei einem Apache nicht hinbekomme werde ich bei anderen Sachen sicherlich mehr Probleme bekommen.

Ich finde es schon spannend das es mehrere Alternativen gibt, meine frage ist nur welche sind die besten und einfachsten Lösungen?
Nginx soll doch auch gut mit Docker zusammenarbeiten.

Ich würde sehr gerne alles über den Proxy laufen lassen, also auch SSL.
Hat den einer eine Gute Anleitung für die von novalix genannten Tolls?
Gruß und Danke Stefan

[novalix]

Hi,

persönlich würde ich dafür HAProxy verwenden. Das liegt daran, dass ich mich damit ein wenig auskenne, d.h. mich darin eingelesen und damit Erfahrungen gesammelt habe. Das lohnt sich.
Allerdings ist es manchmal nicht ganz trivial und es hilft erheblich, wenn man einigermaßen mit englischen Texten klar kommt.

Wie so häufig liegt der Schlüssel zum Erfolg in einer schrittweisen Umsetzung.

Voraussetzung wäre zunächst, dass keine anderen daemons an den benötigten Ports lauschen. Du müsstest den Apache mindestens stoppen oder disablen oder gar deinstallieren.
HAProxy lässt sich über apt* aus den Repos installieren. Ich würde im Falle von stable empfehlen, die backports zu aktivieren und die Version daraus zu installieren.
Das Handbuch ist recht umfang- aber auch lehrreich: https://cbonte.github.io/haproxy-dconv/2.0/intro.html
Die wesentliche Konfiguration ist "/etc/haproxy/haproxy.cfg".

Im ersten Schritt solltest Du versuchen das Routing ohne SSL zum laufen zu bekommen.
Eine Frontend-Sektion könnte so aussehen:

Code: Alles auswählen

...
         frontend meinproxy_80
         bind *:80
         mode http
         
         acl host_jitsi hdr(Host) -i jitsi-sub.deine-domain.xyz # Eine Regel für Anfragen an Jitsi Meet
         
         use_backend jitsi_meet if host_jitsi # Anfragen die der Regel entsprechen gehen hier hin
         
         default_backend nextcloud_backend # Alle anderen Anfragen landen hier
         

Die Backend-Sektion könnte so aussehen:

Code: Alles auswählen

...
backend jitsi_meet
         server jitsiweb 192.168.0.50:80 check maxconn 100
         
backend nextcloud_backend
         server ncweb 192.168.0.70:80 check maxconn 100         
         

Die SSL-Konfiguration wäre dann etwas aufwendiger, weil ein paar Besonderheiten von HAProxy und Details des HTTP-Protokolls zu beachten sind.

[wanne]

Ganz grundsätzlich: Dein PI müsste ja wissen, ob die anfrage zum Jitsi - Meet oder zum Nextcloudpi geht. Dazu müsste es ja verstehen was in der Anfrage steht. Die Idee von TLS ist aber gerade, dass dritte, die dein Zertifikat/Key nicht haben NICHT mitlesen können. Kurz so wie aufgezeichnet kann das mit dem Apachen erst mal nicht funktionieren. Der haproxy kann dass für viele Browser, die Informationen leaken dann doch umgehen (Stichwort SNI) die will man aber eher nicht benutzen, weil TLS gerade damit aufräumen will, dass man Informationen leakt. Konterkaniert ja die die Idee von Verschlüsslung. Entsprechend willst du die Zertifikate auf dem PI haben.
Lösung Grundiee: Du installierst deinen Certbot auf dem PI hältst die Zertifikate da. (Hast du schon gemacht. Nur zum Verständnis, was an deiner Zeichnung "falsch" ist)

Das nächste ist das ein bisschen widersprüchlich:

Code: Alles auswählen

<VirtualHost *:80>
ServerName videomeet.dyndns.org
ProxyPreserveHost On
DocumentRoot /var/www/html
ProxyPass /.well-known !
ProxyPass / http://192.168.0.50:80/
ProxyPassReverse / http://192.168.0.50:80/
RewriteEngine on
RewriteCond %{SERVER_NAME} =videomeet.dyndns.org
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>

Entweder du machst den Rewrite von http nach nach https und deine Nutzer werden auf https weitergeleitet. Oder du machst ein ProxyPass zum http und deine Nutzer können die Seite (auch) über http nutzen. Am Ende schlägt der Rewrite die ProxyRegel. Wenn du die drin lässt ist das sind die 3 ProxyPass-Regeln schlicht unnötig. (Aber nicht schädlich.) Das zweite ist, dass du die Condition eigentlich nicht brauchst. Mit ServerName videomeet.dyndns.org hast du ja schon angegeben, dass du nur videomeet.dyndns.org behandelst. Auch hier ist noch kein wirklicher Fehler aber halt ne Menge verwirrendes. Daneben willst du den redirect wahrscheinlich für beide Server haben. Du kannst dir also auch einfach das ServerName und die RewriteCond sparen und nur einen Server statt zwei konfigurieren. – Du machst ja eh immer das selbe: Weiterleiten nach https.

So jetzt zu den eigentlichen Fehlern:
a) Du leitest weiter nach https://%{SERVER_NAME}%{REQUEST_URI} du gibst keinen Port an. => Es wird der Standardport 443 genutzt. Auf der Fritzbox hast du aber 4430 konfiguriert. Also bevorzugt Fritzbox auf 443 korrigieren oder den Port 4430 einfügen:

Code: Alles auswählen

https://%{SERVER_NAME}:4430%{REQUEST_URI}

Daher kommt die Felermeldung

b) du leitest zwar weiter auf https weiter. Da läuft aber gar nichts.
Von der Idee her müsste das so aussehen:

Code: Alles auswählen

<VirtualHost *:443>
    ServerName videomeet.dyndns.org
    ProxyPass / http://192.168.0.50:80/
    ProxyPassReverse / http://192.168.0.50:80/

    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/videomeet.dyndns.org/cert.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/videomeet.dyndns.org/privkey.pem
</VirtualHost>

Von der Idee her müsste der Certbost auch schon teile (Ohne die passenden ProxyPass-Regeln) generiert haben.