
Ich versuche, ncat (aus der Nmap-Distribution für Windows) zu verwenden, um einfach einen UDP-Stream weiterzuleiten.
Beispiel: Ein Videostream kann auf Port 5444 empfangen werden. Ich möchte diesen Stream an einen anderen Computer (sagen wir 192.168.10.10) auf Port 5555 weiterleiten.
Ich habe herausgefunden, dass dies für TCP-Verbindungen problemlos möglich ist (z. B.
Netsh-Schnittstelle Portproxy hinzufügen v4tov4 Listenport = 5444 Listenaddress = 192.168.10.9 Connectport = 80 Connectaddress = 192.168.10.10
), aber ich weiß nicht, wie das für UDP geht.
Socat ist die naheliegende Lösung unter Linux, aber ich muss Windows verwenden.
Ich habe Folgendes versucht:
ncat -l -u 5444 | ncat -u 192.168.10.10 5555
Aber die Leistung ist so miserabel, dass es unbrauchbar ist. Ich glaube, ich bin mit ncat auf dem Holzweg.
Das MUSS einfach sein, aber ich bin ein Neuling, wenn es um iptables und dergleichen geht (wo ich die Antwort vermute). Alle Hinweise sind willkommen.
Antwort1
Ich habe eine „einfache“ Windows-basierte Lösung ohne Abhängigkeiten von Drittanbietern gefunden. Sie besteht darin, RRAS NAT auf einem Windows Server-Betriebssystem zu aktivieren. Dann
Netsh-Routing-IP-NAT fügt Portmapping "Ethernet" UDP 0.0.0.0 5444 192.168.10.10 5555 hinzu
Dabei ist „Ethernet“ der Name der Netzwerkkarte, die die „öffentliche Schnittstelle“ mit aktiviertem NAT in Routing und Remoteunterstützung darstellt.
Bei richtiger Konfiguration führt der folgende Befehl zu der folgenden Ausgabe:
>netsh routing ip nat show interface
NAT Ethernet Configuration
---------------------------
Mode : Private Interface
NAT Static Port Mapping Configuration
-------------------------------------
Protocol : UDP
Public address : 0.0.0.0
Public port : 5444
Private address : 192.168.10.10
Private port : 5555
Der Vorschlag von harrymc mit sudpproxy war ebenfalls eine gute Antwort, aber für meine Anwendung ist der zusätzliche Aufwand des nativen Windows-Ansatzes weniger ein Nachteil als die Abhängigkeit von einem Drittanbieter-Tool.