Relay Nebula configurato ma inutilizzato: tre impostazioni da controllare

Hai aggiunto un host relay, hai messo il suo indirizzo Nebula in una configurazione, e i due peer continuano a non parlarsi. Succede perché un percorso relay richiede che tre dichiarazioni separate concordino, e solo una di esse si trova sulla macchina che probabilmente hai modificato. Ci sono già passato due volte: una in cui l’host di inoltro non aveva mai ricevuto il ruolo relay, una in cui le impostazioni erano scritte dalla parte sbagliata della connessione. La sequenza qui sotto controlla il ruolo, l’annuncio e il permesso in quest’ordine, e ogni passo ha un comando che ti dice se proseguire.

Mappa i tre ruoli prima di modificare una configurazione

Nebula assegna un compito a ogni host, e questi compiti non si ereditano. Un lighthouse risponde alle domande del tipo dov’è questo peer, così gli host riescono a trovarsi. Un relay inoltra traffico tra due peer che non hanno un percorso diretto funzionante. Un host ordinario non fa né l’una né l’altra cosa. Le tre impostazioni che contano vivono su tre macchine diverse, ed è per questo che una configurazione client che sembra completa può lasciare entrambi i peer in attesa.

# on the discovery host
lighthouse:
  am_lighthouse: true
  hosts: []

# on every other host, point at the discovery host's Nebula address
lighthouse:
  hosts:
    - 10.42.0.1

Un solo sintomo separa le due classi di guasto. Se entrambi i peer si elencano a vicenda e il registro mostra tentativi di handshake che non si completano mai, la scoperta funziona e il percorso dati è bloccato da NAT o da un firewall. Se un peer non viene mai a sapere l’indirizzo dell’altro, il problema è nel lighthouse o nella sua mappa statica degli host, e le impostazioni relay non possono ripararlo.

Verifica quale configurazione ha caricato davvero ogni host prima di modificare qualsiasi altra cosa. Una unit che legge un percorso diverso dal file che hai modificato è una causa comune e imbarazzante del fatto che «la modifica non ha cambiato nulla»:

systemctl cat nebula | grep ExecStart
nebula -version
journalctl -u nebula -n 20 --no-pager

La riga della versione conta in una flotta mista. La gestione dei relay, il comportamento del punching e le chiavi di configurazione accettate non sono identici tra le versioni, quindi non dare per scontato che una build più vecchia capisca una sezione per cui non è stata scritta. Allinea gli host sulla stessa serie minore, esegui poi nebula -test -config /etc/nebula/config.yml su ogni host e confronta l’output prima di fare debug di un trasporto che il codice non implementa.

Abilita il ruolo di inoltro sull’host relay

Il ruolo relay è un solo flag sull’host di inoltro, ed è separato dall’essere un lighthouse. Un host con la scoperta attiva e l’inoltro relay disattivato resta solo un servizio di scoperta. Sul relay:

relay:
  am_relay: true

Quel flag dichiara un’intenzione; non crea raggiungibilità. Un relay deve essere raggiungibile da entrambi i peer, il che in pratica significa un indirizzo pubblico, UDP in ingresso sulla porta Nebula aperta nel firewall dell’host e in qualsiasi gruppo di sicurezza cloud, e nessun doppio NAT davanti. Controlla il socket in ascolto, poi osserva se arrivano i pacchetti del peer:

ss -lunp | grep nebula
tcpdump -ni any udp port 4242 and host 198.51.100.7

Due limiti fanno risparmiare tempo dopo. Non si raggiunge un relay attraverso un altro relay, quindi una catena di nomi relay in una configurazione non sostituisce un percorso utilizzabile verso l’host di inoltro. E un relay inoltra pacchetti; non concede permessi, le regole in ingresso della destinazione decidono ancora se il flusso inoltrato è consentito. Il ruolo e i suoi requisiti sono descritti nella documentazione di configurazione del relay.

Annuncia il relay dalla destinazione, non dal client

È questa inversione che consuma più ore. L’elenco dei relay appartiene all’host che stai cercando di raggiungere, perché dice agli altri peer quali relay si possono usare per raggiungere quell’host. Metterlo sul client che avvia la connessione non serve alla direzione di cui il client ha bisogno:

# on the DESTINATION host: relays others may use to reach me
relay:
  relays:
    - 10.42.0.5

