GuidePartiamo dalla provocazione, perché me la sono fatta anch'io. Se ti sei tirato su un overlay mesh — NetBird, Tailscale, o WireGuard puro — la VPN commerciale ad abbonamento sembra una cosa per gente che non sa cosa sia un tunnel. E per buona parte di ciò che fa un homelab è esatt
Self-HostingAccesso remoto al tuo server di casa senza port forwarding né firewall aperto: NetBird usa WireGuard P2P e funziona gratis fino a 100 device.
30 marzo 2026 · 8 min lettura
Ho ricevuto il sample da TRENDnet e l'ho messo subito al lavoro sul pve2. Il primo benchmark dice già la cosa che volevo verificare: il path pve↔pve2 attraverso MokerLink core e TRENDnet failover, con i due switch interconnessi a 2.5G, satura davvero a 2.5G end-to-end.
Iscriviti alla newsletter per ricevere i migliori articoli direttamente nella tua inbox.
2 nodi, 3 subnet, 14 container LXC. Tutta la mia rete Proxmox raggiungibile da qualsiasi posto in 12 minuti netti, cronometro alla mano. Tailscale fuori, NetBird dentro. E il piano Business non mi costa un euro.
Ho usato Tailscale per oltre un anno. Funzionava, non lo nego. Ma quando un progetto open source con 26.000 stelle su GitHub ti offre lo stesso servizio con controllo completo, API REST documentata e un Business plan gratuito, la domanda non riguarda la lealtà verso il vecchio strumento. Riguarda quanto tempo stai perdendo a non provarlo.
Se hai già letto come ho risolto il CGNAT con Tailscale Peer Relays, sai che il mio homelab dipende dalla VPN per l'accesso remoto. Cambiare overlay network non è una decisione che prendi a cuor leggero. Questa è la cronaca di come l'ho fatto, cosa ho guadagnato, e cosa ho perso.
Tailscale ha un problema che non è tecnico. È strutturale. Il control plane è proprietario. Le ACL si scrivono in un formato JSON inventato da loro. E il piano gratuito — 6 utenti, dispositivi illimitati — funziona finché sei solo tu con il tuo portatile. Appena vuoi qualcosa di più di un team piccolo, le opzioni sono due: pagare $8/utente/mese (piano Standard) oppure accettare i limiti del free.
NetBird ribalta l'equazione. Il client è open source sotto licenza BSD-3, management e signal server sotto AGPLv3. Puoi self-hostare tutto — dal relay alla dashboard — oppure usare il cloud gestito. Il piano gratuito copre 5 utenti e 100 macchine. Il Business plan aggiunge SSO, audit log, posture check e activity monitoring.
Il mio setup: Fedora come workstation, Proxmox VE su Ryzen 7 1800X con 14 container LXC distribuiti su tre subnet — 10.0.10.0/24 (management), 10.10.10.0/24 (backend), 10.20.20.0/24 (Docker). Il gateway è un Raspberry Pi che fa da router/firewall con AIWALL, l'IDS che ho costruito con un LLM.
Su PVE (root, Debian):
curl -fsSL https://pkgs.netbird.io/install.sh | bash
netbird up --setup-key 64AF895E-xxxx-xxxx-xxxx-xxxxxxxxxxxxRisposta: Connected. Nessuna domanda, nessun browser da aprire, nessun OAuth flow. La setup key si genera dal dashboard in 3 click. Su Fedora, stesso script. Due nodi connessi in peer-to-peer con WireGuard in meno di 90 secondi.
Confronto diretto: Tailscale richiede tailscale up che apre un URL nel browser per l'autenticazione. Se sei su un server headless via SSH, devi copiare l'URL, aprirlo su un altro dispositivo, autenticarti, tornare al terminale. NetBird con la setup key elimina questo passaggio completamente.
Qui viene il bello. Con Tailscale usavo --advertise-routes per esporre le subnet del Proxmox. Funzionava, ma dovevi anche approvare le route dal pannello admin. Con NetBird, le network routes si configurano via API REST.
Ho creato 3 network, assegnato le subnet come resource, e impostato PVE come routing peer con masquerade attivo. Tutto via curl — nessun click sul dashboard:
# Crea la network
curl -X POST "https://api.netbird.io/api/networks" \
-H "Authorization: Token ${NB_TOKEN}" \
-H "Content-Type: application/json" \
-d '{"name":"PVE Management","description":"vmbr0"}'
# Aggiungi la subnet come resource
curl -X POST "https://api.netbird.io/api/networks/${NET_ID}/resources" \
-H "Authorization: Token ${NB_TOKEN}" \
-H "Content-Type: application/json" \
-d '{"address":"10.0.10.0/24","name":"management","type":"subnet"}'
# Imposta PVE come router
curl -X POST "https://api.netbird.io/api/networks/${NET_ID}/routers" \
-H "Authorization: Token ${NB_TOKEN}" \
-H "Content-Type: application/json" \
-d '{"peer":"${PVE_PEER_ID}","masquerade":true}'Risultato sul client Fedora:
$ netbird networks list
Available Networks:
- ID: management-subnet
Network: 10.0.10.0/24
Status: Selected
- ID: vmbr1-subnet
Network: 10.10.10.0/24
Status: Selected
- ID: vmbr2-subnet
Network: 10.20.20.0/24
Status: SelectedLe route compaiono automaticamente su tutti i peer del gruppo. Non devi approvarle una per una. Non devi riavviare nulla.
Ping dal portatile (Fedora, fuori dalla LAN del Proxmox) verso PVE attraverso il tunnel NetBird:
$ ping -c 3 100.70.87.58
64 bytes from 100.70.87.58: icmp_seq=2 ttl=64 time=1.32 ms
64 bytes from 100.70.87.58: icmp_seq=3 ttl=64 time=3.21 ms
$ ping -c 2 10.0.10.200 # PVE via network route
64 bytes from 10.0.10.200: icmp_seq=1 ttl=64 time=1.21 ms
64 bytes from 10.0.10.200: icmp_seq=2 ttl=64 time=3.04 ms
$ curl -o /dev/null -w '%{http_code}' http://10.0.10.103:3000
302 # Grafana risponde attraverso la routeLatenza media sotto i 3 ms in connessione peer-to-peer sulla stessa LAN. In condizioni normali, la connessione P2P si stabilisce direttamente — il relay (hosted da NetBird) interviene solo se il NAT traversal fallisce. Nel mio caso, connessione diretta al primo tentativo.
Non è tutto rose. Tailscale ha MagicDNS integrato — scrivi pve.tailedac2b.ts.net e raggiungi il nodo. NetBird ha introdotto Custom DNS Zones nella v0.63, ma la configurazione è meno immediata. Tailscale ha anche Funnel per esporre servizi pubblicamente; NetBird ha risposto con un reverse proxy integrato nella v0.65, disponibile sia self-hosted sia su NetBird Cloud.
Il vantaggio killer di NetBird per un homelabber? Le network routes via API. Ho automatizzato l'intera configurazione delle 3 subnet con uno script bash. Se domani aggiungo una quarta VLAN su Proxmox, la espongo in 30 secondi con un curl. Con Tailscale, --advertise-routes richiede un restart del daemon e l'approvazione manuale dal pannello.
Una volta verificato che tutto funziona via NetBird, rimuovere Tailscale è banale:
# Su ogni nodo
tailscale logout
systemctl stop tailscaled
systemctl disable tailscaledHo controllato che i miei script di deploy e il pipeline di pubblicazione del blog (che fa SSH su 10.0.10.200) funzionassero ancora. Tutto ok — usavano già l'IP LAN, non quello Tailscale.
Un'alternativa per chi non ha un server fisico: Pangolin fa qualcosa di simile su WireGuard per esporre servizi self-hosted. E se non vuoi gestire nemmeno il tunnel, servizi come PikaPods ti permettono di hostare le stesse app (Vaultwarden, Uptime Kuma, Grafana) senza hardware — NetBird + PikaPods copre lo scenario zero-infrastruttura.
NetBird fa tutto quello che Tailscale fa nel mio homelab, con tre vantaggi che per me sono decisivi: open source completo, API REST per automatizzare tutto, e un modello di licensing che non ti punisce quando aggiungi un utente. La migrazione da Tailscale ha richiesto 12 minuti. Non ho perso un singolo servizio. L'unica cosa che mi manca è MagicDNS, e ci metteranno una pezza. Per chi gestisce un homelab Proxmox con subnet multiple, NetBird VPN è la scelta giusta oggi.
Fonti: NetBird GitHub, NetBird March 2026 Newsletter, Tailscale Pricing, NetBird vs Tailscale — birdhost.de, NetBird Network Routes Docs, XDA — NetBird for first-time homelabbers
Il piano free di NetBird Cloud copre fino a 100 peer e 5 utenti, più che sufficiente per un homelab. Basta creare un account su netbird.io, generare una setup key e collegare i nodi: nessuna carta di credito richiesta. Per i miei 14 container LXC e 3 subnet la spesa è zero euro al mese.
Nel mio caso 12 minuti netti, cronometro alla mano. Setup account, creazione della setup key nel dashboard, comando netbird up --setup-key su ogni nodo, configurazione network routes via API. Se tieni entrambe le VPN attive durante il passaggio hai zero downtime sui servizi interni.
Stesso protocollo sotto il cofano (WireGuard), latenza RTT misurata praticamente identica sui miei test tra pve1 e pve2. La differenza vera sta nella governance: NetBird è open-source sotto licenza BSD-3, puoi self-hostare l'intero control plane, e il modello di licensing non ti punisce quando aggiungi un utente.
netbird up --advertise-routes come Tailscale?No. A differenza di Tailscale, NetBird non espone un flag --advertise-routes su netbird up: gli unici flag di routing del client sono --disable-client-routes e --disable-server-routes. Le subnet si definiscono lato management — dashboard o API REST /api/networks — assegnando la subnet come resource e un peer come router, come mostrato sopra. Il client riceve le route e le seleziona da solo; le controlli con netbird networks list (l'alias netbird routes list funziona ancora). In pratica sostituisci «advertise-routes + approvazione manuale» di Tailscale con una definizione centralizzata e automatica.