Anwendungs Server als Client betreiben mit Indy

[QuickAndDirty]

Der Kontext
Ich möchte das eine Mobile App einen Windowserver erreichen kann. Bisher ist das auch möglich mit Freigaben in der Firewall.
Um die Firewall Freigabe zu umgehen möchte ich den Windows Server Dienst und die Mobile App als client betreiben.
Es wird also einen Server in der Cloud geben zu dem sich beide verbinden und der als Relay funktionieren soll.
Wie ich das genau mache weiß ich noch nicht. Es soll so ähnlich funktionieren wie Reverse-Proxy-SSH nur eben ohne SSH und am liebsten ohne tunneln,
weil es schon ein TCP bzw. ein SOAP Protocoll benutzt und man soll TCP ja nicht durch TCP tunneln wegen der ganzen SYN,ACK,&c. Geschichte.

Also die eigentliche Frage:
Kann ich TIDTCPSERVER oder TIdHTTPWebBrokerBridge als Client betreiben?
Sprich ich will, dass sie aktiv eine Adresse und Port Connecten aber dann auf Anfragen warten.

[Kas Ob.]

Zitat:

Zitat von QuickAndDirty (Beitrag 1530045)

Der Kontext
Ich möchte das eine Mobile App einen Windowserver erreichen kann. Bisher ist das auch möglich mit Freigaben in der Firewall.
Um die Firewall Freigabe zu umgehen möchte ich den Windows Server Dienst und die Mobile App als client betreiben.
Es wird also einen Server in der Cloud geben zu dem sich beide verbinden und der als Relay funktionieren soll.
Wie ich das genau mache weiß ich noch nicht. Es soll so ähnlich funktionieren wie Reverse-Proxy-SSH nur eben ohne SSH und am liebsten ohne tunneln,
weil es schon ein TCP bzw. ein SOAP Protocoll benutzt und man soll TCP ja nicht durch TCP tunneln wegen der ganzen SYN,ACK,&c. Geschichte.

Also die eigentliche Frage:
Kann ich TIDTCPSERVER oder TIdHTTPWebBrokerBridge als Client betreiben?
Sprich ich will, dass sie aktiv eine Adresse und Port Connecten aber dann auf Anfragen warten.

Not sure if i understand the question,
But are you asking how to connect a peer to a server where the server doesn't have public IP (AKA the server in NAT)? if so, then the answer is no, you can't do it as you described above.

One solution is (away from SSH and tunneling which also need a public IP) the use of STUN server, in short STUN is reverse proxy server where peers register and a tunnel can be achieved, so the server side will have a client to connect to the STUN and act as tunnel for the traffic, the Internet full of better and more detailed explanation for STUN protocol.

As for Delphi to my knowledge there is only two libraries implement STUN protocol, which in fact very simple and short protocol :
1) LakeOfSoft VC http://lakeofsoft.com/vc/a_stunsample.html https://github.com/lakeofsoft/vcpub
2) esegece WebSockets https://www.esegece.com/websockets/p2p/stun/stun-server

Also there is many free and open STUN server, like google STUN for WebRTC
https://gist.github.com/sagivo/3a4b2...7c2f1f59ac6c6b
https://gist.github.com/mondain/b0ec1cf5f60ae726202e

[QuickAndDirty]

I might not use your suggested idea. But I'm realy learning a lot somewhat related to my problem from diving in to the details of the acronyms in your post!

[QuickAndDirty]

So I might need a TURN Server in the cloud. This is the All-Server-Releay.
And The windows-service and the Mobile-App will connect as clients to that TURN server.
I think I might need a Service that acts as All-Client-Relay between TURN Server and Windows-Service.
All Relays(at least 2) should not "tunnel" but "Translate"/"foward" the data.

[Kas Ob.]

Zitat:

Zitat von QuickAndDirty (Beitrag 1530058)

So I might need a TURN Server in the cloud. This is the All-Server-Releay.
And The windows-service and the Mobile-App will connect as clients to that TURN server.

STUN is way easier to use and better than TURN, also STUN is everywhere and you don't need to own a STUN server, you can use the google one and any other.
Also don't be misinformed by many resources that STUN is only UDP, STUN is TCP too.

You need to know the difference between the two, well it is complicated a little, so from https://en.wikipedia.org/wiki/Traver...ays_around_NAT

Code:

TURN does not aid in running servers on well known ports in the private network through a NAT; it supports the connection of a user behind a NAT to only a single peer, as in telephony, for example.

While STUN is https://en.wikipedia.org/wiki/STUN and in support TCP per provider.

Zitat:

Zitat von QuickAndDirty (Beitrag 1530058)

I think I might need a Service that acts as All-Client-Relay between TURN Server and Windows-Service.
All Relays(at least 2) should not "tunnel" but "Translate"/"foward" the data.

Well you got the idea, but again TURN is different from what you are assuming.


I would suggest to stick IPv6, but from what i read most mobile providers limit its functionality, see, IPv6 come with different routing mechanism and in theory any IP (IPv6) address should be reached because there is no NAT, no subnet and masking is ownership, which is included.

