sync: auto-sync from GURU-5070 at 2026-06-23 07:57:32

Author: Mike Swanson
Machine: GURU-5070
Timestamp: 2026-06-23 07:57:32
This commit is contained in:
2026-06-23 07:58:24 -07:00
parent 3e414c1572
commit 5f30e1154a
8 changed files with 217 additions and 3 deletions

View File

@@ -30,6 +30,7 @@
- [reference_backblaze_storage_rate](reference_backblaze_storage_rate.md) -- ACG's Backblaze B2 storage cost rate ($0.00695/GB) for the GuruRMM mspbackups storage-cost calculation
- [Unraid VM no-IP causes](unraid-windows-vm-virtio-no-ip.md) — PRIMARY (general "new VMs stopped getting IPs lately"): Docker sets bridge-nf-call-iptables=1, so br0 VM DHCP OFFERs hit DOCKER-FORWARD (no br0 ACCEPT) and get dropped; new VMs can't complete DORA (existing renew via ESTABLISHED). Fix `=0` runtime (needs persistent post-Docker hook; not yet persisted on Jupiter). SECONDARY (Windows VM): virtio-net has no in-box driver -> use e1000 or virtio-win. Diagnose: tcpdump DHCP on pfSense; /sys vnetN rx_packets.
- [Starr Pass mail routing](reference_starrpass_mail_routing.md) — starrpass.com is DIRECT to MS (EOP/Defender, tenant 222450dd…); only devconllc.com is on Mailprotector (MP acct 16170). Check @starrpass.com quarantine/rejects via remediation-tool, not Mailprotector.
- [INKY outbound breaks DMARC](reference_inky_outbound_breaks_dmarc.md) — Reverse-resolve DMARC rua failing IPs before blaming a sender: ipw-outbound.inkyphishfence.com / us.cloud-sec-av.com = INKY re-injection breaking DKIM+SPF. INKY is in-M365 (connectors+transport rules) per enrolled tenant, but hosting-level (IX/cPanel website) outbound also routes through it independent of M365 enrollment. Fix is INKY-side (outbound DKIM/SPF/ARC), not cPanel DNS.
- [AAD Connect msDS-KeyCredentialLink writeback](reference_aadconnect_keycredlink_writeback.md) — "completed-export-errors" + 8344 INSUFF_ACCESS_RIGHTS on a protected admin account = WHfB key writeback blocked by AdminSDHolder. Diagnose with csexport /f:x; fix with dsacls WP;msDS-KeyCredentialLink on AdminSDHolder + SDProp.
- [UniFi Site Manager cloud API](reference_unifi_site_manager_api.md) — `api.ui.com` + `X-API-KEY` (vault `services/unifi-site-manager`) = remote access to the WHOLE ACG UniFi fleet (~36 consoles) outside UOS. Tier1 `/v1/hosts|sites|devices|isp-metrics` = inventory+health+WAN. Tier2 CONNECTOR `/v1/connector/consoles/{id}/proxy/network/api/s/default/stat/{device,sta}` = **full UOS parity** (per-radio cu_total airtime + per-client RSSI) for ANY console, remote. Backend `unifi-wifi/scripts/gw-sitemanager.sh` (`fleet|devices|sites|isp|net`). Standalone UDM WAN SSH usually firewalled; per-console SSH pw at `clients/<slug>/udm-ssh`.
- [reference_sqlx_migrations_immutable](reference_sqlx_migrations_immutable.md) -- NEVER edit an already-applied sqlx migration file — even a comment. sqlx::migrate! checksums each file at compile time and validates against _sqlx_migrations at startup; a changed checksum crash-loops the server with "migration N was previously applied but has been modified". Code review MUST flag any edit to an applied migration.

View File

@@ -0,0 +1,14 @@
---
name: reference-inky-outbound-breaks-dmarc
description: INKY/GuruProtect outbound re-injection breaks DMARC alignment; reverse-resolve DMARC report source IPs before attributing failures
metadata:
type: reference
---
When analyzing DMARC aggregate (rua) reports, **reverse-resolve every failing source IP before attributing a failure to a sender.** Multiple ACG client failures (glaztech.com p=reject, cryoweave.com p=quarantine) traced not to the apps/websites first assumed, but to **INKY (GuruProtect)** outbound: PTRs `ipw-outbound.inkyphishfence.com` and `us.cloud-sec-av.com` (AWS IP pools 3.x / 34.210.x / 35.174.x / 100.2x.x).
**Mechanism:** INKY receives an already-signed message (M365 `selector1` or cPanel `default` DKIM), **modifies the body** (GuruProtect banner / link rewrite), then re-sends from its own IPs. Body change breaks the original DKIM; INKY IPs aren't in the domain's SPF → SPF fails too → DMARC fails. So a domain can be 99% aligned and still show a steady trickle of INKY-origin fails.
**INKY topology (per Mike, 2026-06-23):** INKY is installed *directly into M365* via connectors + transport rules per enrolled tenant — NOT an external-only relay. So check tenant enrollment. NOTE: cryoweave M365 is **NOT** enrolled in INKY, yet cryoweave.com mail still appeared from INKY outbound IPs — that traffic is the **IX/cPanel website** (WordPress, `envelope=ix.azcomputerguru.com`, cPanel `default` DKIM) whose *hosting-level* outbound routes through INKY, independent of the M365 tenant. Don't assume "INKY fail" == "tenant on INKY."
**Fix is INKY-side, not DNS-blind:** republishing cPanel DKIM or adding the web server to SPF will NOT fix it (INKY breaks the sig downstream and the mail comes from INKY's IP, not the web server's). Real options: enable INKY outbound DKIM signing per domain, add INKY's SPF include, or ARC — or route low-volume app/website mail through an authenticated M365 SMTP path so it aligns directly. See [[feedback-dmarc-rua-inky-onboarded-only]].