From the User’s Network
A Process on One Host
The tunnel process holds a long-lived TLS connection that it opened to Telnyx. An inbound connection would need a public address, a port forward on the router, and a firewall rule. An outbound connection needs none of them, because networks already let hosts open outbound connections. The router and the firewall stay as they are. The tunnel host has only private addresses, and its one connection to Telnyx is one it opened:Tunnel host
Output
No Root
The tunnel process runs as a normal user. It creates no interface and changes no route, so it needs no administrator rights on the host:Tunnel host
Output
Streams on That Connection
The process sends its token as soon as it connects, and Telnyx confirms the token on the first stream of the connection. Telnyx then opens one more stream for each flow, and each stream opens with a connect request that names the destination. Connections follows one flow through every step.A Client Like Any Other
The process dials each destination as any program on its host would, and copies bytes between the stream and that connection until the flow ends. On the web service, a request thatcurl makes on a tunnel host and requests from the function look the same:
Tunnel host
10.20.3.7 access log
curl on dc1-tunnel-a. The other two are function requests, which arrived from dc1-tunnel-a and dc1-tunnel-b.
From the Network
The Next Hop of a Route
A route that names a tunnel hands each flow in its CIDR to the tunnel process. The route list shows the tunnel as the next hop for10.20.0.0/16:
Workstation
Output
Telnyx Terminates the Client’s Connection
Telnyx terminates the client’s connection itself and opens a stream to the process for it. When the destination refuses, the process reports the refusal and Telnyx resets the client’s connection. A request to a closed port shows it:Function
TypeError: fetch failed, and its cause is ECONNRESET. Run with -v, the tunnel process that received the connect request logs the refusal:
Tunnel host