On 31.05.2018 03:03, Damien Miller wrote: > On Wed, 30 May 2018, dev@xxxxxxxxxxxxxxx wrote: >> 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. i cannot match e.g. regexps, like tun(13|14|15|16|17), just wildcards, like tun*. so as soon as there is more than one config for all (tun or tap), every interface has to be entered individually. > 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...) this sounds like all clients requesting 0 get office1 - i guess to be helpful this would have to be defined per client. from my perspective and usecases this (per client mapping) would enable me to use the interface config as intended on the server side (client side the problem would not change), the extra indirection being just a complication (compared to just using full device names for devices), a configuration step to stumble over. a bit out of the line, but i just realized that an option for the server to en-/disable each tunnel channel type would probably be generally desirable. i added a PermitTunTap simply working like PermitTunnel for the new channel type (and PermitTunnel is not regarded for the new channel type). so now the new channel type will not be accidentally enabled on PermitTunnel != no setups on upgrade. (also, some leaks were fixed, btw - i think/hope there should be none left) > Now, we're not totally stuck with the existing message format (it is i guess for compatibility tun@xxxxxxxxxxx can't really be changed or replaced, and the message format is static per type if i got that right... using a new channel type just seems like the canonical approach for this case. > 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. what costs do you mean? (actually i was quite surprised that the feasibility check quickly turned into a working patch, and i was kind of delighted with what i found to be a very straightforward and relatively small-footprint solution just following the overall design) > Would either of the above alternatives solve your use-cases? mapping both client- and serverside (and per client) would make the intended interface config (boils down to "matching some different namespaces with wildcards") possible. in my view the mapping would be a rather ugly part (mostly a config-obstacle). at least in case of pubkeyauth, per-client tunnel mapping looks similar to me to an authorized_keys config with tunnel=office1 (i.e. changing (just) this option to full device name). so as an example, this option uses the forced_tun_device variable, this would have to become a string then. forced_tun_device would then have to be handled differently and conversion to/from other device ids would be necessary - or alternatively all devices would internally have to be handled as strings. the new-channel-type patch changes forced_tun_device as well as the other device identifiers to string, and just maps between id-only syntax and full-name on in- or output. and apart from that, the patch just adds the new channel type and the config option and that's it. for mapping, a good place for per-client mapping definitions has to be found or added, device-handling will have to be dealt with in any way, and not simply using full device names internally seems to add more code and complexity, and mapping itself will probably also add more code and complexity than a new channel type. so after all i'd currently say the transparent full interface name solution, and also the new channel type, seems to be preferable. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
