70 lines
3.1 KiB
Markdown
70 lines
3.1 KiB
Markdown
# 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
|