-
Notifications
You must be signed in to change notification settings - Fork 670
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
move rendezvous server to port 80 or 443? #243
Comments
Maybe a protocol multiplexer might be useful in the short term? For example, if you wanted to host HTTPS and wormhole traffic on 443. Here's one multiplexer https://github.com/yrutschle/sslh |
You could probably steal some ideas from Crossbar's "universal" listener (which multiplexes between websockets, HTTP and Crossbar's 'raw socket' on one port). This is aided by the first byte sent in the 'raw socket' protocol isn't legal in HTTP/WebSocket at all so detection is easy: https://github.com/crossbario/crossbar/blob/da7f0808d3ac9ebd4eebf51a51bb2b4b151f25e7/crossbar/router/unisocket.py#L65 |
Perhaps using UDT would make it easier to use other ports (maybe only TCP is broken, not the whole internet). |
can you just use a virtual host and proxy through nginx? I feel like that's not hacky, or at least it's less hacky than other things mentioned here. |
Is there any progress on this issue or a recommended workaround? I'm having exactly this problem, where a restrictive site firewall is blocking the relay server port. And none of the alternatives wormhole-william, croc, webwormhole, ... use ports 80 or 443. Related issues for reference: #294 #288 #388 Edit: |
Yeah, curious if the nginx/proxy work could be doable in a relatively short amount of time |
I came accross this issue because I was also having some firewall issues. |
The servers deployed by LeastAuthority for https://winden.app and Destiny (phone app) are running on HTTPS, so a workaround could be to use those servers. See the bottom of the FAQ, or use Note that all participants must be using the same mailbox server to successfully communicate. |
In #207 is kinda sounds like one user was unable to reach the rendezvous server because of a super-restrictive site-wide firewall. I probably made a mistake having the rendezvous server listen on port 4000 instead of 80 or 443 (my motivation was 1: the host I'm using for that server already has an unrelated web server on it, and 2: I'm unwilling to accept that the internet is so broken that the TCP port number space has been reduced from 65536 to 2).
But maybe I should accept that the internet is just broken, and ports 80 and 443 are the only usable ports anymore.
If so, then the tasks are:
public_relay.py
to setRENDEZVOUS_RELAY
to use port 80To allow super-restrictive-firewalled clients to reach the transit relay too, the easiest approach is probably to put that relay on a separate server, and let it use port 443. The protocol it uses is not HTTP or TLS by a long shot, but maybe firewalls will let 443 through without trying to proxy it.
In the future, I want to add websocket access for the transit relay, to enable web-based clients and #9. I might be able to find a way to multiplex the current protocol with plain HTTP, but if not this will need a different port too. So the sequential migration from port 4001 to 443 to something else, leaving 80 or 443 available for a new protocol on the same host, may require some careful planning.
This should all probably wait until after we split out the servers to a separate repo (#240), which will let us run the rendezvous server on a different host than the transit relay (not necessary for performance or load or anything, but it'd make it easier to have them both use 80 or 443 without interfering with each other).
We could also run them on the same host, but use a multihomed host, and use one IP address (port 80) for the rendezvous server, and the other IP address (also port 80) for the transit relay.
To avoid a flag day for the DNS switchover, we could enhance the rendezvous server to be able to cooperate with other rendezvous servers (sharing their databases, or internally knowing which specific server owns which nameplate/mailbox and forwarding requests). Then we could bring up the new server on the new IP address, update DNS, use both servers while migration is happening, then tear down the old one once everyone has stopped using it.
The text was updated successfully, but these errors were encountered: