feat: new page dedicated to Networks access management

Author: nazarewk

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

@@ -1,6 +1,6 @@
 <mxfile host="Electron" agent="Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) draw.io/26.1.1 Chrome/138.0.7204.100 Electron/37.2.2 Safari/537.36" version="26.1.1">
   <diagram name="Page-1" id="cSO_DhjBtIs-y8T3Yu-b">
-    <mxGraphModel dx="721" dy="1030" grid="0" gridSize="10" guides="1" tooltips="1" connect="1" arrows="1" fold="1" page="0" pageScale="1" pageWidth="827" pageHeight="1169" background="#18181B" math="0" shadow="0">
+    <mxGraphModel dx="1046" dy="1493" grid="0" gridSize="10" guides="1" tooltips="1" connect="1" arrows="1" fold="1" page="0" pageScale="1" pageWidth="827" pageHeight="1169" background="#18181B" math="0" shadow="0">
       <root>
         <mxCell id="0" />
         <mxCell id="1" parent="0" />
@@ -125,7 +125,7 @@
         <mxCell id="tk96eruObW772T1n_iph-25" value="100.XX.1.123" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=10;fontColor=#FFFFFF;" parent="1" vertex="1">
           <mxGeometry x="122" y="491.67" width="60" height="30" as="geometry" />
         </mxCell>
-        <mxCell id="kU3IDCsIoFBLPOvx1m8k-9" value="" style="shape=image;verticalLabelPosition=bottom;verticalAlign=top;imageAspect=0;aspect=fixed;image=data:image/svg+xml,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIGZpbGw9Im5vbmUiIHZpZXdCb3g9IjAgMCA4MCA1OCIgaGVpZ2h0PSI1OCIgd2lkdGg9IjgwIj4mI3hhOyAgICA8cmVjdCBoZWlnaHQ9IjUzIiB3aWR0aD0iNzUiIHk9IjIuNSIgeD0iMi41Ii8+JiN4YTsgICAgPHBhdGggZmlsbD0iI0Y2ODMzMCIgZD0iTTgwIDU4TDc0LjYzNTEgNDAuODQyOVYwSDUuMzY0ODhWMzkuNjI4M0wwIDU4SDgwWk0yLjIwOTA2IDU2LjQ4MTdMNi42MjcxOSA0MS4xNDY2SDczLjA1NzJMNzcuNzkwOSA1Ni40ODE3SDIuMjA5MDZaTTYuOTQyNzkgMS41MTgzMkg3My4wNTcyVjM5LjYyODNINi45NDI3OVYxLjUxODMyWiIvPiYjeGE7ICAgIDxwYXRoIGZpbGw9IiNGNjgzMzAiIGQ9Ik00Ny4wMjE5IDUyLjY4NkgzMi45Nzg1VjU0LjIwNDRINDcuMDIxOVY1Mi42ODZaIi8+JiN4YTsgICAgPHBhdGggZmlsbD0iI0Y2ODMzMCIgZD0iTTQ0Ljg5NzMgMTIuMzgxOEM0Mi4yNDI2IDEyLjYyNTkgNDAuOTIxMyAxNC4xNTcxIDQwLjQyMjEgMTQuOTMxOUwzMi42NjUgMjguMzk2MUg0Mi4wMjM0TDUxLjI1MzkgMTIuMzgxOEg0NC44OTczWiIvPiYjeGE7ICAgIDxwYXRoIGZpbGw9IiNGNjgzMzAiIGQ9Ik00Mi4wMzA1IDI4LjM5NjJMMjkuMjY4NiAxNC44MzQzQzI5LjI2ODYgMTQuODM0MyA0My42OTg4IDEwLjk0ODIgNDUuMTA1MyAyMy4wNzAzTDQyLjAzMDUgMjguMzk2MloiLz4mI3hhOyAgICA8cGF0aCBmaWxsPSIjRjM1RTMyIiBkPSJNNDAuMTM0OCAxNS40MzM4TDM2LjIxOTcgMjIuMjNMNDIuMDIyMyAyOC4zOTc4TDQ1LjA5NzEgMjMuMDU5N0M0NC42MSAxOC44OTI5IDQyLjU4MjQgMTYuNjE3NCA0MC4xMzQ4IDE1LjQyNzciLz4mI3hhOzwvc3ZnPg==;" parent="1" vertex="1">
+        <mxCell id="kU3IDCsIoFBLPOvx1m8k-9" value="User" style="shape=image;verticalLabelPosition=top;verticalAlign=bottom;imageAspect=0;aspect=fixed;image=data:image/svg+xml,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIGZpbGw9Im5vbmUiIHZpZXdCb3g9IjAgMCA4MCA1OCIgaGVpZ2h0PSI1OCIgd2lkdGg9IjgwIj4mI3hhOyAgICA8cmVjdCBoZWlnaHQ9IjUzIiB3aWR0aD0iNzUiIHk9IjIuNSIgeD0iMi41Ii8+JiN4YTsgICAgPHBhdGggZmlsbD0iI0Y2ODMzMCIgZD0iTTgwIDU4TDc0LjYzNTEgNDAuODQyOVYwSDUuMzY0ODhWMzkuNjI4M0wwIDU4SDgwWk0yLjIwOTA2IDU2LjQ4MTdMNi42MjcxOSA0MS4xNDY2SDczLjA1NzJMNzcuNzkwOSA1Ni40ODE3SDIuMjA5MDZaTTYuOTQyNzkgMS41MTgzMkg3My4wNTcyVjM5LjYyODNINi45NDI3OVYxLjUxODMyWiIvPiYjeGE7ICAgIDxwYXRoIGZpbGw9IiNGNjgzMzAiIGQ9Ik00Ny4wMjE5IDUyLjY4NkgzMi45Nzg1VjU0LjIwNDRINDcuMDIxOVY1Mi42ODZaIi8+JiN4YTsgICAgPHBhdGggZmlsbD0iI0Y2ODMzMCIgZD0iTTQ0Ljg5NzMgMTIuMzgxOEM0Mi4yNDI2IDEyLjYyNTkgNDAuOTIxMyAxNC4xNTcxIDQwLjQyMjEgMTQuOTMxOUwzMi42NjUgMjguMzk2MUg0Mi4wMjM0TDUxLjI1MzkgMTIuMzgxOEg0NC44OTczWiIvPiYjeGE7ICAgIDxwYXRoIGZpbGw9IiNGNjgzMzAiIGQ9Ik00Mi4wMzA1IDI4LjM5NjJMMjkuMjY4NiAxNC44MzQzQzI5LjI2ODYgMTQuODM0MyA0My42OTg4IDEwLjk0ODIgNDUuMTA1MyAyMy4wNzAzTDQyLjAzMDUgMjguMzk2MloiLz4mI3hhOyAgICA8cGF0aCBmaWxsPSIjRjM1RTMyIiBkPSJNNDAuMTM0OCAxNS40MzM4TDM2LjIxOTcgMjIuMjNMNDIuMDIyMyAyOC4zOTc4TDQ1LjA5NzEgMjMuMDU5N0M0NC42MSAxOC44OTI5IDQyLjU4MjQgMTYuNjE3NCA0MC4xMzQ4IDE1LjQyNzciLz4mI3hhOzwvc3ZnPg==;fontColor=#FFFFFF;labelPosition=center;align=center;" parent="1" vertex="1">
           <mxGeometry x="126.19" y="454.24" width="51.62" height="37.43" as="geometry" />
         </mxCell>
       </root>

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

@@ -120,6 +120,7 @@ export const docsNavigation = [
               isOpen: false,
               links: [
                   { title: 'Concept', href: '/how-to/networks' },
+                  { title: 'Networks access management', href: '/how-to/networks-access-management'},
                   { title: 'Routing traffic to multiple IP resources', href: '/how-to/routing-traffic-to-multiple-resources' },
                   { title: 'Accessing restricted website domain resources', href: '/how-to/accessing-restricted-domain-resources' },
                   { title: 'Accessing entire domains within networks', href: '/how-to/accessing-entire-domains-within-networks' },

src/components/NavigationDocs.jsx

@@ -0,0 +1,96 @@
+# Networks access management
+
+To manage access to and through the Routing Peers in Networks it is essential to understand that in the
+standard operating system networking model IP addresses assigned directly to the device are handled differently and
+independently of addresses behind it (aka routed/forwarded addresses).
+This currently also holds true in context of NetBird's Networks and Routing Peers access management:
+
+- IP address attached directly to any of the client's local interfaces is NOT considered being routed/forwarded
+  and is policed by the device's rules. In context of NetBird those are the Access Policies naming any of
+  the Routing Peer's Groups as the destination:
+  - this holds true especially when the address overlaps with the routed network's range,
+- all the other IP addresses from the network range are considered being routed/forwarded and are governed by separate
+  set of rules. In NetBird context
+
+## General rules
+
+Here are some general rules resulting from above mechanism:
+
+- access to **Resources** does not require access to the **Routing Peer** itself,
+  - the Resource's Group needs to be mentioned in Access Policy's destination explicitly:
+    - `All` Group does not cover Resources, unless it is explicitly assigned to those,
+    - it is generally advised not to use the `All` group in the context of Networks,
+- access to the **Routing Peer**'s local IP address needs to be explicitly allowed:
+  - granting access to Resource will establish connectivity to the Routing Peer (eg: in `netbird status -d`), but
+    traffic destined to any of the Routing Peer's local IP addresses will be rejected,
+- the Resource policy can have completely different scope than the Routing Peer policy,
+  - access to the Routing Peer is not limited by the Resource policies in any way,
+  - it is possible to grant broader or more restricted access to the Routing Peer's IP address
+    than to the rest of the routed network,
+- you can access _inactive_ Routing Peers on the same Network by their "local" IP addresses, because they are now
+  effectively remote Resource,
+- domain-based (as opposed to subnet-based) Resources still resolve to and create routes for a set of one or
+  more IP addresses (`/32` subnets), which in turn conform to the same rules and need to be planned accordingly:
+  - if it happens to resolve to the IP address of the Routing Peer it will need to be allowed by a policy mentioning
+    Routing Peers as destination,
+
+## Visualising access
+
+Following diagram explains the differences visually, it depicts:
+
+- 1 User's laptop running NetBird client,
+- 3 Routing Peers running NetBird client,
+- a single LAN server, which does not run NetBird,
+- Network Resource routing the `192.168.1.0/24` network,
+- set of green dashed lines representing connections governed by the Access Policy
+  granting access to the Resource,
+- set of orange solid lines representing connections governed by the Access Policy
+  granting access directly to the Routing Peer,
+
+<p>
+    <img src="/docs-static/img/how-to-guides/routing-peer-policies.drawio.png" alt="routing-peer-policies" className="imagewrapper-big"/>
+</p>
+
+
+In practice, you might observe seemingly "random" results depending on which Peer is
+currently handling your requests.
+
+### When access is allowed only to the Resource
+
+Having a single policy allowing access to Resources, but not to the Routing Peer would result in following behaviors:
+
+- connecting through `router-1` you will be able to access the`192.168.1.0/24` subnet
+  except for a single IP `192.168.1.1`(Routing Peer's local address),
+- connecting through `router-2` you won't be able to access `192.168.1.2`,
+- connecting through `router-3` you won't be able to access `192.168.1.3`,
+
+### Restrictive Resource policy with permissive Routing Peer policy
+
+Having a Resource policy scoped to ICMP and a Routing Peer policy scoped to TCP 443 (HTTPS) would result in following
+behaviors:
+
+- connecting through `router-1` you will be able to ping (and nothing else) the `192.168.1.0/24` subnet
+  except for a single IP `192.168.1.1`. You will not be able to ping it, but instead you will be able to
+  access all of HTTPS services running on this specific Routing Peer,
+- connecting through `router-2` you won't be able to ping `192.168.1.2`, but will be able to access HTTPS services,
+- connecting through `router-3` you won't be able to ping `192.168.1.3`, but will be able to access HTTPS services,
+
+### Security caveats
+
+Combining very restrictive Resource policies with broad Routing Peer policies might result in what some users
+would at the first glance consider security vulnerabilities.
+
+This can be particularly unexpected when the Routing Peer is handling multiple subnets with different Groups or
+permission levels assigned. Granting access to the Routing Peer will grant access to all the services running
+on the Routing Peer itself for all the routed subnets, even if one (or all) of the subnets have very
+restrictive/harmless Resource policies in place:
+
+- a potentially harmless Resource policy will make it advertised to the clients, without granting any meaningful access,
+- a permissive Routing Peer policy can grant _full_ access to the IP address from the routed network,
+
+By combining above two policies seemingly unrelated policies and harmless policies,
+you can unexpectedly grant complete access to the Routing Peer's local IP address:
+
+- if you omitted the Resource policy, the route would not be advertised and therefore never be allowed to pass through
+  the WireGuard connection,
+- if you omitted the Routing Peer policy, you would not be able to access that single IP address at all,

src/pages/how-to/networks-access-management.mdx

@@ -73,28 +73,6 @@ 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 Peer is forwarding your requests,
-- access to **Resources** does not require access to the Routing Peer itself,
-- access to the Routing Peer's local IP address needs to be explicitly allowed:
-  - granting access to Resource will establish connectivity to the Routing Peer (eg: in `netbird status -d`), but
-    traffic destined to any of the Routing Peer's local IP addresses will be rejected,
-- you can access _inactive_ Routing Peers on the same Network by their "local" IP addresses, because they are now
-  effectively remote,
-
-Following diagram explains the differences visually with orange/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.