Hacker News new | past | comments | ask | show | jobs | submit login
Simple WireGuard Docker network setup (eisfunke.com)
97 points by bjoko on Sept 24, 2020 | hide | past | favorite | 19 comments

I recently set this up, but with Podman since I was experimenting with CentOS. It turned out to be quite simple to use network namespaces. I created a new namespace for wireguard and moved wg0 into the namespace, then had the container use that namespace:

  ip netns add vpn
  ip link add wg0 type wireguard
  ip link set wg0 netns vpn
  # configure wireguard as usual, prefix commands with ip netns exec vpn
  podman run --network=ns:/var/run/netns/vpn ...
When I tried this was not yet possible with rootless containers, but in newer Podman versions you can tell slirp4netns to use a specific network interface with --network=slirp4netns:outbound_addr=INTERFACE.

> take a look at an OpenVPN config file and you will appreciate this shortness

OpenVPN config files can be pretty small once you remove all the comments (my server is 22 lines)

That being said, I like WireGuard. I've switched over a lot of stuff to it. It does have some issues though:

* Road warrior configurations aren't easy. If you use a DNS name as an endpoint, and that DNS entry changes, you have to refresh it. They have a contrib script in the repo that you can put in cron and do this for you, but it's still not built in.

* You might need keep-alives in certain configurations

* You can't bind Wireguard to an IP address. It listens on all adapters. The devs argue it doesn't matter since WG won't respond via UDP unless it gets a valid key, but this does put WG into a weird state where it might send on an IP it's not receiving on.

There are others I'm probably forgetting. I do like it though. It's faster, the setup is clear. If you have one setting wrong in OpenVPN the connection could fail and you not get useful stuff in the logs.

> If you use a DNS name as an endpoint, and that DNS entry changes, you have to refresh it.

This is really frustrating for me. If you put a DNS name as a peer endpoint, wg-quick will resolve the name and then _replace the name with the ip address_. My IP address changes frequently and I have a script to update the A record when it does, but wireguard didn't have built in support for just keeping the domain name around when I last looked.

I haven't been arsed to do it yet, but I'm often concurrently connected to separate wireguard subnets with their own dns so the sane thing to do would be to run a local dnsmasq and map it there instead.

What's the alternative? Allow the Wireguard user to specify an FQDN in the config file and require Wireguard to perform a DNS query on every outgoing packet to check if the data in the RR has changed?

You could honor the TTL, that's why it exists. Just one DNS query every 1min, 5min, 1hour... whatever TTL you have.

Imo the free tier of tailscale is the best way to consume wireguard for me.

If you have or are willing to create a gmail account, yes.

>> take a look at an OpenVPN config file > OpenVPN config files can be pretty small

That particular jab was pretty strange.

The very first example in the OpenVPN documentation is of a server config:

  dev tun
  secret static.key
That's three lines. The client needs a "remote" entry as well. How much more terse can it get?

There are many applications with complex configuration formats, but OpenVPN is not it. It has both a simple format and good defaults. It should be an example to others!

It seems like you are taking this personally. Why?

Not sure what you're trying to read between the lines, but it's not there intentionally. There was no sarcasm intended.

OpenVPN has a terse and logical configuration language. For all the complaints that open source projects do bad UX, someone put a bit of thought into this one, and it shows.

An even simpler way of routing a certain container through wireguard, without needing to create a docker network and bind it to wg manually:


Note that when using docker-compose you don't need any manual docker network calls with my solution as well. The systemd-network and docker-compose files suffice.

It still creates a separate network with compose and requires the systemd-network file though ;)

imo the sidecar solution is hard to beat if you don't need the features that the separate network provides.

This is the most simple setup I could get. https://github.com/lightswitch05/wireguard-docker

WireGuard tackles these problems:

1. Complex implementation: lots of moving parts with a lot of room for defects

2. Complex configuration: lots of configuration settings with a lot of room for misconfiguration

3. Complex protocols: overcomplicated handshaking and key negotiation

All these things leave a lot of flexibility for backdooring, binary exploitation, etc. aka "capabilities" in spook-speak.

I appreciate the write up, but you can't just put "simple" in a title to and expect it to be simple for everyone. It's simple for what audience? I know there are plenty of developers (especially Mac/Windows users) who would read this and be put off. Simple for me would be running one command like "docker-compose up" and be up and running.

A certain willingness to teach oneself using the tools available, including googling words you don't know, is essential to many modern careers.

"docker-compose up" is not quite as bad as "curl | sudo" , but it's pretty darn close.

It's simple compared to other solutions I found when writing the article, in my opinion (while I wasn't the one who put "simple" in the title here, my original title is different).

Anyway, take a look at the "Instructions in Short" section (I just added a button at the article beginning to jump to that section). You only have to fill in a few blanks (probably just copying from a wg-quick file you already have), add a few lines to your docker-compose file and then run docker compose up.

I think that's somwhat simple enough for a non-trivial task. I might write a script to do that automatically in the future (somebody in the article's discussion asked for that, by the way).

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact