Redraw the Networks diagram and illustrate forward vs input chain (#1049)

* docs: redraw the Networks diagram and illustrate forward vs input chain

Replace the Networks overview image on the Networks and How Routing
Peers Work pages with a redrawn diagram: peers reach a routing peer
through a WireGuard tunnel, and per-resource access policies on the
routing peer allow specific ports, while a resource with no policy is
unreachable. The old footnote referred to Network Routes HA; the new one
describes adding more than one routing peer to a Network.

Replace the ASCII block in "Through the peer, or to the peer?" with a
diagram of the two paths (network resource policy in the forward chain,
peer-to-peer policy in the input chain), and add the same diagram to
"Two chains, two policy types".

The previous image is kept because the Implement Zero Trust page still
uses it.

* docs: use the redrawn Networks diagram on the Implement Zero Trust page

Point the routing peer section at networks-overview.png with descriptive
alt text, and remove netbird-network-routes.png, which nothing references
any more.

* docs: note that the routing peer decrypts traffic before forwarding it

* docs: place the routing peer inside the private network in the Networks diagram

The routing peer is a NetBird client installed inside the private
network, so the diagram now draws it entirely within that network, with
the WireGuard tunnel crossing into it.

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

@@ -37,7 +37,7 @@ NetBird offers two ways to configure routing peers. Both are actively maintained
 ## Mental model: how traffic flows
 
 <p>
-    <img src="/docs-static/img/manage/networks/netbird-network-routes.png" alt="Routing peer bridging NetBird overlay to a private network" className="imagewrapper-big"/>
+    <img src="/docs-static/img/manage/networks/networks-overview.png" alt="Three NetBird peers on the overlay network connect through a WireGuard tunnel to a routing peer in a private network. Access policies on the routing peer allow a database on TCP 5432, a web app on TCP 443, and an RDP workstation on TCP/UDP 3389; a printer with no policy is unreachable." className="imagewrapper-big"/>
 </p>
 
 The walkthrough below describes the **Linux kernel-mode** path, where forwarding and firewalling happen in the kernel via `nftables` / `iptables`. On other platforms, NetBird performs the same logical steps in a userspace filter, but the implementation differs.
@@ -172,6 +172,10 @@ This is the subtlest part of the model and the source of most policy mistakes.
 - **Forward chain.** Packets routed *through* the peer to backend resources. Network resource policies (Networks) and ACL Groups (Routes) apply here.
 - **Input chain.** Packets destined to the routing peer's own IP. [Peer-to-peer policies](/manage/access-control/manage-network-access) apply here.
 
+<p>
+    <img src="/docs-static/img/manage/networks/through-or-to-the-routing-peer.png" alt="Two paths compared. Through the routing peer: a network resource policy, evaluated in the forward chain, lets a client reach a web app behind the routing peer on TCP 443. To the routing peer: a peer-to-peer policy, evaluated in the input chain, lets a client reach SSH on the routing peer's NetBird IP on TCP 22." className="imagewrapper-big"/>
+</p>
+
 If users need to reach both the resources behind a routing peer **and** services running on the routing peer itself (Pi-hole, monitoring, jump-host SSH), you need one policy of each kind.
 
 **Example.** A routing peer fronts the `10.10.0.0/16` office network and also runs Grafana on TCP/3000 plus SSH on TCP/22. To let the `Engineers` group reach both, create two policies:

src/pages/manage/networks/index.mdx

@@ -21,10 +21,10 @@ Throughout this page, a capitalized **Network** means the configuration object y
 If you remember one thing, remember this: **a NetBird Network is a map of part of your infrastructure, drawn onto your overlay network.** The **resources** are the destinations, the **access policies** are the gatekeepers that decide who may pass, and the **routing peers** are the roads that carry traffic to each destination.
 
 <p>
-    <img src="/docs-static/img/manage/networks/netbird-network-routes.png" alt="A NetBird client reaching resources on a private network through a routing peer" className="imagewrapper-big"/>
+    <img src="/docs-static/img/manage/networks/networks-overview.png" alt="Three NetBird peers on the overlay network connect through a WireGuard tunnel to a routing peer in a private network. Access policies on the routing peer allow a database on TCP 5432, a web app on TCP 443, and an RDP workstation on TCP/UDP 3389; a printer with no policy is unreachable." className="imagewrapper-big"/>
 </p>
 
-*Left to right: a peer in a source group clears an access policy, reaches the routing peer, and connects to a resource behind it.*
+*Left to right: peers reach the routing peer through a WireGuard tunnel, and access policies on the routing peer decide which resources behind it each peer can reach. The printer has no policy, so nothing reaches it.*
 
 ## The four building blocks
 
@@ -90,7 +90,7 @@ A network resource policy grants access to the network **behind** the routing pe
 Here is the whole path, end to end:
 
 1. Your client encrypts the packet and sends it through the tunnel to the routing peer.
-2. The routing peer forwards it onto the local network toward the resource.
+2. The routing peer decrypts the packet and forwards it onto the local network toward the resource.
 3. By default the routing peer **masquerades** the traffic, rewriting the source to its own LAN IP, so the destination network needs no awareness of NetBird.
 4. Replies follow the reverse path. The connection is stateful, so return traffic needs no extra policy.
 
@@ -100,13 +100,9 @@ One subtlety causes most policy mistakes. A network resource policy permits traf
 
 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
-
-TO the routing peer        →  input chain    →  peer-to-peer policy
-   your client ──tunnel──► routing peer  (its own SSH, dashboard, …)
-```
+<p>
+    <img src="/docs-static/img/manage/networks/through-or-to-the-routing-peer.png" alt="Two paths compared. Through the routing peer: a network resource policy, evaluated in the forward chain, lets a client reach a web app behind the routing peer on TCP 443. To the routing peer: a peer-to-peer policy, evaluated in the input chain, lets a client reach SSH on the routing peer's NetBird IP on TCP 22." className="imagewrapper-big"/>
+</p>
 
 <Note>
 For the full kernel-level traffic walkthrough, host requirements (IP forwarding, container capabilities), masquerade internals, and the forward-vs-input-chain rule in depth, see [How Routing Peers Work](/manage/networks/how-routing-peers-work).

src/pages/use-cases/security/implement-zero-trust.mdx

@@ -515,7 +515,7 @@ A routing peer is a NetBird peer that:
 - Is selected as a routing peer in a [Network](/manage/networks) or [Network Route](/manage/network-routes) configuration
 
 <p>
-    <img src="/docs-static/img/manage/networks/netbird-network-routes.png" alt="high-level-dia" className="imagewrapper-big"/>
+    <img src="/docs-static/img/manage/networks/networks-overview.png" alt="Three NetBird peers on the overlay network connect through a WireGuard tunnel to a routing peer in a private network. Access policies on the routing peer allow a database on TCP 5432, a web app on TCP 443, and an RDP workstation on TCP/UDP 3389; a printer with no policy is unreachable." className="imagewrapper-big"/>
 </p>
 
 ### 5.2 Direction of traffic with routing peers