dswd
Direct websocket mode
** Describe the high-level goal you want to achieve **
The websocket proxy mode recently released is good, but requires a centralized proxy. Everything technically required is here in the code, but it would be ideal to launch server/client in ws mode natively without requiring the proxy.
** Describe the proposed solution **
Propose an effort/tracking towards a feature that allows a ws port for listening as an alternative to UDP from the local host and client itself. The idea is to be able to run the entire VPN in a ws mode where remote connect addresses are ws and local listening address is also ws. Solution should allow for nginx, cloudflared, etc., proxy to handle TLS and handoff/pass-through websocket.
The websocket proxy mode recently released is good, but requires a centralized proxy.
That is not 100% correct. You can have separate proxies for the nodes. However I get what you mean and it is an additional component that seems unnecessary and each node can only have one proxy.
Everything technically required is here in the code, but it would be ideal to launch server/client in ws mode natively without requiring the proxy.
You are right on this. Everything is there and one could implement websocket as a first level protocol besides UDP. When I first implemented that feature I saw it as a hack to get around firewalls and never intended it to be a first grade feature. I also expected it to be very slow and was completely surprised to find out how fast it is. I am currently working on a multithreaded version which makes it so much easier to implement such functionality as it won't slow down the single threaded main loop. So stay tuned, there are interesting things to come.
Yes it could be very fast with HTTP/2 and could be even faster with HTTP/3, especially if an option to establish trust based on server certificate identify and no longer encrypt at the tunnel layer were added since TLS is already handling encryption
I thought about it some more and I realized that I forgot a very important aspect in that plan: Websocket connections are asymmetric. One node is the server and the other one would be the client. In a peer-to-peer mesh network all nodes need to be able to connect to all other nodes. With UDP you can do hole punching to get inside of a firewall. With websockets being TCP based, it is pretty much futile to connect to them when they are behind a firewall. So websocket it a wonderful way to get through a firewall in egress direction but not in ingress direction. Just one way is not enough, since there could be two peers behind a firewall that then can not connect anymore. That was the reason why I implemented it with a separate proxy that is located in the Internet. The websocket connection will help the node to communicate through a firewall and other nodes can still connect to it via the proxy.
To summarize: While it is simple to move the websocket server into the node code it prevents other nodes from connecting to the node.
I am planning some other features right now that could help with this scenario however.
Nothing gets through firewalls like outbound TL'S. I think my use case is different. For all sites i would already have inbound TL'S allowed and handled through nginx. So I would need something like this but nodes would need to exchange https addresses of other nodes and know to initiate a web socket there and also accept inbound was from nginx.