tunnel interface names

[Damien Miller]

On Wed, 30 May 2018, dev at cyphermonks.org wrote:

> >> the fact that ssh insists on tap* and tun* tun/tap-device-names is a
> >> real nag and prevents from nice and easy solutions in some cases.
> > 
> > Could you offer some examples?
> 
> some client:
> ssh -o "Tunnel Ethernet" -w any office
> 
> next client:
> ssh -o "Tunnel Ethernet" -w any office
> ...and so forth.
> 
> interface configuration on the hub for all clients:
> allow-hotplug /tap*=tap
> iface tap inet manual
> 	bridge hub
>
> now some other client needs a specific config on the server or there
> happens to be something else wanting to use a tap-interface for
> something else => every single client's interface has to be configured
> specifically, all interfaces have to be statically assigned to
> clients, clients have to reserve every single interface they might
> want to use in advance.

Couldn't you avoid this by picking high numbers for the ones that you need
specific configuration for? This would leave the rest free to choose "any"
since they allocate lowest numbered tun/tap devices first.

> client:
> ssh -b 1.2.3.4 -w office1:office-alice1 office
> ssh -b 2.3.4.5 -w office2:office-alice2 office

Alternately we could add a server-side map of number->interface name.
E.g. by extending the existing PermitTunnel; something like:

PermitTunnel 0:office1

to indicate a client requesting device '0' gets interface "office1"
(we'd probably need to flesh this out a little more...)

> what is the point of artificially restricting names to just tun\d+ and
> tap\d+ ?

I didn't write the tun/tap support, but I guess it was partly the
original author not seeing the need for more flexibility and partly
some caution in not wanting to allow the client the specify interface
names directly.

Now, we're not totally stuck with the existing message format (it is
an extension after all), but adding a new message that includes names
does impose a number of costs that I'd like to avoid if possible.
Would either of the above alternatives solve your use-cases?

-d