Nebula-Lighthouse-Filter gegen Firewall: was jede Schicht blockiert

Betrachtet man einen Nebula-Handshake vom falschen Ende, wirken die beiden Mechanismen austauschbar. Der eine entscheidet, welche Adressen ein Knoten dem Lighthouse meldet und welche entfernten Adressen er versuchen wird; der andere entscheidet, was passieren darf, sobald der Tunnel besteht. Ein Filter kann eine Verbindung stoppen, bevor irgendeine Firewall-Regel ausgewertet wird, und eine Firewall-Regel kann einen Endpunkt nicht wiederbeleben, den die Erkennung entfernt hat. Die beiden Schichten beantworten unterschiedliche Fragen, und die Reihenfolge, in der sie wirken, ist der Schlüssel.

Verfolgen Sie eine Verbindung durch vier Stufen: die angekündigte lokale Adresse, den betrachteten entfernten Endpunkt, den Handshake und den Verkehr im Overlay. Jede Stufe hat ihre eigene Konfiguration und ihre eigene Fehlersignatur.

Beginnen Sie bei der lokalen Adresse, die der Knoten ankündigt

local_allow_list filtert die lokalen Adressen dieses Hosts, bevor sie an Lighthouses gemeldet werden. Die Einträge können Adressbereiche sein, und die Konfiguration unterstützt auch Muster für Schnittstellennamen. Das ist nützlich, wenn ein Host Container-Bridges oder zusätzliche Tunnelschnittstellen hat, die keine Peer-Endpunkte werden sollen.

Gehen Sie die Schnittstellen des Hosts durch und fragen Sie, welche ein entfernter Peer tatsächlich erreichen kann. Eine Docker-Bridge-Adresse ist lokal für diesen Host und für einen Peer in einem anderen Netz nutzlos. Sie anzukündigen verschwendet die Erkennung und kann einen Peer auf eine Adresse schicken, die nie antwortet. Alles, wohin ein Peer nicht routen kann, ist Rauschen in der Antwort des Lighthouses.

Eine enge Erlaubnisliste ist hier sicherer als eine breite Sperrliste. Sind nur Erlaubniseinträge vorhanden, wird der nicht angegebene Rest ausgeschlossen; ein später hinzugefügter Sperreintrag ändert die Standardlogik und braucht eine eigene Prüfung. Diese Änderung verdient einen zweiten Blick auf den Standard.

Beobachten Sie dann die Auswahl des entfernten Endpunkts

remote_allow_list filtert die Adressen, die dieser Host für einen entfernten Peer während eines Handshakes in Betracht zieht. Es gilt für die Underlay-Adresse, nicht für die Overlay-Adresse, die der Peer nach dem Aufbau des Tunnels verwendet.

Ein privater Bereich kann in einem gemeinsam genutzten Büronetz bestens brauchbar und sinnlos sein, wenn die beiden Hosts in unabhängigen Netzen sitzen, die beide 10.0.0.0/8 verwenden. Der Filter lässt Sie den routingfähigen Pfad bevorzugen und den Zufall ignorieren.

Wenn ein Peer keine Verbindung aufbaut, vergleichen Sie die versuchte Adresse mit der Regel, die zu ihr passt. Aktivieren Sie die Handshake-Protokolle und lesen Sie die ausgewählte entfernte Adresse; die Protokollzeile nennt den Endpunkt, der die Filterung überstanden hat, was nützlicher ist als die Liste der Adressen, die der Peer besitzt.

Ein Schnittstellennamenfilter auf der ankündigenden Seite kann den Endpunkt entfernen, bevor die empfangende Seite ihn überhaupt sieht. Prüfen Sie beide Knoten, wenn nur eine Richtung fehlschlägt.

Nach dem Handshake gelten die Zugriffsregeln des Overlays

Nebula-Firewall-Regeln wirken innerhalb des Overlays, nachdem der Tunnel aufgebaut ist. Sie gleichen Hosts, Gruppen, Ports und Protokolle ab und entscheiden, ob ein Paket den lokalen Host betreten oder verlassen darf. Sie wählen keinen Underlay-Endpunkt aus.

Diese Trennung erklärt eine häufige Fehldiagnose. Ein Betreiber fügt eine Firewall-Regel für einen Port hinzu und kann sich weiterhin nicht verbinden, weil der Lighthouse-Filter den einzigen erreichbaren Endpunkt entfernt hat. Ein anderer Betreiber öffnet den Adressfilter und erreicht den Dienst weiterhin nicht, weil die Overlay-Firewall den Port ablehnt.

Lesen Sie den Fehler auf der richtigen Schicht. Ein Handshake, der nie abgeschlossen wird, deutet auf Erkennung, Endpunktfilterung oder den Netzwerkpfad hin. Ein abgeschlossener Handshake, gefolgt von einer abgelehnten oder verworfenen Dienstverbindung, deutet auf die Overlay-Firewall oder die Anwendung hin.

Lesen Sie den Standard, wenn Erlauben und Sperren gemischt werden

Die Lighthouse-Konfiguration unterstützt reine Erlaubnis-, reine Sperr- und gemischte Listen, und der Standard für den nicht angegebenen Rest unterscheidet sich zwischen diesen Formen. Eine gemischte Liste braucht einen ausdrücklichen Standard für die Adressfamilie; anzunehmen, der Rest verhalte sich wie die vorherige Konfiguration, ist der Weg, auf dem ein funktionierender Endpunkt still verschwindet.

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

Behandeln Sie den Standard als Teil der Regel, nicht als Boilerplate. Ist der Familienstandard Sperren, wird jede nicht gelistete Adresse ausgeschlossen, auch ein neuer Bürobereich, der nach dem Schreiben der Konfiguration hinzugefügt wurde.

Notieren Sie, welche Adressen erreichbar sein sollten, und testen Sie von beiden Seiten. Ein Filter, der für ein Peer-Paar funktioniert, kann für ein anderes Paar fehlschlagen, dessen einziger gemeinsamer Pfad eine Adresse nutzt, die die Liste ausschließt.

Nutzen Sie Relay, wenn kein direkter Endpunkt erreichbar ist

Wenn jeder Kandidaten-Endpunkt herausgefiltert oder unerreichbar ist, ist die Antwort keine breitere Erlaubnisliste, die Adressen wieder aufnimmt, denen Sie nicht trauen. Die Relay-Konfiguration von Nebula bietet einen alternativen Peer-Pfad, wenn direkte Konnektivität nicht machbar ist.

Relay löst Transport und Erkennung, nicht Autorisierung, und es erweitert die Firewall nicht. Die Overlay-Firewall entscheidet weiterhin, welche Dienste genutzt werden dürfen, und Relay macht die Lighthouse-Filterung nicht zu einem Zugriffskontrollmechanismus.

Testen Sie den Relay-Pfad mit deaktivierten direkten Endpunkten und bestätigen Sie, dass der beabsichtigte Dienst weiterhin funktioniert, ein unbeabsichtigter aber nicht. Dieser eine Test trennt eine Transportkorrektur von einer Richtlinienänderung und hält die beiden Schichten ehrlich.