Jump to content

IPTV Firewall Problem nach DVBViewer Update


x112

Recommended Posts

Posted

Kann es sein das das letzte DVBViewer Update die IPTV Firewall Einträge löscht? Bei mir liefen die Magenta TV Sender erst wieder nach Aufruf von DMS_IPTV_Firewall_Rules.

 

Posted

Wenn du im Installer per Checkbox Firewall-Einträge erzeugen lässt, überschreiben die Standard-Einträge die vorherigen Einträge.

 

Posted

Kann durchaus sein das ich das Firewall Regeln Erzeugen aktiv hatte (ist ja Default) und es kann auch sein das ich beim vorherigen Update noch kein Magenta TV genutzt habe und es deshalb egal war.

Vielleicht wäre eine zweite Checkbox für die IPTV Firewallregeln sinnvoll.

 

 

 

Posted (edited)
On 12/20/2022 at 7:58 PM, x112 said:

Vielleicht wäre eine zweite Checkbox für die IPTV Firewallregeln sinnvoll.

 

Vielleicht... die IPTV-Regel bezieht sich allerdings nur auf eine bestimmte Art IPTV. Nämlich auf mittels UDP Multicast verbreitete TV-Daten wie bei Magenta TV. Anwender verstehen unter IPTV im allgemeinen jedoch alles TV, was irgendwie aus dem Internet kommt, davon das meiste via HTTP. Dafür reicht die Standard-Regel, weil HTTP vom DVBViewer als Client explizit angefordert wird und nicht "von alleine" in den PC kommt. Eine solch feinsinnige Unterscheidung überfordert das Verständnis der meisten Anwender.

 

Ich habe das noch mal genauer untersucht. Was DVBViewer_IPTV_Firewall_Rules.bat (im DVBViewer-Programmverzeichnis) anlegt, besteht aus zwei Regeln:

  • DVBViewer TCP LAN/WLAN entspricht der standardmäßig für den DVBViewer angelegten Firewall-Regel, ist aber nun auf TCP als Protokoll beschränkt (das auch HTTP beinhaltet).
  • DVBViewer UDP LAN/WLAN & IPTV ist auf UDP als Protokoll beschränkt und lässt in einem Punkt zwei Punkten mehr Freiheit als die Standardregel:
  1. Wenn man in den erweiterten Firewall-Einstellungen -> Eingehende Regeln -> Rechtsklick auf Regel -> Eigenschaften -> Erweitert nachschaut, sieht man dort unter "Edgeausnahme" die Einstellung "Auf Benutzer zurückstellen", d.h. du darfst entscheiden. Ansonsten steht dort bei  den DVBViewer-Regeln (auch bei der für TCP) "Edgeausnahme blockieren" mit der Bedeutung "Der Empfang von nicht angefordertem Datenverkehr aus dem Internet über ein NAT-Gerät für Edge wird für Anwendungen verhindert".
  2. In den Eigenschaften der UDP-Regel -> Bereich -> Remote IP-Adresse ist "Beliebige IP-Adresse" ausgewählt. Bei der TCP-Regel dagegen "Diese IP-Adressen: -> Lokales Subnetz". Bei der UDP-Regel darf sich der Server also im Internet befinden, bei der TCP-Regel nur im eigenen (lokalen) Netz.

Da man i.a. nicht möchte, dass irgendwas aus dem Internet unaufgefordert hereinrauscht und von Anwendungen verarbeitet wird, gilt hier: Nur erlauben, was unumgänglich ist. Also nur für UDP, nicht für andere Protokolle.

 

Das Problem beim Installieren einer neuen Version ist nun, dass der Installer die Regel für TCP mit einer ansonsten gleichlautenden Regel überschreibt, die jedoch wieder für alle Protokolle gilt. Die Regel DVBViewer UDP LAN/WLAN & IPTV bleibt zwar vorhanden (jedenfalls war das hier der Fall), steht nun aber im Widerspruch zu einer mehr einschränkenden Regel für alle Protokolle. Offenbar geht die Windows-Firewall dann nach dem Motto "Im Zweifelsfall besser einschränken als erlauben" vor, und der Empfang von UDP Multicast aus dem Internet wird für den DVBViewer wieder geblockt.

 

Das ist so nicht ideal. Ich muss mir das noch mal durch den Kopf gehen lassen. Vorschläge für eine bessere Handhabung sind willkommen!

 

Edited by Griga
Korrektur und Ergänzung
Posted

Es ist sogar noch etwas komplizierter. Bei mir läuft eigentlich alles über den Mediaserver auf dem gleichen Rechner. Nach dem Update (und auch davor) gab es zwei Mediaserver Regeln und die TCP Viewer Regel. Also hätte es eigentlich auch ohne die DVBViewer UDP Regel gehen müssen. Vielleicht hat sich beim Starten des Mediaserver irgendwas verschluckt. Jetzt geht es auch ohne die DVBViewer UDP Regel.

Posted

