Remoteler implements an encrypted reverse tunnel that can be used to create access routes to the resources available on unstable network connections, edge computing resources, and private networks, including resources behind the NAT, without the need to expose them publicly on the internet.
The underlying technology behind this is reverse tunnels. A reverse tunnel is a secure connection established by an edge site into a Remoteler cluster via the cluster’s proxy.
There are two types of reverse tunnels:
Let’s look into each type in more detail.
The diagram below shows the Remoteler cluster accessible via a proxy on
proxy.example.com. This cluster has two regular nodes (A and B) and one remote node (R1).
From a user’s perspective, there is no difference between the nodes on the private network and the remote box
node-R1. A user may have an Ansible script which pushes a code update simultaneously into all nodes, i.e.
# login into the cluster:
$ tsh login --proxy=proxy.example.com
# SSH into node running on VPC/LAN:
$ ssh node-a
# SSH into a remote note:
$ ssh node-r1
teleport daemon on regular nodes A and B is usually configured as a systemd unit and takes the following command-line arguments:
# local nodes need to know the address of the auth service on the private network
$ teleport start --auth=auth.example.com
teleport daemon on the remote device does not have access to
auth.example.com, because it resolves to a local IP on the private network. The remote nodes must use the address of a proxy instead:
# remote nodes use the proxy address instead of the auth service:
$ teleport start --auth=proxy.example.com
Using the Remoteler Poxy Service address instead of the Remoteler Auth Service address instructs the proxy daemon to create a permanent reverse tunnel, through which future user connections will be proxied.
Why not connect all nodes as remote, then? You can, but reverse tunnels require more system resources, so using the Remoteler Auth Service address is more optimal, as it reduces the load on the proxy.
It is also possible to create reverse tunnels between two Remoteler clusters. This may be useful in the following scenarios:
To understand how this works, consider the diagram below, which shows two Remoteler clusters:
root.example.comand it has two nodes named A and B.
leaf.example.comand it also has two nodes, also named A and B.
One approach is to configure both clusters with the same identity storage, possibly Github or Google Apps. A user will have to log in via two different proxies:
leaf.example.commay be behind NAT and inaccessible to external users.
Another approach is to let users go through
root.example.com and configure the ROOT cluster to proxy their connections into the LEAF cluster. This capability is called Trusted Clusters in Remoteler documentation.
By creating a reverse tunnel from the LEAF to the ROOT, the ROOT cluster becomes “trusted,” because its users* are now allowed to access the LEAF. The connection from a user to the A node inside the LEAF will look like this:
In the scenario above with two trusted clusters, here is how a user session may look:
Note that the audit records never leave cluster boundaries. When users connect to LEAF nodes via the ROOT cluster, their actions will be recorded in the audit log of the LEAF cluster.