Filtri del faro di Nebula contro firewall: cosa blocca ciascuno

Guardate un handshake di Nebula dal lato sbagliato e i due meccanismi sembrano intercambiabili. Uno decide quali indirizzi un nodo annuncia al faro e quali indirizzi remoti proverà; l’altro decide cosa può passare una volta che il tunnel esiste. Un filtro può fermare una connessione prima che venga valutata qualsiasi regola del firewall, e una regola del firewall non può far rivivere un endpoint che la scoperta ha rimosso. I due livelli rispondono a domande diverse, e l’ordine in cui agiscono è la chiave.

Seguite una connessione attraverso quattro fasi: l’indirizzo locale annunciato, l’endpoint remoto considerato, l’handshake e il traffico nel livello sovrapposto. Ogni fase ha la propria configurazione e la propria firma di guasto.

Iniziate dall’indirizzo locale che il nodo annuncia

local_allow_list filtra gli indirizzi locali di questo host prima che vengano riportati ai fari. Le voci possono essere intervalli di indirizzi, e la configurazione supporta anche modelli di nome dell’interfaccia. È utile quando un host ha bridge di container o interfacce tunnel aggiuntive che non devono diventare endpoint dei peer.

Percorrete le interfacce dell’host e chiedete a quali un peer remoto può davvero arrivare. Un indirizzo di bridge Docker è locale a quell’host e inutile per un peer in un’altra rete. Annunciarlo spreca la scoperta e può mandare un peer verso un indirizzo che non risponde mai. Tutto ciò a cui un peer non può instradare è rumore nella risposta del faro.

Una lista di autorizzati stretta è più sicura qui di una lista di bloccati ampia. Se sono presenti solo voci di autorizzazione, il resto non specificato viene escluso; aggiungere dopo una voce di blocco cambia la logica predefinita e richiede una propria revisione. Quel cambiamento merita un secondo sguardo al valore predefinito.

Poi osservate la selezione dell’endpoint remoto

remote_allow_list filtra gli indirizzi che questo host considererà per un peer remoto durante un handshake. Si applica all’indirizzo del livello sottostante, non all’indirizzo del livello sovrapposto che il peer userà dopo che il tunnel è attivo.

Un intervallo privato può essere perfettamente utilizzabile su una rete d’ufficio condivisa e privo di senso quando i due host si trovano in reti non correlate che usano entrambe 10.0.0.0/8. Il filtro vi permette di preferire il percorso instradabile e di ignorare la coincidenza.

Quando un peer non riesce a connettersi, confrontate l’indirizzo in prova con la regola che gli corrisponde. Abilitate i log dell’handshake e leggete l’indirizzo remoto selezionato; la riga di log nomina l’endpoint che ha superato il filtraggio, il che è più utile dell’elenco degli indirizzi posseduti dal peer.

Un filtro di nome dell’interfaccia lato annuncio può rimuovere l’endpoint prima che il lato ricevente lo veda. Controllate entrambi i nodi quando fallisce una sola direzione.

Dopo l’handshake si applicano le regole di accesso del livello sovrapposto

Le regole del firewall di Nebula operano dentro il livello sovrapposto, dopo che il tunnel è stabilito. Corrispondono host, gruppi, porte e protocolli, e decidono se un pacchetto può entrare o uscire dall’host locale. Non selezionano un endpoint del livello sottostante.

Questa separazione spiega una diagnosi errata comune. Un operatore aggiunge una regola del firewall per una porta e ancora non riesce a connettersi, perché il filtro del faro ha rimosso l’unico endpoint raggiungibile. Un altro apre il filtro degli indirizzi e ancora non raggiunge il servizio, perché il firewall del livello sovrapposto rifiuta la porta.

Leggete il guasto al livello giusto. Un handshake che non si completa mai indica la scoperta, il filtraggio degli endpoint o il percorso di rete. Un handshake completato seguito da una connessione al servizio rifiutata o scartata indica il firewall del livello sovrapposto o l’applicazione.

Leggete il valore predefinito quando mescolate autorizzazione e blocco

La configurazione del faro supporta liste solo autorizzate, solo bloccate e miste, e il valore predefinito per il resto non specificato differisce tra queste forme. Una lista mista richiede un valore predefinito esplicito per la famiglia di indirizzi; supporre che il resto si comporti come la configurazione precedente è il modo in cui un endpoint funzionante scompare in silenzio.

lighthouse:
  local_allow_list:
    interfaces:
      docker0: false
  remote_allow_list:
    192.168.0.0/16: true
    default: false

Trattate il valore predefinito come parte della regola, non come testo modello. Se il valore predefinito della famiglia è il blocco, ogni indirizzo non elencato viene escluso, compreso un nuovo intervallo d’ufficio aggiunto dopo la scrittura della configurazione.

Annotate quali indirizzi dovevano essere raggiungibili e provate da entrambi i lati. Un filtro che funziona per una coppia di peer può fallire per un’altra coppia il cui unico percorso comune usa un indirizzo che la lista esclude.

Usate il relay quando nessun endpoint diretto è raggiungibile

Se ogni endpoint candidato viene filtrato o è irraggiungibile, la risposta non è una lista di autorizzati più ampia che riammette indirizzi di cui non vi fidate. La configurazione relay di Nebula offre un percorso peer alternativo quando la connettività diretta non è praticabile.

Il relay risolve trasporto e scoperta, non l’autorizzazione, e non allarga il firewall. Il firewall del livello sovrapposto decide ancora quali servizi possono essere usati, e il relay non trasforma il filtraggio del faro in un meccanismo di controllo degli accessi.

Provate il percorso relay con gli endpoint diretti disattivati e confermate che il servizio desiderato funziona ancora mentre uno non desiderato no. Quell’unica prova separa una correzione di trasporto da un cambio di politica e mantiene onesti i due livelli.