Liebe alle,
ich habe seit ein paar Tagen diese Meldung jede Sekunde mit wechselndem Quellport im meine Log-File, so dass es täglich um 15MB wächst...
Connection refused from the non-local address 192.0.0.95:38163, as there is no working allowed instance defined for it
Die IP-Adresse ist mein lokaler Synology-Server.
Zeitlich fällt das Problem damit zusammen, dass ich eine Synology Surveillance Station in Betrieb genommen und inkl. SSChat in FHEM eingebunden habe. Ich habe schon versucht, bei der dafür verwendeten FHEMWEB-Instanz die 192.0.0.95 mit "allowfrom" freizugeben - aber die Logeinträge bleiben, selbst wenn ich es bei allen FHEMWEB-Instanzen reinschreibe (nur beim MQTT-Server, der auch unter FHEMWEB gelistet wird, gibt es das Attribut nicht).
Gibt es irgendwo eine Möglichkeit, die Definition der lokalen Adressen um meinen lokalen Adressraum 192.0.0.* zu erweitern? Ich weiß, dass das nicht Standard-Konform ist - aber irgendwie war der schon immer so und das in allen Systemen zu ändern wäre mir inzwischen zu viel Aufwand. Da hoffe ich, dass es einen anderen Weg gibt. Ich könnte auch damit leben, wenn genau dieser Eintrag nicht mehr geloggt wird...
Naja 192.0.0.0/24 o.ä. ist halt nun mal KEINE private IP bzw. KEIN privater IP-Bereich!
Auch wenn du die IP selbst vergeben hast...
https://de.m.wikipedia.org/wiki/Private_IP-Adresse
Es kann auch an anderer Stelle mit solchen IP-Adressen zu Problemen kommen, z.B. beim Routing, NAT, etc.
Ansonsten wie in der Meldung steht: ein allowed-Device erstellen
https://wiki.fhem.de/wiki/Allowed
Das mag für das aktuelle Problem helfen...
...aber beachte was im Wiki-Link steht und ich geschrieben habe...
Gruß, Joachim
Danke für die schnelle Antwort, Joachim.
Ja - ich weiß dass der IP-Bereich so Mist ist. Ich sträube mich aber noch, die Zeit für eine Korrektur zu investieren. Bislang hatte ich mit dem Routing und VPN keine Probleme. Sollte das passieren, ist es wohl soweit...
Beim Thema allowed-device bin ich auch schon gelandet - aber ich habe glaube ich den Lösungsansatz übersehen. Ich habe bislang nur eines für den Passwortzugang zum Webfrontend definiert.
Ich habe leider nicht gesehen, wo ich da Quell-IP-Adressen auf das Trust-Level lokaler Adressen heben kann. Auch weiß ich ja nicht, für wen ich das allowed-Device erstellen soll, da es die FHEMWEB-Instanz von SSChat ja nicht zu sein scheint...
Was kommt denn bei:
list TYPE=FHEMWEB
Wenn so eine Meldung für ein Fhem-Web kommt, dann muss es eins dafür geben... ;)
Wie geschrieben: der von dir verwendete IP-Bereich ist kein privater, Punkt ;)
Ich weiß nicht ob es reicht einfach nur ein allowed-Device anzulegen (ohne User/PW etc.) und dem Fhem-Web zuzuordnen, um dein Problem zu "beheben" (oder eher das Symtom deines Problems zu "umgehen" ;) )...
Gruß, Joachim
Moin,
ZitatIch habe leider nicht gesehen, wo ich da Quell-IP-Adressen auf das Trust-Level lokaler Adressen heben kann.
Damit:
Zitatallowfrom
Regexp der erlaubten IP-Adressen oder Hostnamen. Wenn dieses Attribut gesetzt wurde, werden ausschließlich Verbindungen von diesen Adressen akzeptiert.
Achtung: falls allowfrom nicht gesetzt ist, und keine gütige allowed Instanz definiert ist, und die Gegenstelle eine nicht lokale Adresse hat, dann wird die Verbindung abgewiesen. Folgende Adressen werden als local betrachtet:
IPV4: 127/8, 10/8, 192.168/16, 172.16/10, 169.254/16
IPV6: ::1, fe80/10
Doku:
https://fhem.de/commandref_DE.html#FHEMWEB
Gruß Otto
Zitat von: MadMax-FHEM am 28 Oktober 2020, 00:24:58
Ich weiß nicht ob es reicht einfach nur ein allowed-Device anzulegen (ohne User/PW etc.) und dem Fhem-Web zuzuordnen, um dein Problem zu "beheben"
Es reicht sogar, die IP ganz ohne allowed-device direkt in der FHEMWEB Instanz zuzuordnen.
Funktioniert auf jeden Fall bei meinen FHEM Servern bei Amazon Web Service ganz prima :)
Danke Euch allen. Leider hat das mein Problem nicht gelöst, da ich keine FHEMWeb-Instanz gefunden habe, wo das Problem aufläuft.
Ich habe am Ende die IP der Synology bei allen FHEMWeb-Instanzen eingetragen - und dennoch weiter die Fehlermeldung bekommen. Am Ende habe ich heute früh in den sauren Apfel gebissen, und das Netz auf eine offizielle private IP umgestellt. Zumindest dieses Problem ist seit dem behoben. Am Rest kaue ich noch...