Files

dtoro ce1bf4d0d2 docs: gluetun VPN + static IP migration (2026-06-02)

2026-06-02 22:42:46 +02:00

9.4 KiB

Raw Blame History

DNS — split-horizon `*.hubris.network`

LAN clients resolve *.hubris.network to the Caddy reverse proxy (192.168.8.175). Public clients resolve to the IONOS VPS (82.165.190.79) via an IONOS wildcard, where they hit the VPS traefik public ingress.

There is no wildcard on the LAN side. Every subdomain needs an explicit entry.

Components

Authoritative public DNS: IONOS. *.hubris.network → 82.165.190.79 (was 74.118.126.4 until 2026-04-22).
LAN authoritative for hubris.network records: dnsmasq on authentik (124), 192.168.8.180:53 and 127.0.0.1:53. Config at /etc/dnsmasq.d/hubris-split.conf. Forwards everything else to 1.1.1.1 and 8.8.8.8 (no-resolv, server=...).
PVE host (192.168.8.77): resolver is the local Netbird daemon at 100.122.38.109:53, which forwards to the LAN/upstream and learns hubris.network answers via that path. netbird status says "Nameservers: 0/0 Available" — confirming netbird does NOT manage a hubris.network zone; it just caches whatever the system resolver returns.
Some LXCs keep router DNS (192.168.8.1) or Tailscale MagicDNS (100.100.100.100), both of which return the public IONOS A record. Those LXCs need either a /etc/hosts override or local dnsmasq — see mesh migration for which technique applies where.

Live entries (as of 2026-05-31)

address=/auth.hubris.network/82.165.190.79   # → VPS, not Caddy (Authentik migrated 2026-05-31)
address=/sso.hubris.network/192.168.8.175    # → Caddy → LAN forward-auth outpost (106); added 2026-06-01
address=/git.hubris.network/192.168.8.175
address=/media.hubris.network/192.168.8.175
address=/paperless.hubris.network/192.168.8.175
address=/books.hubris.network/192.168.8.175
address=/home.hubris.network/192.168.8.175
address=/cloud.hubris.network/192.168.8.175
address=/matrix.hubris.network/192.168.8.175
address=/proxmox.hubris.network/192.168.8.175
address=/docker.hubris.network/192.168.8.175
address=/jellyseerr.hubris.network/192.168.8.175
address=/qbit.hubris.network/192.168.8.175
address=/sab.hubris.network/192.168.8.175
address=/blog.hubris.network/192.168.8.175
address=/photos.hubris.network/192.168.8.175
address=/photos-new.hubris.network/192.168.8.175
address=/artifacto.hubris.network/192.168.8.175
address=/plato.hubris.network/192.168.8.175
address=/zimaos.hubris.network/192.168.8.175
address=/nfs-export.hubris.network/192.168.8.200

Note: nfs-export.hubris.network is the only .hubris.network entry that points to a non-HTTP service (NFSv4 on port 2049). It bypasses caddy (121) because NFS is L4, not HTTP — Caddy has nothing to do.

Why split-horizon

The IONOS wildcard points at the VPS for public ingress (per-host routers in VPS traefik). The VPS only routes hostnames it knows — anything else 404s. So LAN clients pointing at the public IP are a dead end for any service that isn't explicitly published. The dnsmasq override on LXC 124 keeps LAN traffic on the home Caddy.

The gotcha that cost a debug session (2026-04-22)

Creating a new Caddyfile site block is necessary but not sufficient. Without the LXC-124 dnsmasq entry, LAN queries fall through to upstream, get the public IONOS answer, and time out. Symptom: "subdomain doesn't load" even though Caddy config + cert are fine.

Recipe — adding a new subdomain

Edit /etc/caddy/Caddyfile on caddy (121), commit + push to dtoro/caddy-conf. Webhook reloads caddy. See auto-deploy.
Append to /etc/dnsmasq.d/hubris-split.conf on authentik (124):
```
address=/<new>.hubris.network/192.168.8.175
```
pct exec 124 -- systemctl restart dnsmasq — reload/SIGHUP may not pick up the new address= line; hard restart is the reliable path.
Verify: dig @192.168.8.180 +short <new>.hubris.network → 192.168.8.175.
On macOS clients, flush: sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder.

The dnsmasq config is not tracked in git. If you stand up a dtoro/dnsmasq-conf repo, wire it like caddy-conf (webhook on LXC 124).

Public path — what does and doesn't follow the LAN map

Hostnames published in VPS traefik dynamic config (currently artifacto.hubris.network, blog.hubris.network) reach a real backend over the netbird mesh.
Anything else with a *.hubris.network URL hits the VPS but isn't routed anywhere — returns 404.
netbird.hubris.network is its own thing — TCP passthrough at the VPS, served by netbird-proxy. Doesn't follow the file-provider router pattern.

