slides: TaPPaaS VPS publishing (technical review)
Marp deck for the split-horizon DNS + public exposure design: reuses the mf01 pattern (TLS at VPS, plain HTTP over wg1 to TaPPaaS Caddy). Two Mermaid request-flow diagrams, decisions, phasing, isolation, risks. Publishes to slides.makerfloss.eu on CI. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
sjat
parent
a6033e2038
commit
125d1d67e9
1 changed files with 170 additions and 0 deletions
170
docs/presentations/2026-06-28-tappaas-vps-publishing.md
Normal file
170
docs/presentations/2026-06-28-tappaas-vps-publishing.md
Normal file
|
|
@ -0,0 +1,170 @@
|
|||
---
|
||||
marp: true
|
||||
theme: gaia
|
||||
class: invert
|
||||
paginate: true
|
||||
---
|
||||
|
||||
<style>
|
||||
table { font-size: 0.7em; }
|
||||
th, td { padding: 0.25em 0.6em; }
|
||||
section.dense table { font-size: 0.55em; }
|
||||
section.dense th, section.dense td { padding: 0.2em 0.5em; }
|
||||
.mermaid svg { max-width: 100% !important; height: auto !important; }
|
||||
code { font-size: 0.85em; }
|
||||
</style>
|
||||
|
||||
# Routing TaPPaaS through the VPS
|
||||
|
||||
### Split-horizon DNS · public exposure on a static IP
|
||||
|
||||
MakerFLOSS · June 2026 · _technical review_
|
||||
|
||||
---
|
||||
|
||||
## The goal
|
||||
|
||||
Publish selected **TaPPaaS** web services under `*.tappaas.makerfloss.eu`.
|
||||
|
||||
- **Public exposure** — A records point at the VPS static IP `88.99.32.236`,
|
||||
so the cluster's services are reachable from anywhere.
|
||||
- **Split-horizon DNS** — the _same_ hostname resolves to a **local** address
|
||||
for internal clients, so they never round-trip to the VPS.
|
||||
- **Isolation preserved** — nothing on the makerspace side egresses through
|
||||
the VPS or reaches the homelab.
|
||||
|
||||
> We are not inventing anything — we clone a pattern already running.
|
||||
|
||||
---
|
||||
|
||||
## Building block: the proven `mf01` pattern
|
||||
|
||||
`mf01` already publishes `*.mf01.makerfloss.eu` exactly this way, live since
|
||||
2026-06-09:
|
||||
|
||||
- TLS terminates on the **VPS** (wildcard cert, Gandi DNS-01).
|
||||
- Plain HTTP rides the **`wg1`** WireGuard tunnel to an internal reverse proxy.
|
||||
- The internal proxy routes by **Host** to the right container.
|
||||
|
||||
**TaPPaaS = the same shape**, with Caddy as the internal proxy instead of an
|
||||
internal Traefik. Low risk, known gotchas already solved.
|
||||
|
||||
---
|
||||
|
||||
## External request flow
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
C["Browser<br/>(off-site)"] -->|"https · *.tappaas<br/>DNS → 88.99.32.236"| T["VPS Traefik :443<br/>wildcard cert<br/>TLS ends here"]
|
||||
T -->|"plain HTTP<br/>inside wg1"| K["FLOSSFirewall / Caddy<br/>10.13.0.9:80"]
|
||||
K -->|"route by Host"| S["TaPPaaS service<br/>srv01 / srv02 / srv03"]
|
||||
```
|
||||
|
||||
TLS terminates at the VPS; the backend hop is plain HTTP but **encrypted on the
|
||||
wire inside WireGuard**.
|
||||
|
||||
---
|
||||
|
||||
## Internal flow — two views, one name
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
N["<svc>.tappaas.makerfloss.eu"]
|
||||
N -->|"public DNS (Gandi)"| V["VPS 88.99.32.236<br/>VPS wildcard cert"]
|
||||
N -->|"internal DNS (FLOSSFirewall)"| L["Caddy local IP<br/>Caddy's own LE cert"]
|
||||
```
|
||||
|
||||
A client only ever sees the cert for the IP it resolved — **VPS wildcard
|
||||
externally, Caddy's own cert internally**. The two views never collide.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: invert dense -->
|
||||
|
||||
## Key decisions
|
||||
|
||||
| Decision | Choice | Why |
|
||||
|---|---|---|
|
||||
| Transport | New **`wg1`** WireGuard peer | Mirrors mf01; both ends self-owned; static hub-and-spoke |
|
||||
| TLS (external) | **Terminate at the VPS** | Cert issuance while isolated kills passthrough; Gandi DNS-write key stays on the VPS; keeps edge routing/middleware |
|
||||
| Naming | **Wildcard** `*.tappaas.makerfloss.eu` | One cert + one route; add services with zero VPS change; no apex clash (`forgejo.tappaas…` ≠ `forgejo.makerfloss.eu`) |
|
||||
| Internal DNS | **FLOSSFirewall** (already runs DNS), cluster first | LAN view deferred — depends on third-party router |
|
||||
|
||||
---
|
||||
|
||||
## Components — VPS side
|
||||
|
||||
All additive in `AnsibleBaobabV4/host_vars/makerfloss.yml`, mirroring mf01:
|
||||
|
||||
1. **wg1 peer** — FLOSSFirewall, `allowed_ips: 10.13.0.9/32`.
|
||||
2. **Wildcard cert** — add `tappaas.makerfloss.eu` + `*.tappaas` to
|
||||
`traefik_wildcard_sets` → ACME anchor issues it via Gandi DNS-01.
|
||||
3. **Catch-all route** — `tappaas-delegate.yml`:
|
||||
`HostRegexp(...tappaas...)` → `http://10.13.0.9:80`, `passHostHeader: true`.
|
||||
4. **Public DNS** — `tappaas` + `*.tappaas` A → `88.99.32.236`.
|
||||
|
||||
After this, **new services need zero VPS change** — exposure is decided at Caddy.
|
||||
|
||||
---
|
||||
|
||||
## Components — TaPPaaS / Caddy side
|
||||
|
||||
1. **WireGuard client** — peer to the VPS hub, interface `10.13.0.9/32`,
|
||||
`AllowedIPs = 10.13.0.0/24` only → **split-tunnel** (no general egress
|
||||
through the VPS).
|
||||
2. **Caddy plain-HTTP backend** — Host-routed listener on the wg interface
|
||||
(`10.13.0.9:80`), **HTTPS-redirect OFF**. Caddy keeps serving `:443` with its
|
||||
own certs to internal clients, unchanged.
|
||||
3. **Firewall** — allow `tcp/80` **only from `10.13.0.1`** (the VPS) on the wg
|
||||
interface.
|
||||
|
||||
---
|
||||
|
||||
## Phasing — five verifiable steps
|
||||
|
||||
1. **Tunnel** — FLOSSFirewall up as `wg1` peer; ping `10.13.0.1 ↔ 10.13.0.9`.
|
||||
2. **Caddy backend** — from the VPS,
|
||||
`curl -H 'Host: <svc>.tappaas.makerfloss.eu' http://10.13.0.9:80`.
|
||||
3. **VPS edge** — add cert + route + DNS; off-site
|
||||
`curl https://<svc>.tappaas.makerfloss.eu` with a valid cert.
|
||||
4. **Internal DNS** — add `*.tappaas` override; a cluster node resolves to
|
||||
Caddy's local IP and gets Caddy's own cert.
|
||||
5. **(Later)** makerspace LAN view — conditional-forward + firewall pinhole on
|
||||
the OrangeMakers router.
|
||||
|
||||
---
|
||||
|
||||
## Isolation — the hard requirement
|
||||
|
||||
- **Split-tunnel** (`AllowedIPs = 10.13.0.0/24`) — the cluster never egresses
|
||||
through the VPS; nothing on `wg1` reaches the makerspace or homelab.
|
||||
- VPS→Caddy locked to `tcp/80 from 10.13.0.1` on the wg interface.
|
||||
- Backend hop encrypted inside WireGuard.
|
||||
- **No public-DNS-write credential leaves the VPS** — the reason TLS terminates
|
||||
there, not via passthrough.
|
||||
|
||||
---
|
||||
|
||||
## Risks & open items
|
||||
|
||||
- **Caddy redirect** — the wg-interface listener must _not_ force HTTPS-redirect,
|
||||
or the VPS hits a loop (mf01's known gotcha).
|
||||
- **YAML safety** — a syntax error in `tappaas-delegate.yml` breaks the whole
|
||||
VPS file provider; keep the regex single-quoted.
|
||||
- **`10.13.0.9` free?** — confirm before assigning.
|
||||
- **TaPPaaS config repo TBD** — the FLOSSFirewall/Caddy/DNS config home is not
|
||||
yet identified.
|
||||
- **Phase 5** depends on OrangeMakers router cooperation.
|
||||
|
||||
---
|
||||
|
||||
## Summary & next steps
|
||||
|
||||
- Reuse the **proven mf01 pattern** — terminate TLS at the VPS, proxy over
|
||||
`wg1` to TaPPaaS Caddy, split-horizon DNS for the internal view.
|
||||
- VPS side is a small, additive, **zero-new-tech** change.
|
||||
- **Next:** identify the TaPPaaS config repo, then write the implementation plan
|
||||
and execute phases 1–4.
|
||||
|
||||
_Design: `MakerFLOSS_Troubleshooting/docs/superpowers/specs/2026-06-28-tappaas-vps-publishing-design.md`_
|
||||
</content>
|
||||
Loading…
Add table
Reference in a new issue