jschoubben
5d01006eab
The full topology now raises: four machines, three routers, a transit router, six segments, in 35 seconds. Everything the declaration model can express except `place`, which is refused because the node host it would place does not exist yet. Transit was a real gap, not a bug. The design says public networks are unrelated and routed to each other, never bridged — and I built the segments and never built the thing that routes between them, so three public networks were islands and nothing crossed. A transit router now holds an interface on every public segment, forwarding and no translation: the closest thing the lab has to the internet, deliberately dumb. Proven rather than asserted, by ping TTL across the raised topology: within one segment ttl=64 no hops across two unrelated public networks ttl=62 gateway + transit multicast between public networks 0 replies A flat internet would have shown ttl=64 and answered multicast — which would let a node discover a peer it could never reach in production, and report success. That is the fault the as-is layer records the mesh already hitting with multicast name resolution. inbound: deny is implemented as a host firewall on the machine, read back after applying. A declared refusal that silently did not load leaves the machine wide open, which looks exactly like a machine that is working. Established and related traffic is accepted, so a defended machine can still dial out rather than being a disconnected one. Verified by running, all of it: home -> devices (policy allow) reachable devices -> home (policy deny) blocked behind unforwardable NAT -> out reachable in -> behind unforwardable NAT unreachable inbound: deny, dialling out reachable reaching a machine that denies inbound refused The two routers differ exactly as declared: the forwardable one carries the policy rule and no inbound drop, the unforwardable one carries `ct state new drop` and no DNAT.
66 lines
1.6 KiB
YAML
66 lines
1.6 KiB
YAML
# Two things production has and a flat lab cannot show.
|
|
#
|
|
# `devices` and `home` sit behind ONE router — identical gateway declarations — with a
|
|
# policy allowing home→devices and denying the reverse. That is an ordinary segmented
|
|
# household router, and the asymmetry is the normal case.
|
|
#
|
|
# `cafe` sits behind a gateway we do not control. Outbound works; nothing initiates
|
|
# inward, and nothing can be published there at all.
|
|
scenario: segmented-and-unforwardable
|
|
|
|
segments:
|
|
hosting:
|
|
kind: public
|
|
cidr: [192.0.2.0/24]
|
|
|
|
home:
|
|
kind: private
|
|
cidr: [192.168.1.0/24]
|
|
gateway:
|
|
to: hosting
|
|
address: [192.0.2.50]
|
|
nat: [v4]
|
|
forwardable: true
|
|
mapping_ttl: 120s
|
|
|
|
devices:
|
|
kind: private
|
|
cidr: [192.168.30.0/24]
|
|
gateway:
|
|
to: hosting
|
|
address: [192.0.2.50] # identical → the SAME router
|
|
nat: [v4]
|
|
forwardable: true
|
|
mapping_ttl: 120s
|
|
|
|
cafe:
|
|
kind: private
|
|
cidr: [10.50.0.0/16]
|
|
gateway:
|
|
to: hosting
|
|
address: [192.0.2.80]
|
|
nat: [v4]
|
|
forwardable: false # carrier-grade NAT, or simply not ours
|
|
mapping_ttl: 30s
|
|
|
|
policy:
|
|
- { from: devices, to: home, allow: false }
|
|
- { from: home, to: devices, allow: true }
|
|
|
|
machines:
|
|
anchor:
|
|
at: { segment: hosting, address: [192.0.2.10] }
|
|
inbound: allow
|
|
|
|
home-server:
|
|
at: { segment: home, address: [192.168.1.135] }
|
|
inbound: allow
|
|
|
|
thermostat:
|
|
at: { segment: devices, address: [192.168.30.20] }
|
|
inbound: allow
|
|
|
|
roamer:
|
|
at: { segment: cafe, address: [10.50.3.23] }
|
|
inbound: allow
|