sendnrw/netbird-docs
2
0
Fork 0
mirror of https://github.com/netbirdio/docs.git synced 2026-04-16 07:26:35 +00:00
Code Issues Packages Projects Releases Wiki Activity

Improved grammar and readability of how-netbird-works.mdx (#357)

Browse Source 
Little more straight-forward for anyone whose native language is not English. :- )
This commit is contained in:
Hammy Havoc
2025-05-29 10:00:41 +00:00
committed by GitHub
parent 5433a0bdb0
commit beb668988c
1 changed files with 12 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files

24
src/pages/about-netbird/how-netbird-works.mdx
View File

@@ -63,9 +63,9 @@ The Management service runs in the cloud NetBird-managed. It can also be self-ho
### Client Application
The NetBird Client application (or agent) is a software that is installed on your machines.
It is an entry point to you private network that makes it possible for machines to communicate with each other.
Once installed and registered, a machine becomes a peer in the network.
The NetBird Client application (or agent) is a software that is installed on the machines within a NetBird network.
It is an entry point to your private network that makes it possible for machines to communicate with each other.
Once installed and registered, a machine becomes a peer within the network.
The Client's roles are the following:
@@ -76,24 +76,24 @@ The client application sends its public key to the Management service which then
The client application requests a user to log in with an Identity Provider (IDP) or a [setup key](/how-to/register-machines-using-setup-keys) so that the peer can be associated with the organization's account.
* **Receiving network updates from the Management service.**
Each peer receives initial configuration and a list of peers with corresponding public keys and IP addresses so that it can establish a point-to-point connection.
* **Establishing point-to-point WireGuard connection.** To establish a connection with a remote peer, the Client first discovers the most suitable connection candidate, or simply address (IP:port) that other peer can use to connect to it.
Then sends it to the remote peer via Signal. This message is encrypted with the peer's private key and a public key of the remote peer.
* **Establishing point-to-point WireGuard connection.** To establish a connection with a remote peer, the Client first discovers the most suitable connection candidate, or simply address (IP:port) that other peers can use to connect to it.
It then sends it to the remote peer via Signal. This message is encrypted with the peer's private key and a public key of the remote peer.
The remote peer does the same and once the peers can reach each other, they establish an encrypted WireGuard tunnel.
* **Applying access control policies.** The client application applies access control rules that are received from the Management service.
It uses system's available firewall manager like `nftables` to apply the rules.
The client uses a system's available firewall manager like `nftables` to apply the rules.
* **Applying DNS settings.** The client application runs an [embedded DNS resolver](https://netbird.io/knowledge-hub/using-xdp-ebpf-to-share-default-dns-port-between-resolvers) and ensures that the machine can resolve other peers' FQDNs in the `netbird.cloud` namespaces.
It also applies other DNS settings that are received from the Management service.
The client also applies other DNS settings that are received from the Management service.
<Note>
The **private key**, generated by the Client, **never leaves the machine**, ensuring that only the machine that owns the key can decrypt traffic addressed to it.
The **private key**, generated by the NetBird client, **never leaves the machine**, ensuring that only the machine that owns the key can decrypt traffic addressed to it.
</Note>
### Signal Service
The Signal Service or simply Signal is a lightweight piece of software that helps peers to negotiate direct connections.
The Signal Service, or simply Signal, is a lightweight piece of software that helps peers to negotiate direct connections.
It does not store any data and no traffic passes through it.
The only Signal's responsibility is:
Signal's sole responsibility is:
* **Serve as a notification mechanism for peers.** Before a connection can be established,
peers need to find each other and exchange the most suitable connection candidates.
This is done through Signal. After a connection has been established, Signal steps out.
@@ -113,13 +113,13 @@ It runs in the cloud NetBird-managed and can be self-hosted.
The Relay service is a [TURN server](https://webrtc.org/getting-started/turn-server) in WebRTC terminology.
In fact, we use an open-source implementation called [Coturn](https://github.com/coturn/coturn).
The purpose of this service is to be a "plan B" and relay traffic between peers in case a point-to-point connection isn't possible. However starting with v0.29.0 a new relay based on WebSocket is implemented, moving away from TURN relay (coturn). [More info](https://netbird.io/knowledge-hub/september-newsletter).
The purpose of the Relay service is to gracefully implement a "Plan B" by relaying traffic between peers when a direct point-to-point connection is not possible. However, starting with v0.29.0, a new WebSocket-based relay has been introduced with the intent of replacing the previous TURN relay (Coturn). [More info](https://netbird.io/knowledge-hub/september-newsletter).
<p>
<img src="/docs-static/img/architecture/relay.png" alt="relay-dia" className="imagewrapper-big"/>
</p>
<Note>
Similar to Signal, traffic that flows through the Relay can't be decrypted due to the **WireGuard point-to-point encryption**.
Similar to Signal, traffic that flows through the Relay cannot be decrypted due to the **WireGuard point-to-point encryption**.
</Note>
It runs in the cloud or can be self-hosted.