Socket Sockets an ein anderes Gerät weiterreichen?

[Jannn]

Hallo allerseits. Ich versuche momentan eine Java-Anwendung zu schreiben. Hierbei sollen zwei Clients eine direkte Verbindung zueinander aufbauen. Ohne einen vermittelnden Server (also per STUN/TURN oder ICE) habe ich keine zuverlässige Lösung finden können. Deshalb möchte ich nun versuchen, einen Server zu programmieren. Dieser soll dabei helfen, die direkte p2p Verbindung zwischen den Clients herzustellen. Nachdem diese Verbindung hergestellt wurde, soll der Server nicht mehr an der Kommunikation beteiligt sein.

Mein Grundgedanken war es nun, dass der Server eine Verbindung zu Client A und Client B herstellen soll. Der Server "verfügt" nun also über zwei Client-Sockets. Nun stellt sich mir die Frage, ob ich diese Client-Sockets bzw. die darin enthaltenen Informationen einfach an den jeweils anderen Client weiterreichen kann. Client A soll also vom Server den Socket von Client B bekommen und umgekehrt.
Mein Gedanken dahinter war nun, dass wegen der vorangegangenen Kommunikation mit dem Server, bereits NAT-Einträge vorhanden sein sollten und nun eine direkte Verbindung zwischen den Clients möglich sein sollte - besonders dann, wenn keine Portweiterleitung aktiviert ist.
Ich meine, dass Webbrowser das auch so machen: Es wird eine Verbindung zu einem Webserver hergestellt. Dabei werden die private IP-Adresse, der lokale Port und der externe Port in einem Eintrag in der NAT-Tabelle miteinander verknüpft. Nur so kann anschließend sichergestellt werden, dass die Antwort des Webservers - die lediglich an eine öffentliche IP-Adresse und einen externen Port geht - an das richtige Gerät innerhalb des Netzwerks weitergeleitet wird.
Übertragen auf mein Programm stellt sich dann quasi die Frage, was passiert, wenn nun nicht der ursprünglich adressierte Webserver antwortet, sondern ein Gerät mit einer ganz anderen Adresse. (Hier vermute ich mein Problem.)

Jetzt zum eigentlichen Problem: Ich habe es ausprobiert und funktioniert - aber nur gelegentlich. Sobald einmal eine Verbindung hergestellt wurde, funktioniert alles problemlos. Ob allerdings überhaupt erst eine Verbindung hergestellt werden kann, hängt davon ab, in welchen Netzwerken sich die Clients befinden. Dabei gilt aber, dass es pro Netzwerk entweder immer funktioniert oder immer nicht funktioniert. Es scheint also kein Zufall zu sein, sondern irgendein Problem, dass ich übersehe.

Ich verzichte an der Stelle mal darauf, Quelltext zu teilen - Die 500 verschiedene Ansätze würden wohl den Rahmen sprengen. Es muss definitiv ein konzeptionelles Problem sein und liegt nicht an einfachen Programmierfehlern.

Nun wäre ich ausgesprochen dankbar, wenn mir jemand dabei behilflich sein könnte, herauszufinden, wo das Problem liegt. Ich würde jeden Input sehr wertschätzen!

 

[KonradN]

Mein Grundgedanken war es nun, dass der Server eine Verbindung zu Client A und Client B herstellen soll. Der Server "verfügt" nun also über zwei Client-Sockets. Nun stellt sich mir die Frage, ob ich diese Client-Sockets bzw. die darin enthaltenen Informationen einfach an den jeweils anderen Client weiterreichen kann. Client A soll also vom Server den Socket von Client B bekommen und umgekehrt.
Mein Gedanken dahinter war nun, dass wegen der vorangegangenen Kommunikation mit dem Server, bereits NAT-Einträge vorhanden sein sollten und nun eine direkte Verbindung zwischen den Clients möglich sein sollte - besonders dann, wenn keine Portweiterleitung aktiviert ist.

Das verstehe ich nicht. Wenn Client A und B nicht direkt miteinander kommunizieren können, dann geht es nicht ohne den Server in der Mitte. Was Du da mit den NAT Einträgen meinst, erschließt sich mir schlicht nicht, denn die NAT Einträge, die entstehen, sind ja nur vom Client -> Router -> Server mit Rückweg. Dass der Server da irgendwas an einen anderen Client sendet macht ja nichts an dieser Kommunikation und natürlich nützen diese NAT Einträge nichts um eine direkte Kommunikation zu ermöglichen.

 

[Jannn]

Das verstehe ich nicht. Wenn Client A und B nicht direkt miteinander kommunizieren können, dann geht es nicht ohne den Server in der Mitte.

Das können sie schon und sollen sie sogar. Eine direkte Kommunikation ohne Server sollte möglich sein. Lediglich der Aufbau der Kommunikation ist mir nicht ohne Server gelungen.

Was Du da mit den NAT Einträgen meinst, erschließt sich mir schlicht nicht, denn die NAT Einträge, die entstehen, sind ja nur vom Client -> Router -> Server mit Rückweg. Dass der Server da irgendwas an einen anderen Client sendet macht ja nichts an dieser Kommunikation und natürlich nützen diese NAT Einträge nichts um eine direkte Kommunikation zu ermöglichen.

Das Problem bei der direkten Kommunikation ist ja im Grunde das NAT. Ohne das NAT hätte ich keine Probleme.
Wenn nun beim Client keine Portweiterleitung aktiviert ist, hat der Router initial keine Ahnung, an welches Geräte er eine Nachricht - die ja lediglich einen externen Port (und eine öffentliche IP-Adresse) als Adresse beinhaltet - weiterleiten soll. Client A kann also nicht einfach per IP-Adresse und Port Client B kontaktieren.
Wenn Client B nun aber zuvor eine Verbindung zu meinem Server hergestellt hat, dann gibt es bei Client B im NAT einen Eintrag, der die private IP-Adresse und den lokalen Port des Geräts von Client B auf einen externen Port abbildet. Nur so ist es dem Router von Client B überhaupt möglich, die Antwort des Servers an das Gerät von Client B weiterzuleiten. Der Router von Client B übersetzt also den externen Port, den die Nachricht des Servers beinhaltet, in eine private IP-Adresse und einen lokalen Port.
Genau das möchte ich nun ausnutzen. Mein Server gibt die öffentliche IP-Adresse und den externen Port von Client B an Client A weiter. Client A kann dann eine Nachricht an Client B senden. Client A verhält sich also ganz einfach so, als wäre er selbst der Server. Da Client B davor mit dem tatsächlichen Server kommuniziert hat, gibt es im NAT von Client B einen Eintrag, der den dazugehörigen externen Port auf die private IP-Adresse und den lokalen Port abbildet. So sollte es nun klappen, dass die Nachricht, die Client A an Client B gesendet hat (adressiert an dieselbe öffentliche IP-Adresse und denselben externen Port, an die auch der Server seine Nachrichten gesendet hat) tatsächlich vom Router an das richtige Gerät weitergeleitet wird.

So habe ich mir das zumindest gedacht. Kurzgefasst gehe ich davon aus, dass das NAT beim Weiterleiten von ankommenden Nachrichten den externen Port in eine lokale IP-Adresse und einen lokalen Port übersetzt. So wie ich das sehe, sollte die Adresse (und der Port), von dem aus die Nachricht gesendet wurde, dabei keine Rolle spielen. Das NAT sollte also eigentlich nicht dazwischen unterscheiden, ob nun der Server oder Client A versucht, eine Nachricht zu senden. Genau das wollte ich ausnutzen. Möglicherweise liegt aber genau hier mein Fehler. Vielleicht berücksichtigen - zumindest manche NATs - eben doch die IP-Adresse, von der eine Nachricht stammt.

Offensichtlich muss sich in diesen Überlegungen irgendwo ein Fehler eingeschlichen haben. Ich habe gerade erst begonnen, mich mit dem Thema Netzwerk zu beschäftigen und hoffe, dass ich es jetzt besser formuliert habe und verständlich wird, was ich meine. Wenn du in meiner Ausführung irgendwo Fehler findest, wäre ich sehr froh darüber, wenn du mir sagst, wo ich falsch liege.

 

[KonradN]

Wenn Client B nun aber zuvor eine Verbindung zu meinem Server hergestellt hat, dann gibt es bei Client B im NAT einen Eintrag, der die private IP-Adresse und den lokalen Port des Geräts von Client B auf einen externen Port abbildet. Nur so ist es dem Router von Client B überhaupt möglich, die Antwort des Servers an das Gerät von Client B weiterzuleiten. Der Router von Client B übersetzt also den externen Port, den die Nachricht des Servers beinhaltet, in eine private IP-Adresse und einen lokalen Port.

Also mir scheint, dass Du die ganze Technologie noch nicht wirklich verstanden hast. NAT ist erst einmal nur Network Adress Translation und da gibt es viele diverse Arten von. Und das kann man auf viele verschiedene Weisen konfigurieren. Und da kommen dann auch recht viele zusätzliche Technologien ins Spiel.

Ein erster Startpunkt, sich das etwas anzulesen, wäre z.B. Network address translation - Wikipedia - da finden sich auch viele Links zu diversen RFCs.

Das, was Du sehr oft findest, ist Networt address and port translation (NAPT). Das kann z.B. einfach ein Port Forwarding auf dem Router sein.
Damit wäre ein System eines lokalen Netzes auch erreichbar (so der Router erreichbar ist, was auf Grund der IP Knappheit aber nicht gegeben sein muss. In Mobilfunknetzen und Kabelnetz von Vodafone ist es z.B. in der Regel nicht möglich, den Router zu erreichen, da dieser auch nur eine lokale IP bekommen hat).

Hier ist aber wichtig: Das ist eine explizite Portweiterleitung, die da erstellt wird.

Was hier auch oft an Begriffen zu finden ist sind "Source NAT" und "Destination NAT".

Das, was Router bei einem reinen Verbindungsaufbau machen, ist aber meist etwas anderes. Der Router öffnet keinen expliziten Port. Nur weil da also eine Verbindung über den Router aufgebaut wurde, kann da kein anderes System das nutzen, um den Client zu erreichen.
(Bei TCP Verbindungen wäre auch die Frage, wie Du Dir das vorstellst. Du baust ja eine Verbindung auf - damit hast Du einen Socket für die ausgehende Verbindung. Mit dem könntest Du auch keine Verbindungen annehmen...)

Daher ist wirklich die Fragestellung:
a) Was ist das Problem mit der Verbindung über den Server? Das sollte den Server nicht groß belasten und wäre eine einfache Lösung.
b) Du kannst natürlich probieren, eine Portweiterleitung zu erstellen. Das kann aber zum Teil problematisch sein (uPnP, PCP wären da zwei Stichworte)
c) ipv6 wäre ggf. eine Lösung. Wenn die Provider ipv6 unterstützen und die Clients das auch haben, dann könnte man direkt kommunizieren. Aber natürlich muss das Routing aktiviert sein und die Firewall darf das nicht blocken.

Das einfach nur einmal als Gedanken von meiner Seite. Generell sehe ich da keine wirkliche Lösung für direkte Verbindungen alleine schon, weil dies per default immer unterbunden ist (aus guten Gründen!)

 

[Oneixee5]

Du meinst wahrscheinlich so etwas wie avahi/zeroconf. Auf jedem Rechner wird ein Dienst/Server gestartet. Die einzelnen Dienste suchen dann das Netzwerk ab, ob sie Gleichgesinnte finden können. Jeder Dienst ist so etwas wie Server und Client gleichzeitig. Der Client sucht im Adressbereich deines Netzwerkes und fragt jede Adresse an. Wenn ein Server antwortet, dann wird ausgetauscht was sie untereinander zu bieten haben, z.B. Chat, Dateien, Drucker, Musikstreaming usw. Wichtig dabei ist, dass die Firewalls so eingestellt werden, dass eine Kommunikation möglich ist.

 

[Jannn]

Also mir scheint, dass Du die ganze Technologie noch nicht wirklich verstanden hast. NAT ist erst einmal nur Network Adress Translation und da gibt es viele diverse Arten von. Und das kann man auf viele verschiedene Weisen konfigurieren. Und da kommen dann auch recht viele zusätzliche Technologien ins Spiel.

Definitiv. Ich habe mich gerade nochmal ein wenig eingelesen. Alleine das Wort symmetrisch sprengt schon meine ganzen Überlegungen. Mich wundert inzwischen eher, dass es tatsächlich manchmal geklappt hat.

Das, was Du sehr oft findest, ist Networt address and port translation (NAPT). Das kann z.B. einfach ein Port Forwarding auf dem Router sein.
Damit wäre ein System eines lokalen Netzes auch erreichbar (so der Router erreichbar ist, was auf Grund der IP Knappheit aber nicht gegeben sein muss. In Mobilfunknetzen und Kabelnetz von Vodafone ist es z.B. in der Regel nicht möglich, den Router zu erreichen, da dieser auch nur eine lokale IP bekommen hat).

Die Lösung hatte ich ursprünglich verwendet. Zusammen mit einer Domain und DynDNS hat das gut funktioniert. Ich suche aber nach einer Lösung, die überhaupt keine Konfiguration am Router benötigt. Damit fällt Port Forwarding weg.

a) Was ist das Problem mit der Verbindung über den Server? Das sollte den Server nicht groß belasten und wäre eine einfache Lösung.

Das Problem ist, dass ich es mir in den Kopf gesetzt habe, eine direkte Verbindung zwischen Clients herstellen zu wollen. Das ganze ist mehr oder weniger ein Selbstzweck: Ich will lernen, wie es funktioniert. Für mich als Einsteiger in die Materie klang das auch überhaupt nicht kompliziert. Zwei Geräte mit einander verbinden, war das nicht der Grundgedanken des Internets...

b) Du kannst natürlich probieren, eine Portweiterleitung zu erstellen. Das kann aber zum Teil problematisch sein (uPnP, PCP wären da zwei Stichworte)

Das habe ich auch implementiert. Läuft beides gut. Das Problem ist hier wieder, dass es nicht von allen Routern unterstützt wird bzw. zuerst aktiviert werden muss.

ipv6 wäre ggf. eine Lösung. Wenn die Provider ipv6 unterstützen und die Clients das auch haben, dann könnte man direkt kommunizieren. Aber natürlich muss das Routing aktiviert sein und die Firewall darf das nicht blocken.

Das hatte ich auch zuerst durchdacht. Ausgeschlossen habe ich es dann, weil - stand heute - ipv6 keinesfalls die Standardkonfiguration an allen Routern ist.

Das einfach nur einmal als Gedanken von meiner Seite. Generell sehe ich da keine wirkliche Lösung für direkte Verbindungen alleine schon, weil dies per default immer unterbunden ist (aus guten Gründen!)

Das ist leider die Antwort, die ich davor auch immer bei meinen Suchen gefunden habe. Ich wollte es nur einfach nicht glauben. Nach dem, was ich gelesen habe, verwenden einige Programme (z.B. Zoom) nämlich tatsächlich eine direkte Verbindung zwischen den Clients im die Verzögerungen niedrig zu halten. Das Stichwort soll hier WebRTC (mit ICE) sein. Hier hatte ich nur enorme Schwierigkeiten, mich einzulesen und wollte einfach nicht glaube, dass es keine einfachere Lösung geben soll.

 

[Jannn]

Du meinst wahrscheinlich so etwas wie avahi/zeroconf. Auf jedem Rechner wird ein Dienst/Server gestartet. Die einzelnen Dienste suchen dann das Netzwerk ab, ob sie Gleichgesinnte finden können. Jeder Dienst ist so etwas wie Server und Client gleichzeitig. Der Client sucht im Adressbereich deines Netzwerkes und fragt jede Adresse an. Wenn ein Server antwortet, dann wird ausgetauscht was sie untereinander zu bieten haben, z.B. Chat, Dateien, Drucker, Musikstreaming usw. Wichtig dabei ist, dass die Firewalls so eingestellt werden, dass eine Kommunikation möglich ist.

So ähnlich hatte ich mir das gedacht. Ich wollte mich aber nicht auf das lokale Netzwerk beschränken sondern das ganze Internet zur Verfügung haben. Deshalb wollte ich auch nicht alle Adressen anfragen, sondern gezielt eine Verbindung aufbauen.

Was ich so geplant hatte, war die Verwendung von "internen" Servern. Ich hatte es mir so gedacht, dass ein Client eine Sitzung hosten kann. Dieser Client hätte dann auf seinem Gerät den Server bereitgestellt und sich selbst als Client damit verbunden. Das löst dann zwar die Probleme auf logischer Ebene (wer darf wann was machen?) aber die Netzwerkprobleme bleiben leider.

 

[LimDul]

Das ist leider die Antwort, die ich davor auch immer bei meinen Suchen gefunden habe. Ich wollte es nur einfach nicht glauben. Nach dem, was ich gelesen habe, verwenden einige Programme (z.B. Zoom) nämlich tatsächlich eine direkte Verbindung zwischen den Clients im die Verzögerungen niedrig zu halten. Das Stichwort soll hier WebRTC (mit ICE) sein. Hier hatte ich nur enorme Schwierigkeiten, mich einzulesen und wollte einfach nicht glaube, dass es keine einfachere Lösung geben soll.

Einfach ist das nicht: https://de.wikipedia.org/wiki/Session_Traversal_Utilities_for_NAT

Ein Client, der hinter einem NAT sitzt kann man nicht einfach von außen erreichen.

NAT funktioniert wie folgt.
Client hinter NAT: A
NAT-Router: B
Rechner im Netz: C

Wenn A eine Verbindung nach C aufbaut, wird die IP Adresse von A (die nicht von außen erreichbar ist) durch die IP Adresse von B ersetzt. Der NAT Router muss nun sicherstellen, dass er die Pakete, die von C ankommen auch wieder an A weiterreicht. Dazu gibt es mehrere Möglichkeiten wie er das Mapping machen kann (Siehe die verschiedenen NAT-Arten, die im Wikipedia Artikel beschrieben sind). STUN versucht diese zu erkennen, so dass unter Umständen eine Verbindung zwischen zwei hinter NAT liegendem Rechnern aufgebaut werden kann. Trivial ist aber was anderes, es benötigt insbesondere wohl zwei STUN Server und klappt - wie man im Flussdiagramm sieht - auch nicht in allen Fällen.

Ausgenutzt wird dabei, dass wenn A and C ein Paket schickt, die Verbindung in der Regel einen auf dem NAT-Router per Ziel-IP & Port gemappt wird. Sprich, B baut die Verbindung zu C auf und nutzt Ausgangs-Port X. Wenn dann eine Antwort von C kommt, die an B + Port X gerichtet wird, dann wird das Paket an A durchgelassen. Wenn man das nun spiegelt (weil man auf der anderen Seite auch ein NAT hat), dann kann man so quasi auf den Ports unter Nutzung der öffentlichen IPs eine direkte Verbindung aufbauen.

 

[Oneixee5]

Kann man nicht über IPV6 das Problem einfach vermeiden?