wip(vpn): gluetun custom-provider mode with operator's PIA .ovpn

PIA-provider server selection is flaky here (random dead IPs); the operator's .ovpn
uses sweden.privacy.network (load-balanced, reliable). Switch to custom mode
(VPN_SERVICE_PROVIDER=custom, OPENVPN_CUSTOM_CONFIG=/config/pia.ovpn), mount the
pia-custom-ovpn Secret, keep creds + kill-switch + tun-mtu 1300. Drops PIA-provider
server list/updater and native PF (Phase-6 concern). Pending the operator-provisioned
pia-custom-ovpn Secret (not merged until it exists).

Co-Authored-By: Claude Opus 4.8 <[email protected]>

DECISIONS-LOG.md

@@ -555,7 +555,27 @@ return traffic) and had me check MTU at each layer. Findings via `ping -M do` sw
   overhead → **pod MTU 1450**. OpenVPN emits ~1500-byte handshake packets → exceed 1450 → dropped (broken
   PMTUD = no ICMP back). This is why HTTPS (MSS-clamped) + small UDP (DNS/NTP) work but OpenVPN doesn't.
 
-**Fix (operator's choice: "shrink OpenVPN MTU in gluetun"):** set gluetun `OPENVPN_MTU=1350` (tun-mtu) and
+### Phase 3 VPN — custom .ovpn mode (the real cause: flaky server selection) (2026-08-23)
+After the MTU red-herrings, packet capture (node ens3 + host wlp4s0, GNOME OFF so it wasn't the host's own
+VPN) proved the pod CAN complete a **full** PIA handshake — a working flow (`50017 → 158.173.241.22:1198`)
+showed 1222-byte cert packets BOTH ways, reaching the node and pod end-to-end through the double NAT
+(Cilium SNAT → libvirt masq → router). It's **intermittent per-server**: gluetun's PIA-provider mode
+random-picks server IPs and many don't answer this cluster's flows (→ TLS timeouts, exit-0 restarts ~every
+2min), while the operator's GNOME client is reliable because its `.ovpn` targets **`sweden.privacy.network`**
+— a load-balanced hostname that always lands on a healthy server. NOT MTU, NOT encryption preset (strong AND
+normal both fail identically once the env name `PRIVATE_INTERNET_ACCESS_OPENVPN_ENCRYPTION_PRESET` was
+corrected), NOT Cilium (policy default-allow, host-fw off, Hubble FORWARDED), NOT a network block.
+
+**Decision (operator's choice):** switch gluetun to **custom-provider mode** feeding the operator's exact
+`.ovpn` (`VPN_SERVICE_PROVIDER=custom`, `OPENVPN_CUSTOM_CONFIG=/config/pia.ovpn`, .ovpn from the
+`pia-custom-ovpn` SOPS Secret; creds still via OPENVPN_USER/PASSWORD; kill-switch kept; tun-mtu 1300 for the
+1450 pod MTU). Dropped the PIA-provider server list + updater initContainer. **Trade-off:** custom mode
+loses gluetun's PIA-native port forwarding (Phase-6/qBittorrent concern) — revisit then. This is an
+implementation choice within ADR-0013's "single shared Gluetun PIA OpenVPN gateway" model (architecture
+unchanged), noted here rather than escalated. Pending operator provisioning of the `.ovpn` Secret.
+
+<!-- superseded strong/normal-preset attempt below, kept for the record -->
+**(superseded) Fix (operator's choice: "shrink OpenVPN MTU in gluetun"):** set gluetun `OPENVPN_MTU=1350` (tun-mtu) and
 `OPENVPN_MSSFIX=1350` so encrypted packets (~1350+52 ≈ 1402) fit under the 1450 pod MTU. Keeps OpenVPN +
 Cilium VXLAN unchanged. Port kept at 8080 (confirmed PIA responds). Re-enabled `vpn-egress`. Values hardcoded
 as quoted strings (int-coercion gotcha). Alternatives not taken: Cilium native routing (pod MTU→1500) or