Einfache Portweiterleitung für UDP-Stream unter Windows

Einfache Portweiterleitung für UDP-Stream unter Windows

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.

verwandte Informationen