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 1 hour 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,