Hass-Server mit seinen ganzen Diensten wie im Lan/WWW verfügbar machen ?

[selfmade01]

Hallo

habe hier einen Raspberry Pi 4 (mit LAN und Wlan) auf dem Hass sowie die ganzen anderen Dienste (mariadb, influxdb, nginx etc....)installiert sind.

Info: Ich habe noch einen Thread aufgemacht... der hat aber mit dieser Frage nichts zu tun,,,, deswegen 2 Threads

Später sollen natürlich Smartphones mit HA-app oder ein Laptop zum Administrieren via Fernzugriff haben. (eigene Domain im www ist vorhanden, eine Weiterleitung zu meinem myfritz-dns ibesteht auch.

Ich möchte aber auch vom LAN den Server nicht nur via ssh auf der kommandozeile sondern auch via Web das HA-System administrieren.

Wie konfiguriert man nun am besten die einzelnen Systeme wie mqtt, influxdb, mariadb HA etc. auf einem Raspberry Pi mit Dockersystem (alles läuft im Docker).
Gemeint ist hier der interne Datenverkehr der einzelnen Dienste wie z.B. HA mit abfragen der Datenbanken.

Wie im Netzplan ersichtlich hat der Raspi4 2 Netwerkkarten.
die eine zeigt mit ihrer 192.168.2.0/24'er Ip ins sogenannte DMZ zum Fritzboxrouter wobei mit einem nginx-proxy-manager die Ports der Dienste wie Nameservice angesprochen werden können.
Bei meinem Domain-Provider habe ich AUCH DIE DNS-Einträge mit ihren Subdomains eingerichtet.

Ich frage deshalb da man ja so glaube ich, die Docker mit dem HA und anderen Diensten so einrichten kann das diese entweder nur auf die DMZ-IP-Adresse hören oder auch auf beide Bereiche also auf das 10.3.141.0'er WifI-Lan auch.
Weiter kann ich das Docker-System wohl auch so einstellen das es dort ein virtuelles Netz gibt wo die Dienste untereinander kommunizieren.



Jetzt frage ich mich wie man Hass. Docker und die Zugriffe am besten konfiguriert?

Ps. Ich muss später den Raspberry Fernwarten können.

Grüße Achim

 

[blurrrr]

Hi,

eine einfache Möglichkeit wäre z.B. ein SOCKS-Proxy, läuft auch einfach via SSH...

Vorher:

ssh <user>@<remote-host>

Mit Proxy:

ssh -D <gewünschter Port> <user>@<host>

Danach trägst Du im Browser unter Proxy "localhost" bzw. "127.0.0.1" und den angegebenen Port ein und fertig, sieht dann z.B. so aus:



Die Doku zum Parameter "-D" findet Du z.B. hier oder einfach in der manpage direkt auf dem System.

Wünsche gutes Gelingen!

EDIT: Alternativ kannst Du Dich natürlich auch mit den verschiedenen Netzwerk-Möglichkeiten bei Docker beschäftigen: https://docs.docker.com/network/, das mit dem SOCKS-Proxy wäre halt die "schnelle" Lösung

 

[selfmade01]

Danke... das wäre fast wie ein VPN Tunnel oder? das würde dann alle andere Konfiguration an meinem Server unnötig machen
oder?

 

[blurrrr]

Jain, aber machste erstmal auch nix mit kaputt... Wenn Du eh via SSH dran kommst, probier es einfach aus... einfach noch "-D <Port>" dranhängen, im Browser localhost + Port als SOCKS-Proxy angeben und dann guckste einfach mal, vielleicht reicht Dir das ja schon als Lösung für Dein Vorhaben

EDIT: Sämtliche Anfragen kommen dann natürlich vom Proxy-Host(!), das wäre wie Client im VPN-Netz wo dann nochmal zusätzlich ein NAT drübergestülpt würde bei Anfragen ins interne Netz. Zudem geht dann auch jeder Browser-Request über den Proxy-Host(!)... kannste mal mit "wieistmeineip.de" o.ä. schauen.

 

[selfmade01]

EDIT: Alternativ kannst Du Dich natürlich auch mit den verschiedenen Netzwerk-Möglichkeiten bei Docker beschäftigen: https://docs.docker.com/network/, das mit dem SOCKS-Proxy wäre halt die "schnelle" Lösung

Hallo,
da muss ich nun doch nochmal nachfragen.
Wenn ich via Proxy-Socks den Zugriff von Außen mache

Hi,

eine einfache Möglichkeit wäre z.B. ein SOCKS-Proxy, läuft auch einfach via SSH...

Vorher:


Mit Proxy:

Danach trägst Du im Browser unter Proxy "localhost" bzw. "127.0.0.1" und den angegebenen Port ein und fertig, sieht dann z.B. so aus:

Anhang anzeigen 3304

Die Doku zum Parameter "-D" findet Du z.B. hier oder einfach in der manpage direkt auf dem System.

Wünsche gutes Gelingen!

EDIT: Alternativ kannst Du Dich natürlich auch mit den verschiedenen Netzwerk-Möglichkeiten bei Docker beschäftigen: https://docs.docker.com/network/, das mit dem SOCKS-Proxy wäre halt die "schnelle" Lösung

So wie ich das nun verstanden habe, könnte ich dann JEDEN Dienst der eigentlich von außen erreichbar sein müsste nur auf dem Localhost also mit der 127.0.0.1 und einem anderen Port laufen lassen?
das bedeutet dann das der eigentliche Dienst nicht mehr öffentlich im Netz steht oder?
Das ich dennoch einen zugriff bekomme müsste ich auf dem Server noch einen Proxy einrichten?

Das o-g- Beispiel mit dem ssh ===> ich würde also einen ssh tunnel zum entferneten Server aufmachen.
Auf meinem Client (sofern die ssh-Verbindung steht) könnte ich dann mit meiner eigenen localhost-adresse jedoch mit der Portangabe so auf den entfernten Server zugreifen (vom broswer aus meine ich)?

Wäre das dann nicht viel anderes als ein VPN Tunnel?

Sämtliche Anfragen kommen dann natürlich vom Proxy-Host(!),

und wo steht der? der läuft doch dann auch auf dem Server auf dem der gewünschte erreichbare Dienst läuft zumindest wäre das in meinem Fall so oder?

 

[blurrrr]

So wie ich das nun verstanden habe, könnte ich dann JEDEN Dienst der eigentlich von außen erreichbar sein müsste nur auf dem Localhost also mit der 127.0.0.1 und einem anderen Port laufen lassen?

Tunneln kannst Du wie Du lustig bist. Aber wenn Dienste auf Hosts "nur" auf "localhost" lauschen, kommst Du auch "nur" vom jeweiligen Host dran (was eher weniger Sinn macht). Beim Tunnel bzw. SOCKS-Proxy ist es für Dich der "localhost" (also Deine Workstation) zu welcher Du initial gehst, damit die Verbindung dann durch den SSH-Tunnel wandert und Du am anderen Ende wieder rauskommst. Ähnliches Prinzip wie beim VPN, da ist es dann aber eben eine virtuelle Schnittstelle, welche vom VPN-Client erzeugt wird und die wird dann für Verbindungen in das Remote-Netz genutzt.

Das ich dennoch einen zugriff bekomme müsste ich auf dem Server noch einen Proxy einrichten?

Es besteht ein massiver Unterschied zwischen "Proxy" und "Reverse-Proxy". Für "ausgehende" Verbindung bietet sich ein "Proxy" an. Für eingehende Verbindungen (um die eigentlichen Geräte nicht "direkt" via Internet erreichbar zu machen) entsprechend ein "Reverse-Proxy".

Auf meinem Client (sofern die ssh-Verbindung steht) könnte ich dann mit meiner eigenen localhost-adresse jedoch mit der Portangabe so auf den entfernten Server zugreifen (vom broswer aus meine ich)?

So wie bereits oben beschrieben.

und wo steht der? der läuft doch dann auch auf dem Server auf dem der gewünschte erreichbare Dienst läuft zumindest wäre das in meinem Fall so oder?

Vermutlich... kann aber auch ein anderer Host im Netz sein, Fakt ist jedenfalls, dass - sofern der Browser entsprechend konfiguriert ist - sämtliche Anfragen des Browsers über den Proxy-Host gehen. Ob das nun der eigentliche "Zielhost" einer Anfrage ist, oder nicht, spielt dabei keine Rolle, sieh den Proxy-Host vllt vielmehr als "Gateway".

Etwas anderes wäre es noch, wenn Du gezielt hingehst und "bestimmte" Ports zu Dir lokal umbiegst. Das wäre dann die Option "-L" (https://linux.die.net/man/1/ssh, Stichwort "Portforwarding"). Das würde dann so laufen, dass Du Dich beim Zielhost einwählst und z.B. einen lokalen Port (z.B. 80) an den Port 80 des Zielhosts weiterleitest. Somit würdest Du unter "localhost:80" das gleiche erreichen wie bei "Zielhost:80", ist aber etwas völlig anderes, als die Geschichte mit dem SOCKS-Proxy.

Alternativ - und das wäre wohl die einfachste Lösung:

<Internet>-<Router1>-<Router2>

Du richtest auf Router2 eine VPN-Verbindung ein. Somit landest Du direkt "ganz hinten" in Deiner Netzwerk-Infrastruktur und kommst von dort aus (sofern die Routen der VPN-Verbindung passen) auch in das Netz von Router1 (und ggf. auch direkt ins Internet über die VPN-Verbindung). Das mit dem SOCKS-Proxy ist schon eine ziemliche Sonderlocke in der heutigen Zeit, grade wo es den Leuten mit den VPN-Geschichten mittlerweile so einfach gemacht wird

 

[selfmade01]

bzw. SOCKS-Proxy ist es für Dich der "localhost"

ok... nur nochmal für totale Dummies....
In Bezug auf den Zugriff via Browser.
Die Proxy-Einstellung Localhostort läuft so, dass ich dann z.B. die aufgebaute SSH-Verbindung meines PC's zum Zielhost mit dem Zugriff des Browsers auf den localhostort nutze wobei Localhost mein PC ist und Port ist dann der Zielport auf dem Zielhost bzw. auf dem Ziel-Reserve-Proxy der mich dann zum Zielhostort weiterleitet?

Das würde doch in meinem Fall der nginx-proxy-manager erledigen oder?
dort kann ich doch eine Anfrage an subdomain.domain.com die von außen kommt an einen Zielhostort weiterleiten
Das müsste doch genau dafür gedacht sein oder?

aktuell habe ich bei meinem domain-Provider schon subdomains eingerichtet und diese entsprechend via myfritz-adresse weitergeleitet.
Bei mir dann auf dem Raspberry wo mein nginx läuft würde das dann empfangen und entsprechend weitergeleitet werden oder?

Ich frage deshalb nach da mich das Thema sehr interessiert denn so verstehe ich dann besser was ich mit einem Routing und evtl. auch entsprechenden Firewall anstellen kann , was ich brauche und was sinnlos ist.

kommst Du auch "nur" vom jeweiligen Host dran (was eher weniger Sinn macht). Beim Tunnel bzw. SOCKS-Proxy ist es für Dich der "localhost"

Ich dachte da ganz anders mmmhh...
wenn z.B. der ssh-Tunnel oder der Reserve-proxy auf dem Zielserver läuft und dieser eine Anfrage über einen ssh-Tunnel bekommt... so kommt doch meine Anfrage http://localhost:3333 beim Reserve-proxy auf der Gegenseite so an dass er weiss wo der Port 3333 zu finden ist ... dem webserver z.B. für Homeassistant müsste es doch egal auf welche ip er lauscht
Ich meine, der empfangende Reverse-proxy könnte doch dann die Anfrage (sofern bei ihm im Routing so eingestellt) auf port 3333 dann zu 127.0.0.1:3333 weiterleiten?
Oder bin ich da jetzt total daneben?

Für "ausgehende" Verbindung bietet sich ein "Proxy"

Das wäre der Fall wenn mir der Server Messages vom Hass-System sendet bzw. mit meiner mobile-app kommuniziert... mails sendet etc. oder?
wird sowas im privaten Bereich eingesetzt?

 

[blurrrr]

Für externe Zugriffe bieten sich derweil eigentlich nur 2 Varianten an:

a) VPN (on demand) + interner Zugriff

VPN wäre die Einwahl ins Heimnetzwerk, Kommunikation mit internen Geräten durch einen verschlüsselten Tunnel. Da sowas mitunter auch etwas umständig sein kann, wenn man sich ständig vorher einwählen kann, gibt es noch die "on demand"-Möglichkeit (je nach OS unterschiedlich umzusetzen). Heisst soviel wie: Wenn Zugriff auf Domain XY (oder Netz XY), dann VPN-Tunnel automatisch aktivieren.

b) Reverse-Proxy

