noisysockets
rtun
| noisysockets | rtun | |
|---|---|---|
| 3 | 1 | |
| 61 | 0 | |
| - | - | |
| 8.4 | - | |
| 3 days ago | over 1 year ago | |
| Go | Go | |
| Mozilla Public License 2.0 | BSD 3-clause "New" or "Revised" License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
noisysockets
-
Attackers Can Decloak Routing-Based VPNs
An interesting (and portable) alternative to network namespaces is to bypass kernel networking entirely and use a userspace network stack.
I've got an example of doing just that with my project Noisy Sockets, https://github.com/noisysockets/noisysockets/blob/main/examp...
-
WireGuard client that exposes itself as a HTTP/SOCKS5 proxy
https://github.com/noisysockets/noisysockets
With that, you can replace a Dialer in Go that connects sockets, effectively wrapping sockets with Wireguard. Since it does that in userspace, you get no tun/tap. This is all open-sourced by @dpeckett
With those things, he also built a userspace wireguard gateway that includes DNS resolution. https://github.com/noisysockets/gateway
https://news.ycombinator.com/user?id=dpeckett
-
JIT WireGuard
Might as well take the opportunity to shill one of my recent experimental projects, If you are interested in building Go apps that act as userspace WireGuard peers take a look at https://github.com/dpeckett/noisysockets
Based off the excellent work in done by wireguard-go but I've attempted to simplify and make things a lot more idiomatic for library use.
rtun
-
JIT WireGuard
I have issues trusting SSHFS. It's never been stable enough for me. Maybe it's because I have to go through at least one ssh proxy, in addition to a VPN. Maybe it's that the remote filesystem is slow enough, so trying to do anything remotely is very slow.
But really, it think it's that I'm already in a terminal connected to a remote system. I don't want to have to go to a different terminal to try and transfer data that I'm already looking at. And trying to use a Finder window (or explorer) to navigate a complex remote filesystem hierarchy isn't fun.
Occasionally I can do my work locally, but usually the data is large enough that I have to do my work on a remote server/cluster. When I generate figures describing my data, I want to see those locally. This particular use-case could be solved by using something like Xpdf, but it's easier to send the figure back to my local machine and view it with Preview.app.
I also sometimes do need to send datafiles back to my local computer. In these cases, I could use sshfs (but don't like the duelling terminals) or scp (but my file paths can be long and complicated, so typing out paths is a pain). I used to actually just handle this with Dropbox. I'd have a program that would send files to a specific Dropbox folder and that would then sync to my local computer. That worked well, but the delay between syncing was an issue.
Here's the code/project I wrote to manage this: https://github.com/mbreese/rtun