Anwendungs Server als Client betreiben mit Indy

[QuickAndDirty]

Zitat:

Zitat von Kas Ob. (Beitrag 1530119)

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.

ya that clears the myst, thanks for taking your time , with me :) .

Is a Google API-ID needed to use the STUN server of google?
When registering to a STUN server for example?

[Kas Ob.]

Zitat:

Zitat von QuickAndDirty (Beitrag 1530129)

ya that clears the myst, thanks for taking your time , with me :) .

You are welcome.

Zitat:

Zitat von QuickAndDirty (Beitrag 1530129)

Is a Google API-ID needed to use the STUN server of google?
When registering to a STUN server for example?

Google API-ID or anything has to do with Google is needed, some public STUN does need a login because it is a service just like VPN, and some doesn't, you can also can host your own STUN server on public IP server or a VPS or any other means, the point is to keep your main server on your local network and use a light weight relay to connect to it, this also will hide your real Server IP from the Internet hence provide your server with privacy and avoiding DDoS and other stuff, also doesn't required high price host, as the cheapest could be enough it could be any small VM Linux with enough bandwidth to relay your traffic.

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.

[Kas Ob.]

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.

[QuickAndDirty]

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.pdf
I'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.

[Kas Ob.]

Zitat:

Zitat von QuickAndDirty (Beitrag 1530185)

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.

Nope, it doesn't work like that !
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:

Zitat von QuickAndDirty (Beitrag 1530185)

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?

First, you don't need a list as explained above, only one will be enough, so if you have your own STUN server, then hardcode its address:port in client and server, or (later down will explain neat trick i do always..)
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.

[QuickAndDirty]

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.

[Kas Ob.]

Here an article might help
https://community.cisco.com/t5/colla...e/ta-p/4766853

The 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 !