so unbekannt & kompliziert ist das Problem nun auch nicht... das ja auch der breiten Masse als TeamViewer-Konzept bekannte Verfahren, bietet sich für solche "Client2Client" Verbindungen an.
Es braucht dazu nur einen im Inet verfügbaren Server, wo eine Software drauf läuft, welche logisch für n:m Connects ausgelegt ein sollte.
Klar bietet das Angriffsfläche und Datenschutzprobleme, aber wenn die Clients nur selbst per z.B. AES End2End verscchlüsselte Daten austauschen, können die WorstCase sicher im ganzen INet mitgehört werden, aber dekodieren kann sie soeinfach niemand, wenn niemals der Key auf diesem Weg verschickt wird.
Da reicht als dummes ServerGateway in Step1 auch was per
Indy zusammengeklicktes.
Wenn man TMS Componenten verfügbar hat, nehme konfiguriere man per XDATA einen HTTPS/SSL verschlüsselten SokectServer und installiere ein eigenes SSL Zertifikat, dann ist nach Connect auch die Datenstrecke per SSL noch Standard verschlüsselt... letztendlich dist diese SSL plus XY Verschlüsselung bei Teamviewer so zig tausende Male im Einsatz und da installiert man als Anwender nur eine ganz einfache APP, zu 99% muss sich niemand um irgendwelche Netzwerkfragen kümmern (wenn nich ein ehrgeiziger Admin da explizit Steine in den Weg gelegt hat).
Die einfache technische Basis auf Anwender und Betreiberseit mit ner StandardDSL Konfihuartion ist also nicht so schlimm, solange es zentral im Inet für ja schon 10..15€/MOnat zu haben einen RootServer gibt, wo man seine eigene kleine und funktional möglichst dumme "Gateway-Software" drauf installiert.
Mit etwas Aufwand für Authentifizierung und einer (von extern) zu Konfigurierende Liste der zulässigen N:M Verbindungen ist das Konzept um Aufwand als auch von Datenschutz unschlagbar, denn der Server speicher NULL Daten, er empfängt nur in den
RAM und leitet die Daten realtime an die zur Verbindung hinterlegten Clients weiter. Man braucht sich also "nur" um die Sicherheit der Verbindungen zu kümmern.