Hauptmenü

Port 8084 über Internet

Begonnen von HarryB, 30 November 2015, 12:54:37

Vorheriges Thema - Nächstes Thema

Tedious

#15
Moin,

ich hab das Thema Apache2 mal getestet. Beim Start des Services bekomme ich noch eine Fehlermeldung:

pi@FhemServer ~ $ sudo invoke-rc.d apache2 reload
[....] Reloading web server config: apache2apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1 for ServerName
. ok


Ansatz ist an sich wie folgt - ich nutze u.a. einen WHS2011 Server im Netzwerk. Die URL bekomme ich auf die entsprechende (eigene aktuelle) IP von Microsoft, also http://********.homeserver.com. Über 8080 läuft der Zugriff auf den WHS, ohne Probleme. Port 8084 ist in der FB auf den RPI umgebogen. Hab ehrlich gesagt grade ein Fragezeichen über dem Kopf.

Via http://*****.homeserver.com lande ich auf dem WHS. Via http://*****.homeserver.com/fhem bekomme ich den 404 - der düfte vom WHS kommen, da er das Verzeichnis nicht kennt - klar, ich komme ja per 80/8080 rein und der WHS sagt - ätsch. Per http://*****.homeserver.com/fhem:8084 bekomme ich einen "Serverfehler in der Anwendung" auf dem Handy - Laufzeitfehler. Hier stimmt offensichtlich noch was in der Config nicht... jemand einen Tip für mich?

Edit: das Verhalten ändert sich nicht wenn ich in der FB den request von 8084 auf Port 80 RPI umbiege...

