68 lines
2.3 KiB
Markdown
68 lines
2.3 KiB
Markdown
---
|
|
title: Homelab Network Architecture
|
|
description: Reference network architecture for a segmented homelab with private access and clear service boundaries
|
|
tags:
|
|
- homelab
|
|
- networking
|
|
- architecture
|
|
category: systems
|
|
created: 2026-03-14
|
|
updated: 2026-03-14
|
|
---
|
|
|
|
# Homelab Network Architecture
|
|
|
|
## Summary
|
|
|
|
A homelab network architecture should separate trust zones, keep administrative paths private, and make service traffic easy to reason about. The goal is not enterprise complexity, but a structure that reduces blast radius and operational confusion.
|
|
|
|
## Why it matters
|
|
|
|
Flat networks are easy to start with and difficult to secure later. A basic segmented design helps isolate management, servers, clients, guest devices, and less trusted endpoints such as IoT hardware.
|
|
|
|
## Core concepts
|
|
|
|
- Segmentation by trust and function
|
|
- Routed inter-VLAN policy instead of unrestricted layer-2 reachability
|
|
- Separate administrative access paths from public ingress
|
|
- DNS and reverse proxy as shared network-facing platform services
|
|
|
|
## Practical usage
|
|
|
|
Example logical layout:
|
|
|
|
```text
|
|
Management -> hypervisors, switches, storage admin
|
|
Servers -> applications, databases, utility VMs
|
|
Clients -> workstations and laptops
|
|
IoT -> low-trust devices
|
|
Guest -> internet-only access
|
|
VPN overlay -> remote access for administrators and approved services
|
|
```
|
|
|
|
This model works well with:
|
|
|
|
- A firewall or router handling inter-segment policy
|
|
- Private access through Tailscale or another VPN
|
|
- Reverse proxy entry points for published applications
|
|
|
|
## Best practices
|
|
|
|
- Keep management services on a dedicated segment
|
|
- Use DNS names and documented routes instead of ad hoc host entries
|
|
- Limit which segments can reach storage, backup, and admin systems
|
|
- Treat guest and IoT networks as untrusted
|
|
|
|
## Pitfalls
|
|
|
|
- Publishing management interfaces through the same path as public apps
|
|
- Allowing lateral access between all segments for convenience
|
|
- Forgetting to document routing and firewall dependencies
|
|
- Relying on multicast-based discovery across routed segments without a plan
|
|
|
|
## References
|
|
|
|
- [RFC 1918: Address Allocation for Private Internets](https://www.rfc-editor.org/rfc/rfc1918)
|
|
- [RFC 4193: Unique Local IPv6 Unicast Addresses](https://www.rfc-editor.org/rfc/rfc4193)
|
|
- [Tailscale: Subnet routers](https://tailscale.com/kb/1019/subnets)
|