5 ms·

Dwgd: Docker WireGuard Driver

47 points by leomos 3y ago

geenat 3y ago
> 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.
- wmf 3y ago
  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.
  - ericb 3y ago
    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?
nntwozz 3y ago
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
- Spivak 3y ago
  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?
  - nntwozz 3y ago
    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).
    - Spivak 3y ago
      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.
piaste 3y ago
Question: what does this do better than the (relatively) well-established Gluetun [0]? [0] https://github.com/qdm12/gluetun https://github.com/qdm12/gluetun
- deleted 3y ago
  [deleted]
- leomos 3y ago
  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).
- aaravchen 3y ago
  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 https://github.com/qdm12/gluetun/wiki/Wireguard#performance

47 points by leomos 3y ago

> 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.

wmf 3y ago
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.
- ericb 3y ago
  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?

nntwozz 3y ago

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

Spivak 3y ago
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?
- nntwozz 3y ago
  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).
  - Spivak 3y ago
    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.

piaste 3y ago

Question: what does this do better than the (relatively) well-established Gluetun [0]? [0] https://github.com/qdm12/gluetun https://github.com/qdm12/gluetun

deleted 3y ago
[deleted]
leomos 3y ago
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).
aaravchen 3y ago
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 https://github.com/qdm12/gluetun/wiki/Wireguard#performance