![Direkter nativer TCP-Dateitransfer zwischen zwei NAT-Maschinen](https://rvso.com/image/1475800/Direkter%20nativer%20TCP-Dateitransfer%20zwischen%20zwei%20NAT-Maschinen.png)
Ziel:
Ich möchte den schnellstmöglichen TCP-basierten Dateitransfer zwischen zwei Maschinen durchführen, die sich hinter zwei verschiedenen NATs befinden, und zwar in einer Situation, in der ein öffentlicher Port nicht auf eine der beiden Maschinen umgeleitet werden kann (lokale Richtlinien).
Näherungswerte:
Bisher konnte ich: 1) ein VPN mit einem zentralen öffentlichen Knoten einrichten, der als Relay fungiert (OpenVPN), 2) ein Mesh-VPN einrichten, um eine direkte Verbindung zwischen beiden Maschinen ohne Relay herzustellen (tinc). Das VPN kann dann nahtlos verwendet werden, um Datenübertragungen über beliebige Dateiübertragungs-Clients/-Server von Drittanbietern durchzuführen (als ob sich beide Maschinen im selben LAN befänden).
Problem:
Die Verbindung zwischen den beiden Maschinen ist ziemlich instabil und ein einzelner TCP-Stream erreicht normalerweise nur einen winzigen Bruchteil der verfügbaren Bandbreite. Darüber hinaus verursacht die Kapselung von TCP über TCP zusätzlichen Overhead und ist bei instabilen Verbindungen notorisch ineffizient. Ich möchte daher eine direkte (kein Relay) und native Verkehrsverbindung (keine VPN-Kapselung) zwischen den beiden Maschinen herstellen. Eine naheliegende Wahl ist das STUN-Framework, aber ich bin zu dem Schluss gekommen, dass eine Anwendung zur Interaktion mit einem öffentlichen STUN-Server und zur Erzielung von NAT-Traversal mit Ad-hoc-STUN-Bibliotheken kompiliert werden muss und auf STUN-spezifischen Sockets statt auf regulären Sockets basiert. Dies bedeutet im Wesentlichen, dass jeder neue Satz STUN-fähiger Client/Server-Anwendungen von Grund auf neu geschrieben werden muss.
Frage:
Um den Vorgang zu vereinfachen, frage ich mich, ob es möglich wäre, einen generischen STUN-Client zu implementieren, der im Grunde als Daemon auf beiden Rechnern ausgeführt würde. Die Clients würden sich mit einem öffentlichen STUN-Server verbinden, um sich bei anderen Clients zu registrieren und Informationen abzufragen. Sie würden außerdem den gesamten ausgehenden Datenverkehr von einem lokal überwachten Port auf die richtige IP/den richtigen Port (Benutzerkonfiguration + STUN-Serverinformationen) umleiten, um den anderen Rechner zu erreichen. Dies könnte es jeder Client-/Server-Anwendung eines Drittanbieters ermöglichen, problemlos reguläre TCP-Sockets (möglicherweise mehrere) zu öffnen und eine Verbindung mit dem anderen Rechner herzustellen (als ob er sich im selben LAN befände).
Antwort1
Du kannst es versuchenSoftEther VPN
- Es:
- Habe ganz gut
NAT Traversal
. - Ermöglicht die Konfiguration mehrerer
Listener Ports
.
Meiner Meinung nach ist es eine ziemlich gute Software, die Ihnen viel Arbeit ersparen kann ...