Hallo zusammen,
eventuell hat hier ja jemand eine Idee, ich bin mit meinem Latein ziemlich am Ende.
Infos zur Infrastruktur: diverse Handys, Laptops, Multimediageräte etc entweder per WLan oder geswitchtem GBit-Netzwerk vorhanden. Provider ist Unitymedia, Router eine FB6360. Kritische Geräte im Netzwerk um die es sich hier dreht sind ein WHS 2011, eine WDMycloud und ein RPI.
Ausgangslage: WHS bzw. die nötigen Ports (80, 443, RDC, Plex...) in der FB als Portweiterleitung konfiguriert. DNS übernimmt der WHS, der via MS eine ******@hmoeserver.com als Adresse zugewiesen bekommt. WHS ist von extern problemlos zu erreichen, interne Administrattion via RDC, extern auch via Teamviewer. Soweit, so gut.
Zuhause übernimmt ein RPI mit einem kleinen FHEM-Server die Hausautomatisation, stellt einen Drucker per CUPS zur Verfügung, etc.. FHEM bietet auf den Ports 8083, 8084 und 8085 auf Browser, Handy und Tablet optimierte Webseiten zur Steuerung und Monitoring bereit. Intern funktioniert das alles bestens, teilweise übernehme ich die Steuerungen und Statusmeldungen auch via Kommunikation von extern per WhatsApp (yowsop-Client auf dem RPI) --> hier kann ich per WA bspw. Temperaturen anfragen und bekomme das reading per WA zurück oder kann Geräte schalten. Um eine volle Funktionalität nach außen zu gewärleisten will ich aber den Port 8083 nach außen weitergeben um z.B. per Handy auf FHEM direkt zugreifen zu können.
Ich habe dazu auf dem RPI einen reverse Proxy eingerichtet der 8084 auf Fhem weitergibt, sich authentifiziert und mir die Daten liefert. Funktioniert im INTERNEN Netz hervorragend (192.168.192.10/fhem biegt mich um auf den FHEM Webserver auf dem RPI, also die URL 192.168.192.10/fhem:8084). Leider funktioniert das von extern NICHT (******.homeserver.com:8084/fhem). Gibt einen lapidaren Timeout. Setze ich den RPI vorübergehend testweise in die DMZ komme ich mit dem Aufruf *****.homeserver.com/fhem wie im internen Netz problemlos auf FHEM den RPI (also wie intern per Aufruf, s. oben --> 192.168.192.10/fhem biegt mich um auf den FHEM Webserver auf dem RPI, also die URL 192.168.192.10/fhem:8084).
Gebe ich keinen Port an lande ich, wie er das soll, direkt auf dem WHS Webserver, hänge ich da ein lapidates /fhem an bekomme ich ienen 404 - soll er ja auch, das Verzeichnis existiert ja auf dem WHS nicht (Port 80).
Hat hierzu jemand eine Idee??? Kann ja nur noch an der FB liegen, denn bei RIP@DMZ lüppt ja alles wie es soll. Routing in der FB besagt nichts anderes als Request auf Port 8084 --> 192.68.192.10:8084. Ich blick das nicht....
--- [2015-12-04 09:34 CET] Automatisch zusammengeführter Beitrag ---
Moin,
Falls es irgendwann mal jemanden interessiert
Ich habe Port 443 fix auf den WHS gebogen, das Port 80 Routing auf den WHS gelöscht (der redirected eh auf 443) und Port 80 auf den RPI geleitet. Der wiederum macht denn ein reverse proxying bei Angabe url/fhem auf Port 8084 und alles läuft.
eventuell hat hier ja jemand eine Idee, ich bin mit meinem Latein ziemlich am Ende.
Infos zur Infrastruktur: diverse Handys, Laptops, Multimediageräte etc entweder per WLan oder geswitchtem GBit-Netzwerk vorhanden. Provider ist Unitymedia, Router eine FB6360. Kritische Geräte im Netzwerk um die es sich hier dreht sind ein WHS 2011, eine WDMycloud und ein RPI.
Ausgangslage: WHS bzw. die nötigen Ports (80, 443, RDC, Plex...) in der FB als Portweiterleitung konfiguriert. DNS übernimmt der WHS, der via MS eine ******@hmoeserver.com als Adresse zugewiesen bekommt. WHS ist von extern problemlos zu erreichen, interne Administrattion via RDC, extern auch via Teamviewer. Soweit, so gut.
Zuhause übernimmt ein RPI mit einem kleinen FHEM-Server die Hausautomatisation, stellt einen Drucker per CUPS zur Verfügung, etc.. FHEM bietet auf den Ports 8083, 8084 und 8085 auf Browser, Handy und Tablet optimierte Webseiten zur Steuerung und Monitoring bereit. Intern funktioniert das alles bestens, teilweise übernehme ich die Steuerungen und Statusmeldungen auch via Kommunikation von extern per WhatsApp (yowsop-Client auf dem RPI) --> hier kann ich per WA bspw. Temperaturen anfragen und bekomme das reading per WA zurück oder kann Geräte schalten. Um eine volle Funktionalität nach außen zu gewärleisten will ich aber den Port 8083 nach außen weitergeben um z.B. per Handy auf FHEM direkt zugreifen zu können.
Ich habe dazu auf dem RPI einen reverse Proxy eingerichtet der 8084 auf Fhem weitergibt, sich authentifiziert und mir die Daten liefert. Funktioniert im INTERNEN Netz hervorragend (192.168.192.10/fhem biegt mich um auf den FHEM Webserver auf dem RPI, also die URL 192.168.192.10/fhem:8084). Leider funktioniert das von extern NICHT (******.homeserver.com:8084/fhem). Gibt einen lapidaren Timeout. Setze ich den RPI vorübergehend testweise in die DMZ komme ich mit dem Aufruf *****.homeserver.com/fhem wie im internen Netz problemlos auf FHEM den RPI (also wie intern per Aufruf, s. oben --> 192.168.192.10/fhem biegt mich um auf den FHEM Webserver auf dem RPI, also die URL 192.168.192.10/fhem:8084).
Gebe ich keinen Port an lande ich, wie er das soll, direkt auf dem WHS Webserver, hänge ich da ein lapidates /fhem an bekomme ich ienen 404 - soll er ja auch, das Verzeichnis existiert ja auf dem WHS nicht (Port 80).
Hat hierzu jemand eine Idee??? Kann ja nur noch an der FB liegen, denn bei RIP@DMZ lüppt ja alles wie es soll. Routing in der FB besagt nichts anderes als Request auf Port 8084 --> 192.68.192.10:8084. Ich blick das nicht....
--- [2015-12-04 09:34 CET] Automatisch zusammengeführter Beitrag ---
Moin,
Falls es irgendwann mal jemanden interessiert
Ich habe Port 443 fix auf den WHS gebogen, das Port 80 Routing auf den WHS gelöscht (der redirected eh auf 443) und Port 80 auf den RPI geleitet. Der wiederum macht denn ein reverse proxying bei Angabe url/fhem auf Port 8084 und alles läuft.