Moin
ich habe einen neuen SmartTV und dort Plex installiert.
Nun funktioniert alles (Bilder und Musik) außer halt die Filme.
Als Meldung kommt:PLAYER_ERROR_CONNECTION_FAILER
Ich bin die Einstellungen mehrmals durchgegangen und konnte nicht feststellen warum diese Meldung kommt.
Hat einer einen Tipp für mich ???
Der neue TV ist der vierte im Haus.Auf allen 3 funktioniert Plex mit allen Funktionen hervorragend.
1000 Dank
PS:Ich merke gerade das ich bei der Musik zwar die Cover sehe aber die Musik nicht abgespielt wird.
Sorry …
Aaaalso… ich habe eine Synology DS415+ auf der die Filme drauf sind.
Auf dem SamsungTV habe ich die App “PLEX” installiert.
Starte ich die App komme ich automatisch auf den Server und werde auch automatisch eingeloggt.
Starte ich dann einen Film kommt nach ein paar Sekunden diese Meldung.
Alle anderen SamsungTV’s mit dieser App laufen problemlos.
1: UE 65 HU 7590 LX
2: UE 48 JU 6450 UXZG
3: UE 40 J 6250 SUXZG
4: UE 40 MU 6179 UXZG
Beim TV 1-3 funktioniert die aktuelle Plex Version aus dem Store .
Der vierte hat auch die aktuelle Plex - Version bei dem funktioniert das streamen aber nicht.Es kommt bei diesem die besagte Meldung.
Alle TV’s sind per LAN Kabel an einem Switch angeschlossen.
Bei allen TV’s kann ich z.B. über Amazon streamen.
Auch komme ich mit allen TV’s mittels Browser auf diverse Homepages.
Ich hoffe nun alle nötigen Infos zusammen gebracht zu haben … püüüüh.
Wenn man die Verschlüsselung ausmacht, stehen auch keine Indirekten/Relay-Verbindungen zur Verfügung mehr.
Die ordentliche Lösung ist hier, im Router die evtl. aktive ‘DNS rebinding protection’ mit einer Ausnahme zu versehen (für die DomaIn plex.direct)
und den DNS Server vom ISP auf die von Google (8.8.8.8 und/oder 8.8.4.4) oder OpenDNS umzubiegen.
@OttoKerner: ich verstehe bis heute nicht, warum die Einträge im LAN-Netwerk nicht von der Sicherheitseinstellung ausgenommen sind und sich somit Clients im LAN-Netwerk unsicher verbinden dürfen. Man könnte sagen das die Sicherheitseinstellungen “bevorzugt” das bietet, was aber nicht stimm, denn hier könnten auch Clients aus dem Internet ungesichert auf den Server zugreifen.
@kopfpilot said: @OttoKerner: ich verstehe bis heute nicht, warum die Einträge im LAN-Netwerk nicht von der Sicherheitseinstellung ausgenommen sind
Weil man das relativ einfach fälschen kann. Darum wurde diese Möglichkeit absichtlich weggelassen.
Schau dir mal an, wie viele Leute sich einen Reverse Proxy aufsetzen. Nur um einen eigenen Domain Namen für ihren Plex Server zu haben.
Ein Reverse Proxy verändert die Pakete die durch ihn wandern so, dass sie aussehen als kämen sie von einer Station im lokalen Netzwerk und nicht von außerhalb.
(Und das ist nicht die einzige Möglichkeit so was zu faken.)
Wenn du jetzt noch die Verschlüsselung im lokalen Netzwerk ausschaltet, bist du komplett unverschlüsselt unterwegs.
(Um das Maß voll zu machen: es besteht die nicht unerhebliche Chance, dass der Nutzer auch bereits die Pflicht zur Authentifizierung für sein lokales Netzwerk abgeschaltet hat. In Verbindung mit einem Reverse Proxy hat man damit alle Scheunentore weit offen.)
Ich verstehe Deine Argumente und habe zwei wesentliche Punkte anzumerken:
Seit der Header X-Forwarded-For von Plex ausgewertet wird, wird nicht mehr die Ip des Reverse-Proxies erkannt, sondern die des Client.
2.Dein Einstellung LAN-Netzwerke erlaubt meines Wissens nach nur private IP-Segmente.
Was spricht dagegen, X-Forwarded-For auch für den Sicherheits-Kontext zu verwenden? Bleiben damit noch die Personen übrig, die das Feld im Reverse-Proxy nicht setzen. Aber mal im ernst: wer in der Lage ist einen Reverse-Proxy aufzusetzen, der sollte auch über das Wissen verfügen dieses Feld zu setzen. Somit haben wir im Server also auch im Reverse-Proxy-Szenario die echten Public IPs der Clients.
Unter der Prämisse, dass LAN-Netzwerke nur private IP-Ranges erlauben und Reverse-Proxies mittels X-Forwareded-For die Public Client Ip an Plex meldet, wie soll da ein Spoofing weiterhelfen? IPs aus einer privaten IP-Range werden nicht über das Internet groutet.
@kopfpilot said:
Ich verstehe Deine Argumente und habe zwei wesentliche Punkte anzumerken:
Seit der Header X-Forwarded-For von Plex ausgewertet wird, wird nicht mehr die Ip des Reverse-Proxies erkannt, sondern die des Client.
Setzt voraus, dass der Nutzer weiß was er tut.
Viele der Benutzer haben einfach nur ein HowTo aus dem Internet kopiert.
Außerdem erwähnte ich bereits, dass ein Reverse Proxy nicht die einzige Möglichkeit ist, die Herkunft zu fälschen.
2.Dein Einstellung LAN-Netzwerke erlaubt meines Wissens nach nur private IP-Segmente.
Ist für die Problematik nicht hilfreich, da ja der RP es so aussehen lässt als kämen die Pakete aus dem lokalen (und damit ‘privaten’ IP Segment).
Wir haben unterschiedliche Perspektiven bei dem Thema: Deine ist den DAU vor sich selber schützen. Meine ist als nicht DAU nicht bevormundet zu werden.
Botschaft ist angekommen. Danke für’s Aufklären
Ich habe nur noch eine letzte Frage: ist der Einsatz eines Reverse-Proxies ein supported oder unsupportes Szenario?
Ich fasse zusammen: die Argumente die aus Herstellersicht gegen die unsichere Nutzung innerhalb des LAN-Netzwerks sprechen gelten für ein “eigentlich” unsupportes Nutzungsszenario, dass bei Falschnutzung zu Sicherheitsproblemen führt.
Trifft es das?
Ich frage mich nur, warum in eurer Impact-Analyse unsupportete Szenarien berücksichtigt werden, die dann in Folge dessen zu Einschnitten für die “normale Nutzung” führen und in Konsequenz den Nutzer zwingen eine DNS-Rebind Ausnahme im Router zu definieren und ggf. noch DNS-Server ändern zu müssen.
Verstehe mich nicht falsch: ich bin froh das vor kurzen eine wichtige Funktionalität für den Reverse-Proxy-Betrieb implementiert wurde, die Auswertung des X-Forwarded-For Headers. Mir ist der aktuelle “Half-Assed” support lieber, als ein Boykott
Gegenbeispiel: wenn höchstmögliche Sicherheit erzwungen werden sollte, warum kann dann JEDE Webanwendung nach der Installation nur über HTTP erreicht werden?! Oftmals ist das einbinden der Zertifikate dann für viele Benutzer zu kompliziert.
Den Umgang mit Zertifikaten löst Plex vorbildlich! Ich möchte nun mal für Remote Zugriffe Sicherheit erzwingen und für alles andere nicht. Aber genau dieses Szenario erlauben mir ALLE anderen Webandungen…
Ich werde einfach zuhaue nun auch das unsupportete Reverse-Proxy szenario einsetzen, damit ich über Remote HTTPS erzwingen kann und lokal HTTP verwenden kann. Lustig, dass es ausgerechnet mit dem unsupporteten Szenario möglich ist
