Conversation
| --- | ||
| title: "Rosenpass inside a Docker container" | ||
| linkTitle: "Docker" | ||
| weight: 20 |
There was a problem hiding this comment.
In my experience, it's easiest to use larger ranges. That way, there's no need to reshuffle all weights when a new page need to be inserted in between two existing ones (and lexicographical ordering isn't sufficient).
Example:
- Arch: 50 (instead of 5)
- Debian: 40 (instead of 4)
- Ubuntu: 30 (instead of 3)
That's of course an insignificant detail, but I don't see any disadvantages either :)
Semi-related: The Arch and "Generic Linux" guides have the same weight (5) - copy/paste error?
| menu: false | ||
| hideLead: true | ||
| type: docs | ||
| shortBlerb: "Set up and use Rosenpass with Docker" |
There was a problem hiding this comment.
Don't have a source for this guideline (except this?), but "use" is very unspecific in this context. It's not that important if the text doesn't feature prominently, but in the guides themselves I'd refine those key verbs.
|
|
||
| {{% blocks/section color="light" class="no-flex contains-code-snippets package" %}} | ||
|
|
||
| This page provides you with a usage guide for running Rosenpass and WireGuard inside a Docker container, and shows how to route the host's traffic through the VPN that the container provides. |
There was a problem hiding this comment.
| This page provides you with a usage guide for running Rosenpass and WireGuard inside a Docker container, and shows how to route the host's traffic through the VPN that the container provides. | |
| This guide explains how to run both Rosenpass and WireGuard from inside a Docker container. You'll also learn how to route the host's traffic through the VPN that this container provides. |
There was a problem hiding this comment.
It might be worth specifying upfront what level of familiarity with Docker concepts is assumed. Adding something like "Docker-specific concepts will not be explained here" is perfectly acceptable as well, although I suspect someone who doesn't know the first thing about Docker wouldn't read the guide to begin with.
Naturally, if no Docker-specific knowledge is required to follow the instructions this is a moot point.
| This page provides you with a usage guide for running Rosenpass and WireGuard inside a Docker container, and shows how to route the host's traffic through the VPN that the container provides. | ||
|
|
||
| Table of Contents: | ||
| * [WireGuard on the hosts, Rosenpass in containers](#wireguard-on-the-hosts-rosenpass-in-containers): Connect two hosts through a Rosenpass-enhanced WireGuard connection, Rosenpass running inside a container, respectively. |
There was a problem hiding this comment.
| * [WireGuard on the hosts, Rosenpass in containers](#wireguard-on-the-hosts-rosenpass-in-containers): Connect two hosts through a Rosenpass-enhanced WireGuard connection, Rosenpass running inside a container, respectively. | |
| * [Running WireGuard on the hosts and Rosenpass inside containers](#wireguard-on-the-hosts-rosenpass-in-containers): Connect two containerized Rosenpass instances, without restricting Wireguard itself |
|
|
||
| Table of Contents: | ||
| * [WireGuard on the hosts, Rosenpass in containers](#wireguard-on-the-hosts-rosenpass-in-containers): Connect two hosts through a Rosenpass-enhanced WireGuard connection, Rosenpass running inside a container, respectively. | ||
| * [Rosenpass and WireGuard both in containers (on the same host)](#rosenpass-and-wireguard-both-in-containers-on-the-same-host): Connect two containers through a Rosenpass-enhanced WireGuard. |
There was a problem hiding this comment.
| * [Rosenpass and WireGuard both in containers (on the same host)](#rosenpass-and-wireguard-both-in-containers-on-the-same-host): Connect two containers through a Rosenpass-enhanced WireGuard. | |
| * [Running both Rosenpass and WireGuard inside containers (on the same host)](#rosenpass-and-wireguard-both-in-containers-on-the-same-host): Connect two containerized Rosenpass instances. |
Somewhat debatable, but the idea is to highlight the key difference (WireGuard containerized or not).
There was a problem hiding this comment.
Side note: If full virtualization is expected to be the "commonly-used" option, maybe swapping them so that the common case comes first could be beneficial? (Not sure how likely WG w/o Docker is in general)
|
|
||
| #### 1. Start by generating secret keys for both peers | ||
|
|
||
| **Note:** These will be stored in newly created `server.rosenpass-secret` and `client.rosenpass-secret` directories. |
There was a problem hiding this comment.
| **Note:** These will be stored in newly created `server.rosenpass-secret` and `client.rosenpass-secret` directories. | |
| Rosenpass will store generated keys in newly-created `server.rosenpass-secret` and `client.rosenpass-secret` directories. |
| ... | ||
| ``` | ||
|
|
||
| While the ping is running, you may stop the server container, and verify that the ping-log halts. In another terminal do: |
There was a problem hiding this comment.
| While the ping is running, you may stop the server container, and verify that the ping-log halts. In another terminal do: | |
| While `ping` is running, you may stop the server container and confirm that the ping-log halts. To do so, type this (in another terminal): |
| exchange workdir/server.rosenpass-secret dev rosenpass0 \ | ||
| listen 0.0.0.0:9999 peer workdir/client.rosenpass-public allowed-ips 10.0.0.0/8 | ||
| ``` | ||
| We note down some values we need to start the VPN client container: |
There was a problem hiding this comment.
| We note down some values we need to start the VPN client container: | |
| Storing some variables needed to start the VPN client container: |
|
|
||
| {{% blocks/section color="light" class="no-flex contains-code-snippets compilation" %}} | ||
|
|
||
| If you want to move the containers to separate hosts, you can try Docker overlay networks and swarm. |
There was a problem hiding this comment.
Since that isn't explicitly covered by the guide, it's not clear to me whether the intent was to explain "why" users might want to containerize WG. If that's indeed the idea, then the introduction could be rephrased to clarify that this is just one particular use case. I'd probably focus more on contrasting this scenario with the previous one, which mentions kernel access/trust (not portability) to convey what's different here.
| private-key ./workdir-client/wg-client-secret \ | ||
| peer $(cat ./workdir-client/wg-server-public) \ | ||
| allowed-ips $CIDR_VPN \ | ||
| endpoint $SERVER_IP:10000 \ |
There was a problem hiding this comment.
| endpoint $SERVER_IP:10000 \ | |
| endpoint $SERVERIP:10000 \ |
| outfile workdir/server-sharedkey | ||
| ``` | ||
|
|
||
| If you get the error message `… rosenpass] Cannot assign requested address (os error 99)`, try with `listen 0.0.0.0:9999`. |
There was a problem hiding this comment.
(Can't actually see this when running in detached mode)
| Both peers need the `-public` directory of other peer, respectively, and it needs to be placed next to the `-secret` and `-public` directories that already exist: | ||
|
|
||
| Copy the server's public key to the client's working directory: | ||
| ```sh{class="starter-code-client-user"} |
There was a problem hiding this comment.
Shouldn't this use the $SERVERIP and $CLIENTIP variables, respectively?
Other potential improvements (if the command was intended to be copy/pasted directly):
The paths are relative and not absolute; the user name could be obtained via whoami?
Co-authored-by: Philipp Dresselmann <phildremi+github@gmail.com>
2 participants
No description provided.