Media Server Betrieb auf Rechner mit mehreren IP-Adressen/Netzwerkinterface

[h0ly0ne]

Hallo nochmal,

 

ich habe mit dem Media Server noch ein Problem das sich irgendwie nicht brauchbar lösen lässt.

Im Prinzip sind auf dem Rechner/Server mehrere Netzwerkinterface und somit multiple IP-Adressen

(auch mehrer IP-Adressen pro Netzwerkinterface) verfügbar.

Man kann zwar bei einigen Diensten (WebServer, UPnP AV Server) angegeben auf welchen IPs diese

nicht zur Verfügung stehen sollen - aber z.b. für den RTSP/SATIP Server (und womögliche andere

Server Dienste) ist dies nicht möglich.

 

Auf meinen SATIP Clients scheint jetzt die IP-Adresse des RTSP Servers "zufällig" genommen zu werden.

Damit könnte ich ja noch leben - jedoch scheint die "falsche" Wahl der IP Adresse (nicht die Haupt-IP auf

der, der Server im DNS registriert ist) dann auch einen funktionalen Einfluss auf meine z.b. Panasonic TVs

mit SATIP Client haben - sprich er findet keine Sender - obwohl der SATIP Server dort brav erkannt wird.

Ich konnte das Verhalten auch DVBViewer reproduzieren (in dem ich z.b. die IP Adresse der zweiten

Netzwerkkarte angegeben habe) - dort funktioniert die SATIP Verbindung dann über UDP nicht (über TCP

scheint es jedoch zu funktionieren).

 

Firewall(s) und/oder Routing kann ich soweit ausschließen, da ich für den Testcase alle Firewalls (Betriebssystem)

deaktiviert habe - und die Geräte direkt per Ethernet verbunden sind (ohne Double-GWs oder ähnliches).

 

Konfigurationsmöglichkeiten habe ich für RTSP/SATIP konnte ich leider keine finden - im Log File schreibt er

aber brav das er so ziemlich alle Services/Sockets auf alle IP-Adressen bindet.

 

Lösungsansatz in meinen Augen wäre für JEDEN Socket/Server den der Media-Server bereitstellt die IP-Adresse

und/oder das Interface konfigurieren zu lassen. Wäre natürlich jetzt genau der umgekehrte Ansatz zur Ausschlussliste

(welche nicht für alle Sockets/Server zur verfügung steht) - aber vermutlich auch mit geringstem Aufwand zu realiseren.

 

lg,

Oswald Oliver

[DetlefM]

Da mich das Thema interessiert hat habe ich mal eine allgemeine Frage an CoPilot gestellt https://copilot.microsoft.com/shares/f21fb3xyfUuocRn7ry7qK
 

Er hat (nicht direkt auf Deine Frage aber als generelle Antwort) vorgeschlagen die Routing Tabelle anzupassen. 
Methode 2: Routing-Tabelle anpassen (für systemweite Steuerung)

 

Aber - ich habe keine Ahnung, sondern weiß nur wie man mit CoPilot chattet.

[Griga]

vor 2 Stunden schrieb h0ly0ne:

Auf meinen SATIP Clients scheint jetzt die IP-Adresse des RTSP Servers "zufällig" genommen zu werden.

 

Ich habe es im Code nachgeschlagen. Bei Sat>IP trifft  im Server zunächst vom Client eine Request via TCP ein. Video/Audio-Daten sendet der Server jedoch standardmäßig via UDP (darauf bezieht sich die Protokoll-Auswahlmöglichkeit im Client - der kann dem Server sagen, welche Art des Datentransports er gerne hätte). Die Wahl, über welchen Adapter die Daten an den Client rausgehen, überlässt der RTSP Server Windows. Und Windows schaut dann in seiner Routing Tabelle nach, über welchen Adapter die Client-Adresse am besten zu erreichen wäre. Hier habe ich schon etwas dazu im Hinblick auf Multicast geschrieben.

 

Sinnvoller wäre womöglich, wenn der RTSP Server für das Senden der UDP Daten den Adapter wählen würde, über den die TCP Request des Clients eingetroffen ist. Bei  Verwendung von TCP für das Senden der Daten ergibt sich das wohl automatisch, weil in dem Fall eine Verbindung hergestellt wird. Das ist bei UDP als verbindungslosem Protokoll jedoch nicht der Fall, d.h. der RTSP Server schickt die Daten einfach an Zieladresse und Port, ohne jemals zu erfahren, ob sie den Client erreichen.

 

Man müsste mal mit einer Testversion probieren, ob diese Maßnahme das Problem löst. Mein Problem ist, dass ich nicht weiß, wie sich eine solche Änderung allgemein auswirkt, d.h. ich müsste eine Option ergänzen, die eine Rückkehr zum bisherigen Server-Verhalten ermöglicht.

 

Ich komme drauf zurück... habe gerade keine Zeit mehr für weiteres.

 

[Griga]

Ich könnte jetzt bei Interesse eine Testversion des Media Servers bereitstellen, die für das Senden der UDP Daten den Adapter wählt, über den die TCP Request des Clients eingetroffen ist.

 

[h0ly0ne]

Ich habe zwischenzeitlich mit einer DLL-Injektion Lösung "ForceBindIP" experimentiert (welche alle WinSock Verbindungen hijacked und auf ein Interface/eine IP umbiegt) - das Ergebnis war dementsprechend durchwachsen. Interesse habe ich natürlich - vor allem wäre es interessant ob es mein Problem mit den springenden Verbindungen auf der Panasonic-TV Seite verändern wird.

[h0ly0ne]

Ein paar Zusatzinformationen konnte ich zu meinem Thema jetzt sammeln - folgende Details habe ich jetzt konfiguriert:

 

Rechner: DVBViewer (Ein Netzwerkinterface, nur mehrere IP-Adressen - die Rechner-IP ist die primäre auch am DNS registrierte)

Rechner-IP: x.y.z.5

Zusätzliche-IP: x.y.z.51

 

Folgendes habe ich im Media Server konfiguriert:

Web/UPnP -> Webserver -> Netzwerk-Adapter IP(s) NICHT nutzen: 127.0.0.1;x.y.z.5

Web/UPnP -> UPnP AV Server aktivieren -> JA

Web/UPnP -> UPnP AV Server aktivieren -> Netzwerk-Adapter IP(s) NICHT nutzen: 127.0.0.1;x.y.z.5

RTSP / SAT>IP Server aktivieren -> JA (Standard Settings darunter - Netzwerk-Adapter-Filter ist hier nicht möglich)

 

Wenn ich jetzt im DVBViewer nach SAT>IP Server suche, bekomme ich den Rechner DVBViewer geliefert - mit folgenden Einstellungen:

RTSP Server - Adresse: x.y.z.51

 

Versuche ich es mit diesen Einstellungen gibt es kein Signal/keine Kanäle.

Ändere ich die RTSP Server - Adresse auf x.y.z.5 - funktioniert es einwandfrei - jedoch lassen das die meisten SAT>IP Clients nicht zu (die gelieferte IP zu ändern)

 

Wie kommt der "RTSP Server" dazu die Zusätzliche-IP zu liefern? Diese ist weder die Standard-IP noch habe ich für den RTSP Server einen

"Ausschluß" konfiguriert (eher konfigurieren können, da es diese Funktion ja nicht gibt).

Ich habe hier den Verdacht, das die "Filter" Settings für den Webserver hier irgendwie verwendet werden - die Frage ist - warum? Oder alternativ wäre die Frage

noch, warum bekomme ich keine RTSP Kommunikation auf x.y.z.51 - wird hier immer der Socket auf die Rechner-IP gebunden?

 

Edit: Ich konnte zwischenzeitlich das Verhalten von "Netzwerk-Adapter IP(s) NICHT nutzen" soweit einschränken das es anscheinend irgendwie einen Effekt auf ALLE IPs pro Netzwerk-Adapter hat -> sprich ist eine IP von einem Adapter angegeben, scheinen alle IPs von dem "Block" betroffen zu sein. Das klärt für mich leider noch immer nicht das Verhalten das die "Zusätzliche-IP" als RTSP-Server IP zurückgeliefert wird.

 

Grüße,

Edited 18 hours ago by h0ly0ne

[HaraldL]

vor 4 Minuten schrieb h0ly0ne:

Rechner-IP: x.y.z.5

Zusätzliche-IP: x.y.z.51

Also falls bei den beiden IPs am gleichen Rechner tatsächlich die ersten 3 Zahlen x.y.z identisch sind dann wäre das netzwerktechnisch Unsinn (vorausgesetzt du hast keine kleinere Subnetzmaske welche die beiden IPs in unterschiedliche!! Subnetze separiert).

 

Es ist bei mehreren Netzwerkschnittstellen (egal ob LAN, WLAN, VPN, ...) oder mehreren IP-Subnetzen auf einer Schnittstelle erforderlich daß jede einzelne einem anderen, nicht überlappenden Subnetz zugeordnet ist. Ansonsten kann Windows gar nicht entscheiden ob es ein Ziel x.y.z.100 über die IP x.y.z.5 oder x.y.z.51 kontaktiert wenn beides möglich würde. Das ergibt nur Chaos.

 

Falls die beiden x.y.z unterschiedlich sind dann war das oben halt etwas missverständlich geschrieben. Dann besser z.B. x.y.w o.ä. für eine davon, oder halt die richtigen IP-Adressen, die sind ja wohl kaum geheim, und 192.168.x, 10.x.x.x oder 172.16.x-127.31.x sind von extern sowieso nie erreichbar.

[h0ly0ne]

Hallo - danke für die Antwort - jedoch handelt es hier um eine klassische Themaverfehlung - leider ...

 

51 minutes ago, HaraldL said:

Also falls bei den beiden IPs am gleichen Rechner tatsächlich die ersten 3 Zahlen x.y.z identisch sind dann wäre das netzwerktechnisch Unsinn (vorausgesetzt du hast keine kleinere Subnetzmaske welche die beiden IPs in unterschiedliche!! Subnetze separiert).

x.y.z sind ident - und dies ist kein netzwerktechnischer Unsinn, sondern eine relevante technische Notwendigkeit wenn man am selben Gerät/Interface verschiedene Dienste am gleichen Port betreiben möchte und muss. Natürlich befinden sich Default-Route und Default-Gateway nur auf einer IP - das wäre dann wohl eher der "Unsinn" an der Konfiguration - aber das geht wie gesagt am Thema vorbei.

 

53 minutes ago, HaraldL said:

Es ist bei mehreren Netzwerkschnittstellen (egal ob LAN, WLAN, VPN, ...) oder mehreren IP-Subnetzen auf einer Schnittstelle erforderlich daß jede einzelne einem anderen, nicht überlappenden Subnetz zugeordnet ist. Ansonsten kann Windows gar nicht entscheiden ob es ein Ziel x.y.z.100 über die IP x.y.z.5 oder x.y.z.51 kontaktiert wenn beides möglich würde. Das ergibt nur Chaos.

Es wäre höchstgradiger Unsinn diese Konfiguration auf verschiedene Subnetze aufzuteilen - wie schon erwähnt am Thema vorbei. Die anderen Interfaces befinden sich in anderen Netzen und/oder VLANs - alles fein diesbezüglich.

 

54 minutes ago, HaraldL said:

Falls die beiden x.y.z unterschiedlich sind dann war das oben halt etwas missverständlich geschrieben. Dann besser z.B. x.y.w o.ä. für eine davon, oder halt die richtigen IP-Adressen, die sind ja wohl kaum geheim, und 192.168.x, 10.x.x.x oder 172.16.x-127.31.x sind von extern sowieso nie erreichbar.

Geheim oder nicht - vermutlich noch dazu irrelevant für den Entwickler und/oder den Hersteller - somit geschwärzt/verallgemeinert.

 

Grüße,

[Griga]

vor 8 Stunden schrieb h0ly0ne:

Wie kommt der "RTSP Server" dazu die Zusätzliche-IP zu liefern?

 

Der liefert sie nicht. Der DVBViewer entnimmt die Remote IP dem Socket, über den ihn die vom Server gesendeten Infos erreichen. Die Kommunikation basiert auf UPnP. D.h. der Client sendet eine Multicast-Anfrage (M-SEARCH) über sämtliche verfügbaren Adapter bzw. IP-Adressen. Und der Server sendet eine Multicast-Antwort (NOTIFY) über alle Adapter bzw. IP-Adressen außer den in den Optionen ausgeschlossenen, wobei die UPnP-Ausschlussliste auch für Sat>IP gilt, soweit ich sehen kann. NOTIFY sendet er auch ohne Suchanfrage, wenn er gestartet wird, und danach in gewissen Zeitabständen.

 

Was der Sat>IP Server in seiner Antwort liefert, ist die URL einer description.xml (http://ip:port/description.xml), in der er seine Eigenschaften beschreibt. Die kannst du auch im Browser über den Webserver abrufen. Clients beziehen sie aber i.a. vom RTSP Server über Port 554 oder 8554.

 

Angaben ohne Gewähr. Ich bin in dem Thema zur Zeit überhaupt nicht drin, da mit etwas anderem beschäftigt, und müsste mich erst wieder einarbeiten, um Details in Hinblick auf dein schräges Setup zu untersuchen.

 

[Griga]

vor 10 Stunden schrieb h0ly0ne:

Interesse habe ich natürlich - vor allem wäre es interessant ob es mein Problem mit den springenden Verbindungen auf der Panasonic-TV Seite verändern wird.

 

@h0ly0ne: Ich habe dich einer PM-Konversation als Empfänger hinzugefügt, in der ich Media Server-Testversionen bereitstelle.

 

[h0ly0ne]

2 hours ago, Griga said:

 

@h0ly0ne: Ich habe dich einer PM-Konversation als Empfänger hinzugefügt, in der ich Media Server-Testversionen bereitstelle.

 

Vielen lieben Dank

[h0ly0ne]

Kurzes Update, ich konnte eine Teil-Lösung für das Problem des "IP"-hüpfens finden - ist nun zwar nicht die feine Englische Art - aber mit ner lokalen Windows Firewall Regel und der passenden Konfiguration im Media Server funktioniert es nun:

 

Interface: LAN

IP-Adresse: 172.31.255.5, 172.31.255.50 (SkipAsSource=true), 172.31.255.51 (SkipAsSource=true)

 

Lokaler WebService (Windows Admin Service) erreichbar unter: https://mediarechner.local (https://172.31.255.5:443)

Custom WebService erreichbar unter: https://mediamonitor.local (https://172.31.255.50:443)

Media Server WebService erreichbar unter: https://mediaserver.local (https://172.31.255.51:443)

 

Konfiguration Media Server:

Web/UPnP -> Webserver -> Netzwerk-Adapter IP(s) NICHT nutzen: 127.0.0.1;172.31.255.5;172.31.255.50

Web/UPnP -> UPnP AV Server aktivieren -> JA

Web/UPnP -> UPnP AV Server aktivieren -> Netzwerk-Adapter IP(s) NICHT nutzen: 127.0.0.1

RTSP / SAT>IP Server aktivieren -> JA

 

Konfiguration Firewall:

Block | Port TCP 554 | Scope - Local IP address - 172.31.255.50 + 172.31.255.51

 

Mit dieser Konfiguration melden (fast) alle SAT>IP Clients bei der Suche die primäre IP Adresse (172.31.255.5) und es gibt auch kein hüpfen mehr zwischen den IP Adressen beim Ergebnis. Zusätzlich funktioniert alles wie gewohnt - mit dem Luxus mehrere WebService unter Port 443 auf einem System zu betreiben. Einzig allein die Panasonic SAT>IP Clients bleiben dabei, das 172.31.255.51 (anstelle von 172.31.255.5) der SAT>IP Server ist ...

 

Grüße,

Edited 4 hours ago by h0ly0ne

[h0ly0ne]

Update #2:

 

Nachdem die Panasonic SAT>IP Clients nicht davon zu überzeugen waren die primäre IP-Adresse über RTSP zu erkennen, habe ich mich kurzum entschieden das Thema von der anderen Seite anzugehen und die Kommunikation pimär über die MediaServer IP-Adresse zu konfigurieren - somit ergab sich folgende Konfiguration mit der jetzt alle Geräte zufrieden sind:

 

Konfiguration Media Server:

Web/UPnP -> Webserver -> Netzwerk-Adapter IP(s) NICHT nutzen: 127.0.0.1;172.31.255.5;172.31.255.50

Web/UPnP -> UPnP AV Server aktivieren -> JA

Web/UPnP -> UPnP AV Server aktivieren -> Netzwerk-Adapter IP(s) NICHT nutzen: 127.0.0.1;172.31.255.5;172.31.255.50

RTSP / SAT>IP Server aktivieren -> JA

 

Konfiguration Firewall:

Block | Port TCP 554 | Scope - Local IP address - 172.31.255.5 + 172.31.255.50

Allow | Port TCP 554 | Scope - Local IP address - 172.31.255.51

 

Bis jetzt hat diese Konfiguration multiple Reboots und Suchläufen auf den SAT>IP Clients überlebt. Jedoch ist mir nach wie vor nicht klar, wie ich den Multicast Traffic soweit einschränken könnte, das er nicht eher "zufällige" Interfaces aushandelt (wobei der Zufall derzeit eher auf die "höchste" IP schließen lässt).

 

Grüße,

 

[Griga]

vor 2 Stunden schrieb h0ly0ne:

Web/UPnP -> Webserver -> Netzwerk-Adapter IP(s) NICHT nutzen:

 

Das hat mit Sat>IP / RTSP rein gar nichts zu tun.

 

vor 2 Stunden schrieb h0ly0ne:

Web/UPnP -> UPnP AV Server aktivieren -> Netzwerk-Adapter IP(s) NICHT nutzen:

 

Das wirkt auf die Multicast-Erkennungmechanismen. Gerade selbst probiert. Wenn ich dort die 192.168.xxx.xxx Adresse des Adapters auf dem Server-PC eintrage, findet ein Remote-DVBViewer den Server unter Optionen -> Hardware -> Einstellungen für ein assoziiertes RTSP-Netzwerkgerät nicht mehr. Sat>IP funktioniert trotzdem, weil das ja nur die Erkennung via UPnP betrifft, nicht die Anforderung und den Empfang von DVB/TV-Daten.

 

Um den gleichen Effekt bei einem lokalen DVBViewer zu erreichen, muss ich jedoch 127.0.0.1 und 192.168.xxx.xxx eintragen. Der DVBViewer erkennt lokale Adressen und biegt sie grundsätzlich auf 127.0.0.1 um, auch wenn das Multicast NOTIFY über 192.168.xxx.xxx eintrifft.