There are these modes:
Use upper case letters as IP# and lowercase as port numbers on that IP#. A and B are customer sockets. X and Y are the SDT nodes for customers to talk to. P and Q are the internal encrypted sockets.
Alice Local Remote Bob A:a --------- X:x . . . . . . . Y:y --------- B:b P:p ------------- Q:q
P and Q aren't needed for this discussion.
To cover all of the eventualities, the packets may need to carry with them:
|Channel||0-4||there is also a channel outside|
|Source IP/port||6-18||only for router mode|
more if ipv6
From one end-point to another, directly. Anything from A:a is sent to B:b, anything from B:b is sent to A:a. All else is dropped.
For one virtual tunnel per process, no additional info past set-up is required. If there are multiple virtual tunnels then there is a need for a channel. Each sent packet needs to identify its end-points tuple as a channel.
There are two versions, but they are mirror images.
Proxy-to-server: Local is the Proxy, remote is server. From local node to remote node, all traffic into listener X:x is directed to server B:b. Replies from B are channelled back to original sender, appearing to come from A.
Server-proxy: remote traffic arriving at B is directed to local server, via local node A. Reverse of above. Replies from server to A are channelled back to original sender, appearing to arrive from B.
Proxy node receives a packet from P:p, this tuple needs to be recorded and channelled. The packet is sent off to server node with a channel indicator C.
On seeing Channel C, server node creates a new socket, and sends to the server using that socket. Replies back to that same socket indicate channel C, which is recorded back to the proxy node.
Both proxy and server nodes then need to maintain channel lists. What is not necessary -- apparently -- is any pre-ordained setup (other than potential channel limit), nor is there any need for the details of the channel to be exchanged.
All traffic arriving at a node is pused through to a single server at the other node. One way.
This is useful for logging systems where the task is to suck messages off the machine for archiving elsewhere.
This may be a subset of the server mode. Likewise there are two mirrored images, local as proxy and remote as proxy.
The difference with the server mode is that without the need for replies, there is no need for multiple sockets and channelling. Resources are therefore smaller.
Packets arriving from any location to A are transported and sent out from B to their targets. Outgoing packets need to carry their eventual target, replies could just be channelised according to local reply.
If dealing in IP packets, this requires forgery of IP packet at local node, as replies need to be returned as if from the target. But, as there is already an expectation that the local node has captured the routed traffic to non-local addresses, this would seem to be plausible.
It seems that this mode is somewhat hypothetical for now. Also, check out the SSH VPN feature; this may make it clearer.