[NCLUG] Speaking of SSH and Tunnels...

Gabriel L. Somlo gsomlo at gmail.com
Fri Oct 13 07:53:07 MDT 2017


Hi Bob,

> From: Bob Proulx <bob at proulx.com>
> 
> 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! :-)

Thanks for the suggestions -- I'm familiar with flock and have used it
in the past, but somehow it didn't occur to me this time -- must be
developing a tolerance for caffeine... :)

My other backup plan was to somehow tap into udev (there's a syslog
entry each time a new tap device gets created, so if I could have
hooked into that and ran my 'brctl addbr' command from there...

In the mean time, it appears one of the openssh developers had already
been thinking about something like this (either that, or he cooked up
a patch within a day of my inquiry, which is impressive):

https://lists.mindrot.org/pipermail/openssh-unix-dev/2017-October/036339.html

If I'm lucky, and this does indeed get applied upstream, we'll be able
to set up a tunnel with a simple one-liner. For my layer-2 example
it'd be:

        ssh -f <server> \
            -o Tunnel=ethernet -o PermitLocalCommand=yes \
            -o LocalCommand='ip link set %T up; ip link set %T master br0' \
            'ip link set $SSH_TUNNEL up; ip link set $SSH_TUNNEL master br0'

Thanks again for the brainstorm!

Regards,
--Gabriel


More information about the NCLUG mailing list