Bump some publish dates and rework the ipv4-expose-2 blog

content/homelab-ipv4-expose-2/index.md

@@ -1,6 +1,6 @@
 +++
 title = "Homelab - IPv4 Expose - Deployment"
-date = 2026-04-25
+date = 2026-05-20
 description = "Integrating the ideas from the previous post"
 draft = true
 
@@ -21,29 +21,122 @@ using it.
 This will cover some of the background needed for this setup, if you have already read the previous post or are familiar with jool and NAT64, you can skip this section.
 
 ## Jool
-Testing
+[Jool](https://github.com/NICMx/Jool) is a tool that implements a bunch of IPv6 and IPv4 translation mechanisms.
+This does the heavy lifting, when it comes to actually processing the packets and performing the low-level translations.
 
-## NAT64
-Testing
+## Stateful NAT64
+[Stateful NAT64](https://nicmx.github.io/Jool/en/run-nat64.html) is one of the mechanisms to translate between IPv6 and IPv4 networks.
+It works similarly to normal NAT, with the addition of not only mapping ports and addresses, but mapping between an IPv6 and IPv4 address.
+So one side of the translation has a unique IPv6 address + port combination and the other side is a unique IPv4 address + port combination.
+
+## ipv-proxy
+[ipv-proxy](https://github.com/Lol3rrr/ipv-proxy) is a custom tool, I developed, which dynamically reads configuration from consul to expose IPv6 services to IPv4 clients.
+This usually runs on some external server, which can do both IPv4 and IPv6.
+Services in consul can then add specific tags, which are found by the ipv-proxy, which then exposes the IPv6 only service from the IPv4 address of the server, by forwarding all the traffic.
+
+Previously this only worked with TCP and was doing the forwarding naively in user-space software, but as part of this I added support for using jool to do the actual forwarding.
 
 # Plan
-<!-- Automated Setup -->
-The entire setup should be automated and portable between vendors.
+Okay so there are a couple of goals/requirements I have for this deployment:
+1. The entire setup should be automated and portable between vendors
+2. Extend ipv-proxy to natively use jool for forwarding
+3. Use wireguard for connecting to my internal consul cluster
 
-<!-- ipv-proxy -->
-I want to continue using the ipv-proxy for handling all the dynamic forwarding stuff.
+## 1. Automated and portable setup
+To make sure my setup is repeatable and portable between different providers, I decided to fully rely on cloud-init.
+{% details(summary="cloud-init config") %}
+```
+#cloud-config
+ssh_authorized_keys:
+  - ${macbook_ssh_key}
+  - ${ubuntu_ssh_key}
 
-<!-- wireguard for ipv-proxy -->
-To support ipv-proxy, it needs to connect to my internal consul cluster, to enable this access I use wireguard.
+package_update: true
+package_upgrade: true
 
-# Extending ipv-proxy
-<!-- Now supports jool as a forwarding backend -->
-In its original state, ipv-proxy could only do the manual forwarding.
-Therefore I first had to extend it, to support different backends to perform the forwarding.
+packages:
+  - jool-dkms
+  - jool-tools
+  - ndppd
 
-<!-- Multiple consul-addr -->
+write_files:
+  - path: /etc/sysctl.d/99-forwarding.conf
+    permissions: '0644'
+    content: |
+      net.ipv4.conf.all.forwarding=1
+      net.ipv6.conf.all.forwarding=1
+      net.ipv6.conf.all.proxy_ndp=1
+  - path: /etc/ndppd.conf
+    permissions: '0666'
+    content: |
+      proxy ens2 {
+          rule ${ipv6_prefix} {
+              static
+          }
+      }
+  - path: /etc/modules-load.d/jool
+    permissions: '0666'
+    content: |
+      jool
+  - path: /usr/local/bin/ipv-proxy
+    permissions: '0777'
+    source:
+      uri: https://github.com/Lol3rrr/ipv-proxy/releases/download/${ipv_proxy_version}/ipv-proxy
+  - path: /etc/systemd/system/ipv-proxy.service
+    content: |
+      [Unit]
+      Description=Proxy IPv4 traffic to IPv6
+      After=cloud-init.target
+      Wants=cloud-init.target
 
-# New Setup
+      [Service]
+      Type=simple
+      ExecStart=/usr/local/bin/ipv-proxy %{ for addr in consul_addrs ~}--consul-addr ${addr} %{ endfor ~} --backend jool --public-ip ${proxy_ipv4_public} --jool-pool6-subnet ${proxy_ipv6_subnet}
+
+      [Install]
+      WantedBy=multi-user.target
+
+wireguard:
+  interfaces:
+    - name: wg0
+      config_path: /etc/wireguard/wg0.conf
+      content: |
+        [Interface]
+        Address = 10.200.0.200/32
+        MTU = 1280
+        PrivateKey = ${wg_private_key}
+
+%{ for peer in wg_peers ~}
+        [Peer]
+        # Name ${peer.name}
+        PublicKey = ${peer.public_key}
+        AllowedIPs = ${peer.ip}/32
+        Endpoint = ${peer.endpoint}
+        PersistentKeepalive = 25
+%{ endfor ~}
+
+runcmd:
+  - "sysctl -w net.ipv4.conf.all.forwarding=1"
+  - "sysctl -w net.ipv6.conf.all.forwarding=1"
+  - "sysctl -w net.ipv6.conf.all.proxy_ndp=1"
+  - "sysctl --system"
+  - "modprobe jool"
+  - "systemctl daemon-reload"
+  - "systemctl enable ipv-proxy.service"
+  - "systemctl start --no-block ipv-proxy.service"
+```
+{% end %}
+
+## 2. Extend ipv-proxy
+In its original state, the ipv-proxy could only do "manual" forwarding.
+Therefore I first extended it, to support different backends for performing the actual forwarding.
+It also now supports multiple addresses for consul, which it will try round-robin style, until one works.
+
+## 3. Wireguard setup
+TODO
+
+
+# Final Overview
 <!-- Running on Scaleway -->
 This new setup is now using Scaleway as the hosting provider, there are a couple of reasons for this:
 * Provides a public routable IPv4 address

content/homelab-monitoring/index.md

@@ -1,6 +1,6 @@
 +++
 title = "Homelab - Monitoring"
-date = 2026-05-04
+date = 2026-06-04
 description = "My current homelab monitoring setup"
 draft = true
 

content/homelab-overview/index.md

@@ -1,6 +1,6 @@
 +++
 title = "Homelab - Overview"
-date = 2026-05-04
+date = 2026-06-04
 description = "A quick and rough overview of my Homelab setup"
 draft = true