xpra icon
Bug tracker and wiki

Opened 3 months ago

Last modified 3 weeks ago

#2125 new enhancement

let a server register with a proxy

Reported by: brief Owned by: brief
Priority: major Milestone: 3.0
Component: network Version: 2.4.x
Keywords: Cc:

Description

If a server has the ability to register on a proxy, the proxy can become aware of servers where discovery via bonjour is not possible.

Furthermore, this allows hole punching in the servers firewall if the server is keeping the connection to the proxy alive. This allows to have client and server behind a NAT and only needs a proxy exposed.

Attachments (2)

command line options.patch (6.3 KB) - added by brief 7 weeks ago.
paket handler.patch (3.7 KB) - added by brief 7 weeks ago.

Download all attachments as: .zip

Change History (9)

comment:1 Changed 3 months ago by Antoine Martin

Milestone: 2.53.0
Owner: changed from Antoine Martin to brief

How would a client identify which server it wants to connect to?

The standard way of doing this at the moment is using sqlite auth (#1488), which you can already use today as long as the server is not behind NAT: the servers can add themselves to the sqlite auth database used by the proxy to locate sessions for its users.

To workaround the NAT problem, the servers would need to connect to the proxy instead of the other way around.
The connection would have to be authenticated and then kept alive until a client takes over.
This is quite similar to #1022.

comment:2 Changed 3 months ago by Antoine Martin

Component: corenetwork
Owner: changed from brief to Antoine Martin
Status: newassigned
Summary: let a server register at a proxylet a server register with a proxy

Add a new command line option so that servers can advertise themselves to remote proxy servers.
This would complement wiki/MulticastDNS and make it easier to deploy proxy servers.
Can also be used for easy NAT traversal: both server and client can be behind NAT.

Related tickets:

  • #1590 network tracker ticket
  • #675 extend xpra proxy for terminal server deployments

ie:

xpra start --start=xterm \
    --register=tcp://proxyusername:proxypassword@proxyip:proxyport/SESSIONID?\
    username=optionalclientloginusername&password=optionalclientloginpassword

Issues:

  • only allow registration on some tcp / ws / wss / ssh sockets?
  • support multiple proxies: register with all of them, or the first one, or random, or...
  • re-connect to the proxy if the connection drops, maybe add an option to give up and exit if none of the proxies are available for too long
  • keep connection to proxy alive - also similar to #1022: "client listen mode"
  • the proxy needs to keep track of those sessions in memory, return them before or after the ones from the client auth module?
  • the proxy servers could also listen for mdns broadcasts and expose those servers

comment:3 Changed 7 weeks ago by brief

I tried to do changes regarding this ticket, but I got stuck after implementing the command line options.

I suggest using one command line option for the server to register himself at a proxy and one command line option for the proxy to accept registrations.

The option for the server could be like yours above. Multiple --register options could be accepted, each with a list of servers. Connections are made to a random not failing entry in each list. Thus multiple proxies with failover configurations can be configured.

The option for the proxy should include the protocol to listen on.

Should there be a new table containing optionalclientloginusernames and passwords with groups matched to users group?

comment:4 Changed 7 weeks ago by Antoine Martin

I tried to do changes regarding this ticket, but I got stuck after implementing the command line options.

Where is your code?

The option for the proxy should include the protocol to listen on.

I think this should be done as per #1160, using chained authentication modules: the last module in the chain would do the registration.

Should there be a new table containing optionalclientloginusernames and passwords with groups matched to users group?

Not sure I understand, I don't think anything should be tied to unix user groups. The solution should be generic.

Changed 7 weeks ago by brief

Attachment: command line options.patch added

Changed 7 weeks ago by brief

Attachment: paket handler.patch added

comment:5 Changed 7 weeks ago by brief

I attached a patch regarding the command line options. The cmd options are not in the format you mentioned but in the old one.

I also attached a patch what I tried with a new paket handler, but I certainly sure this is not the right way to do it.

Regarding optionalclientloginusernames: I understood that a server willing to register at a proxy can provide credentials (optionalclientloginusernames, optionalclientloginpassword). I wanted to ask if a new table in db/... is needed (e.g. server_users) to store these combinations. Furthermore I thought about the idea, to be able to indicate groups at server_users to be able to present users a list of servers matching by group.

comment:6 Changed 7 weeks ago by Antoine Martin

Owner: changed from Antoine Martin to brief
Status: assignednew
  • there is no authentication on the "register" packets? You would be better off using a hello request option. (see how detach or info requests are handled)
  • if using a dedicated packet type, the "register" packet handler should live in the proxy code, not in server core module.
  • I don't understand why you're using mod_python here
  • the "answer" object is constructed weird and I don't see the code for add_user anywhere
  • the register string should be a regular xpra URI (ie for TCP: tcp://username:password@host:port/?extra_args), that way authentication will be handled automatically

comment:7 Changed 3 weeks ago by Antoine Martin

See also #2261

Note: See TracTickets for help on using tickets.