Init repo
This commit is contained in:
commit
96832b88ca
GPG Key ID:
40BE2AF8EBF8D2BB
|
|
@ -0,0 +1 @@
|
||||||
|
site/
|
||||||
|
|
@ -0,0 +1,9 @@
|
||||||
|
# Thom's Documentation
|
||||||
|
|
||||||
|
This is the source repository of Thom's personal documentation which can be
|
||||||
|
found at [docs.secure.garden](https://docs.secure.garden).
|
||||||
|
|
||||||
|
## Contributing
|
||||||
|
|
||||||
|
If you would like to contribute to this documentation, open an issue if you
|
||||||
|
think there's something that needs to be added, changed, or removed.
|
||||||
|
|
@ -0,0 +1,7 @@
|
||||||
|
# Thom's Documentation
|
||||||
|
|
||||||
|
This site hosts various personal documentation that I've written for mostly
|
||||||
|
personal use.
|
||||||
|
|
||||||
|
On the left is a list of small documentation snippets.
|
||||||
|
|
||||||
Binary file not shown.
|
After Width: | Height: | Size: 54 KiB |
|
|
@ -0,0 +1,310 @@
|
||||||
|
# Thom's WireGuard Documentation
|
||||||
|
|
||||||
|
This is a basic guide to setting up the WireGuard VPN with a main server and a
|
||||||
|
couple client nodes. For the majority of this guide, I will assume the working
|
||||||
|
environment to be Linux.
|
||||||
|
|
||||||
|
While this should be used only for personal reference, I've seen this solution
|
||||||
|
in production on both my [personal website](https://secure.garden) and
|
||||||
|
[NixNet](https://nixnet.services).
|
||||||
|
|
||||||
|
!!! note
|
||||||
|
If you're needing to implement a VPN solution for your infrastructure,
|
||||||
|
please consult some extra resources for best practices in your situation. I
|
||||||
|
can't guarantee that copy/pasting this guide will work for your situation.
|
||||||
|
|
||||||
|
## Introduction
|
||||||
|
|
||||||
|
### What is WireGuard?
|
||||||
|
|
||||||
|
[WireGuard][wg-home] defines itself as "an extremely simple yet fast and modern
|
||||||
|
VPN that utilizes state-of-the-art cryptography." Before continuing, let's
|
||||||
|
break down this statement.
|
||||||
|
|
||||||
|
A *Virtual Private Network*, or VPN, is technology that allows a multitude of
|
||||||
|
computers/servers from all across the world to be tied into a single *private network*
|
||||||
|
as if they were sitting in the same room. This provides a multitude of both
|
||||||
|
security advantages and pure networking conveniences for system administrators.
|
||||||
|
|
||||||
|
WireGuard also claims to use "state-of-the-art cryptography" for security. This
|
||||||
|
means that data transmitted over a WireGuard network is safe from the prying
|
||||||
|
eyes of third parties. Explaining the exact specification of what WireGuard
|
||||||
|
uses for its cryptography is beyond the scope of this document. For those who
|
||||||
|
remain curious however, the [technical whitepaper][wg-doc] states that it uses
|
||||||
|
a collection of:
|
||||||
|
|
||||||
|
- Curve25519 for ECDH *(Elliptical Curve Diffie-Hellman)*
|
||||||
|
- HKDF for key expansion of ECDH results
|
||||||
|
- RFC7539's construction of ChaCha20 and Poly1305 for encryption
|
||||||
|
- BLAKE2s for hashing
|
||||||
|
|
||||||
|
The above cryptography can also seen being referenced in [The Noise
|
||||||
|
Protocol][noise].
|
||||||
|
|
||||||
|
### Why Should You Use WireGuard?
|
||||||
|
|
||||||
|
WireGuard allows multiple computers/servers to be tied together even when they're not
|
||||||
|
in the same location. This technology has been increasingly used by the
|
||||||
|
typical consumer, but its original role of large scale network management
|
||||||
|
hasn't been forgotten.
|
||||||
|
|
||||||
|
By linking servers from around the world over a secure connection, we can
|
||||||
|
easily pass information between them without having to worry about security of
|
||||||
|
the applications or services actually sending/receiving this information.
|
||||||
|
|
||||||
|
The classic example is being able to route or load balance incoming (and
|
||||||
|
encrypted) web traffic to a collection of back-end servers. This is simple if
|
||||||
|
the computers are in the same building and the thought of someone sniffing
|
||||||
|
traffic between the load balancer and the back-end isn't important. When the
|
||||||
|
servers are in different locations however, the communication has to be secured
|
||||||
|
somehow. Thus enters WireGuard.
|
||||||
|
|
||||||
|
## Description of Equipment & List of Materials
|
||||||
|
|
||||||
|
For the purposes of this guide, you will need:
|
||||||
|
|
||||||
|
- A server with a static IP address
|
||||||
|
- Some client computers to be connected
|
||||||
|
- Some basic knowledge of the Linux command line
|
||||||
|
|
||||||
|
## Installation
|
||||||
|
|
||||||
|
!!! note
|
||||||
|
There are two parts to WireGuard: the core code that allows transmission of
|
||||||
|
network information over a WireGuard interface, and the user-land tools
|
||||||
|
that allow you to work with WireGuard. As of the Linux 5.6 kernel, the core
|
||||||
|
WireGuard code is included. The following information is strictly for
|
||||||
|
the user-land tools.
|
||||||
|
|
||||||
|
The WireGuard tools need to be installed on **both** the server and the
|
||||||
|
clients. This varies depending on the specific Linux distribution, but for my
|
||||||
|
case of AlpineLinux on the server and ArchLinux on the clients, and the tools
|
||||||
|
are included in their respective package repositories.
|
||||||
|
|
||||||
|
**Install on AlpineLinux:**
|
||||||
|
```
|
||||||
|
apk add -U wireguard-tools
|
||||||
|
```
|
||||||
|
|
||||||
|
**Install on ArchLinux**:
|
||||||
|
```
|
||||||
|
sudo pacman -S wireguard-tools
|
||||||
|
```
|
||||||
|
|
||||||
|
Debian based Linux distributions would use:
|
||||||
|
```
|
||||||
|
sudo apt install wireguard
|
||||||
|
```
|
||||||
|
|
||||||
|
I can't suggest using Microsoft Windows at all, but I would especially not
|
||||||
|
recommend using it as the server. If you're going to have a Windows client
|
||||||
|
connect to your WireGuard network, you will need to fetch the installer from
|
||||||
|
here:
|
||||||
|
[https://download.wireguard.com/windows-client/](https://download.wireguard.com/windows-client/).
|
||||||
|
|
||||||
|
Download the `.exe` file and run it. The installer will walk you through the
|
||||||
|
rest.
|
||||||
|
|
||||||
|
## Setup
|
||||||
|
|
||||||
|
### Simplified Overview
|
||||||
|
|
||||||
|
This is the most important step of this guide. WireGuard needs to be configured
|
||||||
|
before it can do anything useful.
|
||||||
|
|
||||||
|
Without going into unnecessary depth, WireGuard creates 'virtual' network
|
||||||
|
devices on your computer. Traffic sent over this device is sent to the server,
|
||||||
|
then it's forwarded from there to the correct destination.
|
||||||
|
|
||||||
|
As an example, if **Client 2** wanted to send some kind of network request to
|
||||||
|
**Client 1**, it would send traffic over its WireGuard interface to the
|
||||||
|
server. The server would then look at the packet of information and decide what
|
||||||
|
to do with it. If everything checks out (the user is properly authenticated),
|
||||||
|
the server will bounce the message to **Client 1** (the original destination).
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
All of this routing logic is handled behind the scenes, so it's not crucial to
|
||||||
|
know how it does all of this. What *is* important is that each of the clients
|
||||||
|
have to properly identify themselves to the server for the server to route the
|
||||||
|
traffic.
|
||||||
|
|
||||||
|
### The Configuration
|
||||||
|
|
||||||
|
To set up the above configuration, three key-pairs and configuration files have
|
||||||
|
to be created.
|
||||||
|
|
||||||
|
#### Generating Keys
|
||||||
|
|
||||||
|
Asymmetric key pairs will have to be generated for each of the devices on the
|
||||||
|
WireGuard network.
|
||||||
|
|
||||||
|
For those unaware, asymmetric key pairs are made of two pieces of information:
|
||||||
|
one secret, and one public. The secret key goes on the device it belongs to,
|
||||||
|
and the public part will go on the server in our case.
|
||||||
|
|
||||||
|
To generate the keys, type the following into a terminal:
|
||||||
|
```
|
||||||
|
wg genkey | tee privatekey | wg pubkey > publickey
|
||||||
|
```
|
||||||
|
|
||||||
|
The above command does two things:
|
||||||
|
|
||||||
|
1. It uses the `wg genkey` tool to generate a private key and save it to a file
|
||||||
|
named `privatekey`. This is the "secret" part, so don't share it with
|
||||||
|
anyone.
|
||||||
|
2. It then generates a public key using this same private key and saves it to a
|
||||||
|
file name `publickey`. This part doesn't need to be kept secret.
|
||||||
|
|
||||||
|
We can then print out the keys that `wg` generated:
|
||||||
|
```
|
||||||
|
cat {privatekey,publickey}
|
||||||
|
```
|
||||||
|
|
||||||
|
Which prints out two lines:
|
||||||
|
```
|
||||||
|
2FKu9/7RppQsW+MhejnJVu9bzIRbmJj3zWe1Gj/fZHs=
|
||||||
|
eOnnVahlSaHpjAv9w1My3u6azw5T4OtWGMAMlLSgzSM=
|
||||||
|
```
|
||||||
|
|
||||||
|
The first one is the secret and the second is the public key. Make note of
|
||||||
|
these because they're needed in the next part.
|
||||||
|
|
||||||
|
!!! note
|
||||||
|
Remember to generate keys for all the devices you plan to use.
|
||||||
|
Keep track of what keys go to which device. You might want to save them in
|
||||||
|
separate files for each device.
|
||||||
|
|
||||||
|
#### Writing Configuration Files
|
||||||
|
|
||||||
|
Once keys are generated for each of the devices, we need to now tell each of
|
||||||
|
the devices how to connect to each other.
|
||||||
|
|
||||||
|
!!! note
|
||||||
|
`wg0.conf` can be replaced in the following examples depending on what you
|
||||||
|
want the network to be named. Just remember to leave `.conf` as the file
|
||||||
|
extension.
|
||||||
|
|
||||||
|
We should start with the clients. This process will also need to be repeated
|
||||||
|
for each client you choose to connect.
|
||||||
|
|
||||||
|
On Linux machines, edit `/etc/wireguard/wg0.conf`. You will need
|
||||||
|
root/administrator privileges to access this directory.
|
||||||
|
|
||||||
|
In my case, I would run:
|
||||||
|
```
|
||||||
|
sudo vim /etc/wireguard/wg0.conf
|
||||||
|
```
|
||||||
|
|
||||||
|
Open the config file, and the following needs to then be inserted into the
|
||||||
|
file:
|
||||||
|
```
|
||||||
|
[Interface]
|
||||||
|
Address = 10.0.0.1
|
||||||
|
PrivateKey = <client-private-key>
|
||||||
|
|
||||||
|
[Peer]
|
||||||
|
PublicKey = <servers-public-key>
|
||||||
|
EndPoint = <servers-public-ip>:4534
|
||||||
|
AllowedIPs = 10.0.0.0/24
|
||||||
|
|
||||||
|
PersistentKeepalive = 25
|
||||||
|
```
|
||||||
|
|
||||||
|
In the above configuration, a few things will have to be replaced:
|
||||||
|
|
||||||
|
- The `Address` under `[Interface]` is what you want the IP of the client to
|
||||||
|
be. This has to be different on ever device. I suggest starting with
|
||||||
|
`10.0.0.1` for the first client and incrementing from there (`10.0.0.2`,
|
||||||
|
`10.0.0.3`, etc.).
|
||||||
|
- **`<client-private-key>`** needs to be replaced with the **private key** you
|
||||||
|
generated for the device earlier.
|
||||||
|
- **`<servers-public-key>`** needs to be replaced with the **public key** you
|
||||||
|
generated for the *server* earlier.
|
||||||
|
- **`<servers-public-ip>`** needs to be replaced with the public IPv4 address
|
||||||
|
for the server that is going to be facilities this VPN. An example would be `108.177.122.100`.
|
||||||
|
|
||||||
|
!!! note
|
||||||
|
If you're more advanced with networking, you can substitute the
|
||||||
|
`10.0.0.0/24` subnet with another local subnet of your choice. Be sure to
|
||||||
|
know what this means before you do it.
|
||||||
|
|
||||||
|
Once the above process has been repeated for the other client, the server needs
|
||||||
|
to be configured.
|
||||||
|
|
||||||
|
Open the same file on the server (`/etc/wireguard/wg0.conf`) and add the
|
||||||
|
following into it:
|
||||||
|
```
|
||||||
|
[Interface]
|
||||||
|
Address = 10.0.0.0
|
||||||
|
ListenPort = 4534
|
||||||
|
PrivateKey = <server-private-key>
|
||||||
|
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE;iptables -A FORWARD -o %i -j ACCEPT
|
||||||
|
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE;iptables -D FORWARD -o %i -j ACCEPT
|
||||||
|
|
||||||
|
# Client 1
|
||||||
|
[Peer]
|
||||||
|
PublicKey = <client1-public-key>
|
||||||
|
AllowedIPs = 10.0.0.1/32
|
||||||
|
|
||||||
|
# Client 2
|
||||||
|
[Peer]
|
||||||
|
PublicKey = <client2-public-key>
|
||||||
|
AllowedIPs = 10.0.0.2/32
|
||||||
|
```
|
||||||
|
|
||||||
|
As with the configurations on the clients, some values need to be substituted:
|
||||||
|
|
||||||
|
- **`<server-private-key>`**: the *private* key generated for the server
|
||||||
|
- **`<client1-public-key>`**: the *public* key generated for client 1
|
||||||
|
- **`<client2-public-key>`**: the *public* key generated for client 2
|
||||||
|
|
||||||
|
### Starting the Network
|
||||||
|
|
||||||
|
The essential configuration is now setup, but nothing is communicating with
|
||||||
|
each other yet. WireGuard interfaces still have to be created on each of the
|
||||||
|
devices. This can be simplified using the `wg-quick` utility.
|
||||||
|
|
||||||
|
To turn on WireGuard, run the following command on each of the devices:
|
||||||
|
```
|
||||||
|
sudo wg-quick up wg0
|
||||||
|
```
|
||||||
|
|
||||||
|
Now any information that is sent to the addresses of the other devices
|
||||||
|
(`10.0.0.0`, `10.0.0.1`, or `10.0.0.2`), will travel over the secure WireGuard
|
||||||
|
tunnel.
|
||||||
|
|
||||||
|
## FAQ
|
||||||
|
|
||||||
|
## Troubleshooting/ Getting Support
|
||||||
|
|
||||||
|
WireGuard is fairly robust and hard to break, but there are a few steps that
|
||||||
|
usually catch people up.
|
||||||
|
|
||||||
|
Below are a couple common issues, but if all else fails you can ask questions
|
||||||
|
in the `#wireguard` channel on the Freenode IRC server.
|
||||||
|
|
||||||
|
### Check Your Keys
|
||||||
|
|
||||||
|
By far the most common mistake is getting the WireGuard keys wrong. If you're
|
||||||
|
struggling to get WireGuard to work, remake your key pairs.
|
||||||
|
|
||||||
|
Be extra careful to note which key goes to which device and that its pasted
|
||||||
|
into the correct spots in the configuration files.
|
||||||
|
|
||||||
|
### Check The Server's Public IP
|
||||||
|
|
||||||
|
If the WireGuard clients aren't connecting, it could be that the wrong server
|
||||||
|
IP was used as the `EndPoint` in the client configurations.
|
||||||
|
|
||||||
|
## Contributing
|
||||||
|
|
||||||
|
If you would like to contribute to this guide, the source is hosted over on the
|
||||||
|
[NixNet Git][nn-git] server. Open an issue if you think there's
|
||||||
|
something that needs to be added, changed, or removed.
|
||||||
|
|
||||||
|
|
||||||
|
[wg-home]: https://www.wireguard.com/
|
||||||
|
[wg-doc]: https://www.wireguard.com/papers/wireguard.pdf
|
||||||
|
[nn-git]: https://git.nixnet.services
|
||||||
|
[noise]: https://noiseprotocol.org/noise.html
|
||||||
|
|
@ -0,0 +1,30 @@
|
||||||
|
site_name: "Thom's Documentation"
|
||||||
|
nav:
|
||||||
|
- Home: index.md
|
||||||
|
#- Assignment Instructions: instructions.md
|
||||||
|
- WireGuard: wireguard.md
|
||||||
|
#- License: LICENSE.md
|
||||||
|
- LXD: lxd.md
|
||||||
|
theme:
|
||||||
|
name: material
|
||||||
|
features:
|
||||||
|
- navigation.sections
|
||||||
|
- header.autohide
|
||||||
|
palette:
|
||||||
|
- media: "(prefers-color-scheme: light)"
|
||||||
|
primary: red
|
||||||
|
scheme: default
|
||||||
|
toggle:
|
||||||
|
icon: material/lightbulb-outline
|
||||||
|
name: Switch to dark mode
|
||||||
|
- media: "(prefers-color-scheme: dark)"
|
||||||
|
primary: black
|
||||||
|
scheme: slate
|
||||||
|
toggle:
|
||||||
|
icon: material/lightbulb
|
||||||
|
name: Switch to light mode
|
||||||
|
markdown_extensions:
|
||||||
|
admonition: {}
|
||||||
|
copyright: Copyright © 2021 Thom Dickson
|
||||||
|
repo_url: https://git.nixnet.services/boots/docs
|
||||||
|
repo_name: boots/docs
|
||||||
Loading…
Reference in New Issue