Long-term plan

Either:

Move split-horizon DNS to the LAN router so *.hubris.network → 192.168.8.175 is answered for every LAN client. Eliminates per-LXC overrides.
Or, once the Tailscale → Netbird migration completes, every LXC's resolver becomes the netbird daemon, which already learns hubris.network answers via the system resolver chain.

Caddy (121) — every LAN entry points here
Ingress (VPS traefik) — public-side counterpart
Mesh migration — per-LXC DNS workarounds during the transition
Authentik (124) — host of the split-horizon dnsmasq

Changelog

2026-06-02 — 8 LXCs moved from DHCP to static IP

All LXCs that Caddy reverse-proxies to by IP were on ip=dhcp and could float on reboot (arriman got a different lease mid-session and broke). Fixed via pct set + in-LXC /etc/network/interfaces. Affected: 101 jellyfin, 103 paperless, 104 gitea, 105 apps, 114 nextcloud, 118 elementsynapse, 120 mule-images, 121 caddy, 122 arriman. See arriman changelog.

2026-06-01 — dnsmasq replaced by Technitium on dns (107); LXC 124 retired

Split-horizon DNS moved off 124 to a dedicated Technitium LXC at 192.168.8.2 (zone: specific A overrides + wildcard→VPS + replicated MX/SPF/CAA). NetBird home-lab-dns nameserver group cut over to 192.168.8.2 (with .180 as a now-dead fallback). dnsmasq stopped, all names verified via Technitium, LXC 124 shut down. Caveat: the NetBird managed DNS zone still answers most app names directly (bypassing the nameserver group) — three overlapping DNS sources remain; see the single-source-of-truth decision (Phase 4). Action needed: update router DHCP DNS from the dead .180 → 192.168.8.2 for any plain-LAN (non-mesh) clients.

2026-05-31 — `auth.hubris.network` re-pointed to the VPS (`82.165.190.79`)

Authentik migrated off LXC 124 onto the VPS (see investigation). The dnsmasq entry changed from 192.168.8.175 (home Caddy) to 82.165.190.79 (VPS traefik). This is the first LAN entry that intentionally points at the VPS rather than Caddy — auth is now a genuinely public service served directly from the VPS. Gotcha logged: the NetBird per-client resolver (100.122.255.254) caches dnsmasq answers and does not clear on netbird down/up; clients needed /etc/hosts overrides or resolvectl flush-caches to pick up the change. Since the service is now fully public, the long-term cleaner option is to drop the override entirely and let it fall through to the IONOS wildcard (which also points at the VPS).

2026-05-14 — `nfs-export.hubris.network` added (direct, non-HTTP)

NFSv4 export server nfs-export (102) at 192.168.8.200. Direct entry, not Caddy-fronted — NFS is L4, no HTTP reverse-proxy meaningful.

2026-05-14 — `zimaos.hubris.network` added (Caddy-fronted, standard pattern)

New LAN entry for 100-zimaos → caddy (121) → 192.168.8.195. Briefly pointed direct-to-VM during install for the initial smoke-test, then re-pointed once a Caddyfile block was added (reverse_proxy 192.168.8.195 + IONOS DNS-01 TLS).

2026-05-13 — `plato.hubris.network` added; `files.hubris.network` removed

New LAN-only entry for plato (126). Same day, the files.hubris.network entry for the just-decommissioned seafile experiment was dropped; queries now fall through to the public IONOS answer (no LAN backend).

2026-05-12 — `files.hubris.network` added (since removed 2026-05-13)

Originally added for the seafile (LXC 125) Nextcloud-replacement evaluation. Pointed at 192.168.8.175 (Caddy reverse-proxied to 192.168.8.185:80). Entry removed when the experiment was torn down a day later.

2026-04-28 — wiki entry created

Initial documentation. 16 active entries.

2026-04-22 — IONOS wildcard moved 74.118.126.4 → 82.165.190.79

Public path now lands on the VPS traefik, not the old yunohost. Necessary for the public ingress pattern. The LAN dead-end semantics didn't change — public DNS still doesn't help LAN clients reach LAN-only services.

2026-04-22 — three caddy sites without DNS entries (jellyseerr, qbit, sab)

Caddy + certs were working but LAN resolution failed because the dnsmasq lines weren't added. Lesson recorded; entries added later that day.

2026-04-21 — dnsmasq stood up on LXC 124

Co-located with Authentik. Initial entries cover everything routed through Caddy.

9.4 KiB Raw Blame History

DNS — split-horizon *.hubris.network