Closed Kirill888 closed 5 years ago
Hello, I will try to add it this weekend as it should not be too hard to add. I will keep you informed.
BTW, how's your feeling about wireguard ? I currently use openVPN, I wanted to give a try to wireguard to use something simpler, but was demotivated by all the setup required and the no "forward" of network routes.
Thanks that would great.
About Wireguard: it does target "technical user" right now it seems, even with wg-quick
things are pretty manual, and take some poking around to figure out for the first time. There are commercial hosted offerings and maybe they make it easier, but I haven't tried them. I do think that smoother end-user setup experience will come with time, looks like it should be much easier to develop than for things like openvpn. Once everything is running it's pretty good though, even used it on a plane on my phone (android).
I'm hoping to write down my experience of setting it up with wstunnel
(does require turning off routing setup in wg-quick
and doing it yourself via hooks, so not super trivial)
Thanks for the feedback on wireguard. If you write something let me know, I would be interested to read.
I made a pre-release https://github.com/erebe/wstunnel/releases/tag/2.0 with your feature. By default now, the client will prepend "wstunnel" but you can customize it if needed with the new parameter option. You need to use this new versio for the server also in order for it to correctly interpret the new path prefix.
Let me know if it working for you, so that I can make a definitive release.
Thank you @erebe I have verified this working now. I'm using --upgradePathPrefix
as a kind of "pre-shared secret" between wstunnel
client and nginx
proxy, to reduce abuse potential a bit. Since connection is via tls this should be ok.
So I have wireguard traffic working through wstunnel
but looking through the logs I noticed new websocket being established every 30 seconds.
I have changed 30 to 300 here:
and recompiled client only (I'm using released binary on the server). Now it happens every 5 minutes. Does this timeout restart client regardless of network activity?
Ha yeah I forgot about that and indeed it restarts the connection. As with udp there is no way to know if the remote socket has been closed, as there is no notion of session, i have put a timeout in order to not leak connections. My thought was to be able to forward dns requests without leaking.
I can add an cli option to choose the duration of the timeout if you want, but I don't think i will go as far as implémenting one de pending on network usage.
Let me know but I will have time only later in january
Fair enough, different use-cases have different defaults that make sense. If command line options get too much, environment variable would be fine too. No hurry, of course. Enjoy your holidays.
Happy new year, I will add it this week-end :)
Hi @erebe happy new year, just wanted to let you know that I have documented my setup here:
https://kirill888.github.io/notes/wireguard-via-websocket/
I'm also including pre-compiled MacOS binary of wstunnel
in the releases section there, hope that's ok.
We should be good https://github.com/erebe/wstunnel/commit/5ba73def38dc116dfc887c25293f8d1dddcd7d0f You can specify -1 as timeout in order to disable it completly, in your case it should be safe.
I have updated the releases for linux and windows https://github.com/erebe/wstunnel , but will be doing the arm one tomorrow.
Thanks for the article :) and I don't mind at all for the pre-compiled binary on your repo. If you end-up rebuilding it for MacOS from this last commit, let me know I will host it on this repo also with a link toward your article.
@erebe awesome, thanks for that, tested it on my mac, works like a charm, updated my script and a post with the new timeout option.
At long last, I managed to find get an arm machine is build the release for it. Thanks for the macos binary, I have included it I have also added your blog post in the readme https://github.com/erebe/wstunnel/blob/master/README.md#wireguard-and-wstunnel
Thanks :)
Awesome, I have updated my write up to point to your release for MacOS binary. By the way travis supports MacOS builds, if I were to get them working for wstunnel
would you be interested in having that going forward. I know it could be hard if you don't use the platform, but Haskell on a mac is well supported from what I can tell, so hopefully won't be too much of a burden.
Hi, I have recently discovered this project and it's proving to be very useful to me. I'm planning on using this to tunnel wireguard udp traffic from behind firewall that blocks udp but allows https without proxy.
I'm using nginx as a reverse proxy with config like:
and run wstunnel like so:
wstunnel --server ws://127.0.0.1:33344 --restrictTo=127.0.0.1:$wgport
And this works great, but I would like to have an option to have extra prefix before
/{udp|tcp|socks5}/{host}/{port}
. For my use-case it's only needed on a client side as nginx can just strip it away before passing towstunnel
server.I'd like to be able to supply uri like this to the client:
wss://some.host.com/.wstunnel/
meaningsome.host.com:443
/.wstunnel/
path when creating websocketNginx config will then look like
I can barely read Haskell, but I think this should be quite doable,
toPath, parseServerInfo
will need to change as well their data structuresWsServerInfo,TunnelSettings
.