docs: use images instead of ascii for network use cases

src/pages/manage/networks/use-cases/access-home-devices.mdx

@@ -12,10 +12,9 @@ For the mental model — see [How Routing Peers Work — Mental model](/manage/n
 
 After following this guide, you'll be able to access your home NAS, media server, home automation, or any device on your home network from your laptop or phone—anywhere in the world.
 
-```
-Your Laptop ──────► NetBird Tunnel ──────► Routing Peer ──────► Home NAS
-  (peer)                                    (at home)           (no NetBird)
-```
+<p>
+    <img src="/docs-static/img/manage/networks/use-cases/access-home-devices/architecture.png" alt="Laptop connects through an encrypted NetBird tunnel to a home routing peer and then to a home NAS" className="imagewrapper"/>
+</p>
 
 ## Prerequisites
 

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

@@ -13,10 +13,9 @@ The core idea: a domain-joined client's everyday actions quietly depend on **two
 - the **domain controller (DC)**, for DNS, Kerberos authentication, and DFS namespace referrals;
 - the **file server(s)**, the machines that actually hold the shares.
 
-```
-Remote user ──tunnel──► routing peer ──LAN──► Domain Controller   (DNS, Kerberos, DFS referral)
- (NetBird)                              └─────► File server(s)      (the SMB/DFS share data)
-```
+<p>
+    <img src="/docs-static/img/manage/networks/use-cases/active-directory/architecture.png" alt="Remote NetBird user connects through an encrypted tunnel to a routing peer that reaches a domain controller and file servers on the LAN" className="imagewrapper"/>
+</p>
 
 ## What one mapped drive actually depends on
 

src/pages/manage/networks/use-cases/cloud-to-on-premise.mdx

@@ -12,10 +12,9 @@ For the mental model — see [How Routing Peers Work — Mental model](/manage/n
 
 After following this guide, your cloud applications will be able to securely access on-premise databases, APIs, and services without exposing them to the public internet.
 
-```
-Cloud VM ────► NetBird Tunnel ────► Routing Peer ────► Database Server
-(peer)                               (on-prem)         (no NetBird)
-```
+<p>
+    <img src="/docs-static/img/manage/networks/use-cases/cloud-to-on-premise/architecture.png" alt="Cloud VM connects through an encrypted NetBird tunnel to an on-premise routing peer and then to a database server" className="imagewrapper"/>
+</p>
 
 ## Prerequisites
 

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

@@ -8,10 +8,9 @@ Every peer has two addresses: its **NetBird IP** (its `100.x` overlay address, t
 
 The NetBird client is installed only on the file server, so the file server *is* the routing peer. Remote users resolve the file server's name (and any DFS paths) to its LAN IP — but that address belongs to the routing peer itself, so traffic to it must be *delivered locally on the peer, not forwarded* to a network behind it. The symptom: DNS resolves, yet SMB connections and pings to the file server fail.
 
-```
-Remote user ──tunnel──► File server = routing peer  (its own SMB/DFS share at its LAN IP)
- (NetBird)                         └──► Domain Controller (clientless, on the same LAN)
-```
+<p>
+    <img src="/docs-static/img/manage/networks/use-cases/reach-services-on-the-routing-peer/architecture.png" alt="Remote NetBird user connects through an encrypted tunnel to a file server that is also the routing peer, with a clientless domain controller on the same LAN" className="imagewrapper"/>
+</p>
 
 ## The setup
 

src/pages/manage/networks/use-cases/site-to-site.mdx

@@ -6,14 +6,9 @@ Site-to-Site connects two networks through routing peers at each end. Neither en
 
 ## Architecture
 
-<div className="not-prose w-fit max-w-full">
-
-```
-Site A device ──► Routing Peer ──► NetBird Tunnel ──► Routing Peer ──► Site B device
- (no NetBird)       (peer)                              (peer)         (no NetBird)
-```
-
-</div>
+<p>
+    <img src="/docs-static/img/manage/networks/use-cases/site-to-site/architecture.png" alt="Site A device reaches Site B device through routing peers over an encrypted NetBird tunnel" className="imagewrapper"/>
+</p>
 
 <Note>
 Networks is the recommended way to build site-to-site. It has per-Resource access control, is Zero Trust by default, and is the actively developed system.

src/pages/manage/networks/use-cases/site-to-vpn.mdx

@@ -17,10 +17,9 @@ reach a NetBird peer by its overlay IP or NetBird DNS name. Typical examples:
 - An office printer reporting status to a NetBird-connected management
   application
 
-```
-Clientless Device ──► Routing Peer ──► NetBird Overlay ──► NetBird Peer
-   (no NetBird)         (peer)                              (peer)
-```
+<p>
+    <img src="/docs-static/img/manage/networks/use-cases/site-to-vpn/architecture.png" alt="Clientless device reaches a NetBird peer through a routing peer over an encrypted NetBird tunnel" className="imagewrapper"/>
+</p>
 
 <Warning>
 The routing peer must perform **outbound source NAT** for site traffic