docs: standardize on "NetBird client" over "agent" for the client software (#940)

* docs: standardize on "NetBird client" over "agent" for the client software

* docs: address review feedback

- fix "a software" grammar and use lowercase "NetBird client"
- define routing peer as a peer whose client bridges, keeping peer and client distinct
- correct kernel-space claim: the kernel WireGuard data path is what runs in the kernel
- clarify which address the application uses to reach the SOCKS5 proxy from a separate container
This commit is contained in:
Jack Carter
2026-08-21 13:24:33 +02:00
committed by GitHub
parent d60d579197
commit 62baad95a1
28 changed files with 50 additions and 47 deletions
+2 -2
View File
@@ -226,7 +226,7 @@ Understanding policy directionality is essential for implementing Zero Trust acc
### Policies Between Peers
When both source and destination are peers running the NetBird agent, you have full control over directionality:
When both source and destination are peers running the NetBird client, you have full control over directionality:
**Unidirectional:** Traffic flows only from source to destination. In the NetBird UI, this appears as a single arrow (→).
@@ -277,7 +277,7 @@ Direction: ALWAYS Source → Destination (cannot be bidirectional)
**Why is this always unidirectional?**
Network resources don't have the NetBird agent installed. They don't know the NetBird network exists. The routing peer acts as a gateway, forwarding traffic from NetBird peers to these resources, but the resources themselves cannot initiate connections back through the NetBird network.
Network resources don't have the NetBird client installed. They don't know the NetBird network exists. The routing peer acts as a gateway, forwarding traffic from NetBird peers to these resources, but the resources themselves cannot initiate connections back through the NetBird network.
Think of it this way: