staging.inyokaproject.org

Apache2 als ReverseProxy für SSL in Verbindung mit dynamischem DNS

Status: Gelöst | Ubuntu-Version: Ubuntu 22.04 (Jammy Jellyfish)
Antworten |

queen-shit

Anmeldungsdatum:
17. Februar 2010

Beiträge: 129

Hallo zusammen, ich habe einen Web-Dienst, für den ich mit Apache als Reverse-Proxy SSL-Verbindungen forciere.

So sieht mein Virtueller Host dazu aus:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
<VirtualHost *:80>
        ServerName mein.freedns.org

        # Umleitung auf https
        RewriteEngine On
        RewriteCond %{HTTPS} off
        RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</VirtualHost>

<VirtualHost *:443>
        ServerName mein.freedns.org

        SSLEngine on
        SSLProxyEngine on
        SSLProxyVerify none
        SSLCertificateFile /opt/ssl/meincert.pem
        SSLCertificateKeyFile /opt/ssl/privatekey-meincert.pem

        ProxyRequests Off
        #ProxyPreserveHost On

        <Proxy *>
                Order deny,allow
                Allow from all
        </Proxy>
        ProxyVia On
        ProxyPass / http://localhost:8070/
        ProxyPassReverse / http://localhost:8070/

        RequestHeader set “X-Forwarded-Proto” “https”
        SetEnv proxy-nokeepalive 1
</VirtualHost>

Wenn ich nun die IP des Servers innerhalb meines LANs im Browser aufrufe, wird wie erwartet auf eine sichere Verbindung umgeleitet. Leider bekomme ich es nicht hin, dasselbe Verhalten zu forcieren, wenn ich "von außen" über meine FreeDNS Adresse auf den Dienst zugreifen möchte. Im Router ist dafür bereits ein Port-Forwarding eingerichtet - hierbei sind externer und interner Port unterschiedlich: Port 8888 leitet intern auf den Server auf 8070 um.

Wie bekomme ich aus mein.freedns.org:8888 eine SSL-Verbindung hin? Ich dachte, ich bräuchte nur noch oben zusätzlich zur *:80 die *.8888 hinzufügen (und dann noch in der ports.conf eine zusätzliche Listen-Direktive dazu), aber leider funktioniert der Zugriff so nicht. Ich bekomme dann, wenn ich https://mein.freedns.org:8888 aufrufe, im Browser einen Fehler mit "Fehlercode: SSL_ERROR_RX_RECORD_TOO_LONG". Kann hier jemand weiterhelfen, wie ich die Verbindung zum Laufen bekomme?

sebix Team-Icon

Moderator, Webteam

Anmeldungsdatum:
14. April 2009

Beiträge: 5077

Wenn du auf Port 8888 SSL haben willst, musst du schon auf dem Port auch SSL aktivieren, also den :443-Block nutzen.

queen-shit

(Themenstarter)

Anmeldungsdatum:
17. Februar 2010

Beiträge: 129

Also dann so hier:

1
<VirtualHost *:443 *:8888>

... und dann in der ports.conf

1
2
3
4
<IfModule ssl_module>
        Listen 443
        Listen 8888
</IfModule>

?

queen-shit

(Themenstarter)

Anmeldungsdatum:
17. Februar 2010

Beiträge: 129

Habe gerade festgestellt, dass ich genau das schon ausprobiert hatte. Also musste es ja woanders klemmen: Ich hatte ganz vergessen, im Router die alte Weiterleitung auf den direkten internen Port des Dienstes auf den neuen Port 8888 umzubiegen 😳 . So was Doofes aber auch. Jedenfalls funktioniert nun alles - sowohl intern über die IP des Servers als auch extern über DDNS. Rufe ich den Dienst über DDNS ohne https auf, dann kommt ein Fehler, dass ich versuche, per Plain HTTP auf eine SSL-Seite zuzugreifen. Das reicht mir. Ich möchte ja nur verhindern, dass irgendwelche unverschlüsselten Zugriffe überhaupt möglich sind. Mit dieser Apache Konfiguration und dem Blocken des direkten Ports des Dienstes über ufw habe ich ja genau das erreicht. Und 443 nach außen veröffentlichen muss ich auch nicht. Also Ende gut, alles gut 😉.

Jetzt muss ich mich bloß noch mit ModSecurity False-Positives rumschlagen. Was ich diesbezüglich merkwürdig finde, ist, dass ich von ModSecurity einen 403er bekomme, wenn ich mich über eine interne Verbindung (über IP des Servers innerhalb des LANs) an dem Dienst anmelden möchte, diesen Fehler aber nicht kriege, wenn ich die Seite über DDNS besuche. Bei einer reinen internen Verbindung sollte ModSecurity doch standardmäßig nicht weniger Rechte geben als über eine Verbindung von extern... Begreife ich jetzt nicht wirklich. Aber egal - das ursprüngliche Problem, um das es hier ging, ist ja nun gelöst.

Antworten |