Dwgd: Docker WireGuard Driver | Hacker News Reader

Dwgd: Docker WireGuard Driver

github.com

47 pointsleomos10 comments

This looks very useful for torrenting through a VPN, I currently have WireGuard outside of Docker and run my torrent client container with network_mode: host for improved network performance.

In order to have the client use the VPN but keep the rest of the system accessible outside the VPN I bind the client IP (VPN IP4 & IP6) in the client config and have WireGuard setup like this:

  [Interface]
  PrivateKey =

  Address = IP4, IP6
  DNS =

  Table = 12345
  PostUp = ip -4 rule add from IP4 table 12345
  PostUp = ip -6 rule add from IP6 table 12345
  PostUp = iptables -I OUTPUT -s IP4 ! -o %i -j DROP
  PostUp = ip6tables -I OUTPUT -s IP6 ! -o %i -j DROP
  PostDown = ip -4 rule del from IP4 table 12345
  PostDown = ip -6 rule del from IP6 table 12345
  PostDown = iptables -D OUTPUT -s IP4 ! -o %i -j DROP
  PostDown = ip6tables -D OUTPUT -s IP6 ! -o %i -j DROP

  [Peer]
  PublicKey =
  Endpoint =
  AllowedIPs = 0.0.0.0/0, ::/0

If you don't want to suffer the performance penalty why not bridge wg0 with a veth pair where the other end is in your container?

Performance is already capped with network_mode: host. I'm not a network expert but veth seems a bit much for this? My setup is less convoluted.

I can WireGuard to my server and access my home network, meanwhile the torrent client data is all routed through a third party VPN.

If the third party VPN disconnects there is no data leak from the torrent client (basically a kill switch).

True, but I assumed you might actually want to have the container network isolated. For most people I think they consider --privileged and host networking a last resort for misbehaving software.

> This software is by no means ready for production. I use it in personal projects, but it has not been tested anywhere else other than my machine (as far as I know). Use it at your own (high) risk.

if it's public, it's in production somewhere.

Yeah. I realize it's "mean" to say this but it makes me nervous to see no discussion of why you would do this. This kind of project can too easily get cargo-culted into places where it shouldn't be used.

Where should it be used, and where shouldn't it?

I think, right now, with something like mitmproxy, for example, you can't use the wireguard mode unless the other proxy is "elsewhere." With this, perhaps you could use it from the same machine?

Question: what does this do better than the (relatively) well-established Gluetun [0]?

[0] https://github.com/qdm12/gluetun

It's the first time I hear about Gluetun, thank you for sharing that! From a very quick first impression it seems like it solves a different problem than dwgd. With Gluetun you are creating a container that has access to various VPN providers (and exposing ports where proxies listen apparently); with dwgd you are giving a container the capability to route packets toward a WireGuard tunnel (you are essentially just giving the container the "ownership" of the WireGuard interface).

The purpose of Gluetun is to isolate your VPN into a container that you can then bind as the network provider of other containers. However, it's a documented problem [0] that performance isn't anywhere near as good as running the VPN natively, especially for Wireguard. At the minimum this can be related on some systems to the container being unable to load the kernel-space driver and having to rely on lower performing user-space driver, but even with a pre-loaded kernel-space driver performance testing is reporting significant lower values than the host. Presumably this project is to try and resolve that issue.

[0] https://github.com/qdm12/gluetun/wiki/Wireguard#performance

Reply on news.ycombinator.com