ced4568
eae8e48d43
Adds platform/lab-router/ — a narrow service that runs on the Lab Host, authenticates the Gateway via mTLS, and resolves an opaque routing token to a local container purely from Docker label state (no Postgres access, no callback to the Provisioner). Replaces the Gateway's env.internal_ip assumption (only valid when Gateway and Lab share a Docker daemon) with a data-driven direct/router decision per lab_host (lab_hosts.routing_mode/router_endpoint, migration 004), resolved in one place (platform/gateway/src/lab-endpoint.js's labTarget()) that every proxy/fetch call site in server.js now goes through. Extends the existing Docker TLS CA (infra/scripts/docker-tls/generate-docker-tls.sh) with a second mTLS leaf pair (router-server/gateway-client) for this new data-plane connection, deployed by the docker-tls Ansible role into a separate directory from the control-plane pair. Firewall (rn-lab-host-01.rules) replaces the old speculative wide port-range allowance with one narrow rule: platform_ip -> the Router's port only. dev-local stays routing_mode: direct — zero behavior change for local dev, confirmed by the full existing regression suite passing unmodified.
Production firewall policy
iptables (not nftables) — deliberately, to stay consistent with the Provisioner's own dynamic
per-Lab egress rules, which already manipulate the DOCKER-USER chain via iptables
(platform/provisioner/src/firewall.js, Phase 1). Mixing the nft and legacy iptables backends
on the same host is a known source of silent rule-ordering bugs; the host-level policy below
uses the same backend the app already depends on.
Each .rules file is iptables-restore format — deployed by the matching Ansible role
(firewall for the VMs; the Proxmox host ruleset is applied manually per
docs/PRODUCTION_DEPLOYMENT.md §2, since Proxmox host firewalling is out of Ansible's blast
radius by design — a mistake there can lock out the only way in).
| File | Applies to | Deployed by |
|---|---|---|
proxmox-host.rules |
The Proxmox hypervisor itself | manual, docs/PRODUCTION_DEPLOYMENT.md §2 |
rn-platform-01.rules |
Platform VM | infra/ansible/roles/firewall/ |
rn-lab-host-01.rules |
Lab Host VM | infra/ansible/roles/firewall/ |
All three encode the same policy table from docs/PRODUCTION_NETWORK_SECURITY.md §6 — this
README doesn't restate it, that doc is the source of truth for why; these files are the
what, in a form the host can actually load.
IP addresses/subnets are Ansible template variables ({{ platform_ip }},
{{ lab_host_ip }}, {{ management_cidr }}, etc.) — see infra/ansible/group_vars/production.yml.
Nothing here hardcodes a real production IP, per the explicit Phase 4 instruction not to guess
those before the real host exists.
infra/firewall/validate-firewall.sh renders each ruleset with dummy IPs and runs it through
iptables-restore --test (syntax/semantic validation only — proves the rules are well-formed
iptables, not that the real network topology is correct, which needs the real hardware).