Publish sanitized current homelab architecture

docs/networking.md

@@ -0,0 +1,69 @@
+# Networking
+
+## Segmentation model
+
+The network uses purpose-specific policy lanes rather than one trusted broadcast domain.
+
+| Lane | Intended occupants | Default posture |
+|---|---|---|
+| **Management** | Gateway, switches, access points, controllers | Administrative access only |
+| **Trusted** | Human-operated laptops, phones, and workstations | May initiate approved internal connections |
+| **Servers** | Application, storage, DNS, and automation hosts | Explicit service exposure |
+| **IoT** | Appliances and embedded clients | Restricted from internal networks by default |
+| **Cameras** | Video and security devices | More restrictive than general IoT |
+| **Guest** | Visitors and temporary clients | Internet only |
+| **Quarantine** | Legacy or unidentified devices | Minimal DNS, time, and internet access |
+| **Lab** | Disposable security and development systems | Default deny toward production |
+
+Exact VLAN identifiers, addressing, SSIDs, and device assignments are intentionally absent from this public repository.
+
+## Policy principles
+
+- Inter-lane access is denied unless a specific workflow requires it.
+- Management interfaces are never reachable from guest, IoT, camera, or lab lanes.
+- IoT exceptions are limited to named services and destinations.
+- Discovery protocols are bridged only when a real use case requires them.
+- DNS, DHCP, and time synchronization are treated as explicit dependencies.
+- A trusted operator path stays available during every network change.
+- Client migrations happen in small batches with rollback after each batch.
+
+## DNS resilience
+
+The lab uses three synchronized internal resolvers:
+
+1. a primary configuration source on the application host
+2. one replica on the offline/resilience host
+3. one replica on the storage host
+
+The replicas receive configuration on a schedule and are verified from another host. External recursive resolvers may provide public-name fallback, but they cannot replace authoritative answers for the private zone.
+
+## Remote access
+
+Two complementary mechanisms are used:
+
+- **Authenticated application ingress:** tunnel gateway → reverse proxy → SSO → selected service
+- **Private administrative overlay:** device-to-device access for operators and private support workflows
+
+Most applications do not expose router-forwarded ports. Protocols that cannot use the HTTP tunnel are handled as narrow, documented exceptions.
+
+## Container networking
+
+Compose projects use named external networks for shared dependencies:
+
+- a data network for databases and caches
+- an ingress network for explicitly published applications
+- optional service-family networks for AI and observability
+
+Applications join only the networks they need. The reverse proxy does not receive unrestricted control of the container runtime.
+
+## Validation gates
+
+After a network change, verify:
+
+1. gateway and controller access from a trusted client
+2. DHCP lease and intended lane placement
+3. private and public DNS answers
+4. the exact application protocol, not only ping
+5. cross-lane allow and deny behavior
+6. recovery after client reassociation or host reboot
+7. absence of broad temporary allow rules