homelab-network-readiness

The homelab-network-readiness skill is a readiness checklist for homelab VLAN segmentation, local DNS filtering, and WireGuard-style remote access, meant to be used before changing router, firewall, DHCP, or VPN configuration. It is a planning and review skill, deliberately not a source of copy-paste router, firewall, or VPN commands unless the target platform, current topology, rollback path, console access, and maintenance window are all known. Its aim is to turn an informal home-network idea into a staged migration plan with validation evidence while preventing changes that could lock the operator out of the gateway, switch, access point, DNS server, or VPN server.

The skill enforces safety rules such as keeping the first answer read-only (inventory, risks, staged plan, validation, and rollback), never exposing admin panels or management UIs to the public internet, and requiring out-of-band or same-room console access before changing management VLANs, trunk ports, firewall default policies, or DHCP/DNS settings. It provides a required inventory table (internet edge, gateway, switching, Wi-Fi, addressing, DNS/DHCP, management, recovery), a VLAN and trust-zone plan spanning Trusted, Servers, IoT, Guest, Management, and VPN zones, and readiness sections for DNS filtering (Pi-hole, AdGuard Home, Unbound) and remote access (WireGuard, Tailscale, ZeroTier, OpenVPN). It includes concrete validation evidence to collect, such as confirming a client gets the expected DHCP lease and DNS resolver, that public and local home.arpa lookups succeed, and that admin interfaces are not reachable from guest or IoT networks.

This skill targets home-lab and small-lab operators preparing changes to networks that mix VLANs, local DNS resolvers, firewall rules, and remote VPN access. It prescribes a change sequence favoring small reversible steps — snapshot current state, reserve infrastructure addresses, create zones without moving critical devices, validate one test client, add narrow firewall exceptions, then move device groups and add VPN access last. It also lists a review checklist and anti-patterns (such as segmenting before knowing which ports and SSIDs carry which VLANs, or pointing all DHCP scopes at a Pi-hole before testing fallback DNS). Stated requirements before implementation steps include a confirmed platform, known topology, documented rollback, and maintenance window.