docs: identify WG endpoint as ProtonVPN Seattle; Mac gate is a second dashboard WG config

This commit is contained in:
Frank committed 2026-09-01 15:58:22 -07:00
1 parent 2d06be876f
commit 3094ffa746
2 files changed
+41 -18

No files matched your search

@@ -26,34 +26,41 @@ stack and qBittorrent inside a **podman machine** VM (Fedora CoreOS-style
qBittorrent downloads through gluetun (netns share); the arrs run without it. qBittorrent downloads through gluetun (netns share); the arrs run without it.
Until `/home/core/Containers/gluetun/env` contains the WireGuard credentials Until `/home/core/Containers/gluetun/env` contains the WireGuard credentials
(a second peer for the Mac — reusing Dankclaw's key would flip its tunnel and (a second Proton WireGuard config for the Mac — running two hosts on
kill SearXNG), `deploy_frankbook_stack` **skips** gluetun and qbittorrent Dankclaw's config would bounce the server-side endpoint and kill SearXNG),
`deploy_frankbook_stack` **skips** gluetun and qbittorrent
with instructions and deploys the five arrs anyway. The qB WebUI port stays with instructions and deploys the five arrs anyway. The qB WebUI port stays
unpublished by design; the e2e torrent test waits on the credentials. unpublished by design; the e2e torrent test waits on the credentials.
### Prepared Mac peer (2026-09-01 — waiting on server-side add) ### Mac provisioning (2026-09-01 — one dashboard action, then mine)
A dedicated keypair is generated and parked on Dankclaw The endpoint is a **ProtonVPN Seattle WireGuard server**, not a
(`~/frankbook-wg/mac-private.key`, 0600, host-local — never in the repo). self-administered box: RDAP says `149.102.254.77` is CDNEXT-CG-SEA
Lighting the tunnel needs exactly one change on the WireGuard server (Datacamp Limited, Proton's Seattle hosting partner) and Dankclaw's own
(149.102.254.77): register a new peer for the Mac — different keypair from tunnel v6 `2a07:b944::2:2` sits in CH-PROTONVPN-20160719. There is no
Dankclaw's (one key cannot serve two machines; the server bounces the peer-registration step on any server of ours — Dankclaw's credentials are a
endpoint between them), same endpoint and server key: dashboard-generated Proton WG config pasted into gluetun's `custom` profile,
and the Mac needs exactly the same thing, generated fresh:
- Server pubkey (route target): `utqNH4P+C0fA1wTgIUaIfhm1b7ai0iEGvXyiw4KC3Fs=` 1. In the Proton dashboard, create a second WireGuard config (e.g. named
- Endpoint: `149.102.254.77:51820` (`VPN_SERVICE_PROVIDER=custom`) `frankbook`) on the Seattle server and download the `.conf`. One config =
- Mac public key to register as the new peer: one keypair; reusing Dankclaw's would make the server bounce the endpoint
`QIoCwI+9VuiWldRvUfPpTfXq7UVVBFynIqYb2vqHtQo=` between the two hosts.
- Allocate the Mac a fresh tunnel IP as the peer's allowed IP — Dankclaw 2. Hand the values over (the file itself or its fields — the private key
holds `10.2.0.2/32`, so likely `10.2.0.3/32` unless the server numbers never enters the repo):
differently. - `PrivateKey` → `WIREGUARD_PRIVATE_KEY`
- `Address` (v4 + v6, e.g. `10.2.0.3/32, 2a07:b944::2:3/128`) →
`WIREGUARD_ADDRESSES`
- `PublicKey` → `WIREGUARD_PUBLIC_KEY` (Seattle server key:
`utqNH4P+C0fA1wTgIUaIfhm1b7ai0iEGvXyiw4KC3Fs=`, same as Dankclaw's)
- `Endpoint` = `149.102.254.77:51820`; gluetun ignores the `.conf` DNS line.
Then `/home/core/Containers/gluetun/env` (0600) inside the VM: Then `/home/core/Containers/gluetun/env` (0600) inside the VM:
VPN_SERVICE_PROVIDER=custom VPN_SERVICE_PROVIDER=custom
VPN_TYPE=wireguard VPN_TYPE=wireguard
WIREGUARD_PRIVATE_KEY=<raw b64 private key — fetch from dankclaw:~/frankbook-wg/mac-private.key> WIREGUARD_PRIVATE_KEY=<from the Proton .conf>
WIREGUARD_ADDRESSES=<allocated tunnel IP>/32 WIREGUARD_ADDRESSES=<from the Proton .conf>
WIREGUARD_PUBLIC_KEY=utqNH4P+C0fA1wTgIUaIfhm1b7ai0iEGvXyiw4KC3Fs= WIREGUARD_PUBLIC_KEY=utqNH4P+C0fA1wTgIUaIfhm1b7ai0iEGvXyiw4KC3Fs=
WIREGUARD_ENDPOINT_IP=149.102.254.77 WIREGUARD_ENDPOINT_IP=149.102.254.77
WIREGUARD_ENDPOINT_PORT=51820 WIREGUARD_ENDPOINT_PORT=51820
+16
View File
@@ -11,6 +11,22 @@ timestamp: 2026-09-14
# Bundle Change Log # Bundle Change Log
## 2026-09-01 - WG endpoint identified as ProtonVPN Seattle; Mac gate is a second dashboard config
- RDAP: `149.102.254.77` = CDNEXT-CG-SEA (Datacamp Limited, Proton's Seattle
hosting partner); Dankclaw's tunnel v6 `2a07:b944::2:2` sits in
CH-PROTONVPN-20160719; observed exit IP `149.22.88.19` = CDNEXT-SEA-CG.
The "custom WG server" is a ProtonVPN Seattle WireGuard server - there is
no peer-registration step on any box of ours (no SSH, only silent TLS
listeners on 443/4443/4444/8443).
- Mac gate corrected: provision a **second** Proton WG config (dashboard,
named e.g. `frankbook`) - one config = one keypair; two hosts on
Dankclaw's config bounce the server-side endpoint and kill SearXNG. Values
paste straight into the gluetun `custom` env. Earlier prepared keypair on
dankclaw (`~/frankbook-wg/`) retired to `~/.AGENTTRASH/` (Proton generates
the keypair per config; no BYO pubkey).
###
- [[FrankBook-Pro]] provisioning section rewritten.
## 2026-09-01 — Jellyfin authentication moved to Authentik LDAP ## 2026-09-01 — Jellyfin authentication moved to Authentik LDAP
- `/dankclaw/authentik/quadlet/authentik-outpost-ldap.container` (`4ad85fa`, - `/dankclaw/authentik/quadlet/authentik-outpost-ldap.container` (`4ad85fa`,
digest-pinned in `f4ef2b8`) — new `authentik-outpost-ldap.service` on digest-pinned in `f4ef2b8`) — new `authentik-outpost-ldap.service` on