[Kas Ob.]

After thinking a little, let me rephrase some of the above

STUN is one-to-many/many-tp-one/one-to-one , should work always if any party can reach (or connect in case TCP) to the STUN server.
TURN is one-to-one with specific requirement from the network.

[QuickAndDirty]

I want to sent large amounts of data over this Server.
So would STUN work?
I mean it would be pretty good if I could actually use the STUN from google.

It's immportant to know that the Windows-Server-Service will be behind different corporate firewalls I can't control (And apparantly even most admins suck at adminstrating those systems).
The Mobile Apps know the WAN-IP of the Windows-Server.
But there are many Mobile Apps and many different organizations with their own Windows-Server.
And the data should allways be sent over the STUN Server . No real peer2peer conection. no interactive exchange of adresses.

[Kas Ob.]

Zitat:

Zitat von QuickAndDirty (Beitrag 1530063)

I want to sent large amounts of data over this Server.
So would STUN work?
I mean it would be pretty good if I could actually use the STUN from google.

Google STUN servers are for streaming audio and video, they are for WebRTC, so yes you can stream or send large amount of data.

Zitat:

Zitat von QuickAndDirty (Beitrag 1530063)

It's immportant to know that the Windows-Server-Service will be behind different corporate firewalls I can't control (And apparantly even most admins suck at adminstrating those systems).
The Mobile Apps know the WAN-IP of the Windows-Server.
But there are many Mobile Apps and many different organizations with their own Windows-Server.
And the data should allways be sent over the STUN Server . No real peer2peer conection. no interactive exchange of adresses.

If by WAN-IP means Internet accessible IP then you don't even need STUN or any sort of tunneling/forwarding, STUN and TURN and other protocol used for either bypass the NAT and firewall restriction or to provide privacy (hide IP's from each others) in case peer-peer connection.

I highly suggest to check https://www.esegece.com/websockets and may be test drive it, as it provide all the security you need for your data, while LakeOfSoft will need experience to add such secured connection by hand.

[QuickAndDirty]

Zitat:

Zitat von Kas Ob. (Beitrag 1530066)

If by WAN-IP means Internet accessible IP then you don't even need STUN or any sort of tunneling/forwarding, STUN and TURN and other protocol used for either bypass the NAT and firewall restriction or to provide privacy (hide IP's from each others) in case peer-peer connection.

So what you are saying is that if I run Websocket server behind a firewall that blocks all incoming connections to the corporate network and isn't configured to route incoming traffic to the right computer in the corporate network, with websockets it would just work I get to bypass the firewall and all clients that are runing on the mobile phones get connections to that server application?

It sound's kinda too good to be true.

[Kas Ob.]

Zitat:

Zitat von QuickAndDirty (Beitrag 1530109)

Zitat:

Zitat von Kas Ob. (Beitrag 1530066)

If by WAN-IP means Internet accessible IP then you don't even need STUN or any sort of tunneling/forwarding, STUN and TURN and other protocol used for either bypass the NAT and firewall restriction or to provide privacy (hide IP's from each others) in case peer-peer connection.

So what you are saying is that if I run Websocket server behind a firewall that blocks all incoming connections to the corporate network and isn't configured to route incoming traffic to the right computer in the corporate network, with websockets it would just work I get to bypass the firewall and all clients that are runing on the mobile phones get connections to that server application?

It sound's kinda too good to be true.

No, I am sorry, may be it is language barrier, what i said is either you have a public accessible IP then you don't need any thing, or the server is not accessible because it is in NAT different form the client (in this case a mobiles), in this case the server must use tunneling, as example in case of STUN, the server will connect to the Internet public STUN server and register a binding, any clients want to reach your server can or must bind to that STUN server and establish a connection,
1) "must", if there is no other way like the server is behind a NAT (with forwarding) or behind a firewall (which doesn't allow incoming connection).
2) "can", the client want to hide its IP from the server for privacy reason, even when the client can access lets say delphipraxis.net directly, but for privacy it want to hide its IP from delphipraxis server so it uses a public STUN server used also by delphipraxis.com server, hence the only one will know its IP is the STUN server, this case is like what Signal (social app) doing but relaying peers audio/video calls through a server to make sure none of them can see the other IP, and of course make sure both can connect, but it is optional and you can allow direct calls, then if one of them can reach the other directly then will connect, but in this case both will know the IP for each other.

Now does that clear things ? i hope so, but let me know if you have questions.

ps: TURN provide almost same as STUN even better but with differences, TURN need two clients (to be exact two peers, clients or server or what ever) to know some sort of a token for each other before register and bind traffic using TURN, so unless you are developing server with hardcoded clients tokens or you have another network structure to manage these tokens (tickets, key ...) there is no way to connect, even if you succeeded in that for server/client infrastructure, the server must establish a dedicated connation for each client to meet at TURN server.
While STUN allow clients to connect to server and having the server to access or refuse these connection over one server-to-STUN connection, the custom traffic you want to exchange will be in a thing called attributes in the messages, so your behind firewall server that can't accept incoming connections, will be able to establish connection and accept clients on STUN server.