Nebula advertise_addrs o static_host_map: scegli in base al proprietario
Una mappa statica è mantenuta da ogni peer che la chiama; un indirizzo annunciato è pubblicato dall’host. Scegli in base a chi conosce l’endpoint.
Le impostazioni static_host_map e advertise_addrs mettono entrambe un indirizzo davanti a un peer, e rispondono a domande diverse. Una è un file locale che elenca un indirizzo overlay e l’endpoint underlay da chiamare. L’altra è un host che dice ai suoi fari quali endpoint aggiuntivi possono raggiungerlo. La proprietà è la vera differenza: la mappa è mantenuta da tutti quelli che ne hanno bisogno, l’annuncio dall’host stesso.
Decidi in base a chi possiede l’informazione
| Setting | Where it lives | Best for |
|---|---|---|
static_host_map | Every peer that needs the entry | Bootstrap endpoints, deliberately fixed paths |
advertise_addrs | The host's own config | Endpoints the host cannot otherwise discover |
Ogni peer che cambia nel file statico di ogni peer è un lavoro di manutenzione che cresce con il quadrato della flotta. È la ragione pratica per ricorrere all’altra impostazione ogni volta che l’host stesso conosce la risposta.
La questione della proprietà predice anche cosa succede quando un indirizzo cambia. Con una mappa statica, qualcuno deve ricordare ogni peer che detiene la vecchia voce. Con un annuncio, l’host pubblica il nuovo endpoint e i suoi fari lo trasmettono, così il cambiamento resta locale alla macchina che si è spostata.
Bootstrap ha ancora bisogno di voci statiche
Un client deve raggiungere almeno un faro prima di poter chiedere a chiunque di altri peer. Quel primo salto non può venire dalla scoperta, quindi viene da una voce statica nella configurazione del client. Fai bene quella singola voce e il resto dell’overlay può essere appreso.
Una voce della mappa abbina un indirizzo Nebula a uno o più endpoint IP o DNS raggiungibili e a porte. Tenere lì i fari è normale; tenere lì ogni peer è lo schema che invecchia male, perché ogni nuovo peer significa modificare file su macchine che forse non controlli. Mantieni la lista abbastanza corta che una persona possa ancora verificarla leggendola.
Annuncia quando l’host conosce l’endpoint
Un host dietro inoltro di porte è raggiungibile a un indirizzo pubblico che non è assegnato a nessuna delle sue interfacce. Non può scoprire quell’indirizzo guardando se stesso. advertise_addrs gli permette di pubblicare l’endpoint tramite i suoi fari, così gli altri peer imparano un percorso che funziona davvero. L’impostazione esiste proprio perché l’host è l’unica parte che sa che la mappatura è stata fatta.
Usa l’indirizzo e la porta che gli altri peer possono realmente raggiungere. Lo stesso ragionamento vale per un host con diversi percorsi di rete, dove un percorso è preferibile per i peer su una rete particolare. L’annuncio è un’affermazione sull’underlay, non una richiesta di qualcosa. Quando la mappatura cambia, aggiorna l’annuncio sull’host e lascia che la scoperta lo porti, invece di modificare file statici in tutta la flotta.
Annunciare non è raggiungibilità
Pubblicare un endpoint non crea la regola di inoltro del router, non apre un firewall a monte e non fa risolvere un nome DNS. Sono pezzi di lavoro separati, e un annuncio corretto con un inoltro di porta mancante produce esattamente il guasto che stavi cercando di correggere. Annunciare è un’affermazione sulla raggiungibilità, non un meccanismo che la stabilisce.
Controlla il percorso dall’esterno prima di incolpare la scoperta. Un peer che impara l’endpoint ma non riesce a completare un handshake ha un problema di routing o di filtraggio sull’underlay, e ripetere lo stesso indirizzo in entrambe le impostazioni non lo cambierà.
Tieni l’indirizzo overlay separato dall’endpoint
Il certificato del nodo identifica il suo indirizzo Nebula. Gli indirizzi annunciati appartengono alla rete sottostante e possono cambiare senza toccare il certificato. Emettere un nuovo certificato con un IP overlay diverso è un’operazione diversa, con le sue conseguenze per ogni relazione di fiducia che aveva fissato la vecchia. Tieni le due modifiche separate nel runbook, altrimenti uno spostamento di endpoint verrà registrato come una riemissione.
Quando il triage si blocca, separa esplicitamente i due livelli: la scoperta restituisce l’endpoint atteso, e un handshake lo raggiunge? Se la scoperta è corretta e i pacchetti falliscono, il problema è sotto l’overlay. Se la scoperta è sbagliata, il problema è nella mappa o nell’annuncio, e la correzione appartiene lì.