Addendum for my wg-reallyquick script for hand-rolled-ngrok

1 files changed, 51 insertions, 0 deletions

diff --git a/content/blog/hand-rolled-ngrok-over-protonvpn.md b/content/blog/hand-rolled-ngrok-over-protonvpn.md
index 7bd2d31..49f9c83 100644
--- a/content/blog/hand-rolled-ngrok-over-protonvpn.md
+++ b/content/blog/hand-rolled-ngrok-over-protonvpn.md
@@ -8,6 +8,8 @@ categories: ["Life of a sysadmin"]
 
 _Or: hand roll a ngrok with protonvpn port forwarding for shenanigans_
 
+_Updated 2025-11-08_: added addendum section on using wireguard in a network namespace.
+
 # Dumbness: port forward `sshd`
 
 Our general plan is this:
@@ -238,3 +240,52 @@ And update our port mapping script to send the newly obtained port to our redire
 ```
 
 Start everything, and now you can visit [https://sh.example.com/funny-business] for fun and profit.
+
+# Addendum: split tunnelling with netns
+
+For those who are unfamilar: split tunnelling is to selectively route _some_ traffic through the VPN but not others, usually discriminated by originating application.
+
+Traditionally, you would do this with `ip rule` on linux. Or you'd go really heavyweight, and just slap docker on the problem, by putting both the VPN connection (wireguard) and the application into containers.
+But it's also possible to just use a network namespace. Docker is basically just this, but also namespacing pid/uts/time/mnt/user at the same time.
+
+To actually do this, you basically have two choices:
+
+- setup the interface manually with `ip(1)`
+- use a heavyweight champion like [wg-netns](https://github.com/dadevel/wg-netns).
+
+with the upshot of both being incompatible with `wg-quick(1)` config files. VPN providers almost always provide wg-quick config generators. Having to manually reformat that is pretty tedious.
+
+So this is the part I present my own cobbled together shell script `wg-reallyquick` that emulates a subset of wg-quick behavior while adding it to a netns: 
+https://gist.github.com/rtk0c/ae7e9aa29fa1a83ba02c7768f871b11c
+
+Enjoy.
+
+P.S. usage in the gist comments
+
+P.P.S. I know that name sucks. But it's also kind of funny at the same time, so I kept it.
+
+## Commentary on specific use cases
+
+BitTorrent client is the best use case I found. It has all these properties at the same time:
+
+1. torrent clients often don't expose enough network configurables
+2. you really want a kill stich
+3. only interacts with the internet (i.e. not with other programs on the system).
+
+As soon as any of these properties go away, netns (manually) can seem like it's not worth the effort anymore.
+
+Every time the isolated application needs to communicate with something else on your system, e.g. HTTP reverse proxy, you start to need many `systemd-socket-proxyd`, or upgrade to `veth(4)` interfaces. In my opinion, at this point you might as well just use containerization.
+
+If the software allows you to bind to a specific interface, or even better, set fwmark on packets it creates, you can just use regular `ip rule` based routing. It's so much simpler to setup and easier to understand.
+
+But also, with multiple applications all needing to be split tunneled, `ip rule` based routing can become pretty convoluted, so in that case, netns can seem appealing again. So it's all situational.
+
+## Some extra friendly links
+
+The grandma of all such efforts is ostensibly [Routing & Network Namespace Integration](https://www.wireguard.com/netns/) from the official wireguard website (note: the author did not fact check this statement), which explains the concept and general procedure better than I can, so go read it.
+
+This [blog](https://blog.thea.codes/nordvpn-wireguard-namespaces/) is a nicely written walkthrough on the particular thing you may be wanting to do, that is, sailing in the high seas. It also has [a section](https://blog.thea.codes/nordvpn-wireguard-namespaces/#accessing-transmission-from-the-host) on how to expose the web UI of some application running inside a netns using `systemd-socket-proxyd`.
+
+Alternatively, you can use good old `socat` [to proxy TCP traffic](https://unix.stackexchange.com/a/298409).
+
+Lastly, for diving even deeper, [this blog](https://7bits.nl/journal/posts/what-does-ip-netns-add-actually-do/) disects the source code to show how the `ip netns add` family of command works under the hood, using syscalls. Sorry it doesn't go into kernel code.