diff options
| author | Paul Buetow <paul@buetow.org> | 2025-05-04 10:05:40 +0300 |
|---|---|---|
| committer | Paul Buetow <paul@buetow.org> | 2025-05-04 10:05:40 +0300 |
| commit | 33f0af52e5c2e541e6c08690ad116f45cc243e0c (patch) | |
| tree | a5463b981bffa4c4b18e449af5958f9b271af2de | |
| parent | 669587dc1eb512c4d66bb4db363171dae8b94889 (diff) | |
more drafting
| -rw-r--r-- | gemfeed/2024-11-17-f3s-kubernetes-with-freebsd-part-1.gmi.tpl | 2 | ||||
| -rw-r--r-- | gemfeed/2024-12-03-f3s-kubernetes-with-freebsd-part-2.gmi.tpl | 2 | ||||
| -rw-r--r-- | gemfeed/DRAFT-kubernetes-with-freebsd-part-5.gmi | 34 | ||||
| -rw-r--r-- | gemfeed/DRAFT-kubernetes-with-freebsd-part-5.gmi.tpl | 33 | ||||
| -rw-r--r-- | gemfeed/f3s-kubernetes-with-freebsd-part-5/wireguard-full-mesh.png | bin | 0 -> 243555 bytes |
5 files changed, 61 insertions, 10 deletions
diff --git a/gemfeed/2024-11-17-f3s-kubernetes-with-freebsd-part-1.gmi.tpl b/gemfeed/2024-11-17-f3s-kubernetes-with-freebsd-part-1.gmi.tpl index 6c4b6050..7709ba82 100644 --- a/gemfeed/2024-11-17-f3s-kubernetes-with-freebsd-part-1.gmi.tpl +++ b/gemfeed/2024-11-17-f3s-kubernetes-with-freebsd-part-1.gmi.tpl @@ -8,7 +8,7 @@ I will post a new entry every month or so (there are too many other side project These are all the posts so far: -<< template::inline::rindex f3s +<< template::inline::index f3s => ./f3s-kubernetes-with-freebsd-part-1/f3slogo.png f3s logo diff --git a/gemfeed/2024-12-03-f3s-kubernetes-with-freebsd-part-2.gmi.tpl b/gemfeed/2024-12-03-f3s-kubernetes-with-freebsd-part-2.gmi.tpl index cf64719d..eb385d9d 100644 --- a/gemfeed/2024-12-03-f3s-kubernetes-with-freebsd-part-2.gmi.tpl +++ b/gemfeed/2024-12-03-f3s-kubernetes-with-freebsd-part-2.gmi.tpl @@ -8,7 +8,7 @@ We set the stage last time; this time, we will set up the hardware for this proj These are all the posts so far: -<< template::inline::rindex f3s +<< template::inline::index f3s => ./f3s-kubernetes-with-freebsd-part-1/f3slogo.png f3s logo diff --git a/gemfeed/DRAFT-kubernetes-with-freebsd-part-5.gmi b/gemfeed/DRAFT-kubernetes-with-freebsd-part-5.gmi index 642cfac9..79ce27f9 100644 --- a/gemfeed/DRAFT-kubernetes-with-freebsd-part-5.gmi +++ b/gemfeed/DRAFT-kubernetes-with-freebsd-part-5.gmi @@ -2,7 +2,7 @@ This is the fith blog post about my f3s series for my self-hosting demands in my home lab. f3s? The "f" stands for FreeBSD, and the "3s" stands for k3s, the Kubernetes distribution I will use on FreeBSD-based physical machines. -I will post a new entry every month or so (there are too many other side projects for more frequent updates—I bet you can understand). +I will post a new entry every month or so (there are too many other side projects for more frequent updates — I bet you can understand). These are all the posts so far: @@ -20,11 +20,37 @@ Let's begin... ## Table of Contents * ⇢ f3s: Kubernetes with FreeBSD - Part 5: WireGuard mesh network -* ⇢ ⇢ TODO +* ⇢ ⇢ Introduction +* ⇢ ⇢ WireGuard -## TODO +## Introduction -* what is wireguard... +By default, traffic within my home LAN, including traffic inside a k3s cluster, is not encrypted. While it resides in the "secure" home LAN, adopting a zero-trust policy means encryption is still preferable to ensure confidentiality and security. So we decide to secure all the traffic of all f3s participating hosts by building a mesh network of all participating hosts as shown in this graph: + +=> ./f3s-kubernetes-with-freebsd-part-5/wireguard-full-mesh.svg Full Mesh network + +Whereas `f0`, `f1`, and `f2` are the FreeBSD base hosts, `r0`, `r1`, and `r2` are the Rocky Linux Bhyve VMs, and `blowfish` and `fishfinger` are two OpenBSD systems running on the internet (as mentioned in the first blog of this series—these systems are already built; in fact, this very blog is served by those OpenBSD systems). + +As we can see from the graph, it is a true full-mesh network, where every host has a VPN tunnel to every other host. The benefit is that we do not need to route traffic through intermediate hosts (significantly simplifying the routing configuration). However, the downside is that there is some overhead in configuring and managing all the tunnels. + +For simplicity, we also establish VPN tunnels between `f0 <-> r0`, `f1 <-> r1`, and `f2 <-> r2`. Technically, this wouldn't be strictly required since the VMs `rN` are running on the hosts `fN`, and there is no network traffic leaving the box. However, it simplifies the configuration as we don't have to account for exceptions, and we are going to automate the mesh network configuration anyway (read on). + +## WireGuard + +I have decided on using WireGuard as the VPN technology for this purpose. + +WireGuard is a lightweight, modern, and secure VPN protocol designed for simplicity, speed, and strong cryptography. It is an excellent choice due to its minimal codebase, ease of configuration, high performance, and robust security, utilizing state-of-the-art encryption standards. WireGuard is supported on various operating systems, and its implementations are compatible with each other. Therefore, establishing WireGuard VPN tunnels between FreeBSD, Linux, and OpenBSD is seamless. This cross-platform availability makes it suitable for setups like the one described in this blog series. + +We could have used Tailscale for an easy to setup and manage a WireGuard network, but the benefits of creating our own mesh network are: + +* Learning about WireGuard configurationd etails +* Have full control over the setup +* Don't rely on an external provider like Tailscale (even if some of the components are open-source) +* Have even more fun along the way + +=> https://en.wikipedia.org/wiki/WireGuard +=> https://www.wireguard.com/ +=> https://tailscale.com/ * k3s by default traffic not encrypted diff --git a/gemfeed/DRAFT-kubernetes-with-freebsd-part-5.gmi.tpl b/gemfeed/DRAFT-kubernetes-with-freebsd-part-5.gmi.tpl index 564c17f3..ed25db19 100644 --- a/gemfeed/DRAFT-kubernetes-with-freebsd-part-5.gmi.tpl +++ b/gemfeed/DRAFT-kubernetes-with-freebsd-part-5.gmi.tpl @@ -2,11 +2,11 @@ This is the fith blog post about my f3s series for my self-hosting demands in my home lab. f3s? The "f" stands for FreeBSD, and the "3s" stands for k3s, the Kubernetes distribution I will use on FreeBSD-based physical machines. -I will post a new entry every month or so (there are too many other side projects for more frequent updates—I bet you can understand). +I will post a new entry every month or so (there are too many other side projects for more frequent updates — I bet you can understand). These are all the posts so far: -<< template::inline::rindex f3s +<< template::inline::index f3s => ./f3s-kubernetes-with-freebsd-part-1/f3slogo.png f3s logo @@ -16,9 +16,34 @@ Let's begin... << template::inline::toc -## TODO +## Introduction -* what is wireguard... +By default, traffic within my home LAN, including traffic inside a k3s cluster, is not encrypted. While it resides in the "secure" home LAN, adopting a zero-trust policy means encryption is still preferable to ensure confidentiality and security. So we decide to secure all the traffic of all f3s participating hosts by building a mesh network of all participating hosts as shown in this graph: + +=> ./f3s-kubernetes-with-freebsd-part-5/wireguard-full-mesh.svg Full Mesh network + +Whereas `f0`, `f1`, and `f2` are the FreeBSD base hosts, `r0`, `r1`, and `r2` are the Rocky Linux Bhyve VMs, and `blowfish` and `fishfinger` are two OpenBSD systems running on the internet (as mentioned in the first blog of this series—these systems are already built; in fact, this very blog is served by those OpenBSD systems). + +As we can see from the graph, it is a true full-mesh network, where every host has a VPN tunnel to every other host. The benefit is that we do not need to route traffic through intermediate hosts (significantly simplifying the routing configuration). However, the downside is that there is some overhead in configuring and managing all the tunnels. + +For simplicity, we also establish VPN tunnels between `f0 <-> r0`, `f1 <-> r1`, and `f2 <-> r2`. Technically, this wouldn't be strictly required since the VMs `rN` are running on the hosts `fN`, and there is no network traffic leaving the box. However, it simplifies the configuration as we don't have to account for exceptions, and we are going to automate the mesh network configuration anyway (read on). + +## Deciding on WireGuard + +I have decided on using WireGuard as the VPN technology for this purpose. + +WireGuard is a lightweight, modern, and secure VPN protocol designed for simplicity, speed, and strong cryptography. It is an excellent choice due to its minimal codebase, ease of configuration, high performance, and robust security, utilizing state-of-the-art encryption standards. WireGuard is supported on various operating systems, and its implementations are compatible with each other. Therefore, establishing WireGuard VPN tunnels between FreeBSD, Linux, and OpenBSD is seamless. This cross-platform availability makes it suitable for setups like the one described in this blog series. + +We could have used Tailscale for an easy to setup and manage a WireGuard network, but the benefits of creating our own mesh network are: + +* Learning about WireGuard configurationd details +* Have full control over the setup +* Don't rely on an external provider like Tailscale (even if some of the components are open-source) +* Have even more fun along the way + +=> https://en.wikipedia.org/wiki/WireGuard +=> https://www.wireguard.com/ +=> https://tailscale.com/ * k3s by default traffic not encrypted diff --git a/gemfeed/f3s-kubernetes-with-freebsd-part-5/wireguard-full-mesh.png b/gemfeed/f3s-kubernetes-with-freebsd-part-5/wireguard-full-mesh.png Binary files differnew file mode 100644 index 00000000..2b593f8c --- /dev/null +++ b/gemfeed/f3s-kubernetes-with-freebsd-part-5/wireguard-full-mesh.png |
