ea63347cd6
- replace CRA scaffold with Next.js static export config - add app router pages: home, homelab, archive - add components: Nav, Footer, Hero, Skills, ProjectCard, ThemeScript - add ThemeContext for dark mode with FOUC prevention - add data layer: projects.ts, services.ts - update .gitignore for Next.js (ignore .next/, out/, next-env.d.ts) - add docs: handoff plan, homelab decisions, style reference
85 lines
3.1 KiB
Markdown
85 lines
3.1 KiB
Markdown
# DECISIONS
|
|
|
|
# decisions
|
|
|
|
> Short notes on *why* things are configured the way they are.\nYou'll forget this in 6 months. Future-you will thank present-you.\nFormat: title, date, context, decision, alternatives considered.
|
|
|
|
|
|
## AT&T Gateway kept in-line (not bypassed)
|
|
|
|
**Date:** \[date\]
|
|
|
|
**Context:** AT&T Fiber requires 802.1X certificate authentication locked to their gateway hardware. No way to replace it with a standard modem.
|
|
|
|
**Decision:** Keep BGW320 in-line with IP Passthrough mode (DHCPS-fixed to pfSense WAN MAC). pfSense gets the public IP directly. Gateway WiFi disabled.
|
|
|
|
**Alternatives considered:**
|
|
|
|
* EAP proxy bypass — more complex, breaks on AT&T firmware updates, only saves 1-2ms latency. Not worth it.
|
|
* True bridge mode — AT&T gateways don't support it.
|
|
|
|
|
|
## Caddy as reverse proxy with Cloudflare DNS challenge
|
|
|
|
**Date:** \[date\]
|
|
|
|
**Context:** Needed valid SSL certs for all homelab services without exposing port 80/443 to the internet for HTTP challenge validation.
|
|
|
|
**Decision:** Caddy with `caddy-dns/cloudflare` plugin. DNS-01 challenge via Cloudflare API. All subdomains on [lerkolabs.com](http://lerkolabs.com) point to Caddy (10.2.0.20) in Pi-hole. Caddy terminates SSL and proxies to backends.
|
|
|
|
**Alternatives considered:**
|
|
|
|
* Self-signed certs — browser warnings, annoying on mobile/VPN clients.
|
|
* Nginx Proxy Manager — more UI overhead, same result.
|
|
* Traefik — more complex config for the same outcome here.
|
|
|
|
|
|
## WireGuard over OpenVPN
|
|
|
|
**Date:** \[date\]
|
|
|
|
**Context:** Needed remote access to homelab services.
|
|
|
|
**Decision:** WireGuard on pfSense, UDP 51820, VPN subnet 10.200.0.0/24. Clients get same access as LAN for Homelab and MGMT, blocked from Guest/IoT/WFH.
|
|
|
|
**Alternatives considered:**
|
|
|
|
* OpenVPN — slower, more complex config, worse battery on mobile. No advantage here.
|
|
* Tailscale — adds external dependency and relay for what can be direct.
|
|
|
|
|
|
## Pi-hole in Homelab VLAN, not MGMT
|
|
|
|
**Date:** \[date\]
|
|
|
|
**Context:** Pi-hole serves DNS to all VLANs. Needed to decide where to host it.
|
|
|
|
**Decision:** VLAN 1020 (Homelab) at 10.2.0.11. Firewall rules allow port 53 inbound from all VLANs. MGMT VLAN uses pfSense as primary DNS (more reliable for network equipment).
|
|
|
|
**Alternatives considered:**
|
|
|
|
* MGMT VLAN — cleaner separation, but creates firewall complexity allowing all VLANs to reach MGMT.
|
|
* DMZ — no reason to put a DNS server public-facing.
|
|
|
|
|
|
## WFH VLAN uses pfSense DNS only (not Pi-hole)
|
|
|
|
**Date:** \[date\]
|
|
|
|
**Context:** Work laptop on WFH VLAN should be maximally isolated from personal infrastructure.
|
|
|
|
**Decision:** WFH DHCP hands out pfSense (10.5.0.1) as the only DNS server. Work device can't reach Pi-hole at 10.2.0.11 and doesn't need to.
|
|
|
|
|
|
## N100 for pfSense
|
|
|
|
**Date:** \[date\]
|
|
|
|
**Context:** Needed hardware that handles 1Gbps routing + WireGuard VPN without bottlenecking.
|
|
|
|
**Decision:** Intel N100 mini PC. 4-core 3.4GHz, \~6W idle. Handles 2-3Gbps routing, 600-900Mbps WireGuard. Adequate for 1Gbps AT&T fiber with room to grow.
|
|
|
|
**Alternatives considered:**
|
|
|
|
* Raspberry Pi — insufficient for 1Gbps + VPN.
|
|
* Full rack server — overkill power draw for this role. |