Nach dem Michael in der Schule im Informatik-Untericht mit HTML angefangen hat, haben wir Zuhause auf einem Raspberry Pi einen eigenen Web-Server aufgesetzt, um verschiedene Sachen ausprobieren zu können. Nun wollten wir, dass nicht nur unser Raspberry Pi aus dem Internet erreichbar ist, sondern auch dieser Blog, der auf einer Synology Disk Station läuft. Die Portweiterleitung am Router kann aber nur auf eine IP-Adresse konfiguriert werden. Die Lösung für das Problem ist ein Reverse-Proxy. Dieser kann anhand der URL entscheiden an welchen Server die Anfrage weitergeleitet werden soll. Außerdem bietet ein Reverse-Proxy zusätzliche Sicherheit, da die Disk Station dann nicht direkt aus dem Internet erreicht werden kann. So haben wir gleich den lighttpd-Server auf dem Raspberry Pi als Reverse-Proxy konfiguriert:
pi$ sudo lighty-enable-mod proxy
pi$ sudo nano /etc/lighttpd/conf-enabled/10-proxy.conf
$HTTP["url"] =~ "^/wordpress(.*)$" {
proxy.server = ( "" => ( ( "host" => "192.168.1.2", "port" => 80 ) ) )
}
$ sudo systemctl restart lighttpd.service
Allerdings funktioniert es gut nur, wenn wir eine unverschlüsselte Verbindung (http://…) aufbauen. Sobald man https://… verwendet, bekommt man im Browser eine Warnung über „mixed content“ und die Seite wird nicht richtig angezeigt. Mit anderen Diensten auf der Disk Station (z.B. Photo Station) funktioniert es dagegen auch über eine verschlüsselte Verbindung. Eine Netzwerk-Analyse mittels Wireshark hat gezeigt, dass eine Antwort vom nginx und nicht von Apache-Server (auf dem eigentlich der WordPress läuft) kommt:
syno$ sudo netstat -tulpn | grep :80 tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 11735/nginx: master
Das heißt, dass auf der Synology ein nginx-Server als Reverse-Proxy läuft und wir einen Reverse-Proxy hinter einem Anderen haben. Aber wohin wird der WordPress-Traffic von nginx weitergeleitet:
syno$ cd /volume1/@appstore/WordPress/synology_added/etc/
syno$ cat www.WordPress.conf
location ^~ /wordpress {
include proxy.conf;
proxy_pass http://127.0.0.1:914;
proxy_read_timeout 3600s;
}
syno$ sudo netstat -tulpn | grep :914
tcp 0 0 0.0.0.0:914 0.0.0.0:* LISTEN 22223/httpd22
So können wir unsere http-Anfragen an den Port 914 direkt vom Raspberry weiterleiten:
pi$ sudo nano /etc/lighttpd/conf-enabled/10-proxy.conf
$HTTP["url"] =~ "^/wordpress(.*)$" {
proxy.server=(""=>(("host"=>"192.168.1.2","port"=>914)))
}
pi$ sudo systemctl restart lighttpd.service
Allerdings muss man den Apache-Server umkonfigurierten, dass dieser nicht nur auf Anfragen vom lokalen nginx lauscht, sondern auch auf die von dem Raspberry. So ändere ich httpd22.conf:
syno$ sudo vi httpd22.conf ServerRoot "/usr/local/etc/apache22" Listen 0.0.0.0:914
und starte den Apache-Server neu:
syno$ sudo reload pkg-apache22
Folgendes sollte noch in die wp-config.php hinzugefügt werden:
syno$ sudo vi /volume1/web/wordpress/wp-config.php
define('FORCE_SSL_ADMIN', true);
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https')
$_SERVER['HTTPS']='on';
Quelle: https://guides.wp-bullet.com/fix-varnish-mixed-content-errors-cloudflare-ssl-wordpress/
oder so:
/** SSL */
define('FORCE_SSL_ADMIN', true);
// in some setups HTTP_X_FORWARDED_PROTO might contain
// a comma-separated list e.g. http,https
// so check for https existence
if (strpos($_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false)
$_SERVER['HTTPS']='on';
…und ein Test:
pi$ curl https://192.168.1.2:914 pi$ curl https://bayer-in.de/wordpress/