kb:internet:connectivity:stun
STUN
Motivation
Two main approaches to direct connections:
- Client-server model where client connects directly to an exposed server port
- Client-client model facilitated by a server
Common illustrations of the client-server model include VNC, RDP, NoMachine, blah. This contrasts with, say, Teamviewer, which instead hosts a server as the middleman to facilitate P2P connections. The latter is useful in cases where network address translation (NAT) is beyond our control, e.g. in enterprise networks where connections via Wi-Fi is not granted access to the internal network, blah.
There are different approaches to traversing this NAT. Some concepts:
- STUN protocol: Session Traversal Utilities through NAT, basically the whole idea. External address and ports connected to the STUN server is passed to clients looking to connect. Use case seems to be for multiple local clients connecting to a private resource on a different network.
- Interactive Connectivity Establishment (ICE): A structured mechanism to determine the optimal connection path between peers, e.g. extended by Session Initiation Protocol (SIP) for VoIP.
- Traversal Using Relay NAT (TURN): A more resource-intensive version of STUN, where the TURN server acts as the middleman for connections. This is useful for certain network topologies.
- Hole-punching: Server stores the external addresses and ports for each client, and passes to the client to establish direct connection, without passing through the server. Not sure how this is related to STUN.
Some modern implementations:
- P2P client: AppNet.link + peer-vnc
- RemoteDesktop (Windows-only)
- Kennox/rscc (Linux)
A good search of "wireguard stun server" yielded these gold mine of resources:
kb/internet/connectivity/stun.txt · Last modified: 19 months ago ( 2 May 2023) by 127.0.0.1