|
Anwendungs Server als Client betreiben mit Indy
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. |
AW: Anwendungs Server als Client betreiben mit Indy
Zitat:
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/vcpub2) esegece WebSockets https://www.esegece.com/websockets/p2p/stun/stun-serverAlso there is many free and open STUN server, like google STUN for WebRTC https://gist.github.com/sagivo/3a4b2...7c2f1f59ac6c6bhttps://gist.github.com/mondain/b0ec1cf5f60ae726202e |
AW: Anwendungs Server als Client betreiben mit Indy
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!
|
AW: Anwendungs Server als Client betreiben mit Indy
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. |
AW: Anwendungs Server als Client betreiben mit Indy
Zitat:
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:
While STUN is
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.
https://en.wikipedia.org/wiki/STUN and in support TCP per provider.Zitat:
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. |
AW: Anwendungs Server als Client betreiben mit Indy
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. |
AW: Anwendungs Server als Client betreiben mit Indy
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. |
AW: Anwendungs Server als Client betreiben mit Indy
Zitat:
Zitat:
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. |
AW: Anwendungs Server als Client betreiben mit Indy
Zitat:
It sound's kinda too good to be true. |
AW: Anwendungs Server als Client betreiben mit Indy
Zitat:
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. |
AW: Anwendungs Server als Client betreiben mit Indy
Zitat:
Is a Google API-ID needed to use the STUN server of google? When registering to a STUN server for example? |
AW: Anwendungs Server als Client betreiben mit Indy
Zitat:
Zitat:
Today i saw that https://www.esegece.com/ has %30 on all packages for one day, so if you are going after developing network application and might need many tools, real secure tools, then that library is your to think about, from the demos i see it has native implementation of STUN, TURN and ICE too, and that should help solve almost any network topology you ever will need to deal with, of course this library is not limited to these protocols.Go and have a look. |
AW: Anwendungs Server als Client betreiben mit Indy
I just tried the google free STUN, and i see it is limited to only UDP, while this service
https://freestun.net/ worked on both. |
AW: Anwendungs Server als Client betreiben mit Indy
I get it now.
Google and other institutions have free STUN/TURN servers up and running to further the adoption of WEBRTC So Supplying the Peers with the list of free STUN servers with our STUN server at the top. Would ensure that our STUN server has a long list of backups, while we also only have to run one STUN server ourselves and thereby ensure that the providers of free STUN servers don't feel abused. What do you use to test the stun/turn servers? Edit: According to this Document I would need a TURN server. https://www.viagenie.ca/publications...n-turn-ice.pdfI'm beginning to understand what it's all about. Never would have thought that STUN works behind a Sophos Firewall. It needs a TURN Server. |
AW: Anwendungs Server als Client betreiben mit Indy
Zitat:
Both parties (client/server) should know and use one STUN server unless you want them to connect to many, they should already agreed on where to meet . Look at STUN as it is a simple proxy with extra functionality that register connections and tunnel the data between them, the client connections and the server (your server) will register as usual as delivery point within that one STUN server. Zitat:
I test STUN with the demos from sgcWebSocket, i had used it in the past with LakeOfSoft VC, so for me using the demo and watching the events is enough to know it is works. I recommended sgcWebSocket because unlike LoS VC, it has so many features and these are networking, connections and security targeted, so very nice collection. Now, we drifted from your first question into STUN and meeting protocols, so if you are able to provide your own public STUN, why not test SSH with port forwarding, it is easy and simple and will work in most small boxes (my router have SSH server), for your setup if you don't need very high traffic then it might be the perfect usage and will simplify your server part greatly as there is nothing to change to it, your server doesn't need to have an SSH or you can add it internally, but a separated SSH client on your server that will establish the SSH tunnel to your public SSH serve, and that is it !, also the client doesn't need to do any SSH code or connection as the port they are seeing is acting the same as your own server (app) . Also you can write your own tunnel a simple TCP server server that listen and accept connections to a port then forward all the data into the connection from your server, in other words replicate the SSH forward above but without SSH, as you don't care about the data encryption here, because either your clients data is encrypted or not between client - yourproxy, so SSH in this case will only provide security between yourproxy-server, which is useless as security measure. What i am saying : don't complicate things for your self, and always use you are feeling good about, STUN or SSH or your own tunnel,... now i remembered another approach might be even easy, use WireGuard with your own server, WireGuard is very capable to do tunneling and combining IP's and establishing shared subnets...., but be please notice WireGuard is very easy to setup as there is just few settings, and very easy to miss setup. The trick i wanted to share is, i use DNS TXT record to store important data for my networks applications, so in your case as example i would not hardcode your server IP and port into the clients code but let them resolve a DNS with TXT record where the server connection point, it is the same as resolving the A/AAAA record but with extra information, i do many tricks like that .. etc pin the preferred security or the public key for the server. |
AW: Anwendungs Server als Client betreiben mit Indy
I'm in the process of reading on STUN and TURN.
I think it will be a STUN/TURN server combination at the end. I was baffeled that all but symmetric NAT are basically unsafe and open to the STUN procedure... Every NAT that can use STUN is basically vulnerable for a port scan. That's why all NAT/Firewalls out there in corporate newtworks are symmetric NAT. So these Symmetric NAT need a relay server that can also relay TURN connections. Now I'm trying to under understand ICE candidates and why the way they are exchanged isn't part of the god damn specification. |
AW: Anwendungs Server als Client betreiben mit Indy
Here an article might help
https://community.cisco.com/t5/colla...e/ta-p/4766853The article mostly UDP focused, because UDP .. well you know the differences from TCP, but what not very popular knowledge that is UDP is very fast, really faster that TCP, but with problems with dropped and not-queued packets, here comes the even more powerful protocol DTLS to remedy the reliability and security in one go. Notice that HTTP3 is mostly based on Google QUIC https://en.wikipedia.org/wiki/QUIC and it is beat HTTP(S) over TCP in every speed test and latency, with TLS1.3 DTLS (where TLS1.3 provide 0 or 1 roundtrip hand shake) can outperform anything you heard of.About ICE : it is to some degree can be avoided, in other words you can ditch it altogether, and replace it with any mechanism you prefer, like simple HTTP request to your own server to made the first signaling and ID tickets, a mean to establish the meeting point and decide on TURN or STUN, i still prefer STUN and there is STUNS which is DTLS over STUN, it is simpler and have wider usage and support. Anyway, knowledge is priceless, so keep reading and good luck ! |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 13:12 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz