@celilo/e2e 0.10.3 → 0.11.0

package/README.md

@@ -16,25 +16,34 @@ The network consists of 7 Docker bridge networks simulating a realistic home lab
 
 | Network | Subnet | Purpose |
 |---------|--------|---------|
-| **internal** | 192.168.0.0/24 | Home LAN (management, firewalls) |
-| **dmz** | 10.0.10.0/24 | Public-facing services |
-| **app** | 10.0.20.0/24 | Internal applications |
-| **secure** | 10.0.30.0/24 | Sensitive services |
+| **internal** | 10.226.1.0/24 | Home LAN (management, firewalls) |
+| **dmz** | 10.226.10.0/24 | Public-facing services |
+| **app** | 10.226.20.0/24 | Internal applications |
+| **secure** | 10.226.30.0/24 | Sensitive services |
 | **isp-external** | 100.100.0.0/24 | ISP network (between home and internet) |
 | **internet-external** | 100.64.0.0/24 | Simulated internet (DNS, ACME, etc.) |
 | **real-internet** | 172.30.0.0/24 | Bridge to actual internet (for apt, pip, etc.) |
 
 All networks except `real-internet` have Docker IP masquerade **disabled** — traffic flows through explicit iptables routing, not Docker's NAT. The `real-internet` network has masquerade enabled to provide actual internet access for package downloads.
 
+### Why these addresses (#539)
+
+Every simulated **private** zone lives inside `SIM_PRIVATE_SUPERNET` (`10.226.0.0/16` — mnemonic `0xE2` = "e2"), declared once in `src/types.ts` and derived from there by the compose generator, the zone classifier and the harness's `system init`. Two reasons, both load-bearing:
+
+1. **A leaked stack must not be able to collide with a real fleet.** The sim used to number its zones exactly like a production celilo deployment; on celilo's own forgejo-builder, which lives in the real dmz, a leaked bridge claimed the builder's own /24 and blackholed every containerized CI job's route to the forge. Teardown cannot be made reliable enough to prevent that (a SIGKILL runs no handler), so the sim moved instead.
+2. **Nothing may be magic about production's octets.** A suite that only passes on one site's address plan is asserting an accident, not celilo's behaviour.
+
+Don't hardcode an octet: use `zoneIp(zone, host)` / `ZONE_SUBNETS` / `ZONE_GATEWAYS`. `src/address-plan.test.ts` fails if a zone leaves the supernet, or if any retired fleet prefix reappears anywhere in the suite.
+
 ## Machines
 
 ### Fixed Infrastructure (always present)
 
 | Machine | Role | Networks | IPs |
 |---------|------|----------|-----|
-| **management** | Celilo CLI, Ansible, SSH | internal | 192.168.0.100 |
-| **fw-main** | iptables firewall (managed by Celilo) | internal, dmz, app, secure | 192.168.0.254, 10.0.10.1, 10.0.20.1, 10.0.30.1 |
-| **fw-isp** | Greenwave router simulator | internal, isp-external | 192.168.0.1, 100.100.0.100 |
+| **management** | Celilo CLI, Ansible, SSH | internal | 10.226.1.100 |
+| **fw-main** | iptables firewall (managed by Celilo) | internal, dmz, app, secure | 10.226.1.254, 10.226.10.1, 10.226.20.1, 10.226.30.1 |
+| **fw-isp** | Greenwave router simulator | internal, isp-external | 10.226.1.1, 100.100.0.100 |
 | **fw-ext** | Edge router + transparent HTTPS proxy (Squid) | isp-external, internet-external, real-internet | 100.100.0.101, 100.64.0.1, 172.30.0.5 |
 | **comcast-resolver** | Unbound recursive DNS resolver | isp-external, real-internet | 100.100.0.1, 172.30.0.4 |
 | **root-dns** | Knot authoritative DNS (root zone) | internet-external | 100.64.0.53 |
@@ -49,9 +58,9 @@ Added per-test via the `network()` builder API. Each is an Ubuntu 22.04 containe
 
 | Example | Network | IP | Purpose |
 |---------|---------|-----|---------|
-| caddy | dmz | 10.0.10.10 | Caddy reverse proxy deployment |
-| idp | app | 10.0.20.100 | Identity provider deployment |
-| db | secure | 10.0.30.50 | Database deployment |
+| caddy | dmz | 10.226.10.10 | Caddy reverse proxy deployment |
+| idp | app | 10.226.20.100 | Identity provider deployment |
+| db | secure | 10.226.30.50 | Database deployment |
 
 ## Routing
 
@@ -59,8 +68,8 @@ Traffic flows through explicit routing chains, mimicking a real network:
 
 | From | To | Path |
 |------|----|------|
-| management | dmz/app/secure | via fw-main (192.168.0.254) |
-| management | internet | via fw-isp (192.168.0.1) → fw-ext |
+| management | dmz/app/secure | via fw-main (10.226.1.254) |
+| management | internet | via fw-isp (10.226.1.1) → fw-ext |
 | dmz machines | internet | via fw-main → fw-isp → fw-ext |
 | Pebble | caddy (HTTP-01 challenge) | via fw-ext → fw-isp DNAT → fw-main DNAT → caddy |
 
@@ -104,12 +113,12 @@ When called, it updates the Knot DNS zone file and signals a zone reload. DNS pr
 
 ### Greenwave Router
 
-Runs on `fw-isp` (192.168.0.1). A Bun HTTPS server implementing the C4000XG REST API subset:
+Runs on `fw-isp` (10.226.1.1). A Bun HTTPS server implementing the C4000XG REST API subset:
 - `POST /cgi/cgi_action` — Login/logout
 - `GET /cgi/cgi_get` — Read config (public IP, port mappings)
 - `POST /cgi/cgi_set` — Add/remove port forwarding rules
 
-Port forwarding rules are applied via actual iptables commands, making NAT functional in the simulated network. The management HTTPS interface binds to the internal interface only (192.168.0.1), not the external interface.
+Port forwarding rules are applied via actual iptables commands, making NAT functional in the simulated network. The management HTTPS interface binds to the internal interface only (10.226.1.1), not the external interface.
 
 ### Pebble (Let's Encrypt)
 
@@ -136,7 +145,7 @@ cd e2e
 ./bin/e2e-up --full-stack
 
 # Custom machine spec
-./bin/e2e-up --custom '{"dmz":{"caddy":"10.0.10.10","web":"10.0.10.20"}}'
+./bin/e2e-up --custom '{"dmz":{"caddy":"10.226.10.10","web":"10.226.10.20"}}'
 ```
 
 After startup, you're dropped into the management machine shell with tab completion for `celilo` commands (aliased as `c`).
@@ -166,10 +175,10 @@ cd /celilo/modules
 
 # System init
 c system init --accept-defaults \
-    network.dmz.subnet=10.0.10.0/24 \
-    network.app.subnet=10.0.20.0/24 \
-    network.secure.subnet=10.0.30.0/24 \
-    network.internal.subnet=192.168.0.0/24 \
+    network.dmz.subnet=10.226.10.0/24 \
+    network.app.subnet=10.226.20.0/24 \
+    network.secure.subnet=10.226.30.0/24 \
+    network.internal.subnet=10.226.1.0/24 \
     primary_domain=iamtheinternet.org \
     admin.email=admin@iamtheinternet.org \
     dns.primary=100.100.0.1 \
@@ -182,17 +191,17 @@ c module import iptables
 c module import caddy
 
 # Add machines (--ssh-user root needed for non-interactive)
-c machine add 192.168.0.1 --ssh-user root --earmark greenwave
-c machine add 192.168.0.254 --ssh-user root --earmark iptables
-c machine add 10.0.10.10 --ssh-user root
+c machine add 10.226.1.1 --ssh-user root --earmark greenwave
+c machine add 10.226.1.254 --ssh-user root --earmark iptables
+c machine add 10.226.10.10 --ssh-user root
 
 # Pre-configure secrets and non-derivable config
 c module config set namecheap domains '["iamtheinternet.org"]'
 c module secret set namecheap ddns_passwords '{"iamtheinternet.org":"test123"}'
-c module config set greenwave router_ip 192.168.0.1
+c module config set greenwave router_ip 10.226.1.1
 c module secret set greenwave router_username admin
 c module secret set greenwave router_password admin
-c module config set iptables nat_ip 192.168.0.253
+c module config set iptables nat_ip 10.226.1.253
 c module config set caddy hostname www
 c module config set caddy acme_ca https://acme-v02.api.letsencrypt.org/dir
 
@@ -249,7 +258,7 @@ describe('my deployment test', () => {
     net = await CADDY_DEPLOYMENT().start();
 
     // 2. Add machines, import modules, configure
-    await net.celilo('machine add 10.0.10.10 --ssh-user root');
+    await net.celilo('machine add 10.226.10.10 --ssh-user root');
     await net.celilo('module import /celilo/modules/caddy');
     await net.celilo('module config set caddy hostname www');
 
@@ -330,9 +339,9 @@ INFRASTRUCTURE_ONLY() // no dynamic machines
 import { network } from '../src/network-builder';
 
 const net = await network()
-  .dmz({ caddy: '10.0.10.10', web: '10.0.10.20' })
-  .app({ api: '10.0.20.100' })
-  .secure({ db: '10.0.30.50' })
+  .dmz({ caddy: '10.226.10.10', web: '10.226.10.20' })
+  .app({ api: '10.226.20.100' })
+  .secure({ db: '10.226.30.50' })
   .start();
 ```
 

