mirror of
https://github.com/netbirdio/docs.git
synced 2026-10-18 11:39:03 +02:00
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:
@@ -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:
|
||||
|
||||
|
||||
Reference in New Issue
Block a user