Ein System "zwischen" Zielhost und externem Teilnehmer. Externer Teilnehmer spricht "nur" mit dem Reverse-Proxy und der Reverse-Proxy wiederum spricht mit dem Zielhost. Da spielen dann u.a. Dinge wie X-Forwarded-For eine Rolle. Vorteil hierbei ist, dass Du auch div. interne Zielgeräte über den einen Reverse-Proxy ansprechen kannst. Als kleines Beispiel:

www.example.com:443 -> RP -> Webserver:80
nas.example.com:443 -> RP -> NAS:5000
ha.example.com:443 -> RP -> HA:8123
usw.

Etwas "völlig" anderes, was Du hier immer wieder ins Spiel bringst, wäre der (herkömmliche) "Proxy". Das ist ein System zwischen internen Teilnehmern und externen Zielen. Regulär eingesetzt oftmals mit Cache-Funktionalität. Nebst der Caching-Funktionalität wird sowas i.d.R. zwecks weiterer Sicherheitsmaßnahmen genutzt (Einschränkung der Zugriffe, Antivirus, etc.).

wenn z.B. der ssh-Tunnel oder der Reserve-proxy auf dem Zielserver

Da vermischt Du schon wieder 2 völlig unterschiedliche Dinge miteinander. Von mir aus vergleich den SOCKS-Proxy mit einem VPN, aber ein Reverse-Proxy hat damit rein garnichts zu tun.