Ich habe es auch noch mit einer standalone DVBViewer Installation ausprobiert. Für Magenta TV ist die UDP Regel entscheidend. Ob in der anderen Regel TCP oder Alle steht scheint keine Rolle zu spielen.

 

Allerdings löscht bei mir der Mediaserver Update die Mediaserver UDP Regel. Erst nach Aufruf von DMS_IPTV_Firewall_Rules geht es dann wieder.

Vielleicht habe ich gestern die beiden IPTV Firewall Scripte verwechselt.

Posted
On 12/21/2022 at 3:06 PM, x112 said:

Es ist sogar noch etwas komplizierter. Bei mir läuft eigentlich alles über den Mediaserver auf dem gleichen Rechner.

 

Schaue zur Sicherheit auf der Status-Seite des Webinterface nach, ob dort ein Gerät aktiv ist und der DVBViewer als Client erscheint, wenn er Magenta TV wiedergibt. Falls ja: Was genau wird dort angegeben?

 

Die Firewall-Regeln für den DMS aus den Batch-Dateien entsprechen denen für den DVBViewer. Da steht dann nur ein anderer Programmname. Deshalb dürfte es eigentlich keinen Unterschied beim Verhalten geben.

 

On 12/21/2022 at 3:50 PM, x112 said:

Allerdings löscht bei mir der Mediaserver Update die Mediaserver UDP Regel.

 

Stimmt, hier auch. Aber warum der DVBViewer-Installer nicht? Das muss ich mir mal genauer anschauen ;) Setzt man den DVBViewer mittels DVBViewer_Firewall_Rules.bat auf die Standard-Regel zurück, löscht dies ebenfalls die UDP-Regel.

 

Bei meinem vorherigen Post habe ich einen zweiten Unterschied zwischen der TCP- und der UDP-Regel für Magenta TV ergänzt, den ich zuvor übersehen hatte. Hier  wurde die Problematik schon mal behandelt.

 

Interessant ist, was passiert, wenn es keine Firewall-Regel für den DVBViewer gibt (was man leicht durch den Start einer Kopie DVBViewer2.exe erreichen kann): Zumindest im Stand-Alone-Betrieb zunächst gar nichts. Nicht mal beim Einschalten eines HTTP TV Streams. Sobald man jedoch Optionen -> Media Server betritt und dort die Unterstützung für den Media Server einschaltet (oder sie schon eingeschaltet ist), kommt (unter Windows 8.1) sowas:

 

Zwischenablage01.png

 

...weil der DVBViewer nun nach im Netz vorhandenen Media Servern forscht, wobei auch UDP und Multicast ins Spiel kommen. Lässt man den Zugriff zu, erstellt Windows zwei "eingehende" Regeln, eine für TCP und eine für UDP, beide mit Erweitert -> Edgeausnahme -> Auf Benutzer zurückstellen sowie Bereich -> Remote IP-Adresse -> Beliebige IP-Adresse. Damit funktioniert Magenta TV  auf Anhieb.

 

Offenbar findet Windows nichts dabei, diese Möglichkeit zu eröffnen, sowohl für UDP als auch TCP. Laut den Ausführungen von Tjod ist es auch unkritisch, solange sich der PC hinter einem Router befindet, also nicht über ein Modem mit dem Internet verbunden ist. Es stellt sich die Frage, ob der DVBViewer Installer das Einrichten von Regeln nicht lieber Windows überlassen sollte.

 

Was "Edgeausnahme" genau bedeutet, ist leider kaum dokumentiert. Der entsprechende englische Begriff "Edge Traversal" macht es schon etwas klarer: Es geht um das Überschreiten von Netzwerkgrenzen. Die bislang beste Erläuterung habe ich hier gefunden. Wenn ich das richtig verstehe, ist nicht alles betroffen, das aus dem Internet hereinschneit, sondern nur eine bestimmte Art Datenverkehr, die "getunnelt" die im Router durch die NAT (Network Address Translation) gegebene Grenze überwinden soll. Magenta TV gehört offenbar zu diesem Typ.

 

Posted

Die Magenta Daten laufen bei mir tatsächlich über den Mediaserver, im Status wird der Rechner als Client angezeigt.

 

In einer Win11 VM fragt der DVBViewer bei mir auch nach Zugriffserlaubnis wenn man die Mediaserver Konfiguration oder einen Magenta TV Sender aufruft. Man muss allerdings ein passendes Gerät einrichten.

Der Mediaserver kann das nicht, ohne Erzeugung von Regeln bei der Einrichtung oder per DMS Scripte tut sich da nichts.

 

Die Option Edgeausnahme bleibt suspekt. Bei mir funktioniert Magenta TV auch wenn da "Blockieren" steht. Was soll überhaupt "auf Benutzer zurückstellen" tun? Ich kann da nichts entscheiden, das Programm entscheidet ja ob es die Pakete annimmt. Lediglich eine Einschränkung auf das lokale Subnetz mag Magenta TV überhaupt nicht.

 

Schöne Weihnachten noch!

 

 

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...