VPN Markdown
NetBird VPN – Accesso centralizzato ai Datacenter
1. Obiettivo
NetBird viene utilizzato come VPN centralizzata per consentire agli utenti autorizzati di raggiungere le reti private presenti nei diversi datacenter aziendali.
L'obiettivo è evitare:
- una VPN separata per ciascun datacenter;
- configurazioni VPN dedicate sui singoli firewall;
- installazione di NetBird su ogni VM;
- esposizione pubblica dei servizi interni;
- gestione manuale delle route sui client.
L'utente utilizza un solo client NetBird e, in base ai propri permessi, riceve automaticamente accesso alle reti dei datacenter autorizzati.
L'architettura generale è:
INTERNET
│
│
┌───────────▼───────────┐
│ VPS NetBird │
│ │
│ Management │
│ Signal │
│ Relay │
│ Dashboard │
└───────────┬───────────┘
│
NetBird Overlay
│
┌──────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
Client DevOps Firewall DC1 Firewall DC2
Laptop + NetBird + NetBird
│ │ │
│ │ │
│ ┌────┴────┐ ┌────┴────┐
│ │ VLAN A │ │ VLAN C │
│ │ VLAN B │ │ VLAN D │
│ └─────────┘ └─────────┘
│
└──── Accesso in base alle policy ────────►
2. Componenti dell'architettura
NetBird Server
Il server NetBird rimane esterno ai datacenter, sul VPS pubblico.
Nel nostro caso il servizio è raggiungibile tramite:
https://netbird.eagleprojects.cloud
Il VPS ospita il control plane NetBird:
Management
Signal
Relay
Dashboard
Il server NetBird non deve essere confuso con il gateway VPN dei datacenter.
Il suo compito principale è:
- autenticare i peer;
- mantenere l'inventario;
- distribuire le configurazioni;
- distribuire le policy;
- comunicare ai client quali reti possono raggiungere;
- facilitare l'instaurazione delle connessioni;
- fornire relay quando una connessione diretta non è possibile.
3. Un solo NetBird per tutti i datacenter
Non viene creata un'istanza NetBird diversa per ogni datacenter.
Avremo:
1 × NetBird Server
N × Datacenter
1 × NetBird peer/firewall per Datacenter
Ad esempio:
NetBird
│
├── Datacenter Tecno
│ └── firewall-tecno
│
├── Datacenter Tunisia
│ └── firewall-Tunisia
│
├── Datacenter XYZ
│ └── firewall-xyz
│
└── ...
Questo permette di avere una sola:
- VPN;
- console amministrativa;
- autenticazione;
- gestione utenti;
- struttura di gruppi;
- configurazione delle policy.
4. NetBird installato direttamente sui firewall o macchina con accesso globale alle vlan
Ogni datacenter dispone di un firewall Linux.
Sul firewall viene installato soltanto il client NetBird.
Non vengono create VM o LXC dedicate.
Schema:
NetBird
│
│ WireGuard / Overlay
▼
┌───────────────┐
│ Firewall Linux│
│ │
│ NetBird Agent │
│ Routing Peer │
└───────┬───────┘
│
┌──────────┼──────────┐
│ │ │
▼ ▼ ▼
VLAN1 VLAN2 VLAN3
Questa soluzione è particolarmente adatta perché il firewall è già il router delle reti locali.
Il firewall conosce quindi già le route verso:
192.168.x.0/24
192.168.y.0/24
192.168.z.0/24
NetBird non deve creare una seconda infrastruttura di routing interna.
5. Concetto di Network in NetBird
Ogni datacenter viene rappresentato come un Network.
Esempio:
Network
tecno1
oppure:
Datacenter-Tecno
Datacenter-Tunisia
Datacenter-Perugia
Un Network contiene principalmente tre elementi:
Network
│
├── Resources
│
├── Routing Peers
│
└── Access Policies
6. Resources
Le Resources rappresentano le reti o gli host che devono essere raggiungibili tramite NetBird.
Per esempio:
Network: tecno1
potrebbe contenere:
VM1
192.168.200.0/24
VM2
192.168.201.0/24
Un altro datacenter potrebbe avere:
Network: Tunisia
VLAN14
192.168.14.0/24
VLAN15
192.168.15.0/24
Quindi:
NetBird
│
├── Network: tecno1
│ ├── 192.168.200.0/24
│ └── 192.168.201.0/24
│
└── Network: Tunisia
├── 192.168.14.0/24
└── 192.168.15.0/24
È preferibile mantenere subnet diverse come Resources separate, anche quando potrebbero essere aggregate.
Ad esempio:
192.168.14.0/24
192.168.15.0/24
è preferibile a:
192.168.14.0/23
perché consente policy differenti in futuro.
7. Routing Peer
Per ogni Network viene definito il firewall del relativo datacenter come Routing Peer.
Esempio:
Network: tecno1
Resources
├── VM1 → 192.168.200.0/24
└── VM2 → 192.168.201.0/24
Routing Peer
└── firewall-tecno
NetBird interpreta questa configurazione come:
Per raggiungere 192.168.200.0/24 o 192.168.201.0/24, inoltra il traffico attraverso firewall-tecno.
Analogamente:
Network: Tunisia
Resources
├── VLAN14 → 192.168.14.0/24
└── VLAN15 → 192.168.15.0/24
Routing Peer
└── firewall-Tunisia
8. Percorso del traffico
Supponiamo che un amministratore debba raggiungere:
192.168.200.50
situato nel datacenter Tecno.
Il percorso logico sarà:
Notebook DevOps
NetBird client
│
│
▼
NetBird Overlay
│
▼
firewall-tecno
NetBird Routing Peer
│
▼
192.168.200.0/24
│
▼
192.168.200.50
Il notebook non deve conoscere manualmente il gateway del datacenter.
È NetBird a comunicare al client:
192.168.200.0/24
→ raggiungibile tramite firewall-tecno
9. Collegamento diretto e Relay
Il traffico dati non passa necessariamente attraverso il VPS NetBird.
NetBird prova innanzitutto a creare una connessione diretta:
Client
│
│ WireGuard P2P
▼
Firewall Datacenter
Questa è la condizione preferita.
Il VPS NetBird viene utilizzato per coordinare la connessione.
Se NAT o firewall impediscono il collegamento diretto, NetBird può utilizzare il proprio relay:
Client
│
▼
NetBird Relay
│
▼
Firewall Datacenter
Di conseguenza:
Control plane → sempre NetBird Server
Data plane → preferibilmente P2P
altrimenti Relay
10. Access Control
Il fatto che una Resource esista non significa che tutti possano raggiungerla.
L'accesso viene determinato dalle policy.
Ad esempio abbiamo il gruppo:
DevOps
Possiamo creare:
DevOps → VM1
DevOps → VM2
che significa:
Membri del gruppo DevOps
│
├── possono raggiungere 192.168.200.0/24
│
└── possono raggiungere 192.168.201.0/24
Un altro gruppo potrebbe avere accesso soltanto a VM1:
Developers
│
└── VM1
mentre:
DevOps
│
├── VM1
└── VM2
Questo permette di avere una struttura Zero Trust molto più granulare rispetto a una VPN tradizionale.
11. Il gruppo All
Durante i test può essere utilizzata una policy:
All → Resource
ma non dovrebbe essere la configurazione definitiva di produzione.
In produzione conviene utilizzare gruppi espliciti:
DevOps
Developers
Monitoring
BI
RPA
SysAdmins
e associare solo le reti necessarie.
Ad esempio:
Resources
DevOps ────────────────► Datacenter Tecno
│
├──────────────────► Datacenter Tunisia
│
└──────────────────► Datacenter Perugia
Developers ────────────► VLAN Development
Monitoring ────────────► VLAN Monitoring
12. Come si collega un utente
Sul PC dell'utente viene installato NetBird.
Una volta autenticato, il peer appare nella console amministrativa.
Ad esempio:
Peer:
laptop-mario
Groups:
DevOps
Il client non riceve indiscriminatamente tutte le reti.
NetBird valuta:
Peer
↓
Groups
↓
Policies
↓
Resources autorizzate
Quindi per un PC nel gruppo:
DevOps
le policy potrebbero assegnare:
192.168.14.0/24
192.168.15.0/24
192.168.200.0/24
192.168.201.0/24
13. Esperienza dell'utente
Dal punto di vista dell'utente finale l'utilizzo sarà estremamente semplice.
Una volta connesso NetBird:
netbird status
non dovrà selezionare manualmente:
VPN Tecno
VPN Tunisia
VPN Perugia
Avrà una sola VPN:
NetBird
e potrà utilizzare direttamente gli IP autorizzati.
Esempio:
ssh admin@192.168.200.10
oppure:
curl https://192.168.14.108
oppure:
https://192.168.15.5
NetBird sceglierà automaticamente il datacenter corretto.
14. Esempio con più datacenter
L'architettura finale può diventare:
USER
Laptop DevOps
│
│
NetBird Client
│
▼
netbird.eagleprojects.cloud
│
┌─────────────┼─────────────┐
│ │ │
▼ ▼ ▼
DATACENTER 1 DATACENTER 2 DATACENTER 3
fw-tecno fw-Tunisia fw-perugia
│ │ │
┌─────┴─────┐ ┌─────┴─────┐ ┌─────┴─────┐
│ │ │ │ │ │
VM Network Storage VLAN14 VLAN15 PROD TEST
Nella console NetBird:
Networks
│
├── tecno1
│ │
│ ├── Routing Peer
│ │ └── firewall-tecno
│ │
│ └── Resources
│ ├── VM1 → 192.168.200.0/24
│ └── VM2 → 192.168.201.0/24
│
├── Tunisia
│ │
│ ├── Routing Peer
│ │ └── firewall-Tunisia
│ │
│ └── Resources
│ ├── VLAN14 → 192.168.14.0/24
│ └── VLAN15 → 192.168.15.0/24
│
└── perugia
│
├── Routing Peer
│ └── firewall-perugia
│
└── Resources
├── PROD
└── TEST
15. Masquerade
Attualmente sui Routing Peer può essere mantenuto:
Masquerade: ON
È la configurazione più semplice.
Supponiamo:
Client NetBird
100.120.26.80
che contatti:
192.168.14.108
Il traffico arriva al firewall NetBird e viene NATtato.
La macchina interna vedrà come sorgente il firewall invece dell'IP NetBird originale.
Schema:
100.120.26.80
Client
│
▼
Firewall NetBird
│
│ Masquerade
▼
192.168.14.108
Il grande vantaggio è che i server interni non devono conoscere la rete NetBird.
La risposta segue semplicemente il normale default gateway:
Server
│
▼
Firewall
│
▼
NetBird
│
▼
Client
16. Nessuna modifica sulle VM
Una caratteristica importante dell'architettura è che le VM interne non devono essere modificate.
Non serve installare NetBird su:
VM1
VM2
database
Docker host
Proxmox guest
server applicativi
La gestione è concentrata sul firewall:
NetBird
│
▼
FIREWALL
│
┌────────┼────────┐
│ │ │
▼ ▼ ▼
VM VM VM
Questo riduce drasticamente il numero di agent da amministrare.
17. Requisiti del firewall
Ogni firewall utilizzato come Routing Peer deve:
- avere il client NetBird installato;
- essere registrato sul NetBird centrale;
- avere IP forwarding abilitato;
- conoscere le route verso le subnet pubblicate;
- consentire il forwarding del traffico NetBird verso le VLAN interessate;
- poter comunicare verso il servizio NetBird pubblico.
Il firewall è già il gateway L3 delle reti interne, quindi normalmente le route locali sono già presenti.
Ad esempio:
ip route
potrebbe mostrare:
192.168.200.0/24 dev vlan200
192.168.201.0/24 dev vlan201
NetBird utilizza queste normali route Linux per consegnare i pacchetti.
18. Aggiunta di un nuovo datacenter
Per aggiungere un nuovo datacenter la procedura standard sarà:
- Installare NetBird sul firewall Linux.
- Registrare il firewall sul NetBird centrale.
- Creare un nuovo
Network. - Creare le
Resourcescorrispondenti alle subnet da pubblicare. - Assegnare il firewall come
Routing Peer. - Creare le policy di accesso.
- Verificare da un client autorizzato.
Ad esempio:
Nuovo datacenter: Milano
diventa:
Network
Datacenter-Milano
│
├── Resources
│ ├── PROD → 10.40.10.0/24
│ ├── TEST → 10.40.20.0/24
│ └── MGMT → 10.40.30.0/24
│
└── Routing Peer
└── firewall-milano
Policy:
DevOps → PROD
DevOps → TEST
DevOps → MGMT
Developers → TEST
Non occorre modificare i client degli utenti.
19. Aggiunta di una nuova VLAN
Se viene aggiunta una VLAN a un datacenter già configurato, non serve creare un nuovo Routing Peer.
Ad esempio da:
Datacenter Tecno
192.168.200.0/24
192.168.201.0/24
si aggiunge:
192.168.202.0/24
basta creare:
Resource:
VM3
Address:
192.168.202.0/24
all'interno dello stesso Network.
Il Routing Peer rimane:
firewall-tecno
20. Risultato finale
L'infrastruttura diventa concettualmente:
NETBIRD
unica VPN
│
autenticazione + autorizzazione
│
┌───────────────┼───────────────┐
│ │ │
▼ ▼ ▼
DC 1 DC 2 DC 3
│ │ │
Firewall Firewall Firewall
│ │ │
Networks Networks Networks
Per l'utente:
Una connessione NetBird
+
Appartenenza ai gruppi
↓
Accesso automatico ai datacenter autorizzati
Per l'amministratore:
Datacenter
↓
Network
↓
Resources
↓
Routing Peer
↓
Policies
La separazione fondamentale è quindi:
NetBird Server
= control plane centrale
Firewall NetBird
= gateway verso il singolo datacenter
Network
= contenitore logico del datacenter
Resource
= subnet/host raggiungibile
Routing Peer
= firewall attraverso cui raggiungerla
Policy
= definisce chi può accedervi
Client
= riceve automaticamente soltanto le reti autorizzate
Questa struttura permette di mantenere un'unica VPN aziendale, indipendentemente dal numero di datacenter, senza installare agent sulle VM e mantenendo il controllo degli accessi centralizzato in NetBird.