feat: add Routing Peer Access Policies diagram

Author: nazarewk

public/docs-static/img/how-to-guides/routing-peer-policies.drawio.png

@@ -73,6 +73,28 @@ See the example below with a policy that allows the group `Berlin Office` to acc
     Policies for domains or wildcard domains applied to peers with IP ranges might influence access control for those peers, as their destination ranges include any IPs. Therefore, we recommend creating networks with routing peers dedicated to domain and wildcard domains to prevent unwanted access. In upcoming releases, we will provide a fix for this behavior.
 </Note>
 
+### Managing access to and through the Routing Peers
+
+Routing Peer's local IP address is managed in line with the standard Operating System network access management.
+Access to Resources accessible from behind the Routing Peer is managed independently of the access to the services
+running directly on the Routing Peer, even if the locally assigned IP address overlaps with the routed network range.
+
+This means:
+- you might observe seemingly "random" results depending on which Routing Peer is handling your requests,
+- access to Resources does not require access to the Routing Peer itself,
+  - this will still establish connectivity to the Routing Peer (eg: in `netbird status -d`), but any traffic destined
+    for the Routing Peer will be denied,
+- access to the Routing Peer's local IP address needs to be explicitly allowed,
+- you can access _other_ Routing Peers in HA group by their local IP addresses, because they are now effectively
+  remote IP addresses,
+
+Following diagram explains the differences visually with red/green color denoting Access Policies governing
+the specific connections:
+
+<p>
+    <img src="/docs-static/img/how-to-guides/routing-peer-policies.drawio.png" alt="routing-peer-policies" className="imagewrapper-big"/>
+</p>
+
 ## Enable DNS wildcard routing
 When you configure wildcard domains as resources, you need to enable DNS wildcard routing. Which has an additional effect in comparison to the previous DNS routes behavior from Network routes; it switches the DNS resolution to the routing peer instead of the local client system.
 This is also useful for regular DNS routes when you want to resolve the domain names using the routing peer's IP infrastructure, which will allow for more restricted access control rules in newer versions of the clients (**1**) and for the traffic to go to a near routing peer service.