Restructure Troubleshooting into a hub with per-area pages (#814)

* Restructure Troubleshooting into a hub with per-area pages

- Add a Troubleshooting hub (/help/troubleshooting) with icon/chip cards and a "Still stuck?" CTA
- Split NetBird Client troubleshooting into an overview + per-OS pages (Linux, Windows, macOS, Android, iOS)
- Split Self-hosted troubleshooting into an overview + per-area pages (installation, IdP, dashboard, certificates, connectivity, database)
- Split "Report bugs and issues" into Community Support and NetBird Support pages
- Add Troubleshooting resource connectivity and a NetBird Cloud pending-approval page
- Add DNS troubleshooting Issue 8 (Windows NRPT rule blocked by a lingering GPO)
- Cross-reference the new pages from networks, DNS, and reverse-proxy docs; update nav

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

* Address review: client terminology, dead props, labels, cross-links

- Use "client" instead of "agent" across the client troubleshooting pages (headings, prose, anchors)
- Remove unused source: props from the Troubleshooting hub tiles
- Relabel the "NetBird Cloud" grouping to "Cloud & identity" (SSO/provisioning also apply to self-hosted)
- Add a Tiles title on the report-bug landing; add reverse-proxy -> resource-connectivity cross-link
- Fix comma splices introduced by the em-dash cleanup in relayed-connections

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

* Add client-side hash redirect for moved self-hosted anchors

Old deep links like /selfhosted/troubleshooting#debugging-turn-connections now
forward to the per-area page, since next.config redirects can't act on the URL fragment.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

* Apply docs-skill review: conventions + reshape area pages

- "open source" (no hyphen), expand NRPT on first use, descriptive alt text + captions on TURN images
- Fix inherited "Netbird" casing in the client glossary
- Reshape the six self-hosted area pages to Symptom -> likely causes (ordered) -> Fix -> Confirm, preserving anchored headings

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

* Fix two typos in client glossary (CodeRabbit)

- "nunning" -> "running" in the glossary
- possessive "it's" -> "its" in the routing-table sentence

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

* docs: fix two broken links in troubleshooting pages

- database: point the "upgrade path" link at /selfhosted/maintenance/upgrade;
  selfhosted-quickstart has no #upgrade anchor so the old link landed at page top
- client: add HashRedirect so old #net-bird-agent-status deep links forward to
  the renamed #net-bird-client-status section on the same page

* docs: address review follow-ups (deep-link redirects + client casing)

- self-hosted troubleshooting: extend the HashRedirect map with the per-issue
  (###-level) anchors from the old single page, so old deep links land on the
  exact sub-section of the new area page rather than just the page top
- client glossary: lowercase "NetBird client" in the peer-a/peer-b entries
  (house convention) and fix "linux" -> "Linux"

* docs: review polish — fix image class + first-use acronym glosses

- connectivity: fix bad CSS class imagewrapper-nig -> imagewrapper on the
  TURN-test screenshot (the typo'd class matched no style and broke zoom)
- gloss acronyms on first use: GPO (DNS Issue 8), IdP/SSO (identity-provider),
  ACME (certificates), CORS (dashboard)

---------

Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Co-authored-by: Jack Carter <128555021+SunsetDrifter@users.noreply.github.com>

src/pages/manage/dns/troubleshooting.mdx

@@ -6,6 +6,8 @@ export const description = 'Diagnose and fix common DNS issues in NetBird'
 
 This guide helps you diagnose and resolve common DNS issues in NetBird. Follow the structured approach below to identify and fix problems quickly.
 
+If a name resolves correctly but a service behind a routing peer is still unreachable, the problem is past DNS. See [Troubleshooting resource connectivity](/help/troubleshooting-resource-connectivity) to find which layer is dropping the traffic.
+
 <Note>
 The steps below use `ping` to check reachability. `ping` requires an **ICMP** peer-to-peer policy — when testing through or to a [routing peer](/manage/networks/how-routing-peers-work), name resolution and TCP can be healthy while ICMP is simply not allowed by policy. Prefer a TCP port test there: `Test-NetConnection <host> -Port <port>` (Windows) or `nc -z <host> <port>`.
 </Note>
@@ -473,6 +475,37 @@ A domain resource only resolves `A`/`AAAA` records. Active Directory also depend
 
 ---
 
+### Issue 8: Windows NRPT rule is written but never takes effect (lingering GPO)
+
+**Symptoms**:
+- Match-domain names don't resolve on a Windows client, even though `netbird status -d` shows the nameserver as Available and the client log records the NRPT (Name Resolution Policy Table) rule as written.
+- The machine is off-domain (not currently on the company network), often a remote or personal device that was once domain-joined.
+
+**Diagnosis**:
+
+NetBird writes its NRPT rule correctly, but a stale Windows Group Policy Object (GPO) `DnsPolicyConfig` container forces the rule into the *policy* store. On an off-domain machine Windows does not apply policy-store NRPT rules, so the rule exists but is never effective. The write succeeds while Windows quietly drops it from resolution.
+
+From a [debug bundle](/help/troubleshooting-client#debug-bundle), `client.log` and the matching entry in `state.json` show whether the NetBird client detected a GPO in place.
+
+Then compare the rule NetBird wrote against what Windows is actually applying (PowerShell):
+
+```powershell
+Get-DnsClientNrptRule                # the rule NetBird wrote
+Get-DnsClientNrptPolicy -Effective   # what Windows is actually applying
+```
+
+If the rule appears in `Get-DnsClientNrptRule` but not in the `-Effective` output, a lingering GPO container is blocking it.
+
+**Solutions**:
+
+This is a Windows Group Policy state issue, not a NetBird misconfiguration, and the fix has to happen locally:
+- Have local IT clear the stale `DnsPolicyConfig` GPO container from the machine's registry, or
+- Connect the machine to the company network and run `gpupdate /force` so Windows reconciles and removes the lingering container.
+
+NetBird cannot remove a Group Policy container from the client side.
+
+---
+
 ## Verifying Configuration
 
 ### Public nameservers

src/pages/manage/networks/how-routing-peers-work.mdx

@@ -213,6 +213,8 @@ Specifics:
 
 ## Observability and troubleshooting
 
+When a peer is `Connected` but a resource behind it is still unreachable, [Troubleshooting resource connectivity](/help/troubleshooting-resource-connectivity) walks these checks in order, from the peer through to the TCP handshake at the resource.
+
 - `netbird status -d` shows the connection type, status, and details for every peer the client is connected to.
 - `netbird networks ls` shows which networks the client is currently using.
 - `netbird debug trace` simulates a packet against the firewall rules without sending real traffic. Useful when policies look right but traffic is dropped. On Linux this is most informative when the kernel firewall backend is active.

src/pages/manage/networks/index.mdx

@@ -98,6 +98,8 @@ Here is the whole path, end to end:
 
 One subtlety causes most policy mistakes. A network resource policy permits traffic *through* the routing peer to the resources behind it: the routing peer's **forward chain**. Reaching a service running *on* the routing peer itself (SSH, a dashboard) is the **input chain**, and that needs a separate peer-to-peer [access policy](/manage/access-control) with the routing peer's group as the destination. If users need both, create one policy of each kind.
 
+If a resource stays unreachable even though the policy looks right, [Troubleshooting resource connectivity](/help/troubleshooting-resource-connectivity) helps you find which layer is dropping the traffic.
+
 ```
 THROUGH the routing peer  →  forward chain  →  network resource policy
    your client ──tunnel──► routing peer ──────► resource behind it

src/pages/manage/networks/use-cases/reach-services-on-the-routing-peer.mdx

@@ -37,6 +37,7 @@ With these in place, a mapped drive to the share works unchanged — reached at
 
 - Test reachability with `Test-NetConnection <host> -Port <port>` (or `nc -z`), not `ping`. ICMP needs its own peer-to-peer policy; a service working while `ping` fails is the signature of a missing ICMP policy, not a broken route.
 - The service should now answer at the routing peer's LAN IP over the tunnel — for a file server, a mapped drive opens unchanged.
+- Still unreachable? [Troubleshooting resource connectivity](/help/troubleshooting-resource-connectivity) isolates whether the problem is DNS, the route, the policy, forwarding on the peer, or the service itself.
 
 ## Fallback: resolve the name to the NetBird IP
 

src/pages/manage/reverse-proxy/troubleshooting.mdx

@@ -6,6 +6,8 @@ export const description = 'Troubleshoot common reverse proxy issues like 502 er
 
 This guide helps you diagnose and resolve common reverse proxy issues in NetBird. Follow the structured approach below to identify and fix problems quickly.
 
+If a service behind a routing peer is unreachable in general (not specific to the reverse proxy), see [Troubleshooting resource connectivity](/help/troubleshooting-resource-connectivity) to find which layer is dropping the traffic.
+
 ## Quick Diagnostics Checklist
 
 Before diving deep, run through this quick checklist: