[NCLUG] Speaking of SSH and Tunnels...

Bob Proulx bob at proulx.com
Wed Oct 11 17:41:05 MDT 2017


Hello Gabrial,

Gabriel L. Somlo wrote:
> Speaking of ssh and tunneling, I've been using vtun on Fedora to
> implement a sort of "distributed Ethernet switch over IP" for a
> project, a kind of "layer-2 VPN", if you will.
> 
> I'm trying to replace it with ssh, since that's likely to be better
> supported in the future.

Cool!

> The problem with this is lack of scalability. I may have several
> clients, and I don't want to manually pick a different tapX number
> for each one!

I think that is the way things are generally done.  AFAIK it is simply
a parameter number used in this context.  Therefore one can assign a
static assignment to every network.

However if you are trying to do it dynamically I think that could be
done too.  In addition to the way you are trying to do this using
"any" and having it pick the next one I can think of using an
allocation table locally that could be queried before this and use it
to atomically allocate and assign the next number dynamically, then
use that assigned number tun42 or whatever.  There are a bunch of
different ways that come to mind to do this.  Everything from simple
flock on a file, to using a directory as a lock, to using a running
daemon, to using an sqlite database file and let it handle the
semaphoring.  Many different ways to handle the number allocation.
And then use the allocated number instead of using "any".

But I am okay with trying to figure out the next interface that was
assigned too.  Let's walk down that path for a bit.

> So I'm trying to figure out how I could tell what tap device names
> were allocated on the server (preferably also on the client) when
> "-w any:any" is used on the client side, then automatically enslave
> whatever that interface name was to br0 without user (well, admin)
> intervention.

Since ssh isn't telling you this information here is an idea, that
needless to say I have not tried and so may have hidden pitfalls.  Use
'ip addr show' before running ssh to dump out the list of active tun
devices.  Then after running ssh run 'ip addr show' again to get the
list again afterward.  Any new devices that have been created will
appear there.  If there is exactly one new device then you know it is
the one that was just created.

Of course this is a problem with a race condition.  What do you do if
there are *two* or more new devices?  That would be a problem.
Probably could down the ssh to remove the device just created, pause a
small random time interval to let the other processes do their thing
and get out of the way, and try again.  The next time around the race
will probably be won.  And if not this would be repeated until it is
won.  Doesn't seem very elegant.  But seems workable as the race seems
to be easily detected and retried.

Just an idea...  Good luck! :-)

Bob


More information about the NCLUG mailing list