Ich habe das Problem, dass plötzlich mein reverse Proxy auf dem Pi zu macht und mich nicht mehr von außen rein lässt. Daher geht auch alexa nicht mehr. Stelle ich auf Portfreigabe ganz normal um geht auch alexa. Daher muss es am Proxy liegen. Allerdings fehlen mir die Fähigkeiten den Fehler zu finden. Hier mal ein paar Infos
1. Die conf Datei (Alte Dinge sind auskommentiert):
<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerName xxx.myfritz.net
ServerAdmin Etienne-M@web.de
DocumentRoot /var/www/html
ErrorLog ${APACHE_LOG_DIR}/xxx.myfritz.net.error.log
CustomLog ${APACHE_LOG_DIR}/xxx.myfritz.net.access.log combined
SSLCertificateFile /etc/letsencrypt/live/xxx.myfritz.net/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/xxx.myfritz.net/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
ProxyRequests Off
ProxyVia Off
ProxyPreserveHost On
#Alexa hinzugefügt:
SSLEngine on
SSLProxyEngine on
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
# <Location /fhem>
# ProxyPass http://192.168.2.5:8083/fhem
# ProxyPassReverse http://192.168.2.5:8083/fhem
#
# # steht normal in proxy*
# AuthType Basic
# AuthName "Password for FHEM Required"
# AuthUserFile /etc/fhemapi-htpasswd
# Require valid-user
# Order deny,allow
# Allow from all
# </Location>
# Alexa hinzugefügt
<Location /alexa>
ProxyPass https://192.168.2.5:3000/
ProxyPassReverse https://192.168.2.5:3000/
AuthType Basic
AuthName "Authentication Required"
AuthUserFile "/etc/fhem-alexa-htpasswd"
Require valid-user
Order deny,allow
Allow from All
</Location>
<Directory />
# RedirectPermanent / /fhem
RedirectPermanent / /
</Directory>
# normal aktiviert gewesen mit auth... unter fhem
# <Proxy *>
# </Proxy>
</VirtualHost>
</IfModule>
die Abfrage nach der Confsyntax ergibt ok:
sudo apachectl configtest
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName' directive globally to suppress this message
Syntax OK
Ich habe versucht mit letsencrypt zu erneuer, da ich dachte sei abgelaufen, aber hier das Ergebnis:
sudo service apache2 stop && /opt/letsencrypt/letsencrypt-auto renew && sudo service apache2 start
Warning: Unit file of apache2.service changed on disk, 'systemctl daemon-reload' recommended.
Requesting root privileges to run certbot...
/home/pi/.local/share/letsencrypt/bin/letsencrypt renew
Saving debug log to /var/log/letsencrypt/letsencrypt.log
-------------------------------------------------------------------------------
Processing /etc/letsencrypt/renewal/xxx.myfritz.net.conf
-------------------------------------------------------------------------------
Cert not yet due for renewal
The following certs are not due for renewal yet:
/etc/letsencrypt/live/xxx.myfritz.net/fullchain.pem (skipped)
No renewals were attempted.
Warning: Unit file of apache2.service changed on disk, 'systemctl daemon-reload' recommended.
Die conf Datei ist von sites-available zu sites-enabled verlinkt:
pi@raspberrypi:/etc/apache2/sites-enabled $ ls -la
total 8
drwxr-xr-x 2 root root 4096 Apr 1 18:43 .
drwxr-xr-x 8 root root 4096 Aug 25 00:31 ..
lrwxrwxrwx 1 root root 35 Apr 1 18:09 000-default.conf -> ../sites-available/000-default.conf
lrwxrwxrwx 1 root root 31 Apr 1 18:43 myfritz.conf -> ../sites-available/myfritz.conf
Aber ich komme einfach nicht durch. Kann mir jemand mit Ahnung helfen und sagen wo der Fehler liegt? Natürlich habe ich meine Fritz Adresse mittels xxx hier verändert. Sie ist jedoch überall korrekt und bis gestern hat es auch noch funktioniert. Ich habe auch nichts bewusst geändert und auch nicht unbewusst irgendwo dran rumgespielt. Ich glaube, dass es irgendwie am letsencrypt Cert liegt, aber mir fehlt einfach das Fachwissen um den Fehler zu finden.
Geht den Aufruf von https://127.0.0.1:443/alexa lokal auf dem Pi?
folgender Fehler kommt:
wget https://127.0.0.1:443/alexa
--2017-08-25 09:07:25-- https://127.0.0.1/alexa
Connecting to 127.0.0.1:443... connected.
The certificate's owner does not match hostname '127.0.0.1'
Mit URL vom Pi aus:
wget https://xxxu.myfritz.net:443/alexa
--2017-08-25 09:11:27-- https://xxx.myfritz.net/alexa
Resolving xxx.myfritz.net (xxx.myfritz.net)... 2002:5d eb:41fa:8000:5e49:79ff:fe66:def4, 93.235.65.250
Connecting to xxx.myfritz.net (xxx.myfritz.net)|2002:5 deb:41fa:8000:5e49:79ff:fe66:def4|:443... failed: Connection refused.
Connecting to xxx.myfritz.net (xxx.myfritz.net)|93.235 .65.250|:443... failed: No route to host.
Noch ne Info in der Fritte ist der Port freigegeben:
Bezeichnung Protokoll IP-Adresse im Internet Port extern vergeben
SSL TCP xxx 443
Alexa TCP xxx 3000
SSL TCP xxx 443
Alexa TCP xxx 3000
Zitatwget https://127.0.0.1:443/alexa
--2017-08-25 09:07:25-- https://127.0.0.1/alexa
Connecting to 127.0.0.1:443... connected.
OK, findet mind. seinen Weg. Die Nachricht wegen Zertifikat Owner sollte nw. durch die Direktive "SSLProxyCheckPeerCN off" und "SSLProxyCheckPeerName off" nur ein Hinweis sein.
ZitatMit URL vom Pi aus:
Code: [Auswählen]
wget https://xxxu.myfritz.net:443/alexa
Meisten Boxen unterbinden das DNS-rebind. Die Fritzbox genauso, so lange Du keine "Domainnamen-Ausnahmen" eingerichtet hast. Wäre besser von ausserhalb deines Netzes, die myfritz.net Adresse zu testen. Z.B. aus einem Handy mit ausgeschaltetem WLAN.
EDIT: zusätzliche Anmerkung: Der Sinn von Einrichtung vom ReverseProxy ist nw. nur den SSL 443 Port freizuschalten. Wenn Du dazu noch den Port 3000 freischaltest, brauchst Du auch kein ReverseProxy ;)
Übrigens: ist das deine echte öffentliche IP Adresse? Dann bitte anonymisieren...
Habe ich mehrfach getestet:
xxx hat die Verbindung unerwartet geschlossen.
Versuchen Sie Folgendes:
Verbindung prüfen
ERR_CONNECTION_CLOSED
Natürlich habe ich 3000 jetzt nur freigegeben um alexa weiter nutzen zu können, weil der Proxy auf einmal net mehr will ;)
(IP habe ich gexxxt. Voll vergessen. Danke)
Dann wäre es interessant zu sehen, was in ErrorLog ${APACHE_LOG_DIR}/xxx.myfritz.net.error.log
CustomLog ${APACHE_LOG_DIR}/xxx.myfritz.net.access.log combined
kommt
Die sind komischerweise leer bzw. keine neuen Fehler. Hier mal die letzten Zeilen:
xxx.myfritz.net.access.log:
127.0.0.1 - - [25/Aug/2017:09:06:15 +0200] "GET / HTTP/1.0" 400 0 "-" "-"
xxx.myfritz.net.access.log.1:
192.168.2.11 - - [25/Aug/2017:01:55:42 +0200] "GET / HTTP/1.1" 301 624 "-" "Mozilla/5.0 (Linux; Android 7.1.1; E5823 Build/32.4.A.0.160) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.107 Mobile Safari/537.36"
192.168.2.11 - - [25/Aug/2017:01:55:42 +0200] "GET / HTTP/1.1" 301 624 "-" "Mozilla/5.0 (Linux; Android 7.1.1; E5823 Build/32.4.A.0.160) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.107 Mobile Safari/537.36"
xxx.myfritz.net.error.log:
LEER
xxx.myfritz.net.error.log.1
[Sun Aug 13 20:08:53.261985 2017] [proxy_http:error] [pid 17803:tid 1814033456] (70014)End of file found: [client 52.16.198.209:54162] AH01102: error reading status line from remote server localhost:3000
[Sun Aug 13 20:08:53.262206 2017] [proxy:error] [pid 17803:tid 1814033456] [client 52.16.198.209:54162] AH00898: Error reading from remote server returned by /alexa
Die Auflösung von xxx.myfritz.net muss passen. Bei Alexa wurde die gleiche Domain hinterlegt und mit dem offenen Port geht kann sie ja schalten. Ich bin einfach komplett ratlos warum ich nicht durchkomme :D
Edit:
Noch ein Test gerade gemacht. Wenn ich aus dem Netzwerk direkt auf meinen PI zugreife mittels:
https://192.168.2.5/alexa dann kommt die auth Abfrage und ich komme dahin wo ich will.
OH MAN!! Die scheiß Fritzbox hat die Portweiterleitung einfach nicht wirklich eingerichtet. Durch den letzten Test war klar, dass es irgendwo an der Internetverbindung liegen muss. Deswegen kam in den Logs auch nix an. Dann habe ich bei meiner Fritzbox auf die Details von FHEM Device geschaut und festgestellt, dass dort die Portfreigabe von 443 nicht auftaucht. In der Freigaben Gesamtübersicht hingegen steht sie und auch mit einem grünen Punkt für aktiv. Dem war aber nicht so, aus welchen Gründen auch immer. Also die Freigabe nochmal gelöscht und nochmal neu angelegt, jetzt geht es.
Wobei ich sie gestern auch 3 mal neu angelegt habe, keine Ahnung, wieso es nun geht und vorher nicht. Ich danke dir für die Hilfe :)
OK ich war am schreiben, aber mittlerweile sehe ich deine letzte Antwort. Ich lasse es aber hierunten, da es helfen kann zum zukünftigen Debugging ;)
=========================================
Deine Log Auszüge sind aber von verschiedenen Uhrzeiten.
Zitat127.0.0.1 - - [25/Aug/2017:09:06:15 +0200] "GET / HTTP/1.0" 400 0 "-" "-"
ist schon mal schlecht (400 = bad request).
Gibt es andere access.log und error.log Dateien mit Uhrzeiten passend zu deinen heutigen Versuche in /var/log/apache2?
Du kannst auch den Loglevel erhöhen:
LogLevel debug. Vielleicht kommt etwa mehr (nach einem graceful restart von Apache)
Da das die letzten Logeinträge waren und die Uhrzeiten nicht passten, lies es mich dann darauf schließen, dass man erst gar nicht zum Apache durchkommt. Dann habe ich ihn aus dem eigenen Netzwerk nochmal getestet und das ging. Dann dachte ich ok es muss wohl doch irgendwie an der Weiterleitung vom Router liegen und habe da nochmal geschaut. Dort habe ich dann den unverständlichen Fehler von der Fritte gefunden und konnte es endlich lösen :)
Gestern Nacht um 1 Uhr kam mir aber nicht die Idee, dass die fehlenden Log Einträge das bedeuten können. Da kam ich erst heute Morgen drauf :D
In solchen Fällen kann diese Seite helfen, um festzustellen was tatsächlich freigegeben ist: https://www.heise.de/security/dienste/portscan/test/go.shtml
Ein Portscanner, alles Ideen, welche mir gestern Nacht nicht eingefallen sind :D War einfach zu müde und zu verärgert. Dank dir ;)
Habe nun doch wieder ein Problem. Ich wollte heute den ReversProxy auch für FHEM wieder aktivieren, aber entweder geht du Umleitung auf FHEM nicht, oder die Alexa Umleitung nicht. Sieht jemand einen Fehler in der Conf Datei? Der Syntaxcheck sagt, dass alles ok ist. Hier die Datei:
<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerName xxxx.myfritz.net
ServerAdmin Etienne-M@web.de
DocumentRoot /var/www/html
ErrorLog ${APACHE_LOG_DIR}/zselqatc07mzkkvu.myfritz.net.error.log
CustomLog ${APACHE_LOG_DIR}/zselqatc07mzkkvu.myfritz.net.access.log combined
SSLCertificateFile /etc/letsencrypt/live/zselqatc07mzkkvu.myfritz.net/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/zselqatc07mzkkvu.myfritz.net/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
ProxyRequests Off
ProxyVia Off
ProxyPreserveHost On
#Alexa hinzugefügt:
SSLEngine on
SSLProxyEngine on
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
<Location /fhem>
ProxyPass https://192.168.2.5:8083/fhem
ProxyPassReverse https://192.168.2.5:8083/fhem
# steht normal in proxy*
AuthType Basic
AuthName "Password for FHEM Required"
AuthUserFile /etc/fhemapi-htpasswd
Require valid-user
Order deny,allow
Allow from all
</Location>
# Alexa hinzugefügt
<Location /alexa>
ProxyPass https://192.168.2.5:3000/
ProxyPassReverse https://192.168.2.5:3000/
AuthType Basic
AuthName "Authentication Required"
AuthUserFile "/etc/fhem-alexa-htpasswd"
Require valid-user
Order deny,allow
Allow from All
</Location>
<Directory />
# RedirectPermanent / /fhem
RedirectPermanent / /
</Directory>
# normal aktiviert gewesen mit auth... unter fhem
# <Proxy *>
# </Proxy>
</VirtualHost>
</IfModule>
Was mir auffällt, wenn ich bei /fhem proxypass und proxypassreverse von http auf https ändere, dann geht die alexa umleitung wieder, aber die FHEM Umleitung nicht. Wenn ich es so lasse, wie oben, dann geht fhem, aber alexa findet keine Geräte. Alexa läuft laut Lampda immer in ein Timeout. Gebe ich allerdings meine fritz dyndns Adresse mit
https://xxx.myfritz.net/alexa
ein, dann sehe ich den Json String von alexa. Es werden aber wie gesagt keine Geräte mehr gefunden. Diese werden nur gefunden, wenn ich die FHEM umleitung deaktiviere, oder diese auf https einstelle. Verstehe nicht was das Problem ist.
Ich habe kein Plan warum, aber jetzt geht es auf einmal. Scheint nicht am reverseproxy gelegen zu haben. Allerdings kein Plan woran es lag.