package/bin/e2e-status

@@ -22,7 +22,7 @@ docker compose -p "$PROJECT_NAME" exec -T comcast-resolver dig @127.0.0.1 www.ia
 
 echo ""
 echo "=== Connectivity (from management) ==="
-for target in "fw-main:192.168.0.254" "fw-isp:192.168.0.1" "comcast-resolver:100.100.0.1" "root-dns:100.64.0.53" "namecheap-dns:100.64.0.55"; do
+for target in "fw-main:10.226.1.254" "fw-isp:10.226.1.1" "comcast-resolver:100.100.0.1" "root-dns:100.64.0.53" "namecheap-dns:100.64.0.55"; do
   name="${target%%:*}"
   ip="${target##*:}"
   echo -n "  $name ($ip): "

package/bin/e2e-up

@@ -5,7 +5,7 @@
 #   ./bin/e2e-up                          # Infrastructure only
 #   ./bin/e2e-up --caddy                  # + caddy machine in dmz
 #   ./bin/e2e-up --full-stack             # + caddy, idp, db
-#   ./bin/e2e-up --custom '{"dmz":{"caddy":"10.0.10.10","web":"10.0.10.20"}}'
+#   ./bin/e2e-up --custom '{"dmz":{"caddy":"10.226.10.10","web":"10.226.10.20"}}'
 #
 # After startup, drops you into a shell on the management machine.
 # Use `exit` to leave the shell (network stays running).
