homelab: sync post-migration repo and n8n runtime audit
This commit is contained in:
Fizzlepoof
@@ -0,0 +1,249 @@
|
||||
# UniFi Firewall Host-Group Membership Proposal
|
||||
|
||||
Purpose: propose concrete membership for the missing host/device groups referenced by the firewall design, using current repo documentation and the recent UniFi cleanup state. This is a planning artifact only; it does not apply live network changes.
|
||||
|
||||
Evidence used:
|
||||
- `docs/architecture/SERVICES_DIRECTORY.md`
|
||||
- `docs/architecture/NETWORKING_MODEL.md`
|
||||
- `docs/servers/PLAUSIBLEDENABILITY.md`
|
||||
- `docs/servers/SERENITY.md`
|
||||
- `docs/servers/ROCINANTE.md`
|
||||
- `pihole/README.md`
|
||||
- `home/doris-dashboard/docs/unifi-client-cleanup-shortlist-2026-05-22.md`
|
||||
- memory note: UniFi is `10.5.0.1`; PD is `10.5.30.6`; Serenity Pi-hole HA VIP is `10.5.30.53/24`
|
||||
|
||||
## Executive summary
|
||||
|
||||
These groups should be split into three confidence bands:
|
||||
|
||||
- High confidence: safe to define now from documented inventory
|
||||
- Medium confidence: likely right, but validate in UniFi/UI before live enforcement
|
||||
- Low confidence / leave empty for now: do not guess; create the group but keep it empty until a real dependent flow proves it is needed
|
||||
|
||||
## 1. Proposed group membership
|
||||
|
||||
### HOST-ADMIN-TRUSTED
|
||||
Purpose:
|
||||
- devices allowed to initiate management/admin traffic into the Management lane
|
||||
|
||||
Proposed members:
|
||||
- Rocinante trusted endpoint/client
|
||||
- John primary phone: `Pixel-9-Pro-XL`
|
||||
- Optional: `Pixel-7` if you really want phone-based admin
|
||||
|
||||
Do NOT include by default:
|
||||
- `FlyingDutchman`
|
||||
- `steamdeck`
|
||||
- `Valkyrie`
|
||||
- random laptops/TVs/tablets just because they are on Trusted
|
||||
|
||||
Confidence:
|
||||
- Medium
|
||||
|
||||
Reasoning:
|
||||
- the cleanup shortlist says these human/operator devices are intentionally on Trusted
|
||||
- Rocinante is the explicit operator station in the cutover docs
|
||||
- the firewall design says this group should be small and deliberate
|
||||
|
||||
Implementation note:
|
||||
- if UniFi requires IPs instead of clean client objects for this group, resolve the current IP/MACs from live client state before creating the actual group
|
||||
|
||||
### HOST-CORE-SERVICES
|
||||
Purpose:
|
||||
- core homelab service hosts on the Servers lane
|
||||
|
||||
Proposed members:
|
||||
- PlausibleDeniability / PD -> `10.5.30.6`
|
||||
- Serenity -> `10.5.30.5`
|
||||
- N.O.M.A.D. -> `10.5.30.7`
|
||||
- Rocinante -> `10.5.30.112`
|
||||
|
||||
Confidence:
|
||||
- High
|
||||
|
||||
Reasoning:
|
||||
- all four are documented infrastructure hosts
|
||||
- these are the obvious server endpoints repeatedly referenced across the repo
|
||||
|
||||
### HOST-PROTECT-SERVICES
|
||||
Purpose:
|
||||
- target for camera/security devices that need to talk to the Protect/NVR side
|
||||
|
||||
Proposed members:
|
||||
- UDM Pro / UniFi gateway-controller -> `10.5.0.1`
|
||||
|
||||
Confidence:
|
||||
- Medium
|
||||
|
||||
Reasoning:
|
||||
- the docs clearly identify `10.5.0.1` as the UDM Pro / controller
|
||||
- the chimes and doorbell are UniFi Protect accessories
|
||||
- no separate UNVR/NVR host is documented anywhere obvious in the repo inventory
|
||||
|
||||
Caution:
|
||||
- verify in UniFi before hard enforcement whether Protect is actually hosted on the UDM Pro in this environment or whether there is another Protect endpoint not yet documented
|
||||
|
||||
### HOST-DNS
|
||||
Purpose:
|
||||
- approved DNS resolvers for restricted lanes
|
||||
|
||||
Proposed members:
|
||||
- Pi-hole HA VIP -> `10.5.30.53`
|
||||
- Optional explicit backing nodes if you want belt-and-suspenders:
|
||||
- PD Pi-hole primary -> `10.5.30.6`
|
||||
- NOMAD Pi-hole replica admin host -> `10.5.30.7`
|
||||
|
||||
Recommended practical membership:
|
||||
- start with just `10.5.30.53`
|
||||
|
||||
Confidence:
|
||||
- High for VIP
|
||||
- Medium for adding the backing hosts directly
|
||||
|
||||
Reasoning:
|
||||
- the repo explicitly calls `10.5.30.53` the VIP for client DNS
|
||||
- using the VIP keeps the policy clean and decoupled from backend failover details
|
||||
|
||||
### HOST-NTP
|
||||
Purpose:
|
||||
- approved NTP targets for restricted lanes
|
||||
|
||||
Proposed members:
|
||||
- leave empty for now if clients are intended to use public NTP directly
|
||||
|
||||
Alternative if you insist on local NTP later:
|
||||
- add the actual documented local NTP server only after verifying one exists and is intended for clients
|
||||
|
||||
Confidence:
|
||||
- Low / intentionally unresolved
|
||||
|
||||
Reasoning:
|
||||
- the firewall design explicitly says this can be omitted if public NTP is used
|
||||
- the repo docs do not currently provide a clear dedicated client-facing LAN NTP service
|
||||
- the Pi-hole docs explicitly note Pi-hole NTP is disabled on PD because host `chronyd` owns UDP 123, but that alone is not enough proof that PD should become the universal client NTP target
|
||||
|
||||
Recommendation:
|
||||
- for first-pass enforcement, model NTP as outbound internet allowed where needed rather than pretending a local NTP service is definitely part of the design
|
||||
|
||||
### HOST-IOT-HELPERS
|
||||
Purpose:
|
||||
- specific server-side helpers that IoT devices are allowed to contact
|
||||
|
||||
Proposed members for first pass:
|
||||
- Home Assistant on PD -> `10.5.30.6` service port `8123`
|
||||
- Kima Hub on PD -> `10.5.30.6` service port `3333`
|
||||
|
||||
Possible later additions only if proven necessary:
|
||||
- any MQTT broker actually used by IoT devices
|
||||
- any local appliance helper/integration endpoint that demonstrably breaks without local access
|
||||
|
||||
Confidence:
|
||||
- Medium
|
||||
|
||||
Reasoning:
|
||||
- Home Assistant and Kima Hub are the only clearly documented smart-home/helper services in the repo inventory
|
||||
- these are plausible “approved server helpers” for IoT
|
||||
- do not add Plex, Tautulli, or general app hosts here by default just because they exist
|
||||
|
||||
Caution:
|
||||
- no explicit MQTT broker is clearly documented in the current inventory as a central IoT dependency; do not invent one into this group
|
||||
|
||||
### HOST-CAMERA-HELPERS
|
||||
Purpose:
|
||||
- server-side helpers cameras/security devices are allowed to contact beyond pure internet access
|
||||
|
||||
Proposed members:
|
||||
- same initial target as HOST-PROTECT-SERVICES:
|
||||
- UDM Pro / Protect endpoint -> `10.5.0.1`
|
||||
|
||||
Confidence:
|
||||
- Medium
|
||||
|
||||
Reasoning:
|
||||
- until a separate Protect/NVR host is documented, the safest concrete starting point is the documented UniFi gateway/controller
|
||||
|
||||
### HOST-LEGACY-EXCEPTIONS
|
||||
Purpose:
|
||||
- explicit ugly one-off quarantine exceptions for legacy devices
|
||||
|
||||
Proposed members:
|
||||
- none initially; create the group empty
|
||||
|
||||
Confidence:
|
||||
- High for “empty by default”
|
||||
|
||||
Reasoning:
|
||||
- the design explicitly treats Legacy CIA as hospice, not production
|
||||
- there is no documented exception that has already earned inclusion
|
||||
- empty is safer than pretending one-offs are already justified
|
||||
|
||||
## 2. Port-group follow-up proposal
|
||||
|
||||
The firewall gap list noted two useful missing port groups.
|
||||
|
||||
### PORT-PROTECT
|
||||
Proposed status:
|
||||
- define later, only after verifying the actual required Protect ports for chime/doorbell traffic in this environment
|
||||
|
||||
Confidence:
|
||||
- Low now
|
||||
|
||||
Reasoning:
|
||||
- the repo docs do not yet give a trusted exact Protect port list for this design
|
||||
- better to leave broad camera policy undone than to guess wrong and strand security devices
|
||||
|
||||
### PORT-CAST
|
||||
Proposed status:
|
||||
- do not define yet
|
||||
|
||||
Confidence:
|
||||
- High for deferral
|
||||
|
||||
Reasoning:
|
||||
- the design explicitly says cast/discovery rules should only appear after real failure testing
|
||||
- wait for the Google/cast pilot
|
||||
|
||||
## 3. Suggested first-pass implementation set
|
||||
|
||||
If you want the cleanest minimal live enforcement pass later, the least-controversial groups to create/use first are:
|
||||
|
||||
1. `HOST-CORE-SERVICES`
|
||||
- `10.5.30.5`
|
||||
- `10.5.30.6`
|
||||
- `10.5.30.7`
|
||||
- `10.5.30.112`
|
||||
|
||||
2. `HOST-DNS`
|
||||
- `10.5.30.53`
|
||||
|
||||
3. `HOST-ADMIN-TRUSTED`
|
||||
- only the one or two devices John truly admins from
|
||||
|
||||
4. `HOST-PROTECT-SERVICES`
|
||||
- `10.5.0.1` pending verification
|
||||
|
||||
5. `HOST-IOT-HELPERS`
|
||||
- `10.5.30.6` only, if using Home Assistant / Kima Hub as the first-pass helper target
|
||||
|
||||
And leave these empty until proven:
|
||||
- `HOST-NTP`
|
||||
- `HOST-CAMERA-HELPERS` if different from Protect
|
||||
- `HOST-LEGACY-EXCEPTIONS`
|
||||
|
||||
## 4. Validation questions before live rule apply
|
||||
|
||||
Before turning these into real enforced firewall objects, verify:
|
||||
|
||||
1. Which exact Trusted client(s) should truly admin Management?
|
||||
2. Is Protect actually on the UDM Pro at `10.5.0.1`, or is there a separate undocumented host?
|
||||
3. Do IoT devices need Home Assistant and/or Kima Hub locally right now, or can they live on cloud-only plus DNS/internet first?
|
||||
4. Is there a real client-facing local NTP service, or should NTP just be allowed outbound?
|
||||
5. Are there any Legacy CIA one-off exceptions that have actually earned existence? If not, keep that group empty.
|
||||
|
||||
## 5. Blunt recommendation
|
||||
|
||||
If we want a safe first real enforcement pass later:
|
||||
- definitely create/use `HOST-CORE-SERVICES`, `HOST-DNS`, and a very small `HOST-ADMIN-TRUSTED`
|
||||
- probably create `HOST-PROTECT-SERVICES` as `10.5.0.1` after one verification step
|
||||
- treat `HOST-NTP`, `PORT-PROTECT`, and `PORT-CAST` as intentionally unresolved until verified
|
||||
- keep `HOST-LEGACY-EXCEPTIONS` empty unless a specific ugly legacy device proves it needs one
|
||||
Reference in New Issue
Block a user