Manchmal ist es schon charmant, auch mal von unterwegs zu gucken, ob das Licht im Wohnzimmer aus ist oder ein Bild der Webcam anzuzeigen. Für diesen Zugriff gibt es prinzipiell drei Möglichkeiten:
Der Standard-Port von Home Assistant ist 8123. Es dürfte also kein Problem, der FritzBox zu sagen, dass sie Anfragen auf diesem Port an den Rechner im Heimnetz weiterleiten soll, auf dem Home Assistant läuft.
Die zweite Möglichkeit ist, der FritzBox VPN beizubringen und von unterwegs eine VPN-Verbindung aufzubauen.
Die dritte Möglichkeit ist ein Reverse-Proxy, der Anfragen aus dem Internet ins interne Netzwerk weiterleitet.
Möglichkeit 1 – die Portfreigabe – scheidet aus: Sollte der Home Assistant mal nicht so funktionieren, wie er soll, oder eine Sicherheitslücke aufweisen, könnte jemand über den Port in mein Netzwerk gelangen. Und wer weiß was anstellen. Außerdem bin ich nicht begeistert davon, einen oder mehrere Rechner in der FritzBox freizugeben – mal ein Home Assistant hier, dann ein Webserver da; vielleicht noch ein SSH-Server dort. Mal abgesehen davon, dass die Firewall der FritzBox irgendwann große Ähnlichkeit mit einem Schweizer Käse aufweisen dürfte, hat dieser Ansatz einen Haken: Man kann einen Port nur einmal freigeben. Zwei Webserver (die auf verschiedenen Rechnern jeweils auf Port 80 laufen) können so also nicht freigegeben werden. Natürlich kann man den Port eines der Webserver ändern, aber dann kommt wieder das Käse-Thema zum Tragen…
Die zweite Idee – VPN – ist da schon besser. Das VPN einzurichten ist kein Hexenwerk, und wenn man mal eben kurz gucken will, was zuhause los ist, ist das auch völlig in Ordnung. Nun ist es aber so, dass der Home Assistant nicht nur Daten anzeigt, sondern auch sammelt. Ein gutes Beispiel ist die Anwesenheitserkennung: Home Assistant bietet die Möglichkeit, den Standort von Mobilgeräten abzufragen und auf einer Karte anzuzeigen. Dafür ist es sinnvoll, dass die Verbindung dauerhaft besteht. Und damit scheidet die VPN-Lösung auch aus.
Bleibt noch Möglichkeit 3: Der Reverse Proxy. Aber was ist das?
Ein Reverse Proxy, auch Edge Router genannt, ist ein Server, der Anfragen aus dem Internet entgegennimmt ins interne Netz weiterleitet. Wohin diese Anfragen geleitet werden, lässt sich sehr genau definieren. Der Aufruf dahoam.meinedomain.de/web1 wird zu einem Webserver weitergeleitet, dahoam.meinedomain.de/web2 zu einem anderen Webserver und dahoam.meinedomain.de/ssh geht auf den SSH-Server auf einem dritten Rechner.
Der Reverse Proxy kann noch mehr: Zum Beispiel kann eine Authentifizierung vorgeschaltet werden, so dass der Besucher der Seite erst einen Benutzernamen und ein Kennwort eingeben muss, bevor die aufgerufene Seite angezeigt wird. Auch gibt es die Möglichkeit, benutzerdefinierte Fehlerseiten anzuzeigen, wenn eine unbekannte Adresse eingegeben wird. Äußerst charmant ist auch die Möglichkeit, für die internen Server SSL-Zertifikate von Letsencrpt zu beziehen – inklusive der automatischen Verlängerung (die Zertifikate sind nur drei Monate gültig).
Es soll also so ein Reverse Proxy sein – die Frage ist nur: Welcher? Der Apache Webserver kann das, ist aber wohl für meine kleine Umgebung etwas überdimensioniert. Træfik soll sehr gut sein, vor allem wenn es darum geht, Docker-Container zu verwalten – leider hat er meinen kognitiven Horizont überschritten (mit anderen Worten: Ich bin zu blöd dafür…). Nginx ist ebenfalls ein recht bekannter, gut dokumentierter Reverse Proxy. Für den gibt es auch eine Anwendung namens „Proxy Manager“ – das ist genau das Richtige für mich: Eine Klicki-Bunti Oberfläche, über die ich meinen Reverse Proxy einrichten kann. Da es das Ganze als Docker-Container gibt, sollte es sich wunderbar auf einem Raspberry Pi einrichten lassen. (Ich werde dafür einen eigenen Pi nutzen, auf dem nur dieser Container läuft. Sollte dann mal irgendwas schief gehen, muss ich nur diesen einen Pi vom Netzwerk trennen und habe wieder meine Ruhe – wenn ich es denn rechtzeitig merke…)