so kommt doch meine Anfrage http://localhost:3333 beim Reserve-proxy auf der Gegenseite

Okay... Klärungsbedarf... DEIN Host ist für DEINEN Host der LOCALHOST... kurzum: Für Deine Workstation wird "localhost" immer Deine Workstation bleiben. Für den Proxy wird "localhost" immer der Proxy bleiben. Für das Zielsystem wird "localhost" immer das Zielsystem bleiben. Ich kann es auch anders ausdrücken: "localhost" = "ich". Sagst "Du" "ich", meinst Du "Dich". Sage "ich" "ich" meine ich "mich". Check?

"localhost" taucht auch nur in einer einzigen Ecke auf und zwar bei der Angabe des SOCKS-Proxy. Der läuft nämlich auf "localhost" (also dem Initiator der SSH-Verbindung, kurzum Deine Workstation). Vielleicht machst Du einfach mal folgendes:

netstat -tan | find "<angegebener Proxy-Port>"

Das sieht dann z.B. so aus:

  TCP    127.0.0.1:9999         0.0.0.0:0              ABHÖREN         InHost
  TCP    [::1]:9999             [::]:0                 ABHÖREN         InHost

Wie Du siehst, sind dort nur "2" Adressen angegeben: "127.0.0.1" und "::1" aka Hostname "localhost". Der SOCKS-Proxy ist also auch "nur" von Deinem lokalen System selbst (dem Initiator der SSH-Verbindung) nutzbar. Das ist auch der Grund, warum Du in den Browser-Einstellungen "localhost" (oder 127.0.0.1) eintragen musst. An der regulären Ethernetschnittstelle in Deinem LAN z.B. lauscht der SOCKS-Proxy garnicht, weswegen Du Deine Workstation nun nicht einfach als Proxy für andere Systeme im gleichen Netz nutzen könntest.

