Hallo,
ich kann nicht über das Internet auf die Weboberfläche (8084) zugreifen.
Portforwarding auf der Fritzbox ist eingerichet
FHEM ist auch konfiguriert (also Passwort, etc. gesetzt)
Intern über den Port funzt das. Also denke ich mal ist das korrekt. Username und PW werden abgefragt.
Da ich dachte, der Raspberry würde evtl. was blocken, habe ich mit sudo /sbin/iptables --flush mal die Firewall ausgeschaltet.
Aber auch danach ging es nicht.
Portforwarding über die FB geht generell. Anderer Port für eine Überwachungskamera funktioniert einwandfrei.
Hat jemand eine Idee?
Zu Portforwarding bekommst du von mir keinen Tipp.
Ich habe aber trotzdem einen guten: Verwende VPN und du bist auf der sicheren und zuverlässigen Seite.
VPN kann ich auch nur empfehlen. Auf der FB ist das einfach einzurichten.
Wenn Du kein https für fhem laufen lässt, dann dürften die Nuztzer/Passwort - Abfragen auch noch im Klartext über das Internet laufen.
Also -> VPN.
'Elektrolurch
Alternativ über einen https-Proxy (z.B. apache) mit eigener Authentifizierung .....
Aber mal eine andere Frage: Welcher router ist auf Deinem FHEM-Rechner gesetzt? Was für ein Betriebsystem?
Ich wüsste nicht was gegen HTTPS mit Zertifikat sprechen würde - lasse mich aber gerne belehren...
Naja ... fhem ist nicht gerade optimal abgesichert .. für einen direkten Zugriff aus dem Netz.
Naja, ein Portscan auf den 8084 liefert bei mir von extern geschlossenen Port - und dazu habe ich verschlüsselt User/Password. Ich dachte das reicht?!
Der Portscan liefert nix, weil Deine Weiterleitung nicht funktioniert, sonst wäre der Port offen. Um von außen auf fhem zuzugreifen solltest du aus Sicherheitsgründen wirklich ein vpn oder reverse proxy wie apache, nginx, netscaler,... verwenden.
nur weil es technisch "einfach" mit der Portweiterleitung sollte man es mit FHEM nicht machen ...
Das Risiko ist einfach viel zu groß - und der Staatsanwalt bzw. der Rechtevertreteranwalt klopfen vermutlich ganz schnell mit Forderungen bei Dir an der Haustür.
Ohne VPN kein FHEM von draussen
/signed.
per vpn von draussen rein, dann fhem intern.
generell sollte es aber dennoch gehen. hat dein fhem device die richtige ip-config?
subnet/gateway gesetzt? bei manueller ip vergabee vergisst man das gern...
Kannst du von deiner Fritzbox deinen raspi anpingen/erreicht ?
Kannst du von deinem Raspi die Fritzbox anpingen/erreichen?
kurzum .... stimmt dein Routing.
Dann kann man ja in der Fritzbox noch rechnerspezifische Einstellungen machen.
Den ganzen Spielkram in der Fritzbox eben .... hast du dir da nichts zu-konfiguriert ?
Zitat von: Wuppi68 am 30 November 2015, 17:25:53
Das Risiko ist einfach viel zu groß - und der Staatsanwalt bzw. der Rechtevertreteranwalt klopfen vermutlich ganz schnell mit Forderungen bei Dir an der Haustür.
da fhem in der regel nicht als root läuft wird man kaum wegen sinnlos aufgedrehten heizungen und tags über geschaltetem licht verklagt werden....
aber sicher übertrieben gut um leuten angst / respekt vor dem protweiterleiten / dem öffnen von ports nach außen angst zu machen ::)
ich denke man muss den spagat zwischen sicherheit und verwaltbarkeit finden.... im wiki gibts einen schönen artikel zum thema http://fhemwiki.de/wiki/Apache_Authentication_Proxy
proxy. diesen dann noch statt http mit https betreiben und ggf. clientzertifikate zur anmeldung und das reciht dann in der regel.
@vpn: lustige sache und mit fritzbox für jeden einfach einzurichten. auf mobilen endgeräten aber ehr unpraktikabel zu nutzen wie ich finde (iphone zb).
bei den telekom standard routern muss man sich zum von dann zb mehr tun. und ein leihenaft eingerichtetes vpn ist auch nicht der brüller in sachen sicherheit.
zum problem: ist evtl in fhemweb allowfrom gesetzt?
Zitat von: chris1284 am 01 Dezember 2015, 08:07:44
@vpn: lustige sache und mit fritzbox für jeden einfach einzurichten. auf mobilen endgeräten aber ehr unpraktikabel zu nutzen wie ich finde (iphone zb).
Lustig ist, dass du das iPhone ansprichst, denn genau damit ist es sehr praktikabel nutzbar. Stichwort ist hier VPN per URL on demand. Das ist einiges der wenigen Themen, bei denen Android (ohne root) tatsächlich unpraktikabler ist. Aber auch nicht deutlich. Ein Button auf dem Homescreen, damit VPN einschalten und dann die WebApp öffnen macht max 3 Klicks. Sehr praktikabel, wie ich finde. Insgesamt für den Anfänger mit FritzBox ist es deutlich leichter und praktikabler als viele andere Möglichkeiten und sicherer als Portweiterleitung, ist es in jedem Fall. Diese sollte man vermeiden, wenn es eben geht.
Zitat:
@vpn: lustige sache und mit fritzbox für jeden einfach einzurichten. auf mobilen endgeräten aber ehr unpraktikabel zu nutzen wie ich finde (iphone zb).
bei den telekom standard routern muss man sich zum von dann zb mehr tun. und ein leihenaft eingerichtetes vpn ist auch nicht der brüller in sachen sicherheit.
Das meiste hat ja schon mein Vorgänger hierzu geschrieben.
Wer keine Fritzbox hat, kann auch OpenVPN verwenden. Dazu gibt es jede Menge gute Anleitungen im Netz. Das hat auch noch den Charme, dass man das nicht über IPSec, sondern SSL betreibt und den Port frei wählen kann. Ich habe schon Hotspots gesehen, die VPN nicht durchgelassen haben und mit OpenVPN könnte man auch das umgehen.
Habe mir das schon auf dem 'Cubie eingerichtet, warte nur noch auf das iPhone, das ist bestellt....
Elektrolurch
Zitat von: chris1284 am 01 Dezember 2015, 08:07:44
da fhem in der regel nicht als root läuft wird man kaum wegen sinnlos aufgedrehten heizungen und tags über geschaltetem licht verklagt werden....
aber sicher übertrieben gut um leuten angst / respekt vor dem protweiterleiten / dem öffnen von ports nach außen angst zu machen ::)
Hi Chris,
ich denke wer weiss, was er tut stellt diese Frage nicht und hat das Risiko schon selbst eingeschätzt.
Wer diese Frage stellt, dem fehlt mit allergrößter Wahrscheinlichkeit der nötige Hintergrund und deshalb heißt es für mich ganz klar abraten.
Gruß
Ralf
PS.: Die kalte oder warme Heizung ist das harmloseste was passieren kann :-) Als Spam Verteiler zu fungieren ist auch noch langweilig ... so richtig spanend wird es dann bei Msuik/Video Verteilung, Kipo's ...
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) (http://www.pic-upload.de/view-29003440/apache.jpg.html)
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) (http://www.pic-upload.de/view-29003440/apache.jpg.html)
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
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.
Was Du immer noch nicht beantwortet hast, welche Betriebsysteme hast Du am laufen?
Wie sieht die Netzwerkkonfig der betreffenden Systeme aus?
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.
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)
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 :)
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
Laut RTF ist http://*****.homeserver.com:8084/fhem richtig ...
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.
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
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...
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.
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 :(
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
Hi,
ah, OK. Ich hab das Ganze jetzt erstmal zurück auf "ursprung" gesetzt und die Pakete deinstalliert. Ich setze das noch einmal von Grund auf neu auf und schau mal, denn Poste ich gerne auch die Config.
Als Config hab ich an sich die aus dem Wiki 1:1 übernommen:
<Location /fhem>
# ProxyPass/ProxyPassReverse leitet HTTP requests auf eine andere URL um
ProxyPass http://localhost:8084/fhem
ProxyPassReverse http://localhost:8084/fhem
# ProxyHTMLURLMap passt Links im HTML/JavaScript Source an
ProxyHTMLURLMap / /fhem/
ProxyHTMLURLMap /fhem/ /fhem/
AuthType Basic
AuthName "Password Required"
AuthUserFile /etc/fhem-htpasswd
Require valid-user
Order deny,allow
Allow from all
</Location>
Tante Edith:
Ich werde mich mal hier entlang hangeln wenns die Zeit nachher zulässt : https://gist.github.com/gbirke/8608543 (https://gist.github.com/gbirke/8608543)
Hmmm... auch nicht Zielführend. Wenn ich die sites-available einfüge (nur fhemphone @8084) spuckt er beim Restart apache2 fEHLER AUS .8
[....] Starting web server: apache2Syntax error on line 10 of /etc/apache2/sites-enabled/fhemphone:
Invalid command 'ProxyHTMLURLMap', perhaps misspelled or defined by a module not included in the server configuration
Action 'start' failed.
The Apache error log may have more information.
So langsam bin ich fast verleitet auf SSL/Cert zu verzichten und VPN zu nutzen >:( Für mich als IIS/Win-Nutzer ist die Konfig unter Linux ein Mysterium... zumal die freundlichen Einträge im Error-Log für mich wenig hilfreich sind :(
[Wed Dec 02 11:26:43 2015] [notice] caught SIGTERM, shutting down
Na das steht im wiki beschrieben:
Zitat
Falls nach dem Neustart des Apache folgende Fehlermeldung kommt:
Invalid command 'ProxyHTMLURLMap', perhaps misspelled or defined by a module not included in the server configuration
Action 'configtest' failed.
The Apache error log may have more information.
fehlt das Paket libapache2-mod-proxy-html. Einfach mit
apt-get install libapache2-mod-proxy-html
nachinstallieren.
Also Error-Ausgaben lesen ist immer sinnvoll, egal ob Win oder Linux:
ZitatInvalid command 'ProxyHTMLURLMap', perhaps misspelled or defined by a module not included
Und eigentlich sind (die meisten) Linux-Deamons gesprächiger als die von Windows ...
Paket ist installiert. Auch ein apt-get install --remove, mit anschließendem autoremove und Neuinstallation änder nichts an dem Fehler - leider. Die Error-Ausgabe habe ich gelesen und die ersten 20 Google-resultate zu dem Fehler auch. Leider hat keiner der Workarunds funktioniert. Btw, interessant - und mir erschließen sich leider nciht diz Zusammenhänge. Die Definition aus dem Wiki
ProxyHTMLURLMap / /fhem/
ProxyHTMLURLMap /fhem/ /fhem/
frisst er, aus dem verlinkten Howto
ProxyHTMLURLMap / /fhem/
ProxyHTMLURLMap /fhem/ /fhem/
meckert er in der Errormeldung an - exakt diese Zeile. Vielleicht habe ich Tomaten auf den Augen, aber für mich sieht das gleich aus?!
Da Du "Windows-Fuzi" (Sorry), wie hast Du die Datei bearbeitet?
Achtung:
Windows verwendet einen anderen Zeilenendcode als Unix ... eventuell mit "dos2unix" mal die Codierung ändern
Kein Problem :) Via Putty-Session, als Editor nehme ich immer nano - vi und ich werden keine Freunde mehr werden :) Win-seitig nutze ich Notepad++ als Editor. Ich werde mal weiter basteln - VPN wird keine Alternative sein. Ich nutze ein Windows-Phone, lt. AVM:
ZitatDie FRITZ!Box unterstützt allerdings nicht das von Windows Phone 8.1 für VPN-Verbindungen verwendete IKEv2-Protokoll. Es ist daher derzeit nicht möglich, mit Windows Phone eine VPN-Verbindung zur FRITZ!Box herzustellen.
L2TP/IPSec kann sie auch nicht :( Also nichts halbwegs "modernes" :(
Zitat von: Tedious am 02 Dezember 2015, 13:51:51
Kein Problem :) Via Putty-Session, als Editor nehme ich immer nano - vi und ich werden keine Freunde mehr werden :) Win-seitig nutze ich Notepad++ als Editor. Ich werde mal weiter basteln - VPN wird keine Alternative sein. Ich nutze ein Windows-Phone, lt. AVM:
L2TP/IPSec kann sie auch nicht :( Also nichts halbwegs "modernes" :(
EDIT - falls jemand später ähnliche Probleme haben sollte, für die Nachwelt:
ich habe Apache jetzt noch mal komplett auf Null zurückgesetzt. Da hat er ein bisschen gezickt, daher diese Vorgehensweise aus einem anderen Forum:
Hmm, ich habe das mal rekonstruiert und sehe, dass die Konfigurationsdateien nicht neu geschrieben werden. Das liegt wohl daran, dass nicht alle Pakete komplett entfernt werden. Folgendes sollte aber funktionieren:
Zunächst musst du herausfinden, welche Pakete installiert wurden:
sudo dpkg --get-selections | grep apache
Diese musst du dann komplett entfernen:
sudo apt-get remove --purge apache2 apache2-mpm-worker apache2-utils apache2.2-bin apache2.2-common
Wir wollen ganz sicher gehen, dass keine falschen Konfigurationen mehr vorhanden sind:
sudo rm -rf /etc/apache2
Danach apache2 neu installieren:
sudo apt-get install apache2Anschließend kam noch die Meldung zum Thema 127.0.0.1 bzw. localhost. Gefixt wie folgt:
sudo nano"gedit /etc/apache2/conf.d/fqdn"
eintragen: ServerName localhost
Apache ist wieder "jungfräulich", ich beginne mal von vorne...
So, ich nochmal... ich glaube ich kann das Problem weiter eingrenzen.
Apache neu aufgesetzt, alles nur konfiguriert. Im internen (!) Netz klappt das nun (192.168.192.10/fhem landet sauber auf dem Webfrontend Port 8084). prima, prinzipiell läufts.
Problem Konfig dürfte bei der Fritzbox liegen.
Extern:
via ******.homeserver.com routet er auf den WHS, wie er soll. Da die Ports 80/8080/443 auf den WHS verweisen läuft ein externes *******.homeserver.com/fritz beim WHS auf und somit in einem 404 - soweit, so gut, so korrekt.
Übergebe ich nun den Port im Browser *******.homeserver.com:8084 schlägt die Verbindung fehl, ich lande im nirvana - klar. Übergebe ich den Pfad mit fhem, also ******.homeserver.com/fhem:8084 kommt die bekannte Fehlermeldung:
Serverfehler in der Anwendung /.
Laufzeitfehler
Beschreibung: Anwendungsfehler auf dem Server. Aufgrund der aktuellen benutzerdefinierten Fehlereinstellungen für diese Anwendung können die Details des Anwendungsfehlers (aus Sicherheitsgründen) nicht remote angezeigt werden. Sie können jedoch von Browsern angezeigt werden, die auf dem lokalen Server ausgeführt werden.
Details: Sie können die Details dieser Fehlermeldung auf dem lokalen Computer anzeigen, indem Sie ein <customErrors>-Tag in der Konfigurationsdatei web.config erstellen, die sich im Stammverzeichnis der aktuellen Webanwendung befindet. Das mode-Attribut dieses <customErrors>-Tags sollte dann auf "Off" festgelegt werden.
<!-- Web.Config Configuration File -->
<configuration>
<system.web>
<customErrors mode="Off"/>
</system.web>
</configuration>
Hinweise: Die aktuelle Seite kann durch eine benutzerdefinierte Fehlerseite ersetzt werden, indem Sie das defaultRedirect-Attribut des <customErrors>-Konfigurationstags dieser Anwendung so setzen, das es auf einen benutzerdefinierten Fehlerseiten-URL zeigt.
<!-- Web.Config Configuration File -->
<configuration>
<system.web>
<customErrors mode="RemoteOnly" defaultRedirect="mycustompage.htm"/>
</system.web>
</configuration>
Das kapiere ich jetzt definitiv nicht.
wie bereits schon mal geschrieben.
Was spricht den gegen ******.homeserver.com:8084/fhem ?
Bei ******.homeserver.com/fhem:8084 landest du nicht beim Apachen sondern beim WHS im Verzeichnis fhem:8084
Dagegen spricht gar nichts - ausser dass es nicht funktioniert...
Fehler: Verbindung fehlgeschlagen
Firefox kann keine Verbindung zu dem Server unter *******.homeserver.com:8084 aufbauen.
ich spiele hier in aller Himmelsrichtungen. Befürchte die Fehlermeldung kommt auch vom IIS. Irgendwie macht die Fritzbox nicht das was ich will...
Ich habe das Ganze nach dem Wiki eingerichtet, der revers Proxy funktioniert auch - aber nur intern, per direktem Zugriff auf die IP von FHEM. Die Fritzbox biegt extern 8084 auf Fhem 8084 um. Läuft nicht.
ok. Die Meldung kommt, wie du vermutest, nicht vom Apache. Die sehen anders aus. Bei der Fritzbox bin ich allerdings raus. Soweit habe ich mich mit meiner noch nie beschäftigt...
Edit:
Fällt mir jetzt erst auf.
192.168.192.10/fhem ist ja ein 192.168.192.10:80/fhem aufruf. Was passiert denn bei 192.168.192.10:8084/fhem?
Edit2:
Blödsinn was ich da geschrieben habe. Er soll ja den Aufruf weiterleiten... Sorry.
Kannst du http://localhost/fhem aufrufen?
Du meinst localhost vom RPI aus? Da läuft nur eine Konsole drauf (via Putty) - der hängt in der Abstellkammer :D
Sollte aber an sich funktionieren. Wenn ich von einem lokalen Rechner im Netzwerk aus die IP/fhem aufrufe (hier 192.168.192.19/fhem) lande in der Ansicht für das Telefon - also auf Port8084, somit sollte auf dem RPI alles sauber sein. Nur die externe Anfrage (****.homeserver.com:8084/fhem) wird nicht sauber geroutet, ich lande irgendwie im Nirwana ("... Seite kann nicht angezeigt werden"...).
Wie gesagt, es macht mich stutzig dass ein externer Portscan 8084 (oder jeden anderen port den ich auf der FB weiteleiten will) als geschlossen zeigt?!
Zitat von: darkness am 02 Dezember 2015, 16:04:25
Kannst du http://localhost/fhem aufrufen?
Der Tipp war ja genau so gut wie Tastenkombination Alt + F4 um den Rechner zu beschleunigen. ??? Entschuldige.
Ich hatte gedacht, dass die lokale Namensauflösung nicht funktioniert. Das also Localhost aus irgend einen Grund nicht aufgelöst wird.
Du solltest zumindest in den Logfiles vom Apache was sehen, wenn eine Anfrage an kommt (Accesslog oder Errorlog).
Ich habe eben das Wiki mal an meinen Server getestet (Ubuntu 10.15). Dort ist das Paket libapache2-mod-proxy-html nicht mehr in den Paketquellen vorhanden. Aber ein a2enmod proxy
a2enmod proxy_http aktiviert die module (sind in Apache-bin vorhanden)
Anschließen habe ich den Port in der Fritzbox freigegeben. Sie Screenshot
Aufruf mit http://***.anydns.info:8084/fhem
hier meine apache-default.conf:
<VirtualHost *:80>
# The ServerName directive sets the request scheme, hostname and port that
# the server uses to identify itself. This is used when creating
# redirection URLs. In the context of virtual hosts, the ServerName
# specifies what hostname must appear in the request's Host: header to
# match this virtual host. For the default virtual host (this file) this
# value is not decisive as it is used as a last resort host regardless.
# However, you must set it for any further virtual host explicitly.
#ServerName www.example.com
ServerAdmin webmaster@localhost
DocumentRoot /var/www/html
# Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
# error, crit, alert, emerg.
# It is also possible to configure the loglevel for particular
# modules, e.g.
#LogLevel info ssl:warn
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
# For most configuration files from conf-available/, which are
# enabled or disabled at a global level, it is possible to
# include a line for only one particular virtual host. For example the
# following line enables the CGI configuration for this host only
# after it has been globally disabled with "a2disconf".
#Include conf-available/serve-cgi-bin.conf
<Location /fhem>
# ProxyPass/ProxyPassReverse leitet HTTP requests auf eine andere URL um
ProxyPass http://localhost:8084/fhem
ProxyPassReverse http://localhost:8084/fhem
# ProxyHTMLURLMap passt Links im HTML/JavaScript Source an
ProxyHTMLURLMap / /fhem/
ProxyHTMLURLMap /fhem/ /fhem/
AuthType Basic
AuthName "Password Required"
AuthUserFile /etc/fhem-htpasswd
Require valid-user
Order deny,allow
Allow from all
</Location>
</VirtualHost>
Moin,
exakt so schaut das bei mir auch aus :-\ nur dass es nicht funktioniert. Denn kann nur noch mein ISP UM das Problem sein. DsLite habe ich nicht, ganz normales IPv4...
Sicherheitshalber nachgefragt:
Die Weiterleitung von der Fritzbox ist also genau so eingerichtet?
Screenshot?
Jau, denke schon.
(http://www2.pic-upload.de/thumb/29020460/8084.png) (http://www.pic-upload.de/view-29020460/8084.png.html)
hier die komplette Tabelle...
(http://www2.pic-upload.de/thumb/29020461/fritz.png) (http://www.pic-upload.de/view-29020461/fritz.png.html)
IMHO sauber. Dabei fällt mir ein... per global und HTTPS hatte das schon funktioniert (also mit FHEM Boardmitteln, Cert und HTTPS...). Kann also auch nciht das Problem sein. Krasss :o
Das siegt gut aus .... wenn die IP stimmt?
Probiere doch erstmal keinene weiterleitung, sondern ob der apache überhaupt erreichbar ist. Also nimm den Proxyraus und probiere mit einer statischen Webside. Funktioniert das?
Von intern funktioniert beides. Da komme ich auf den Port 80 (It works!) und auch das reverse Proxying auf den 8084 via 192.168.192.17/fhem läuft problemlos. Merkt man auch direkt, der Seitenaufbau ist wesentlich flotter, grade wenn svgs hinterlegt sind.
Ich fasse nochmal zusammen...
- intern via Angabe IP/fhem läuft via Apache/reverse Proxy
- extern lief vorher via global, https und Cert (Oot-Box Lösung FHEM)
- extern mit Apache als reverse proxy läuft nicht.
mah mal für einen kurzen Zeitraum einen Test mit dem Exposed Host auf den RPI mit dem Apache ... also einschalten, testen, ausschalten
Danke für den Tip.
Krasse Sache. Setze ich den RPI in die DMZ komme ich direkt auf den Apache Port 80 (it works!), mit Angabe /fhem auf den RIP in Fhem via Port 8084. So wie es soll. Nehme ich ihn wieder aus der DMZ raus und forwarde wieder nur Port 8084 auf den RPI... Seiten-Ladefehler. Da wird doch der Hund in der Pfanne verrückt... :-\
Macht übrigens keinen Unterschied ob ich den Aufruf via ******.homeserver.com oder via http://176.***.***.*** mache, auch alle Kombis (also Übergabe von :8084 vor/nach /fhem) liegern nur einen Seiten-Ladefehler.
Also extern auf den apache direkt (also nicht die proxy-Funktionalität) funktioniert auch schon nicht?
Sitzt er in der DMZ schon. Auf Apache, auf den reverse Proxy... funktioniert problemlos. Per Portforwarding denn nicht mehr?!
Nein .. wenn Du extern aufrufst, also nur apache OHNE proxy-Funktionalität, kannst Du dann?
Den Apache auf Port 80 erreiche ich im Moment nicht, denn meldet sich der WHS ;) So soll das ja (an sich) auch sein. In der DMZ erreiche ich den Apache auf Port 80. Nehme ich alle Routen raus und definiere nur den RPI (Port 80) lande ich auf dem Apache ("It works").
Scheint jetzt zu laufen :)
ich habe alle Routen rausgeworfen, den WHS nur noch per 443 zugänglich gemacht, Plex und Co definiert und Port 80 auf FHEM umgebogen. Der forwarded jetzt via /fhem Apache auf Port 8084. Muss also nur noch definieren dass Apache nicht mehr auf Port 80 reagiert...
Zu viel Verwirrung hier ;)
Mach doch z.B. folgendes:
Portweiterleitungen
- 80 + 443 auf WHS (und den nicht weiter angreifen)
- 81 od. 444 auf Apache
Den Apache auf Port 81 od. 444 lauschen lassen (Config-File: Listen 444).
FHEM ganz normale Standardinstallation (Port 8083)
In der Apache-Reverse-Proxy-Konfiguration muss dann stehen
ProxyPass http://localhost:8083/fhem
ProxyPassReverse http://localhost:8083/fhem
Dann kannst du sowohl WHS, als auch Apache via SSL absichern wenn du willst.
Dann halt aufpassen, dass du den Apache von außen mit dem richtigen Protokoll aufrufst (HTTP/HTTPS). Browser merken sich gerne falsche Sachen beim Autovervollständigen ;).
Die richtigen Aufrufe wären dann
http://***.homeserver.com für den WHS
http://***.homeserver.com:444 für den Apache
http://***.homeserver.com:444/fhem für FHEM
Die Fehlermeldung, die du gepostet hast, kam übrigens definitiv vom WHS.
hmmm, also RPI in DMZ --> alles OK (intern und extern)
nur Port Forwarding für RPI --> extern nicht OK
Ich würde sagen --> Rücksetzung der Fritte auf Werkseinstellungen und dann noch einmal testen
Hi,
danke nochmal für alle Feedbacks.
Im Moment schauts wie folgt aus:
Port 443 --> WHS. Port 80 ist hier abgeklemmt, da der eh nur einen Forward auf 443 gemacht hat.
Port 80 --> Apache
Port 80/fhem --> Fhem
Per hhtps... lande ich auf dem WHS, per http auf dem Apache :)
Läuft! Danke!
Wobei Dir klar ist, das z.B. Passwortabfragen bei http ohne Verschlüsselung sind?
Ja, das ist mir bewusst. Am Thema Authentifizierung schraube ich noch, bin erst mal froh dass das Routing jetzt überhaupt funktioniert. Ich biege das noch um auf SSL.
Zitat von: Wernieman am 04 Dezember 2015, 08:13:41
Wobei Dir klar ist, das z.B. Passwortabfragen bei http ohne Verschlüsselung sind?
Soweit ich weiss setzt FHEM Basic Auth ein,insofern stimmt das.
Der Vollständigkeit halber möchte ich aber ergänzen: Das Passwörter bei http unverschlüsselt übertragen werden trifft nicht allgemein zu, sondern nur für die Basic-Authentifizierung (oder Passworteingaben in Formularen).
SSL ist natürlich auf jeden Fall besser.