Feature Request: Allow specifying server in "add client" command

[jmac125]

It would be useful to allow specifying the --server-address ::6 in the add client command just like in the add server command. This would create a new client config that connects its relay to the server specified and e2e same as the original client

[luker983]

The way Wiretap is currently structured, this might be a little tricky. Routing rules assume that the network is a tree, with clients being at the root of the tree.

It might be doable if we assume that there is only one "first-hop" server, but if your initial client has multiple first-hop servers then it may not be possible to grant the new client access to both branches when added to an arbitrary server.

Case that would probably work:

 ┌─────┐
 │  C  │
 └──┬──┘
    │
 ┌──┴──┐
 │  S  │
 └──┬──┘
    │
 ┌──┴──┐
 │  S  ◄───────┐
 └─────┘       │
            ┌──┴─┐
            │ C  │
            └────┘

Case that will only allow the new client access to the right branch:

        ┌─────┐
        │  C  │
        └┬───┬┘
         │   │
    ┌────┴┐ ┌┴────┐
    │  S  │ │  S  │
    └──┬──┘ └──┬──┘
       │       │
    ┌──┴──┐ ┌──┴──┐
    │  S  │ │  S  ◄───────┐
    └─────┘ └─────┘       │
                       ┌──┴─┐
                       │ C  │
                       └────┘

Thoughts? If you don't care about the second case, I could see about adding an option like you describe. It may also limit the new client's ability to add additional clients

[jmac125]

I think the only-one-first-hop case is what i'm thinking of. If i was working with parallel server chains i would probably just use two instances of wiretap vs having them combined.
I would only use the first client to add more clients i think.

[luker983]

I have a draft of this working in the add-client-to-any-server branch.

Would you mind trying it out to make sure it works as you intend?

[jmac125]

Yea it works how i expected. It seems like maybe the wiretap status command doesn't show server ::3 after adding the client onto ::3, though pings still work through the tunnels as expected

[luker983]

Thanks for testing, good catch. status command should be fixed now.