so kommt doch meine Anfrage http://localhost:3333 beim Reserve-proxy auf der Gegenseite so an dass er weiss wo der Port 3333 zu finden ist

Also nochmal... nachdem das mit "localhost" ja nun geklärt ist, wissen wir ja nun, dass da "nichts" mit "localhost:33333" ankommt. Wenn Du auf der Gegenseite etwas derartiges laufen hast, wird es mit http://<korrekte Ziel-IP im LAN>:33333 angesprochen. Du gehst ja nicht hin und sagst einfach nur "<IP>", dann würde es per default auf Port 80 (http) versucht werden. Eventuell noch auf Port 443 (https), dann ist aber Feierabend - Seite nicht erreichbar. Ergo musst Du da logischerweise auch angeben, auf welchem Port der Dienst bei der Gegenseite läuft. Im Falle von HA z.B. wäre das eben 8123. <IP>:80 geht nicht, <IP>:443 geht nicht, <IP>:8123 funktioniert, ergo musst Du das System (direkt) auch so ansprechen.

WENN..... Dir allerdings daran gelegen ist, kannst Du den Port bei z.B. HA auch umbiegen (80, oder 443 statt 8123). Wenn Du das überall so willst, musst Du es auch überall so umstellen. AUSSER... Du nutzt noch einen Reverse-Proxy dazwischen (s. Beispiel oben).

Bevor Du Dich hier aber in etlichen Welten verlierst, möchte ich Dir doch eher nahelegen, dass Du es mal via VPN auf dem 2. Router versuchst. Denke, damit solltest Du (für den Anfang) wohl am besten klar kommen Heisst ja nicht, dass man nicht noch alles andere Stricken kann, habe mich nur aufgrund der SSH-Geschichte zum SOCKS-Proxy verleiten lassen