(http://www2.pic-upload.de/thumb/29003440/apache.jpg)
FHEM auf Proxmox-VM (Intel NUC) mit 4xMapleCUN (433,3x868) und Jeelink, HUE, MiLight, Max!, SonOff, Zigbee, Alexa, uvm...

Wuppi68

Zitat von: Tedious am 01 Dezember 2015, 09:56:58
Moin,

ich hab das Thema Apache2 mal getestet. Beim Start des Services bekomme ich noch eine Fehlermeldung:

pi@FhemServer ~ $ sudo invoke-rc.d apache2 reload
[....] Reloading web server config: apache2apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1 for ServerName
. ok


Ansatz ist an sich wie folgt - ich nutze u.a. einen WHS2011 Server im Netzwerk. Die URL bekomme ich auf die entsprechende (eigene aktuelle) IP von Microsoft, also http://********.homeserver.com. Über 8080 läuft der Zugriff auf den WHS, ohne Probleme. Port 8084 ist in der FB auf den RPI umgebogen. Hab ehrlich gesagt grade ein Fragezeichen über dem Kopf.

Via http://*****.homeserver.com lande ich auf dem WHS. Via http://*****.homeserver.com/fhem bekomme ich den 404 - der düfte vom WHS kommen, da er das Verzeichnis nicht kennt - klar, ich komme ja per 80/8080 rein und der WHS sagt - ätsch. Per http://*****.homeserver.com/fhem:8084 bekomme ich einen "Serverfehler in der Anwendung" auf dem Handy - Laufzeitfehler. Hier stimmt offensichtlich noch was in der Config nicht... jemand einen Tip für mich?

Edit: das Verhalten ändert sich nicht wenn ich in der FB den request von 8084 auf Port 80 RPI umbiege...

(http://www2.pic-upload.de/thumb/29003440/apache.jpg)

da kenn Dein Apache nicht deinen kompletten Servernamen .... und benutzt deshalb 127.0.0.1, also sich selber.

Von der Logic her, solltest Du als ersten Apache zum laufen bekommen ( http://askubuntu.com/questions/256013/could-not-reliably-determine-the-servers-fully-qualified-domain-name )

und danach richtest Du den Proxy entsprechend ein ( http://www.fhemwiki.de/wiki/Apache_Authentication_Proxy )

und die Weiterleitung auf der Fritte direkt auf den rpi:8084 brauchst Du dann nicht
FHEM unter Proxmox als VM

Tedious

Vielen Dank für die Info! Localhost ist behoben. Rest bleibt gleich, hab die Konfig direkt übernommen, aber es bleibt leider dabei - Serverfehler in der Anwendung :(

Um die FB komme ich nicht drumrum - IMHO. Alle 80/8080 Requests laufen auf den WHS, wenn ich an den Request ein /fhem anhänge lande ich natürlich wieder auf dem WHS - der damit nichts anfangen kann weil der IIS keinen Ordner fhem bereitstellt.

In der FB ist RPI so definiert dass sie Anfragen auf 8084 an den RPI weitergibt. Hier ist es egal ob ich den Request an den 80 oder 8084 des RPI weiterleite, die Fehlermeldung ist die gleiche wie in obigem Bild :(

Muss gestehen dass ich im IIS recht fit bin, bei Apache aber doch ziemlich unbeholfen :( Eine Weiterleitung im IIS auf den RPI wäre möglich bei request des Verzeichnisses, aber der WHS ist per LightsOut gesteuert und daher nicht immer an.
FHEM auf Proxmox-VM (Intel NUC) mit 4xMapleCUN (433,3x868) und Jeelink, HUE, MiLight, Max!, SonOff, Zigbee, Alexa, uvm...

Wernieman

Was Du immer noch nicht beantwortet hast, welche Betriebsysteme hast Du am laufen?

Wie sieht die Netzwerkkonfig der betreffenden Systeme aus?
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Tedious

Ist an sich nichts komplexes. ISP ist Unitymedia, Modem/Router ist eine FritzBox Cable. Von dort weg hängt alles an einem geswitchten GBit-Netzwerk. Mal abgesehen von Laptops, Handy, Tablets, Multimediazeugs... relevant für die Struktur/Kommunikation sind im Prinzip 3 Geräte:

1x WHS2011 (Basis Win Server 2008RC2), kabelgebunden. IIS aktiv, zuständig u.a. für DNS-Auflösung (*****.homeserver.com), Fileserver, Plex-Sever, etc.
1x RPI2, kabelgebunden. FHEM, CUPS, Webmin.
1x WDMyCloud, redundantes Backup-LW/Spiegelung WHS, Log-Laufwerk für FHEM.

FB betreibt Forwarding von 80/8080 extern auf WHS/IIS 80/8080
FB betreibt Forwarding von 8084 extern auf FHEM

Lief via https problemlos, aufgrund der Diskussion wollte ich umstellen. Configfiles aus dem Wiki habe ich übernommen.
FHEM auf Proxmox-VM (Intel NUC) mit 4xMapleCUN (433,3x868) und Jeelink, HUE, MiLight, Max!, SonOff, Zigbee, Alexa, uvm...

Wuppi68

dann solltest Du entweder

a) eine Weiterleitung vom IIS auf den RPI einstellen
http://www.msxfaq.de/internet/wap.htm
http://www.iis.net/learn/extensions/configuring-application-request-routing-(arr)/creating-a-forward-proxy-using-application-request-routing


oder

b) einen Port auf der FB and den Apache des RPI weiterleiten (siehe Wiki)
FHEM unter Proxmox als VM

Tedious

Das habe ich doch... ;)

a) scheidet aus wie geschrieben, da der WHS nicht dauernd an ist / LightsOut Client, bei Bedarf per WOL
b) hab ich gemacht, Port 8084 incoming an FB --> Port 80 an RPI

Da das Ganze mit HTTPS problemlos funktioniert hat liegt das Problem bei dem nach WIKI eingerichteten Apache... und da klemmts noch bei mir :)
FHEM auf Proxmox-VM (Intel NUC) mit 4xMapleCUN (433,3x868) und Jeelink, HUE, MiLight, Max!, SonOff, Zigbee, Alexa, uvm...

darkness

#22
was sagt denn das Error-Log vom Apache? Nutze den Apache nur auf einen Server und nicht auf dem Pi. Das dürfte aber dann das gleiche sein, oder.

Müsste also irgendwo unter /var/log/Apache liegen. Was kommt den beim Aufruf von Per http://*****.homeserver.com:8084.
In der Grundinstallation sollte dann die Default html-datei aufgerufen werden.
Den Aufruf http://*****.homeserver.com/fhem:8084 kenne ich so nicht. Dacht das geht nur ohne Ordner bzw http://*****.homeserver.com:8084/fhem

Wernieman

Laut RTF ist http://*****.homeserver.com:8084/fhem richtig ...
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

chris1284

Zitat von: marvin78 am 01 Dezember 2015, 08:15:11
Stichwort ist hier VPN per URL on demand... Ein Button auf dem Homescreen, damit VPN einschalten
thx, kannte nur den weg über einstellungen.

Frank_Huber

Zitat von: Tedious am 01 Dezember 2015, 11:58:31
b) hab ich gemacht, Port 8084 incoming an FB --> Port 80 an RPI

da ist der fehler.
Port 8084 auch für den RPI!

/Frank

Tedious

Danke für die Hinweise. 8084 war die ursprüngliche Einstellung, zum testen hab ich mal auf 80 gestellt - keine Änderung.

Das Apache2 Error.log sagt (Ausschnitt):

