# 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