FileMaker WebDirect hinter einem Reverse Proxy
Dieser Blogbeitrag beschreibt, wie man FileMaker 19 WebDirect hinter einem NGinx Reverse Proxy betreibt.
Was ist ein Reverse Proxy?
Beim Einsatz eines Reverse Proxy wird eine Ressource (zum Beispiel unser FileMaker Web Server) nicht direkt im Internet für Clients zugänglich gemacht, sondern die Clients (zB Webbrowser) kommunizieren nur mit dem Reverse Proxy.
Anbei eine Skizze, wie die Kommunikation ohne und mit Reverse Proxy abläuft.
Der Reverse Proxy wiederum kommuniziert dann mit dem FileMaker Web Server, er leitet also die Anfrage weiter, wartet auf die Antwort vom FileMaker Server und gibt diese dann wieder an den Client zurück.
Ähnlich wie wenn Sie im Restaurant Essen bestellen: Da gehen Sie auch nicht in die Küche um Ihr Schnitzel zu bestellen, sondern Sie sagen dem Kellner was Sie wollen.
Der Kellner (unser Reverse Proxy) nimmt die Bestellung entgegen, inklusive Ihrem Sonderwunsch “viel Ketchup”. Dann wird die Bestellung an die Küche weitergeleitet, aber ohne dem Ketchup Wunsch, weil das erledigt der Kellner später selbst.
Wenn das Schnitzel fertig ist und aus der Küche kommt, dann bringt der Kellner jetzt noch eine Flasche Ketchup und das Schnitzel zum Tisch.
So wie der Kellner Ihre Bestellung leicht modifizieren oder abändern kann, kann ein Reverse Proxy Ihre Anfrage oder die Antwort vom Server ändern. Das werden wir später noch sehen.
Wer es genauer wissen will, kann sich auf Wikipedia erkundigen: https://de.wikipedia.org/wiki/Reverse_Proxy
Warum benötigt man einen Reverse Proxy?
Da die Ressource (unser FileMaker Web Server) nicht direkt im Internet freigegeben ist, sondern alle Abfragen über den Reverse Proxy laufen, ist die Ressource besser geschützt.
Der Reverse Proxy kann Logdateien schreiben, was später bei diversen Auswertungen hilft.
Der Reverse Proxy kann (oftmals) cachen. Eine große Datei muss nicht immer vom Webserver abgerufen werden sondern könnte von einem schnelleren Cacheserver kommen.
Ein Reverse Proxy kann für Ausfallssicherheit sorgen. Anfragen könnten zB an 3 Webserver weitergeleitet werden und wenn einer der Server ausfällt, dann werden die Anfragen eben nur noch an 2 Server weitergeleitet, bis der dritte wieder zur Verfügung steht. (So wie im Restaurant, wenn 3 Köche in der Küche sind und einer krank wird. Der Gast merkt das im Normalfall nicht, außer, dass er ev. ein wenig länger aufs Schnitzel warten muss).
Ein Reverse Proxy kann Antworten umschreiben. Aktuell gibt es zum Beispiel viele Webseiten, die Google Fonts direkt einbinden und dann unter Umständen DSGVO-Abmahnungen bekommen, siehe hier. Daher habe ich bei vielen Kundensysteme einen Reverse Proxy laufen, der jede Anfrage an Google Fonts über den lokalen Server umleitet. Das dauert zwar ein paar Millisekunden länger, dafür gibt es keine Probleme mit der DSGVO.
Ein Reverse Proxy kann durch eine zusätzliche Authenfizierung für mehr Sicherheit sorgen, siehe dazu den Folgeartikel FileMaker WebDirect und Authelia!
Ein Reverse Proxy ist also sehr nützlich und kann viele Funktionen erfüllen. Die Liste oben ist lange noch nicht vollständig, aber soll Sinn und Zweck eines Reverse Proxies darstellen.
Reverse Proxy vor FileMaker Server
Folgendes Szenario: Wir haben einen neuen, jungfräulichen, funktionierenden FileMaker Server installiert inklusive funktionierendem SSL Zertifikat.
Der FileMaker Server hat den Namen schubec.fm-server.net, WebDirect ist demnach unter https://schubec.fm-server.net/fmi/web erreichbar, die Admin Console unter https://schubec.fm-server.net/admin-console
Unser Ziel ist es nun, WebDirect und die Admin Console hinter einem Reverse Proxy zu stellen.
1. Versuch. Das klappt nicht!
Mein erster Versuch, das am FileMaker Server selbst zu machen ist gescheitert. Damit Sie nicht den selben Fehler machen (oder mir Tipps per Email schicken können, wie es doch geht), schildere ich hier kurz, was ich getan habe:
Meinen Server FileMaker Server 19.5 habe ich unter Ubuntu 20.04.5 LTS installiert. In diesem Szenario installiert der FileMaker-Installer den Webserver NGinx. (Ältere Versionen nutzen Apache Webserver).
Ich habe dann die FileMaker NGinx Server Config Files so angepasst, dass NGinx nicht mehr die Ports 80 (http) und 443 (https) nutzen, sondern 8080 für http und 4443 für https, damit die Ports 80 und 443 für meinen Reverse Proxy frei werden.
In diesem Setup zeigt dann FileMaker WebDirect sowie die Admin Console keinen Datenbanken mehr an. Ich bin sicher, dass man da noch mehr umkonfigurieren kann, sodass es dann irgendwie klappt, aber da ich auf die schnelle nichts gefunden habe und mir dann außerdem gedacht habe, ich lass den FileMaker Server lieber ganz in Ruhe, habe ich die Änderung wieder rückgängig gemacht (sprich, NGinx nutzt wieder Port 80 und 443)
2. Versuch. So klappts!
Ich habe mir einen zweiten Linux Server geschnappt und dort NGinx als Reverse Proxy installiert.
Dieses Setup hat den großen Vorteil, dass der FileMaker Server wirklich komplett unverändert ist. Ihr FileMaker Server kann daher auch unter Windows oder Mac laufen oder auch eine ältere Version sein, ganz egal. Der Reverse Proxy wird einfach vor den FileMaker Server gesetzt und gut ist.
Nachteil ist, dass Sie einen weiteren (virtuellen) Rechner benötigen. Da darauf aber nicht viel läuft, reicht eine ganz kleine Maschine. Beim Anbieter Hetzner beispielsweise reichen da 5 € im Monat locker aus.
Daher, neue virtuelle Maschine bei Hetzner geholt. Dieser Rechner hat die IP 135.181.36.200 zugeteilt bekommen.
Da ich am liebsten mit Docker arbeite, habe ich meinen Reverse Proxy mit Docker eingerichtet. Certbot holt noch kostenlose Zertifikate von Let’s Encrypt.
Das docker-compose.yml File sieht so aus:
version: '3'
services:
nginx:
image: nginx:alpine
restart: unless-stopped
volumes:
- ./data/nginx:/etc/nginx/conf.d
- ./data/nginx-snippets:/etc/nginx/snippets
- ./data/certbot/conf:/etc/letsencrypt
- ./data/certbot/www:/var/www/certbot
- ./data/custom-certs:/etc/custom-certs
ports:
- "80:80"
- "443:443"
command: "/bin/sh -c 'while :; do sleep 6h & wait $${!}; nginx -s reload; done & nginx -g \"daemon off;\"'"
networks:
- frontproxy_default
certbot:
image: certbot/certbot
restart: unless-stopped
volumes:
- ./data/certbot/conf:/etc/letsencrypt
- ./data/certbot/www:/var/www/certbot
- ./data/certbot/log:/var/log/letsencrypt
entrypoint: "/bin/sh -c 'trap exit TERM; while :; do certbot renew; sleep 12h & wait $${!}; done;'"
networks:
frontproxy_default:
external: true
Da ist nichts besonderes dabei, ein Standard docker-stack. Wenn Sie Docker und Docker-Compose kennen, dann sollte das File oben verständlich sein. Eine Einführung in Docker und Docker-Compose würden diesen Artikel jedoch sprengen.
Die Idee ist, das mein Reverse Proxy unter https://secure.schubec.fm-server.net erreichbar sein soll, daher wird erst einmal der DNS Server konfiguriert:
Nun wird NGinx konfiguriert:
server {
listen 80;
server_name secure.schubec.fm-server.net;
server_tokens off;
location /.well-known/acme-challenge/ {
root /var/www/certbot;
}
location / {
return 301 https://$host$request_uri;
}
}
server {
large_client_header_buffers 4 32k;
client_max_body_size 20M;
listen 443 ssl http2;
server_name secure.schubec.fm-server.net;
server_tokens off;
ssl_certificate /etc/letsencrypt/live/secure.schubec.fm-server.net/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/secure.schubec.fm-server.net/privkey.pem;
include /etc/letsencrypt/options-ssl-nginx.conf;
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
location / {
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_pass https://schubec.fm-server.net;
}
}
Was passiert hier?
- Anfragen an .well-known/acme-challenge leiten wir ins Verzeichnis von Certbot um, damit wir kostenlose SSL Zertifikate von Let’s Encrypt bekommen
- Wir setzen die Limits für large_client_header_buffers und client_max_body_size hinauf, damit wir per WebDirect größere Datenmengen übertragen können.
- Wir konfigurieren SSL mit dem Zertifikat secure.schubec.fm-server.net
- Wir leiten alle Anfragen an / (also alles) an unseren FileMaker Server weiter: proxy_pass https://schubec.fm-server.net;
- Da WebDirect Websockets verwendet, brauchen wir noch die HTTP Version 1.1 und erlauben Verbindungs-Upgrades, sonst würden WebSockets nicht funktionieren.
Wir erzeugen unser Proxy-Netzwerk und starten den Docker Stack.
docker network create frontproxy_default
docker-compose up -dNginx haut uns tausende Fehlermeldungen um die Ohren, da das SSL Zertifikat für secure.schubec.fm-server.net noch nicht existiert, das wir im Configfile angegeben haben.
Wir erstellen also ein selbst ausgestelltes (und daher nicht offiziell gültiges) SSL Zertifikat. Nutzen Sie dafür die Scripts, die ich für Sie (und mich) vorbereite habe. Download am Ende des Artikels
./1_create_dummy_certs.sh secure.schubec.fm-server.netNGinx startet nun nach circa 30 Sekunden. Wenn wir nicht so lange warten wollen, können wir das Script zum Restart verwenden:
./2_restart_nginx.shNun können wir per Certbot das offiziell gültige SSL Zertifikat anfordern:
./3_fetch_certificates.sh secure.schubec.fm-server.net
### Deleting dummy certificate for secure.schubec.fm-server.net ...
### Requesting Let's Encrypt certificate for secure.schubec.fm-server.net ...
Saving debug log to /var/log/letsencrypt/letsencrypt.log
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Would you be willing, once your first certificate is successfully issued, to
share your email address with the Electronic Frontier Foundation, a founding
partner of the Let's Encrypt project and the non-profit organization that
develops Certbot? We'd like to send you email about our work encrypting the web,
EFF news, campaigns, and ways to support digital freedom.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o: y
Account registered.
Requesting a certificate for secure.schubec.fm-server.net
Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/secure.schubec.fm-server.net/fullchain.pem
Key is saved at: /etc/letsencrypt/live/secure.schubec.fm-server.net/privkey.pem
This certificate expires on 2023-02-01.
These files will be updated when the certificate renews.
NEXT STEPS:
- The certificate will need to be renewed before it expires. Certbot can automatically renew the certificate in the background, but you may need to take steps to enable that functionality. See https://certbot.org/renewal-setup for instructions.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you like Certbot, please consider supporting our work by:
* Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
* Donating to EFF: https://eff.org/donate-le
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Wir starten NGinx nun nochmals neu:
./2_restart_nginx.sh…und rufen im Webbrowser https://secure.schubec.fm-server.net auf. Unser FileMaker Server begrüßt uns! 🙂
Beim Aufruf von https://secure.schubec.fm-server.net/admin-console sehen wir die FileMaker Admin Console und unter https://secure.schubec.fm-server.net/fmi/webd sehen wir WebDirect (sofern aktiviert).
Super, das klappt!
Abschlussarbeiten
Unser FileMaker Server ist momentan per Reverse Proxy unter https://secure.schubec.fm-server.net/ als auch direkt unter https://schubec.fm-server.net/ erreichbar.
Genau so, wie Sie als Gast im Restaurant nicht in die Küche maschieren dürfen, wollen wir nicht, dass Clients direkt auf FileMaker Server zugreifen.
Um das zu ändern gibt es viele Möglichkeiten, beispielsweise per Firewall Regel am FileMaker Server selbst oder an einer Firewall die davor sitzt.
Oder wir ändern die Konfiguration am NGinx FileMaker Server und lassen dort nur Anfragen von der IP des Reverse Proxies zu.
Viele Wege führen nach Rom!
Die beiden IPTables Regeln, ausgeführt am Ubuntu Linux FileMaker Server
iptables -I INPUT ! --src 135.181.83.155 -m tcp -p tcp --dport 443 -j DROP
iptables -I INPUT ! --src 135.181.83.155 -m tcp -p tcp --dport 80 -j DROPblockieren sämtliche Zugriffe auf die Ports 80 und 443, außer sie kommen von 135.181.83.155, der IP meines Reverse Proxy Servers.
Download
Hier finden Sie alle benötigten Config Files und Helper Scripts. Free of charge und without warranty!
Und jetzt wird’s spannend!
Richtig spannend wird’s nun noch, wenn wir unseren FileMaker Server mit Authelia absichern. Warum und wie das geht lesen Sie im Beitrag FileMaker WebDirect und Admin Console mit 2FA absichern.
PS: Und was ist mit FileMaker Clients?
Anders als Webbrowser, die das öffentlich dokumentierte HTTP Protokoll zur Kommunikation mit FileMaker WebDirect verwenden, nutzen FileMaker Clients leider ein proprietäres Netzwerkprotokoll, das nur Claris Inc. kennt. Fremdhersteller können daher keine Reverse Proxy Dienste für FileMaker programmieren/anbieten* und Claris Inc. selbst stellt kein Produkt “FileMaker Reverse Proxy” zur Verfügung.
* Die Diskussion zum Thema hat mir auf der FileMaker Konferenz 2022 in Hamburg zwei Bier eingebracht. Danke Andi und Alex für das anregende Gespräch!
FileMaker Clients sind daher immer direkt mit FileMaker Server verbunden. Eine mögliche Lösung, aber ein ganz anderer technischer Ansatz wäre hier der Einsatz von VPN Verbindungen.
Kommentieren und Diskutieren