[Tue Dec 01 10:02:03 2015] [error] [client 109.84.0.35] Invalid method in request \x16\x03\x03
[Tue Dec 01 10:02:03 2015] [error] [client 109.84.0.35] Invalid method in request \x16\x03\x01
[Tue Dec 01 10:02:03 2015] [error] [client 109.84.0.35] Invalid method in request \x16\x03\x03
[Tue Dec 01 10:02:03 2015] [error] [client 109.84.0.35] Invalid method in request \x16\x03\x01
[Tue Dec 01 10:05:02 2015] [error] [client 176.199.233.152] Invalid method in request \x16\x03\x01
[Tue Dec 01 10:24:06 2015] [notice] caught SIGTERM, shutting down
[Tue Dec 01 10:24:11 2015] [notice] Apache/2.2.22 (Debian) proxy_html/3.0.1 configured -- resuming normal operations
[Tue Dec 01 10:24:22 2015] [notice] SIGUSR1 received.  Doing graceful restart
[Tue Dec 01 10:24:22 2015] [notice] Apache/2.2.22 (Debian) proxy_html/3.0.1 configured -- resuming normal operations
[Tue Dec 01 10:26:34 2015] [error] [client 109.84.0.35] Invalid method in request \x16\x03\x03
[Tue Dec 01 10:26:34 2015] [error] [client 109.84.0.35] Invalid method in request \x16\x03\x01
[Tue Dec 01 10:26:34 2015] [error] [client 109.84.0.35] Invalid method in request \x16\x03\x03
[Tue Dec 01 10:26:34 2015] [error] [client 109.84.0.35] Invalid method in request \x16\x03\x01
[Tue Dec 01 10:26:43 2015] [error] [client 109.84.0.35] Invalid method in request \x16\x03\x03
[Tue Dec 01 10:26:43 2015] [error] [client 109.84.0.35] Invalid method in request \x16\x03\x01
[Tue Dec 01 10:26:43 2015] [error] [client 109.84.0.35] Invalid method in request \x16\x03\x03
[Tue Dec 01 10:26:43 2015] [error] [client 109.84.0.35] Invalid method in request \x16\x03\x01



Access-Log:

109.84.0.35 - - [01/Dec/2015:10:02:03 +0100] "\x16\x03\x03" 501 290 "-" "-"
109.84.0.35 - - [01/Dec/2015:10:02:03 +0100] "\x16\x03\x01" 501 290 "-" "-"
109.84.0.35 - - [01/Dec/2015:10:02:03 +0100] "\x16\x03\x03" 501 290 "-" "-"
109.84.0.35 - - [01/Dec/2015:10:02:03 +0100] "\x16\x03\x01" 501 290 "-" "-"
176.199.233.152 - - [01/Dec/2015:10:05:02 +0100] "\x16\x03\x01" 501 290 "-" "-"
109.84.0.35 - - [01/Dec/2015:10:26:34 +0100] "\x16\x03\x03" 501 290 "-" "-"
109.84.0.35 - - [01/Dec/2015:10:26:34 +0100] "\x16\x03\x01" 501 290 "-" "-"
109.84.0.35 - - [01/Dec/2015:10:26:34 +0100] "\x16\x03\x03" 501 290 "-" "-"
109.84.0.35 - - [01/Dec/2015:10:26:34 +0100] "\x16\x03\x01" 501 290 "-" "-"
109.84.0.35 - - [01/Dec/2015:10:26:43 +0100] "\x16\x03\x03" 501 290 "-" "-"
109.84.0.35 - - [01/Dec/2015:10:26:43 +0100] "\x16\x03\x01" 501 290 "-" "-"
109.84.0.35 - - [01/Dec/2015:10:26:43 +0100] "\x16\x03\x03" 501 290 "-" "-"
109.84.0.35 - - [01/Dec/2015:10:26:43 +0100] "\x16\x03\x01" 501 290 "-" "-"


Scheint ja zumindest was anzukommen, Routing ist OK...

FHEM auf Proxmox-VM (Intel NUC) mit 4xMapleCUN (433,3x868) und Jeelink, HUE, MiLight, Max!, SonOff, Zigbee, Alexa, uvm...

darkness

kannst du lokal auf den Apache per ssl zugreifen und eine einfach html-Seite aufrufen?
Scheint als wenn die SSL-Verschlüsselung nicht richtig funktioniert.


Tedious

Jau, so hab ich mir das auch hergeleitet... hab Tante Google bfragt, soweit ich das verstehe erwartet der Browser SSL und Apache sendet Plain... ich hab die entsprechenden Tips mal probiert, leider keine Besserung. Muss gestehen dass ich bei Apache und der Config nicht wirklich durchblicke :(
FHEM auf Proxmox-VM (Intel NUC) mit 4xMapleCUN (433,3x868) und Jeelink, HUE, MiLight, Max!, SonOff, Zigbee, Alexa, uvm...

darkness

#29
Eher anders herum. Der Apache bekommt SSL und kann damit nichts anfangen. ;) Kannst du deine Apache-Config mal anhängen?

Edit: Der Reverse-Proxy leitet aber nicht auf https weiter, oder? (Nur um sicher zu gehen)  :D