Hiddenden/Knowledge-Base
2
0
Fork 0
Code Issues 2 Pull Requests Actions Packages Projects Releases Wiki Activity

first version of the knowledge base :)

Browse Source
This commit is contained in:
Latte
2026-03-14 11:41:54 +01:00
commit 27965301ad
47 changed files with 4356 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

66
20 - Knowledge/networking/dns-architecture.md Normal file
View File

@@ -0,0 +1,66 @@
---
title: DNS Architecture
description: Core DNS architecture patterns for self-hosted and homelab environments
tags:
- dns
- networking
- infrastructure
category: networking
created: 2026-03-14
updated: 2026-03-14
---
# DNS Architecture
## Summary
DNS architecture defines how names are assigned, resolved, delegated, and operated across internal and external systems. In self-hosted environments, good DNS design reduces configuration drift, improves service discoverability, and simplifies remote access.
## Why it matters
DNS is a foundational dependency for reverse proxies, TLS, service discovery, monitoring, and operator workflows. Weak DNS design creates brittle systems that depend on hard-coded IP addresses and manual recovery steps.
## Core concepts
- Authoritative DNS: the source of truth for a zone
- Recursive resolution: the process clients use to resolve names
- Internal DNS: records intended only for private services
- Split-horizon DNS: different answers depending on the client context
- TTL: cache lifetime that affects propagation and change speed
## Practical usage
A practical self-hosted DNS model often includes:
- Public DNS for internet-facing records
- Internal DNS for management and private services
- Reverse proxy hostnames for application routing
- Stable names for infrastructure services such as hypervisors, backup targets, and monitoring systems
Example record set:
```text
proxy.example.net A 198.51.100.20
grafana.internal.example A 192.0.2.20
gitea.internal.example CNAME proxy.internal.example
```
## Best practices
- Use DNS names instead of embedding IP addresses in application config
- Separate public and private naming where trust boundaries differ
- Keep TTLs appropriate for the change rate of the record
- Treat authoritative DNS as critical infrastructure with backup and access control
## Pitfalls
- Reusing the same name for unrelated services over time
- Forgetting that split DNS can confuse troubleshooting if undocumented
- Leaving DNS ownership unclear across platforms and providers
- Building service dependencies on local `/etc/hosts` entries
## References
- [Cloudflare Learning Center: What is DNS?](https://www.cloudflare.com/learning/dns/what-is-dns/)
- [RFC 1034: Domain Concepts and Facilities](https://www.rfc-editor.org/rfc/rfc1034)
- [RFC 1035: Domain Implementation and Specification](https://www.rfc-editor.org/rfc/rfc1035)

131
20 - Knowledge/networking/homelab-network-segmentation.md Normal file
View File

@@ -0,0 +1,131 @@
---
title: Network Segmentation for Homelabs
description: Practical network segmentation patterns for separating trust zones in a homelab
tags:
- networking
- security
- homelab
category: networking
created: 2026-03-14
updated: 2026-03-14
---
# Network Segmentation for Homelabs
## Introduction
Network segmentation reduces blast radius by separating devices and services into smaller trust zones. In a homelab, this helps isolate management systems, user devices, public services, and less trusted endpoints such as IoT equipment.
## Purpose
Segmentation is useful for:
- Limiting lateral movement after a compromise
- Keeping management interfaces off general user networks
- Isolating noisy or untrusted devices
- Applying different routing, DNS, and firewall policies per zone
## Architecture Overview
A practical homelab usually benefits from separate L3 segments or VLANs for at least the following areas:
- Management: hypervisors, switches, storage admin interfaces
- Servers: application VMs, container hosts, databases
- Clients: laptops, desktops, mobile devices
- IoT: cameras, media devices, printers, controllers
- Guest: devices that should only reach the internet
- Storage or backup: optional dedicated replication path
Example layout:
```text
VLAN 10 Management 192.168.10.0/24
VLAN 20 Servers 192.168.20.0/24
VLAN 30 Clients 192.168.30.0/24
VLAN 40 IoT 192.168.40.0/24
VLAN 50 Guest 192.168.50.0/24
```
Traffic should pass through a firewall or router between zones instead of being bridged freely.
## Design Guidelines
### Segment by trust and function
Start with simple boundaries:
- High trust: management, backup, secrets infrastructure
- Medium trust: internal application servers
- Lower trust: personal devices, guest devices, consumer IoT
### Route between zones with policy
Use inter-VLAN routing with explicit firewall rules. Default deny between segments is easier to reason about than a flat network with ad hoc exceptions.
### Use DNS intentionally
- Give internal services stable names
- Avoid exposing management DNS records to guest or IoT segments
- Consider split DNS for remote access through Tailscale or another VPN
### Minimize overlap
Use clean RFC 1918 address plans and document them. Overlapping subnets complicate VPN routing, container networking, and future site expansion.
## Configuration Example
Example policy intent for a firewall:
```text
Allow Clients -> Servers : TCP 80,443
Allow Management -> Servers : any
Allow Servers -> Storage : TCP 2049,445,3260 as needed
Deny IoT -> Management : any
Deny Guest -> Internal RFC1918 ranges : any
```
Example address planning notes:
```text
192.168.10.0/24 Management
192.168.20.0/24 Server workloads
192.168.30.0/24 User devices
192.168.40.0/24 IoT
192.168.50.0/24 Guest
fd00:10::/64 IPv6 management ULA
```
## Troubleshooting Tips
### Service works from one VLAN but not another
- Check the inter-VLAN firewall rule order
- Confirm DNS resolves to the intended internal address
- Verify the destination service is listening on the right interface
### VPN users can reach too much
- Review ACLs or firewall policy for routed VPN traffic
- Publish only the required subnets through subnet routers
- Avoid combining management and user services in the same routed segment
### Broadcast-dependent services break across segments
- Use unicast DNS or service discovery where possible
- For mDNS-dependent workflows, consider a reflector only where justified
- Do not flatten the network just to support one legacy discovery method
## Best Practices
- Keep management on its own segment from the beginning
- Treat IoT and guest networks as untrusted
- Document every VLAN, subnet, DHCP scope, and routing rule
- Prefer L3 policy enforcement over broad L2 access
- Revisit segmentation when new services expose public endpoints or remote admin paths
## 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)
- [Tailscale: Access controls](https://tailscale.com/kb/1018/acls)

123
20 - Knowledge/networking/tailscale-overview.md Normal file
View File

@@ -0,0 +1,123 @@
---
title: Tailscale Overview
description: Conceptual overview of how Tailscale works and where it fits in a homelab or engineering environment
tags:
- networking
- tailscale
- vpn
category: networking
created: 2026-03-14
updated: 2026-03-14
---
# Tailscale Overview
## Introduction
Tailscale is a mesh VPN built on WireGuard. It provides secure connectivity between devices without requiring a traditional hub-and-spoke VPN concentrator for day-to-day traffic. In practice, it is often used to reach homelab services, administrative networks, remote workstations, and private developer environments.
## Purpose
The main purpose of Tailscale is to make private networking easier to operate:
- Identity-based access instead of exposing services directly to the internet
- Encrypted device-to-device connectivity
- Simple onboarding across laptops, servers, phones, and virtual machines
- Optional features for routing subnets, advertising exit nodes, and publishing services
## Architecture Overview
Tailscale separates coordination from data transfer.
- Control plane: devices authenticate to Tailscale and exchange node information, keys, policy, and routing metadata
- Data plane: traffic is encrypted with WireGuard and sent directly between peers whenever possible
- Relay fallback: when direct peer-to-peer connectivity is blocked, traffic can traverse DERP relays
Typical flow:
```text
Client -> Tailscale control plane for coordination
Client <-> Peer direct WireGuard tunnel when possible
Client -> DERP relay -> Peer when direct connectivity is unavailable
```
Important components:
- Tailnet: the private network that contains your devices and policies
- ACLs or grants: rules that control which identities can reach which resources
- Tags: non-human identities for servers and automation
- MagicDNS: tailnet DNS names for easier service discovery
- Subnet routers: devices that advertise non-Tailscale LAN routes
- Exit nodes: devices that forward default internet-bound traffic
## Core Concepts
### Identity first
Tailscale access control is tied to users, groups, devices, and tags rather than only source IP addresses. This works well for environments where laptops move between networks and services are distributed across cloud and on-prem hosts.
### Peer-to-peer by default
When NAT traversal succeeds, traffic goes directly between devices. This reduces latency and avoids creating a permanent bottleneck on one VPN server.
### Overlay networking
Each device keeps its normal local network connectivity and also gains a Tailscale address space. This makes it useful for remote administration without redesigning the entire local network.
## Configuration Example
Install and authenticate a Linux node:
```bash
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up
tailscale status
```
Advertise the node as infrastructure with a tag:
```bash
sudo tailscale up --advertise-tags=tag:server
```
## Operational Notes
- Use ACLs or grants early instead of leaving the entire tailnet flat
- Use tags for servers, containers, and automation agents
- Prefer MagicDNS or split DNS over hard-coded IP lists
- Treat subnet routers and exit nodes as infrastructure roles with extra review
## Troubleshooting
### Device is connected but cannot reach another node
- Check whether ACLs or grants allow the connection
- Confirm the target device is online with `tailscale status`
- Verify the service is listening on the expected interface and port
### Traffic is slower than expected
- Confirm whether the connection is direct or using DERP
- Inspect firewall and NAT behavior on both sides
- Check whether the path crosses an exit node or subnet router unnecessarily
### DNS names do not resolve
- Verify MagicDNS is enabled
- Check the client resolver configuration
- Confirm the hostname exists in the tailnet admin UI
## Best Practices
- Use identity-based policies and avoid broad any-to-any access
- Separate human users from infrastructure with groups and tags
- Limit high-trust roles such as subnet routers and exit nodes
- Document which services are intended for tailnet-only access
- Keep the local firewall enabled; Tailscale complements it rather than replacing it
## References
- [Tailscale: What is Tailscale?](https://tailscale.com/kb/1151/what-is-tailscale)
- [Tailscale: How NAT traversal works](https://tailscale.com/blog/how-nat-traversal-works)
- [Tailscale: Access controls](https://tailscale.com/kb/1018/acls)
- [Tailscale: MagicDNS](https://tailscale.com/kb/1081/magicdns)