docs: recommend Linux routing peers for file-share workloads (#833)

* docs: recommend Linux routing peers for file-share workloads

Add performance guidance to the Active Directory use case (Step 1
placement choice) and a performance trade-off note to Reach Services
on the Routing Peer: Windows/macOS peers process the data path in
userspace, and self-access delivery is slowest for reads, so a
dedicated Linux routing peer is the fast default for SMB/DFS.

* docs: platform-split the self-access performance note

Linux kernel-mode service hosts deliver to their own LAN IP at full
speed; the read-direction penalty is specific to Windows/macOS
userspace hosts.

* docs: scope the AD self-access caveat to Windows file servers

* docs: drop read-direction specifics from performance notes

The directional asymmetry is a suspected client defect under
engineering escalation, not durable documented behavior. Keep only
the kernel-vs-userspace guidance.

* docs: address review — dedupe performance guidance, fix note placement

- AD page: performance point stated once (Step 1 note, linking
  how-routing-peers-work for the mechanism); bullets and recap trimmed;
  Step 1 bullet now carries the Windows qualifier
- reach-services: note compressed to consequence + links, moved below
  The scenario where LAN IP and the shape are defined

src/pages/manage/networks/use-cases/active-directory.mdx

@@ -34,9 +34,13 @@ The domain controller is in almost every step: DNS (steps 1 and 3), the referral
 You rarely install the NetBird client on every server. Pick one of two shapes:
 
 - **A dedicated routing peer at the site.** A separate machine runs the NetBird client and routes to the DC and file servers across the LAN. Natural when shares are spread across several servers.
-- **The file server is the routing peer.** The NetBird client runs on the file server itself; the DC stays clientless behind it. Natural when one file server holds the shares.
+- **The file server is the routing peer.** The NetBird client runs on the file server itself; the DC stays clientless behind it. Saves a machine, but on a Windows server it costs file-transfer performance (see the note below).
 
-Most setups use a dedicated routing peer, and the rest of this guide assumes that. If the file server itself runs the client, only Step 2 changes — reach it via [Reach Services on the Routing Peer](/manage/networks/use-cases/reach-services-on-the-routing-peer) instead — while Steps 3–5 (routing the DC, its ports, and DNS) apply either way.
+Use a dedicated routing peer, and make it a **Linux machine**: a small VM next to the servers is enough. The rest of this guide assumes that. If the file server itself runs the client, only Step 2 changes (reach it via [Reach Services on the Routing Peer](/manage/networks/use-cases/reach-services-on-the-routing-peer) instead), while Steps 3–5 (routing the DC, its ports, and DNS) apply either way.
+
+<Note>
+**Why Linux: performance.** A Linux routing peer forwards traffic in the kernel at almost no cost; Windows and macOS peers process every packet in userspace, which caps file-transfer throughput well below LAN speed and loads the machine (see [How Routing Peers Work](/manage/networks/how-routing-peers-work)). Running the client directly on a Windows file server adds an extra internal delivery step on top. If remote users report documents opening much slower over NetBird than in the office, this choice is the first thing to check.
+</Note>
 
 ## Step 2: Make the file server(s) reachable
 
@@ -149,7 +153,7 @@ Both come from how Windows handles Kerberos logins, not from routing. Avoid them
 
 The whole setup is these pieces — create each one and domain login, shares, and DFS all work:
 
-- **A routing peer** — a peer at the site that routes to the DC and file servers: a dedicated machine, or the file server itself. *(Step 1)*
+- **A routing peer** — a peer at the site that routes to the DC and file servers: a dedicated Linux machine, or the file server itself. *(Step 1)*
 - **A route to the file server** — a Network resource (`/32` or FQDN, e.g. `fileserver1.corp.example.com`) for each share host. *(Step 2)*
 - **A route to the domain controller** — a Network resource (`/32` or `corp.example.com`). *(Step 3)*
 - **An access control policy to the file server** — on **TCP 445** (or whatever the service needs). *(Step 2)*

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

@@ -1,3 +1,5 @@
+import { Note } from '@/components/mdx'
+
 # Reach Services on the Routing Peer
 
 Most routing-peer guides cover reaching resources behind the peer. This one covers the opposite case: reaching a service that runs *on the routing peer itself*, at the peer's own LAN IP — the shape you get when the only machine running the NetBird client *is* the service host. The classic example is a file server that runs NetBird and serves SMB/DFS shares to remote users.
@@ -13,6 +15,10 @@ Remote user ──tunnel──► File server = routing peer  (its own SMB/DFS s
  (NetBird)                         └──► Domain Controller (clientless, on the same LAN)
 ```
 
+<Note>
+**Performance.** On a Linux service host this shape serves at full speed — a Linux file server or NAS can happily be its own routing peer. On Windows and macOS the client's data path runs in userspace, which limits file-transfer throughput; for busy shares on a Windows server, a dedicated Linux routing peer in front is the faster shape (see [Step 1 of the Active Directory guide](/manage/networks/use-cases/active-directory#step-1-decide-where-the-net-bird-client-runs)).
+</Note>
+
 ## The setup
 
 The target *is* the routing peer, addressed by its own LAN IP. Set up the following together: