Retea

NetBird: mesh VPN peer-to-peer bazat pe WireGuard, cu control plane self-hosted

Ai un laptop, doua-trei servere de productie, un NAS acasa si un coleg care are nevoie de acces temporar la o baza de date. Solutia clasica: WireGuard punct-la-punct, cu chei generate manual, wg-quick pe fiecare masina si un fisier AllowedIPs pe care il editezi la fiecare adaugare de nod. Merge, pana cand devine un mesh de 12 noduri si iti dai seama ca fiecare peer nou inseamna sa umbli prin configul a altor 11.

Aici intra soluitile de tip mesh VPN gestionat: Tailscale, ZeroTier si altele rezolva exact problema asta, dar cu un compromis: control plane-ul (identitate, topologie, politici de acces) traieste pe serverele lor. NetBird (netbird.io ) e proiectul open-source (BSD-3) care ia acelasi model peer-to-peer bazat pe WireGuard, dar face self-hostabil intregul control plane: atat serverul de management, cat si serverul de semnalizare (signal server) care ajuta perechile de noduri sa negocieze o conexiune directa. Noi l-am evaluat ca alternativa la stack-ul comercial pentru cazurile in care vrei mesh VPN dar nu vrei ca topologia retelei tale sa fie cunoscuta de un tert.

Ce este, mai exact, NetBird

NetBird construieste o retea overlay peste WireGuard: fiecare nod (server, laptop, container, telefon) primeste o identitate criptografica si o adresa IP dintr-un spatiu privat, iar traficul intre noduri circula, ideal, direct intre ele, criptat WireGuard, fara sa treaca printr-un hub central. Partea “grea” - stabilirea conexiunii - foloseste un mecanism gen ICE (Interactive Connectivity Establishment), similar cu ce foloseste WebRTC: nodurile incearca intai o conexiune peer-to-peer directa (eventual cu hole punching prin NAT), iar daca traversarea NAT esueaza (NAT simetric dublu, firewall restrictiv), NetBird cade pe un server de relay ca fallback, ca sa nu ramai fara conectivitate.

Scheletul serverului consta din doua componente distincte, care in varianta self-hosted ruleaza amandoua pe infrastructura ta:

Management server: tine evidenta nodurilor, grupurilor, politicilor de acces si cheilor de inregistrare. E “creierul” retelei.
Signal server: un canal de semnalizare prin care doua noduri isi schimba informatiile necesare (chei publice WireGuard, candidati de conexiune) inainte sa stabileasca tunelul propriu-zis. Nu vede traficul aplicatiei, doar coordoneaza handshake-ul.

Identitatea utilizatorilor nu e reinventata: NetBird se integreaza cu orice furnizor OIDC/SSO (Keycloak, Authentik, Zitadel, Google si altele), asa ca adaugarea sau eliminarea unui coleg din retea inseamna, practic, gestionarea unui cont in IdP-ul pe care il ai deja.

De ce conteaza asta

Diferenta fata de un mesh VPN comercial nu e cosmetica. Daca serviciul din spate se opreste, iti pierde datele sau isi schimba brusc politica de pret, cu un control plane self-hosted problema e a ta de rezolvat tehnic, nu o negociere cu un vendor. Practic, e vorba de a decide daca harta completa a infrastructurii tale (cine vorbeste cu cine, ce reguli de acces exista) locuieste pe serverele tale sau pe ale altcuiva. Pentru echipe cu cerinte de conformitate sau pur si simplu pentru cine nu vrea o dependenta externa critica pe conectivitate, diferenta e reala.

Ce primesti din cutie

Retea overlay peer-to-peer bazata pe WireGuard, cu adresare privata automata pentru fiecare nod
NAT traversal cu ICE/STUN si fallback pe relay TURN-like cand traversarea directa esueaza
Autentificare prin SSO/OIDC (Keycloak, Authentik, Zitadel, Google, altele), fara sa mai construiesti un sistem de useri separat
Politici de acces bazate pe grupuri (cine poate vorbi cu cine, pe ce porturi), nu doar “toata lumea vede tot”
Chei de inregistrare (setup keys) pentru a adauga noduri automat, util pentru provisioning scriptat sau containere efemere
Client cross-platform (Linux, Windows, macOS, mobil) si CLI pentru automatizare
Cod scris in Go, usor de compilat si de rulat in container

Instalare NetBird pe un VPS

Cel mai simplu mod de a porni self-hosted-ul e cu scriptul oficial de instalare pe un VPS dedicat, separat de nodurile pe care vrei sa le conectezi la retea. Ai nevoie de un domeniu propriu (managementul si signal server-ul se expun prin TLS) si de un IdP OIDC deja configurat.

# pe un VPS curat (Debian/Ubuntu), cu un domeniu care pointeaza deja aici
export NETBIRD_DOMAIN=netbird.exemplu.ro
curl -fsSL https://github.com/netbirdio/netbird/releases/latest/download/getting-started-with-zitadel.sh | bash

# dupa ce stack-ul (management + signal + Zitadel + Caddy) e sus,
# adaugi un nod client pe orice masina cu:
curl -fsSL https://pkgs.netbird.io/install.sh | sh
netbird up --management-url https://netbird.exemplu.ro

Scriptul oficial ridica intregul stack prin Docker Compose (management, signal, un IdP Zitadel daca nu ai deja unul, si un reverse proxy Caddy pentru TLS automat). Daca ai deja un IdP, poti sari peste componenta Zitadel si sa configurezi manual management.json cu emitentul OIDC existent.

Pe firewall-ul VPS-ului, ai nevoie minim de:

# HTTPS pentru API-ul de management + UI
ufw allow 443/tcp
# signal server, daca il expui pe port separat (implicit trece tot prin 443/gRPC-web)
ufw allow 10000/tcp
# relay-ul TURN-like pentru fallback NAT traversal
ufw allow 3478/udp
ufw allow 49152:65535/udp

Portul exact pentru relay depinde de configuratia aleasa (poti folosi coturn extern sau relay-ul inclus); verifica docker compose ps dupa instalare ca sa confirmi ce porturi asculta efectiv fiecare container.

Tipare de configurare care merita stiute

Politici de acces, nu doar conectivitate

Din start, orice nod din retea poate vorbi cu oricare altul. Prima configurare pe care merita sa o faci e sa creezi grupuri (ex. servers, laptops, contractors) si politici explicite care restrictioneaza traficul intre ele. Un contractor temporar nu are nevoie sa vada baza de date de productie doar pentru ca e in acelasi mesh cu ea.

Setup keys pentru provisioning automat

Daca adaugi noduri prin Ansible sau cloud-init (exact scenariul unui VPS proaspat provisionat), foloseste o setup key cu expirare si limita de utilizari in loc sa autentifici manual fiecare masina prin browser. Cheia se genereaza din UI sau API si se paseaza ca variabila de mediu la netbird up --setup-key ....

Relay ca plasa de siguranta, nu ca regula

Daca observi ca majoritatea conexiunilor cad pe relay in loc de peer-to-peer direct, verifica NAT-ul si firewall-ul de la ambele capete. Un relay permanent inseamna latenta suplimentara si o dependenta pe infrastructura ta de relay pentru orice conexiune, exact ce voiai sa eviti alegand un mesh peer-to-peer.

Signal server-ul nu e un punct de incredere pentru trafic

E usor sa presupui gresit ca signal server-ul vede traficul aplicatiei. Nu e asa: el doar mijloceste handshake-ul WireGuard. Asta simplifica modelul de amenintare, dar merita sa fie clar cand explici arhitectura echipei sau auditorilor.

Unde NetBird nu e raspunsul potrivit

Daca ai nevoie doar de 2-3 servere conectate punct-la-punct si nu vrei sa mentii inca un stack (management + signal + IdP), un wg-quick clasic e mai simplu si are mai putine piese care se pot strica. NetBird aduce valoare cand numarul de noduri creste sau cand ai nevoie de politici de acces granulare si onboarding/offboarding rapid prin SSO, nu cand ai o topologie statica de cateva noduri.

De asemenea, self-hosting-ul inseamna ca esti responsabil pentru disponibilitatea management si signal server-ului: daca ambele cad, nodurile deja conectate isi pastreaza tunelurile WireGuard existente, dar nu poti adauga noduri noi sau modifica politici pana repornesti stack-ul. Merita un plan de backup pentru baza de date de management.

Alternative pe care le-am luat in calcul

Tailscale : acelasi model peer-to-peer WireGuard, dar control plane-ul e SaaS (exista si o versiune de coordinare server self-hosted, Headscale, dezvoltata separat de comunitate, nu de Tailscale Inc.)
Headscale : implementare open-source, neoficiala, a control plane-ului Tailscale; buna daca vrei clientul Tailscale dar server self-hosted
ZeroTier : mesh VPN cu protocol propriu (nu WireGuard), overlay layer 2, cu optiune self-hosted pentru controller

Deci, sa-l rulezi?

Daca ai deja mai mult de cativa peer WireGuard de gestionat manual si vrei sa pastrezi controlul complet asupra topologiei si identitatii, NetBird e o alegere solida: e open-source, se bazeaza pe WireGuard (deci criptografia e verificata si stabila), iar self-hosting-ul intregului control plane inseamna ca nu depinzi de disponibilitatea sau politica de pret a unui vendor extern.

Stack-ul (management, signal, eventual coturn si un IdP) merge natural pe un VPS separat, cu resurse modeste pentru echipe mici-medii. Daca vrei sa il pui in productie dar nu vrei sa faci tu tot mentenanta (patch-uri, backup pentru baza de date de management, monitorizare pentru signal server), verifica si administrarea de servere sau sectiunea noastra de retea pentru context despre cum arata restul infrastructurii pe care ar rula un asemenea stack.