Comprendi cosa viene coordinato
Il control plane gestisce la registrazione dei nodi e distribuisce le informazioni di rete. Il traffico dati può utilizzare connessioni dirette tra peer o un relay a seconda della connettività. Eseguire il coordinatore non significa che ogni pacchetto vi transiti.
Rendi l'iscrizione intenzionale
Proteggi l'API amministrativo e utilizza metodi di registrazione a breve scadenza o con ambito adeguato. Rimuovi i dispositivi smarriti o dismessi. La possibilità di unirsi alla mesh non dovrebbe implicare l'accesso a ogni servizio.
Verifica ACL e route
Applica regole di privilegio minimo tra utenti e nodi. Le rotte di subnet annunciate e i nodi di uscita ampliano la rete raggiungibile e richiedono approvazione esplicita. Verifica il traffico negato con la stessa cura del traffico consentito.
Conserva il materiale di recupero
Esegui il backup di configurazione, stato e chiavi secondo la procedura della versione supportata. Mantieni un modo per amministrare VPS se la mesh fallisce. Verifica la compatibilità dei client e le note di aggiornamento prima di modificare il control plane.
Registrazione, instradamento e policy sono controlli separati
Headscale coordina client Tailscale compatibili; le connessioni dirette e i percorsi di relay DERP hanno comportamenti di rete diversi. Un router di subnet annuncia un intervallo, il server di controllo lo approva e il client deve accettare la rotta. Abilita l'inoltro sul nodo di routing e mantieni ristretti gli intervalli annunciati. Una rotta approvata necessita comunque di una policy di accesso che limiti chi può usare quale destinazione e porta.
- Controlla l'elenco delle route del server di controllo
- Test da un dispositivo autorizzato
- Ripeti lo stesso test da un dispositivo che dovrebbe essere negato
headscale nodes list-routesDocumentazione ufficiale: Rotte Headscale
Non inserire l'unico percorso di ripristino all'interno della mesh
Mantieni un secondo modo per raggiungere la console del server o un percorso di amministratore strettamente limitato. Verifica cosa succede quando il coordinatore, il relay o il client non sono disponibili. Conserva lo stato del control-plane e le chiavi in base alla versione installata. Una mesh privata può semplificare l'accesso, ma non dovrebbe diventare una dipendenza non documentata che impedisce la propria riparazione.
Correggi l'identità del control-plane e il percorso di ripristino
Scegli un nome HTTPS stabile, una release Headscale supportata e client Tailscale compatibili. Leggi l'esempio di configurazione fornito con quella release esatta; una configurazione copiata da una release diversa può non superare la validazione o descrivere silenziosamente una politica diversa. Mantieni persistente il database del control-plane e le chiavi richieste. Mantieni privato l'API amministrativo e conserva una console separata o una rotta SSH limitata, così che perdere la mesh non renda impossibile riparare il suo coordinatore.
- Usa un certificato valido per il nome pubblico del control-plane.
- Mantieni le chiavi di registrazione di breve durata e con ambito adeguato.
- Considera il design del relay e lo spazio dei nomi DNS come scelte esplicite.
Documentazione ufficiale: Distribuzione del container Headscale
Registra un dispositivo prima di pubblicizzare una rete
Avvia il server seguendo le istruzioni upstream e registra un utente/dispositivo di test tramite il metodo di enrollment documentato. Conferma che il dispositivo raggiunga il URL di controllo previsto e compaia con l'identità desiderata. Ispeziona lo stato del client e prova un servizio privato prima di aggiungere route di exit-node o di subnet. Un percorso DERP può preservare la connettività dove un percorso diretto non è disponibile; non indica che il coordinatore stia inoltrando ogni pacchetto.
- Inizia con un dispositivo e un servizio che puoi rimuovere in sicurezza.
- Verifica se il traffico peer è diretto o inoltrato.
- Proteggi il relay e gli endpoint di controllo in base alla distribuzione scelta.
Documentazione ufficiale: Riferimento al deployment di Headscale
Approva routing e autorizzazione in modo indipendente
Per l'accesso alle subnet, abilita l'inoltro sul nodo di routing, annuncia un intervallo ristretto, approvalo sul server di controllo e assicurati che il client di destinazione lo accetti. Evita reti sovrapposte che rendono ambigua la rotta di ritorno. Una rotta approvata non è una policy di accesso: definisci chi può connettersi a quale destinazione e porta, inclusi i dispositivi guest. Verifica una connessione consentita e una connessione identica negata prima di estendere la mesh.
# Run on the control server; syntax follows the installed release:
headscale nodes list-routes
# Client-side inspection:
tailscale statusDocumentazione ufficiale: Subnet e rotte di uscita di Headscale
Individua il livello guasto prima di modificare la policy
Se l'arruolamento fallisce, ispeziona DNS, HTTPS e il server URL. Se il dispositivo si unisce ma una subnet non è raggiungibile, ispeziona annuncio, approvazione, accettazione della route del client, inoltro e percorso di ritorno. Se fallisce un solo servizio, ispeziona il suo indirizzo di bind, il firewall dell'host e la policy della mesh. Conserva un backup coerente di database/configurazione e prova un aggiornamento di versione con un client usa e getta prima di modificare l'unico control plane.