From 064be3b0a1d268f98142780bf89e9765ea01677d Mon Sep 17 00:00:00 2001
From: 0xflotus <0xflotus@gmail.com>
Date: Thu, 30 May 2019 21:53:36 +0200
Subject: [PATCH 1/2] fixed small errors
---
README.md | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/README.md b/README.md
index 9502a83..9bcf820 100644
--- a/README.md
+++ b/README.md
@@ -280,7 +280,7 @@ wg show wg0
### What WireGuard Traffic Looks Like
-WireGuard uses encrypted UDP packets for all traffic, it does not provice guarantees around packet delivery or ordering, as that is handled by TCP connections within the encrypted tunnel.
+WireGuard uses encrypted UDP packets for all traffic, it does not provide guarantees around packet delivery or ordering, as that is handled by TCP connections within the encrypted tunnel.
@@ -337,7 +337,7 @@ Authentication in both directions is achieved with a simple public/private keypa
No other certificates or preshared keys are needed beyond the public/private keys for each node.
-Key generation, distribution, and revokation can be handled in larger deployments using a separate service like Ansible or Kubernetes Secrets.
+Key generation, distribution, and revocation can be handled in larger deployments using a separate service like Ansible or Kubernetes Secrets.
Some services that help with key distribution and deployment:
@@ -1025,7 +1025,7 @@ These 5 devices are used in our example setup to explain how WireGuard supports
This VPN config simulates setting up a small VPN subnet `10.0.0.1/24` shared by 5 nodes. Two of the nodes (public-server1 and public-server2) are VPS instances living in a cloud somewhere, with public IPs accessible to the internet. home-server is a stationary node that lives behind a NAT with a dynamic IP, but it doesn't change frequently. Phone and laptop are both roaming nodes, that can either be at home in the same LAN as home-server, or out-and-about using public wifi or cell service to connect to the VPN.
-Whenever possible, nodes should connect directly to each other, depending on whether nodes are directly accessible or NATs are between them, traffic will route accordinly:
+Whenever possible, nodes should connect directly to each other, depending on whether nodes are directly accessible or NATs are between them, traffic will route accordingly:
### The Public Relay
From 41b540cabcb3345c4fb7a67ac754f0c4b93550a4 Mon Sep 17 00:00:00 2001
From: 0xflotus <0xflotus@gmail.com>
Date: Thu, 30 May 2019 21:54:58 +0200
Subject: [PATCH 2/2] Update README.md
---
README.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/README.md b/README.md
index 9bcf820..53b0b02 100644
--- a/README.md
+++ b/README.md
@@ -366,7 +366,7 @@ Overview of the general process:
3. Create a `wg0.conf` wireguard config file on the main relay server
- `[Interface]` Make sure to specify a CIDR range for the entire VPN subnet when defining the address the server accepts routes for `Address = 10.0.0.1/24`
- `[Peer]` Create a peer section for every client joining the VPN, using their corresponding remote public keys
-4. Crete a `wg0.conf` on each client node
+4. Create a `wg0.conf` on each client node
- `[Interface]` Make sure to specify only a single IP for client peers that don't relay traffic `Address = 10.0.0.3/32`.
- `[Peer]` Create a peer section for each public peer not behind a NAT, make sure to specify a CIDR range for the entire VPN subnet when defining the remote peer acting as the bounce server `AllowedIPs = 10.0.0.1/24`. Make sure to specify individual IPs for remote peers that don't relay traffic and only act as simple clients `AllowedIPs = 10.0.0.3/32`.
5. Start wireguard on the main relay server with `wg-quick up /full/path/to/wg0.conf`