Meinung zur Thinktecture RelayServer als Vermittlungsserver

[nit]

Hallo, wir überlegen den Thinktecture RelayServer als Vermittlungsserver für unsere App einzusetzen.
Hat jemand Erfahrung mit den Server oder setzt es schon ein?
Wollte mal eure Meinungen dazu wissen?
Oder gibt’s auf Delphibasis Alternativen?

[sh17]

Was soll denn für ein Problem damit gelöst werden? Mir waren das damals zu viele Abhängigkeiten (SQL-Server z.B.), haben es anders gelöst.

[nit]

Das Hauptziel ist die dynamische öffentliche IP-Adresse und die Firewall beim Kunden zu umgehen, weil der Provider keine öffentliche IP-Adresse vergibt (DS-Lite Anschluss) oder Portfreigaben z.B bei beim Kunden nicht möglich sind. Und eine verschlüsselte REST Kommunikation der App mit dem lokalen Kunden REST-Server.

Wie löst ihr diese Problematik?

[himitsu]

Zitat:

Oder gibt’s auf Delphibasis Alternativen?

Es kommt drauf an, was erreicht werden soll
und wie oft und wie performant.

Irgendein Server/Proxy muß jedenfalls öffentlich her,
also eine öffentliche IP (feste IP, DynIP oder über Domain) mit offenem Port, zu dem sich beide Seiten verbinden können.

* über FTP oder WebDAV auf (d)einer WebSeite
* das kann auch ein PHP-Script auf (d)einer Webseite sein (z.B. die PHP-Zugriffe von Beiden via Stream, Dateien oder MySQL verbunden)
* man kann es über FileSharing-Protokolle leiten, ala Emule/Torrent/...
* über Chat-Protokolle (Slack, WhatsApp, Sykpe, ICQ, ...)
* einen SMS-Service (aber das ist schonwieder old-school und schnell teuer)
* VoIP (Daten im Audio codiert, oder vielleicht auch SMS/MMS)
* durch einen Mailserver (IMAP lesen und schreiben im Posteingang)
* über VPN, was es z.B auch im TeamViewer gibt
* auch Synolgy hat einen DynIP-Service mit Proxy-Server (QuickConnect), wo ich z.B. auch öffentlich auf mein NAS zugreifen kann, ohne offenen Port (bei mir)
...
* halt über irgendwas, wo es durch einen "öffentlichen" Server läuft

* wenn du unbedingt willst, dann auch auf einem Windows- oder inzwischen auch Linux-RootServer, wo du ein Delphi-Programm drauflegen kannst.
* und durch die Cloud kann man sowieso alles jagen





Eigentlich schade, dass man im Web "offiziell" die Rückkanäle nicht umleite/verbinden kann.
* beige Seiten sprechen einen öffentlichen Server an
* und die jeweiligen Rückkanäle dieser Anfrage werden auf die IP des jeweils anderen Servers umgebogen

* Wenn du rauszu mit einem Server redest, wird ja temporär für "diesen" Request rückzu ein Port geöffnet und im Netzwerk wieder zu dir durchgereicht, über welchen die Antwort des Servers zurück kommt.
* Diese beiden Rausgehenden und Rückkanäle müssten "nur" umgebogen werden, so dass deine beiden Clienten sich verbinden.

* Dann würde am Ende der Server nur als Verbinder arbeiten und der Traffic nicht durch diesen Server/Proxy fließen.
-> Die beiden Programme werfen ein Kabel zum Server, der verknotet sie und lässt los.

[sh17]

DS-Lite heisst nur, dass man keine öffentliche IP4-Adresse hat, es handelt sich dann um einen IPv4-in-IPv6-Tunnel. Also eine öffentliche (dynamische) IPv6-Adresse hat man schon. Evtl hat man dann noch Probleme auf Client-Seite, wenn diese kein IPv6 können, wie manche Mobilfunknetze.
OK, kommt natürlich auf die Kundschaft an, aber DS-Lite ist eher in Privathaushalten. Wir können da schon einen geschäftlichen DSL-Anschluss voraussetzen.

Wir haben das so gelöst, das wir für unsere Kunden einen eigenen DynDNS-Dienst aufgebaut haben (wenn der Kunde über eine feste IP verfügt, umso besser). Die Hauptdomain besitzt ein Wildcard-SSL-Zertifikat, jeder Kunde bekommt seine eigene Subdomain, die auf seinen Anschluss mit Port x an seinen Server weitergeleitet wird. Durch die Verteilung ist das relativ Ausfallsicher und wir müssen uns nicht um irgend eine Infrastruktur kümmern. (Der Relay-Server sollte ja mindesten redundant ausgelegt werden.)

[Michael II]

Zitat:

Zitat von himitsu (Beitrag 1474132)

Zitat:

Oder gibt’s auf Delphibasis Alternativen?

* Dann würde am Ende der Server nur als Verbinder arbeiten und der Traffic nicht durch diesen Server/Proxy fließen.
-> Die beiden Programme werfen ein Kabel zum Server, der verknotet sie und lässt los.

Das von dir beschriebene Verfahren funktioniert ja für UDP (etwas weniger häufig auch für TCP) bei "geeigneter" Hardware ganz gut und nennt sich "Hole Punching".

https://de.wikipedia.org/wiki/Hole_Punching
https://en.wikipedia.org/wiki/TCP_hole_punching

Für ein Netzwerk für ein Spiel ist das sicher cool (und funktioniert wirklich ;-)) - aber ich weiss nicht, ob man für Firmenkommunikation einsetzen sollte...(Lösung zu fest abhängig von Hardware).

[sh17]

Gab's hier auch mal was dazu

https://www.delphipraxis.net/172895-...-punching.html

[himitsu]

Ja, drum wäre es schön, wenn dieses als offiziele "Funktion" z.B. im TCP/IP eingebaut würde, damit es eben nicht nur ein "Hack" ist und immer funktioniert.

Denn aktuell ist es ja so, dass der "komplette" Trafic ja doppelt über einen Server läuft (rein und wieder raus), was nicht schön ist, wenn es nicht der eigene Server ist und der andere dann was dagegen hat, dass man dessen Traffic verbraucht :oops:,
was sich durch sowas eben lösen liese, da der Server nur noch für den Verbindungsaufbau zuständig wäre, damit die beiden nicht offenen Zugänge sich finden und verbinden.



51 Jahre Internet aber neeee.
Im Prinzip wäre es doch auch von der "Sicherheit" her interessant, wenn die Daten dann nicht mehr "durch" einen (bestimmten) fremden Server laufen würde.
Und zusätzlich könnten die Daten dann auch den kürzesten Weg nehmen. PC > PC anstatt PC > Server > PC
Wenn die PCs in Deutschland stehen und der Server in den USA, oder auch schon beide Zugänge in Dresden und der Server in Frankfurt, dann müsste das garnicht erst raus aus dem Dorf und würde im Internet bestimmt massenhaft Traffic sparen.

[Michael II]

Zitat:

Zitat von himitsu (Beitrag 1474158)

Ja, drum wäre es schön, wenn dieses als offiziele "Funktion" z.B. im TCP/IP eingebaut würde, damit es eben nicht nur ein "Hack" ist und immer funktioniert.

Ja, das wäre gut ;-).

Früher gab's im Netz viele Listen mit Router Modellen, welche voraussehbare "äussere" Portnummern erzeugten und damit für HP geeignet waren. Irgendwie ist das Thema ein wenig durch: Die Verbindungen sind viel schneller geworden und Serverkosten enorm viel tiefer. Einen Server zwischen A und B zu setzen ist wohl für die meisten Anwendungen am einfachsten/günstigsten.

In Netzwerken mit HomeUserinnen und HomeUsern reicht oft NAT via UPnP. Dann hast du genügend Server um ein sehr stabiles Netzwerk aufzubauen.

Ich verwende heute für den Netzaufbau drei Server, bei den Kunden NAT via UPnP (ist bei ca. 20% ein), HP habe ich vor Jahren entfernt. Das Netzwerk läuft seit vielen Jahren ohne Unterbruch.

[Rollo62]

Zitat:

Zitat von himitsu (Beitrag 1474132)

* das kann auch ein PHP-Script auf (d)einer Webseite sein (z.B. die PHP-Zugriffe von Beiden via Stream, Dateien oder MySQL verbunden)

Richtig, oder gleich einen Provider der DynDns unterstützt.
Ich empfehle immer All-Inkl als Provider, die haben sehr faire Preise und ermöglichen Vieles was bei Anderen geblockt ist,
sogar Unter-Accounts zur Mandantenverwaltung.
https://www.schmuttermaier.com/2019/...tzbox-allinkl/