EDIT: Ups, ganz vergessen:

Das wäre der Fall wenn mir der Server Messages vom Hass-System sendet bzw. mit meiner mobile-app kommuniziert... mails sendet etc. oder?
wird sowas im privaten Bereich eingesetzt?

Anwendungsfall: ja, privater Einsatz: eher nicht

 

[blurrrr]

Kleiner Nachtrag noch betreffend auf den Thread-Titel:

Option 1: nur VPN (Ansprache interner Gerätschaften ganz normal über die internen Adressen)
Option 2: VPN für die Verwaltung + Reverse-Proxy für die "direkt" extern erreichbaren Dienste (wenn möglich, kein Zugriff auf Management-Geschichten, ist nicht immer möglich).

Ich persönlich habe privat "garnichts" nach aussen freigegeben, Zugriff auf interne Dinge (sofern benötigt) immer nur via VPN. Somit sind auch nur die benötigten Ports zwecks VPN an ein internes VPN-Gateway freigegeben. Das in Kombi mit der automatischen VPN-Einwahl (in ein gesondertes VPN-Netzwerk, aus welchem auch nur die "benötigten" Dinge erreichbar sind). Lässt sich aber z.B. mit einfachen SOHO-Routern eher nicht vernünftig umsetzen, daher läuft hier auch eine entsprechende Hardware-Firewall. Wurde hier auch schon divers diskutiert, oftmals genutzt wird z.B. pfSense/OPNsense, vielleicht kommt sowas für Dich ja auch in Frage

EDIT: Die Freigabe direkt von HomeAssistant öffentlich im Netz ist allerdings nicht die beste Idee im Hinblick auf mögliche Sicherheitslücken ("Durch die Lücke könnten Angreifer ohne Authentifizierung direkt mit der Supervisor-API interagieren...")

 

[selfmade01]

wow, vielen vielen herzlichen Dank... du hast es mir wirklich super und ausführlich erklärt.... Danke für deine Geduld.

Ich möchte damit nun ein bisschen mehr testen... kennst du ein Netzwerktool (kostenlos wenn möglich) indem ich z.B. von meiner Windows WS (da habe ich 2 Netzwerkkarten drin eth und wlan. Da könnte ich schön testen und sehen wie die Anfragen ankommen udn weitergeleitet werden... auch so ein routing tool um mal genauer die Route zu verfolgen
Da müsste es doch was geben ...

edit:
ein Beispiel:
ich habe hier eine WS mit zwei Netzwerkkarten 1x lan und 1 x wlan
mit der wlan möchte ich meine Anmeldung an meinem raspberry testen da ich diesen auch als Hotspot einsetze... die hat also eine ip-adresse vom wlan-netz mit 10.3.141.0/24... die lan-karte hängt im 192.168.2.0/24 Netz...
wie kann man angeben das der win pc beim traceroute die wlan-verbindung nutzen soll.... ohne das ich das lan abstöpseln muss?
beim traceroute finde ich keine möglichkeit das er eine bestimtes device als Ausgang verwenden soll

 

[blurrrr]

Da könnte ich schön testen und sehen wie die Anfragen ankommen udn weitergeleitet werden...

Was soll denn da "weitergeleitet" werden? Deine Workstation ist kein Router. Zum "gucken" kannste z.B. TCPView benutzen. Was das Routing allgemein angeht, da schaust Du einfach in die Routing-Tabelle des jeweiligen Gerätes ("route print -4" z.B.).

 

[selfmade01]

allgemein angeht, da schaust Du einfach in die Routing-Tabelle des jeweiligen Gerätes ("route print -4" z.B.).

ich dachte da an ein Tool was u.a auch traceroute beinhaltet... da sieht man zumindest wie der Weg ist.
ich denke ich muss mich in das Thema noch viel mehr einarbeiten. aber wird schon

 

[blurrrr]

Da brauchst Du kein "Tool" für... Linux/OSX "traceroute <Host>", Windows "tracert <Host>"... für ein bisschen mehr Infos unter Windows einfach "pathping <Host>". Für die Konsole liegt eigentlich genügend vor... Da ich eher der Konsolen-Typ bin, muss ich dann bei irgendwelchen grafischen All-in-One-Windows-Tools doch eher passen, sorry

ich denke ich muss mich in das Thema noch viel mehr einarbeiten. aber wird schon

Korrekt, dran bleiben, wird schon