@@ -30,9 +30,9 @@ while [[ $# -gt 0 ]]; do
       echo ""
       echo "Presets:"
       echo "  (default)      Infrastructure only (management, firewalls, DNS, Pebble)"
-      echo "  --caddy        + caddy machine at 10.0.10.10 in dmz"
+      echo "  --caddy        + caddy machine at 10.226.10.10 in dmz"
       echo "  --full-stack   + caddy (dmz), idp (app), db (secure)"
-      echo "  --custom JSON  Custom machine spec, e.g. '{\"dmz\":{\"caddy\":\"10.0.10.10\"}}'"
+      echo "  --custom JSON  Custom machine spec, e.g. '{\"dmz\":{\"caddy\":\"10.226.10.10\"}}'"
       echo ""
       echo "After startup, you'll be dropped into the management machine shell."
       echo "Use ./bin/e2e-down to tear down, or ./bin/e2e-shell to reconnect."
@@ -60,7 +60,7 @@ const presets = {
   },
   'caddy': {
     topology: 'default',
-    dmzMachines: [{ name: 'caddy', ip: '10.0.10.10', zone: 'dmz' }],
+    dmzMachines: [{ name: 'caddy', ip: '10.226.10.10', zone: 'dmz' }],
     appMachines: [],
     secureMachines: [],
     domain: 'iamtheinternet.org',
@@ -69,9 +69,9 @@ const presets = {
   },
   'full-stack': {
     topology: 'default',
-    dmzMachines: [{ name: 'caddy', ip: '10.0.10.10', zone: 'dmz' }],
-    appMachines: [{ name: 'idp', ip: '10.0.20.100', zone: 'app' }],
-    secureMachines: [{ name: 'db', ip: '10.0.30.50', zone: 'secure' }],
+    dmzMachines: [{ name: 'caddy', ip: '10.226.10.10', zone: 'dmz' }],
+    appMachines: [{ name: 'idp', ip: '10.226.20.100', zone: 'app' }],
+    secureMachines: [{ name: 'db', ip: '10.226.30.50', zone: 'secure' }],
     domain: 'iamtheinternet.org',
     ddnsPassword: 'test123',
     verifyRouting: false,
@@ -131,17 +131,17 @@ echo "  Project: $PROJECT_NAME"
 echo "================================================"
 echo ""
 echo "Networks:"
-echo "  internal:          192.168.0.0/24"
-echo "  dmz:               10.0.10.0/24"
-echo "  app:               10.0.20.0/24"
-echo "  secure:            10.0.30.0/24"
+echo "  internal:          10.226.1.0/24"
+echo "  dmz:               10.226.10.0/24"
+echo "  app:               10.226.20.0/24"
+echo "  secure:            10.226.30.0/24"
 echo "  isp-external:      100.100.0.0/24"
 echo "  internet-external: 100.64.0.0/24"
 echo ""
 echo "Key machines:"
-echo "  management:        192.168.0.100  (conductor CLI)"
-echo "  fw-main:           192.168.0.254  (iptables firewall)"
-echo "  fw-isp:            192.168.0.1    (greenwave router sim)"
+echo "  management:        10.226.1.100  (conductor CLI)"
+echo "  fw-main:           10.226.1.254  (iptables firewall)"
+echo "  fw-isp:            10.226.1.1    (greenwave router sim)"
 echo "  comcast-resolver:  100.100.0.1        (DNS resolver)"
 echo "  namecheap-dns:     100.64.0.55       (DDNS simulator)"
 echo "  letsencrypt:       100.64.0.100      (Pebble ACME)"

package/config/dhcp/dnsmasq.conf

@@ -9,13 +9,13 @@ interface=eth0
 bind-interfaces
 
 # DHCP range: .200-.220 (small range for test clients)
-dhcp-range=192.168.0.200,192.168.0.220,255.255.255.0,1h
+dhcp-range=10.226.1.200,10.226.1.220,255.255.255.0,1h
 
 # Default gateway (the greenwave router itself)
-dhcp-option=option:router,192.168.0.1
+dhcp-option=option:router,10.226.1.1
 
 # DNS server (initially the router, updated by greenwave API)
-dhcp-option=option:dns-server,192.168.0.1
+dhcp-option=option:dns-server,10.226.1.1
 
 # Domain name / search domain
 # dhcp-option=option:domain-name,iamtheinternet.org

package/config/resolver/unbound.conf

@@ -32,8 +32,8 @@ server:
     # sit on the `internal` network — celilo-mgr reaches a notification
     # transport locally; a transport needing public ingress could not tell
     # you the ingress was broken.
-    local-data: "signal-cli.lab. IN A 192.168.0.90"
-    local-data: "signal-sim.lab. IN A 192.168.0.91"
+    local-data: "signal-cli.lab. IN A 10.226.1.90"
+    local-data: "signal-sim.lab. IN A 10.226.1.91"
     # signal-cli release host — the sim internet's stand-in for GitHub
     # releases, so the signal module's deploy-time download resolves inside
     # the sealed network. See SIMULATOR_IPS.SIGNAL_RELEASE.

package/config/routing/fw-ext-routes.sh

@@ -6,10 +6,10 @@ ip route del default 2>/dev/null || true
 # Default route via real-internet bridge (for Squid outbound to real internet)
 ip route add default via 172.30.0.1
 # Internal subnets via fw-isp
-ip route add 192.168.0.0/24 via 100.100.0.100     # Internal via fw-isp
-ip route add 10.0.10.0/24 via 100.100.0.100       # dmz via fw-isp
-ip route add 10.0.20.0/24 via 100.100.0.100       # app via fw-isp
-ip route add 10.0.30.0/24 via 100.100.0.100       # secure via fw-isp
+ip route add 10.226.1.0/24 via 100.100.0.100     # Internal via fw-isp
+ip route add 10.226.10.0/24 via 100.100.0.100       # dmz via fw-isp
+ip route add 10.226.20.0/24 via 100.100.0.100       # app via fw-isp
+ip route add 10.226.30.0/24 via 100.100.0.100       # secure via fw-isp
 
 # IP forwarding is set via sysctls in docker-compose
 

package/config/routing/fw-isp-routes.sh

@@ -11,9 +11,9 @@ chmod 600 /root/.ssh/authorized_keys
 # Routing
 ip route del default 2>/dev/null || true
 ip route add default via 100.100.0.101            # Internet via fw-ext
-ip route add 10.0.10.0/24 via 192.168.0.254       # dmz via fw-main
-ip route add 10.0.20.0/24 via 192.168.0.254       # app via fw-main
-ip route add 10.0.30.0/24 via 192.168.0.254       # secure via fw-main
+ip route add 10.226.10.0/24 via 10.226.1.254       # dmz via fw-main
+ip route add 10.226.20.0/24 via 10.226.1.254       # app via fw-main
+ip route add 10.226.30.0/24 via 10.226.1.254       # secure via fw-main
 
 # IP forwarding is set via sysctls in docker-compose
 

package/config/routing/fw-main-routes.sh

@@ -30,14 +30,25 @@ else
   # Two-layer: no external interface on fw-main; it routes outbound to the
   # upstream firewall (fw-isp) and MASQUERADEs toward it (egress leaves via the
   # internal-facing interface, so there is no single WAN interface to scope to).
-  ip route add default via 192.168.0.1
-  # Protected↔protected (dmz/app/secure ↔ each other, all in 10/8) is NOT NAT'd —
-  # a real firewall routes between its segmented zones without NAT, preserving the
+  ip route add default via 10.226.1.1
+  # Protected↔protected (the segmented zones ↔ each other) is NOT NAT'd — a real
+  # firewall routes between its segmented zones without NAT, preserving the
   # client source so the dmz-resident resolver can serve source-based split-horizon
   # (ISS-0156). Only protected↔internal and egress get MASQUERADE'd below. Without
   # this RETURN, app→dmz and internal→dmz would both be SNAT'd to the dmz gateway
   # and become indistinguishable (confirmed via live probe).
-  iptables -t nat -A POSTROUTING -s 10.0.0.0/8 -d 10.0.0.0/8 -j RETURN
+  #
+  # PROTECTED_SUBNETS is passed from the compose generator (ZONE_SUBNETS). It used
+  # to be written as `-s 10.0.0.0/8 -d 10.0.0.0/8`, which meant "protected" only
+  # because `internal` happened to be numbered out of 192.168/16 and every other
+  # zone out of 10/8 — the firewall's NAT policy silently depended on the octets. With
+  # the whole sim in 10.226.0.0/16 (#539) that shorthand would have swept `internal`
+  # into the no-NAT class and handed LAN devices the protected DNS view.
+  for src in ${PROTECTED_SUBNETS:?PROTECTED_SUBNETS not set by compose}; do
+    for dst in ${PROTECTED_SUBNETS}; do
+      iptables -t nat -A POSTROUTING -s "$src" -d "$dst" -j RETURN
+    done
+  done
   iptables -t nat -A POSTROUTING -j MASQUERADE
 fi
 

package/config/routing/management-routes.sh

@@ -20,29 +20,29 @@ echo "UserKnownHostsFile /dev/null" >> /root/.ssh/config
 chmod 600 /root/.ssh/config
 
 # Routing — DEFAULT_GATEWAY comes from docker-compose environment
-# default: 192.168.0.1 (fw-isp), direct-internet: 192.168.0.254 (fw-main)
-GATEWAY="${DEFAULT_GATEWAY:-192.168.0.1}"
+# default: 10.226.1.1 (fw-isp), direct-internet: 10.226.1.254 (fw-main)
+GATEWAY="${DEFAULT_GATEWAY:-10.226.1.1}"
 # Next hop into the segmented zones. On the default topology celilo-mgr is on the
-# internal LAN and reaches them via fw-main's internal leg (192.168.0.254). When
+# internal LAN and reaches them via fw-main's internal leg (10.226.1.254). When
 # celilo-mgr lives on its OWN control-plane network (managementZone secure-mgmt),
 # it reaches them via fw-main's leg on THAT network instead.
-FW_MAIN="${FW_MAIN_HOP:-192.168.0.254}"
+FW_MAIN="${FW_MAIN_HOP:-10.226.1.254}"
 ip route del default 2>/dev/null || true
 ip route add default via "$GATEWAY"
-ip route add 10.0.10.0/24 via "$FW_MAIN"    # dmz via fw-main
-ip route add 10.0.20.0/24 via "$FW_MAIN"    # app via fw-main
-ip route add 10.0.30.0/24 via "$FW_MAIN"    # secure via fw-main
+ip route add 10.226.10.0/24 via "$FW_MAIN"    # dmz via fw-main
+ip route add 10.226.20.0/24 via "$FW_MAIN"    # app via fw-main
+ip route add 10.226.30.0/24 via "$FW_MAIN"    # secure via fw-main
 # Control plane. Only reachable when a secure-mgmt network exists — that is,
 # when celilo-mgr lives there itself, or when a module declaring
 # `zone: secure-mgmt` needs a system to land on (#436). Tolerated silently
 # otherwise so the default topology is unchanged.
-ip route add 10.0.120.0/24 via "$FW_MAIN" 2>/dev/null || true
+ip route add 10.226.120.0/24 via "$FW_MAIN" 2>/dev/null || true
 
 # DNS — Technitium internal resolver (split-horizon) with public fallback.
-# Technitium at 192.168.0.10 is authoritative for iamtheinternet.org internally,
-# resolving www/auth to Caddy's DMZ IP (10.0.10.10) rather than the public WAN IP.
+# Technitium at 10.226.1.10 is authoritative for iamtheinternet.org internally,
+# resolving www/auth to Caddy's DMZ IP (10.226.10.10) rather than the public WAN IP.
 # Fall back to the simulated public resolver if Technitium is not yet up.
-printf 'nameserver %s\nnameserver 100.100.0.1\n' "${INTERNAL_RESOLVER:-192.168.0.10}" > /etc/resolv.conf
+printf 'nameserver %s\nnameserver 100.100.0.1\n' "${INTERNAL_RESOLVER:-10.226.1.10}" > /etc/resolv.conf
 
 # Fetch Pebble's runtime ACME root CA (Pebble generates a fresh root at each
 # startup, unlike the static /config/pebble/pebble-ca.crt baked in at build

package/config/routing/observer-setup.sh

@@ -28,9 +28,9 @@ ip route add default via "${GATEWAY}"
 # A real consumer vantage NEVER has these — that is the whole point. Present only so a
 # `management`-style all-VLAN box can be modelled deliberately.
 if [ "${INTERZONE}" = "1" ]; then
-  ip route add 10.0.10.0/24 via 192.168.0.254 2>/dev/null || true  # dmz via fw-main
-  ip route add 10.0.20.0/24 via 192.168.0.254 2>/dev/null || true  # app via fw-main
-  ip route add 10.0.30.0/24 via 192.168.0.254 2>/dev/null || true  # secure via fw-main
+  ip route add 10.226.10.0/24 via 10.226.1.254 2>/dev/null || true  # dmz via fw-main
+  ip route add 10.226.20.0/24 via 10.226.1.254 2>/dev/null || true  # app via fw-main
+  ip route add 10.226.30.0/24 via 10.226.1.254 2>/dev/null || true  # secure via fw-main
 fi
 
 # --- Resolver ---

package/config/routing/resolver-internal-routes.sh

@@ -1,10 +1,10 @@
 #!/bin/bash
 set -e
 
-# CADDY_IP: IP of the caddy container in the DMZ (default 10.0.10.10).
+# CADDY_IP: IP of the caddy container in the DMZ (default 10.226.10.10).
 # All test-domain queries resolve to this IP so management can reach
 # caddy directly without hairpin NAT through the external interface.
-CADDY_IP="${CADDY_IP:-10.0.10.10}"
+CADDY_IP="${CADDY_IP:-10.226.10.10}"
 
 # DOMAINS: comma-separated list of e2e test domains that should be
 # split-horizon redirected to caddy. Default covers the canonical
@@ -15,7 +15,7 @@ DOMAINS="${DOMAINS:-iamtheinternet.org,example.net}"
 
 # Routing — reach comcast-resolver (100.100.0.1) via fw-main or fw-isp.
 # DEFAULT_GATEWAY is set by docker-compose from the topology config.
-GATEWAY="${DEFAULT_GATEWAY:-192.168.0.254}"
+GATEWAY="${DEFAULT_GATEWAY:-10.226.1.254}"
 ip route del default 2>/dev/null || true
 ip route add default via "$GATEWAY"
 
@@ -61,8 +61,8 @@ $(printf "${SPLIT_HORIZON_BLOCK}")
     # sit on the `internal` network — celilo-mgr reaches a notification
     # transport locally; a transport needing public ingress could not tell
     # you the ingress was broken.
-    local-data: "signal-cli.lab. IN A 192.168.0.90"
-    local-data: "signal-sim.lab. IN A 192.168.0.91"
+    local-data: "signal-cli.lab. IN A 10.226.1.90"
+    local-data: "signal-sim.lab. IN A 10.226.1.91"
     # signal-cli release host — the sim internet's stand-in for GitHub
     # releases, so the signal module's deploy-time download resolves inside
     # the sealed network. See SIMULATOR_IPS.SIGNAL_RELEASE.

package/config/routing/target-routes.sh

@@ -1,6 +1,6 @@
 #!/bin/bash
 # Generic startup for target machines (dmz/app/secure).
-# The default gateway is passed as $1 (e.g., 10.0.10.1 for dmz).
+# The default gateway is passed as $1 (e.g., 10.226.10.1 for dmz).
 set -e
 
 GATEWAY="${1:?Usage: target-routes.sh <gateway-ip>}"

package/config/routing/target-setup.sh

@@ -63,21 +63,23 @@ echo "nameserver 100.100.0.1" > /etc/resolv.conf
   done
 ) &
 
-# Pre-warm apt cache before reporting "ready". Direct upstream (no
-# apt-cacher-ng) is less forgiving: the very first Ansible apt-update
-# was returning success with partially-fetched indexes (universe
-# missing), making "apt install knot" fail with "No package matching
-# 'knot' is available". Running update here, *before* the
-# target-setup service completes, guarantees Ansible finds populated
-# lists when it later connects via SSH.
-echo "Pre-warming apt cache..."
-for attempt in 1 2 3; do
-  if apt-get update -qq; then
-    echo "apt-cache ready (attempt $attempt)"
-    break
-  fi
-  echo "apt-update attempt $attempt failed, retrying in 5s..."
-  sleep 5
-done
+# NOTHING BELOW MAY DEPEND ON EGRESS. Readiness is gated on this script
+# (`systemctl is-active target-setup`, 60s), and this script runs the moment the
+# container does — BEFORE fw-ext has installed its NAT. Until it does, a packet
+# for the real internet is not refused, it is blackholed, so anything fetched
+# here pays a full connect timeout rather than failing fast.
+#
+# This used to pre-warm the apt cache, whose sources include dl.cloudsmith.io:
+# four IPs, each timing out, 64s against a 60s budget. Measured both ways on a
+# live stack — from a converged target that same fetch is 302 in 0.19s; with
+# fw-ext's NAT flushed it hangs past 70s. So the failure was never a slow CDN or
+# a broken simulator, which is exactly what "Timeout waiting for caddy
+# target-setup" sent everyone looking for, twice in one day.
+#
+# The apt lists it was warming are now populated at IMAGE BUILD time (see
+# docker/Dockerfile.target-*): Ansible still gets complete indexes on first
+# connect, and readiness no longer races the firewall. Egress itself is
+# untouched — the topology still NATs out, and pebble/apt still use it at deploy
+# time, by which point the firewall has long converged. See #560.
 
 echo "Target machine ready: $(hostname)"

package/config/socks/startup.sh

@@ -10,7 +10,7 @@ VANTAGE="${VANTAGE:-isp-external}"
 case "$VANTAGE" in
   isp-external)
     # Residential-user view. Default route via fw-ext (.101) which DNATs
-    # public-internet traffic into the dmz (caddy at 10.0.10.10). DNS via
+    # public-internet traffic into the dmz (caddy at 10.226.10.10). DNS via
     # comcast-resolver (.1) which walks the root → TLD → namecheap chain.
     GATEWAY="100.100.0.101"
     NAMESERVER="100.100.0.1"
@@ -19,8 +19,8 @@ case "$VANTAGE" in
     # Operator-on-LAN view. Default route via fw-isp (.1); split-horizon
     # resolver at .10 returns the firewall's same-subnet NAT IP for the
     # test domain, which DNATs to caddy.
-    GATEWAY="192.168.0.1"
-    NAMESERVER="192.168.0.10"
+    GATEWAY="10.226.1.1"
+    NAMESERVER="10.226.1.10"
     ;;
   *)
     echo "Unknown VANTAGE: $VANTAGE (expected isp-external or internal)" >&2

package/docker/Dockerfile.target-machine

@@ -87,7 +87,21 @@ RUN curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | \
     gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
 RUN curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | \
     tee /etc/apt/sources.list.d/caddy-stable.list
-RUN apt-get update && apt-get install -y caddy && rm -rf /var/lib/apt/lists/*
+# Once caddy is installed the cloudsmith source has no job left — but the file
+# must STAY: the Ansible role skips re-adding it on `creates:`, so deleting it
+# only moves the curl into the deploy. Neutered to a comment instead, so no
+# `apt-get update` in the sim waits on a repo whose only package is already
+# installed here.
+#
+# The lists are deliberately NOT cleaned afterwards. target-setup used to run
+# `apt-get update` at boot to guarantee Ansible found complete indexes, paying
+# an external round-trip inside the 60s readiness budget for it; baking the
+# indexes here buys the same guarantee off that path. A source that fails to
+# refresh at deploy time keeps this copy. See #560.
+RUN apt-get update && apt-get install -y caddy \
+ && printf '# neutered at image build: caddy is pre-installed (see #560)\n' \
+      > /etc/apt/sources.list.d/caddy-stable.list \
+ && apt-get update
 
 STOPSIGNAL SIGRTMIN+3
 ENTRYPOINT ["/sbin/init"]

package/docker/Dockerfile.target-machine-docker

@@ -97,5 +97,11 @@ COPY config/routing/docker-image-preload.service /etc/systemd/system/docker-imag
 RUN systemctl enable docker-image-preload
 
 
+# Bake complete apt indexes into the image. target-setup used to run
+# `apt-get update` at boot for this, which put a third party's latency inside
+# the 60s readiness budget (#560). Doing it here gives Ansible the same
+# guarantee — populated lists on first connect — off the readiness path.
+RUN apt-get update
+
 STOPSIGNAL SIGRTMIN+3
 ENTRYPOINT ["/sbin/init"]

package/docker/Dockerfile.target-technitium

@@ -94,5 +94,11 @@ RUN printf '[Unit]\nDescription=Technitium DNS Server\nAfter=network.target\n\n[
     > /etc/systemd/system/dns.service && \
     systemctl enable dns
 
+# Bake complete apt indexes into the image. target-setup used to run
+# `apt-get update` at boot for this, which put a third party's latency inside
+# the 60s readiness budget (#560). Doing it here gives Ansible the same
+# guarantee — populated lists on first connect — off the readiness path.
+RUN apt-get update
+
 STOPSIGNAL SIGRTMIN+3
 ENTRYPOINT ["/sbin/init"]

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@celilo/e2e",
-  "version": "0.10.3",
+  "version": "0.11.0",
   "description": "E2E test infrastructure for Celilo-deployed applications. Provides a simulated internet with DNS hierarchy, ACME server, firewalls, and target machines in Docker.",
   "type": "module",
   "main": "./src/index.ts",
@@ -38,7 +38,7 @@
   ],
   "dependencies": {
     "@celilo/cli-display": "^0.1.9",
-    "@celilo/event-bus": "^0.1.9",
+    "@celilo/event-bus": "^0.1.10",
     "yaml": "^2.8.0",
     "zod": "^3.24.1"
   },

package/simulators/greenwave/server.ts

@@ -68,7 +68,7 @@ const tlsOptions = (() => {
 
 // Bind to internal interface only (like a real router's management UI)
 // The external interface should only handle port-forwarded traffic via iptables
-const BIND_HOST = process.env.ROUTER_BIND_HOST || '192.168.0.1';
+const BIND_HOST = process.env.ROUTER_BIND_HOST || '10.226.1.1';
 
 const server = Bun.serve({
   port: PORT,

package/simulators/greenwave/state.ts

@@ -17,11 +17,11 @@ let nextIndex = 1;
 const dhcpPool: Record<string, string> = {
   Alias: 'cpe-Pool-1',
   Enable: 'true',
-  MinAddress: '192.168.0.2',
-  MaxAddress: '192.168.0.150',
+  MinAddress: '10.226.1.2',
+  MaxAddress: '10.226.1.150',
   SubnetMask: '255.255.255.0',
-  IPRouters: '192.168.0.1',
-  DNSServers: '192.168.0.1',
+  IPRouters: '10.226.1.1',
+  DNSServers: '10.226.1.1',
   DomainName: '',
   LeaseTime: '3600',
   Status: 'Enabled',
@@ -121,7 +121,7 @@ export function setDhcpPool(params: Record<string, string>): CgiObject[] {
 }
 
 function rewriteDnsmasqConfig(): void {
-  const dnsServers = dhcpPool.DNSServers || '192.168.0.1';
+  const dnsServers = dhcpPool.DNSServers || '10.226.1.1';
   const domainName = dhcpPool.DomainName || '';
 
   const lines = [
@@ -129,8 +129,8 @@ function rewriteDnsmasqConfig(): void {
     'port=0',
     'interface=eth0',
     'bind-interfaces',
-    'dhcp-range=192.168.0.200,192.168.0.220,255.255.255.0,60s',
-    'dhcp-option=option:router,192.168.0.1',
+    'dhcp-range=10.226.1.200,10.226.1.220,255.255.255.0,60s',
+    'dhcp-option=option:router,10.226.1.1',
     `dhcp-option=option:dns-server,${dnsServers}`,
     'dhcp-lease-max=20',
     'log-dhcp',