I peer riportano quell’elenco insieme ai loro indirizzi quando si presentano al lighthouse, quindi l’annuncio si propaga tramite la scoperta e non tramite uno scambio diretto. Se la destinazione non raggiunge nessun lighthouse, il suo elenco di relay non si diffonde mai e un relay configurato correttamente resta inattivo. Quel guasto sembra esattamente un relay rotto e non lo è.

Dai alla destinazione un percorso di bootstrap nella stessa passata. La mappa statica degli host lega un indirizzo Nebula a un endpoint pubblico perché il primo handshake abbia dove andare, e serve una voce per il relay se la destinazione deve accettare traffico inoltrato da host che non riesce a raggiungere direttamente:

static_host_map:
  "10.42.0.5": ["203.0.113.10:4242"]

Lascia che il peer che si connette usi il relay

Il lato che avvia ha bisogno del proprio permesso. relay.use_relays è attivo per impostazione predefinita, quindi il caso da cercare è un false esplicito, spesso copiato da un modello scritto prima che esistesse la funzione relay o lasciato da un tentativo precedente di forzare percorsi diretti:

relay:
  use_relays: true

Il permesso da questo lato non è l’unica porta. Le regole in ingresso della destinazione valgono ancora per il pacchetto inoltrato, e la sorgente con cui vengono confrontate è l’identità dentro il tunnel, non l’indirizzo del relay stesso. Quando l’handshake inoltrato si completa e l’applicazione fallisce ancora, leggi il registro della destinazione per la sorgente che ha registrato prima di riscrivere una regola.

Le impostazioni di attraversamento NAT interagiscono con tutto questo. punchy.punch aiuta due peer ad aprire un percorso diretto, e quando ci riesce non c’è traffico relay da osservare; è un successo, non un relay mancante. Una coppia che funziona a intermittenza di solito significa che il punching riesce solo a volte, quindi prova quella coppia più volte invece di trarre una conclusione da un solo tentativo.

Verifica con la coppia che ha fallito, poi ricarica

Prova i due host che hanno davvero fallito, con l’applicazione di cui hanno bisogno. Un ping riuscito dalla tua workstation al servizio del relay stesso non dimostra nulla sull’inoltro tra altri due peer, ed è il falso positivo più comune di tutta questa procedura.

journalctl -u nebula -f | grep -iE "relay|handshake"
ping -c 3 10.42.0.9

Ricarica invece di riavviare, e conferma che il processo in esecuzione abbia ripreso il file che hai modificato. Un riavvio abbatte ogni tunnel e rende la prova successiva più difficile da leggere, mentre un SIGHUP mantiene il processo e gli fa rileggere la configurazione:

sudo systemctl kill -s HUP nebula
# same signal when nebula runs in the foreground
kill -HUP $(pidof nebula)

systemctl reload funziona solo se la unit locale definisce ExecReload, e la unit fornita con il progetto non lo fa, quindi systemctl kill -s HUP è il passo che riesce su un’installazione standard. Dopo la ricarica, leggi il journal per il percorso di configurazione che il processo ha aperto, così sai che è stato letto il file nuovo e non quello che supponevi caricato.

Le impostazioni relay e il punching NAT agiscono entrambi sul percorso; nessuno dei due agisce sull’identità. Se la coppia fallisce ancora l’handshake una volta confermati am_relay, relays e use_relays nella configurazione in esecuzione, controlla che entrambi gli host presentino certificati emessi per i nomi con cui sono configurati e che la CA sia la stessa da entrambi i lati. Tieni ferma la configurazione di certificati e firewall mentre cambi un’impostazione di trasporto alla volta, perché una modifica al certificato e una modifica al relay nello stesso test non ti dicono quale delle due ha spostato l’handshake. Un disallineamento di nome o di CA fallisce nello stesso punto di un relay che non è mai stato trovato, ed è per questo che questa controverifica fa parte della stessa passata.

Poi conferma che ogni dichiarazione stia nel file a cui appartiene:

• am_relay: true sull’host di inoltro, e quell’host raggiungibile via UDP da entrambi i lati.
• relays: con l’indirizzo Nebula di quell’host sulla destinazione.
• use_relays: true sul peer che avvia la connessione.
• Regole in ingresso sulla destinazione che consentono ancora la sorgente reale dopo il cambio di percorso.