Nebula-lighthouse-filters versus firewall: wat elk blokkeert

Bekijk een Nebula-handshake vanaf de verkeerde kant en de twee mechanismen lijken uitwisselbaar. Het ene bepaalt welke adressen een node aan de lighthouse meldt en welke externe adressen hij zal proberen; het andere bepaalt wat er door mag zodra de tunnel bestaat. Een filter kan een verbinding stoppen voordat er ook maar één firewallregel wordt geëvalueerd, en een firewallregel kan een eindpunt dat de ontdekking heeft verwijderd niet nieuw leven inblazen. De twee lagen beantwoorden verschillende vragen, en de volgorde waarin ze werken is de sleutel.

Volg één verbinding door vier fasen: het aangekondigde lokale adres, het overwogen externe eindpunt, de handshake en het verkeer in de overlay. Elke fase heeft zijn eigen configuratie en zijn eigen faalhandtekening.

Begin bij het lokale adres dat de node aankondigt

local_allow_list filtert de lokale adressen van deze host voordat ze aan lighthouses worden gerapporteerd. De vermeldingen kunnen adresbereiken zijn, en de configuratie ondersteunt ook patronen voor interfacenamen. Dat is nuttig wanneer een host containerbruggen of extra tunnelinterfaces heeft die geen peer-eindpunten mogen worden.

Loop de interfaces van de host langs en vraag welke een externe peer werkelijk kan bereiken. Een Docker-brugadres is lokaal voor die host en nutteloos voor een peer in een ander netwerk. Het aankondigen verspilt ontdekking en kan een peer naar een adres sturen dat nooit antwoordt. Alles waar een peer niet naartoe kan routeren, is ruis in het antwoord van de lighthouse.

Een smalle toestemmingslijst is hier veiliger dan een brede blokkeerlijst. Als er alleen toestemmingsvermeldingen zijn, wordt de niet-opgegeven rest uitgesloten; een blokkeervermelding later toevoegen verandert de standaardlogica en vereist een eigen beoordeling. Die wijziging verdient een tweede blik op de standaardwaarde.

Let daarna op de selectie van het externe eindpunt

remote_allow_list filtert de adressen die deze host voor een externe peer overweegt tijdens een handshake. Het geldt voor het underlay-adres, niet voor het overlay-adres dat de peer gebruikt nadat de tunnel staat.

Een particulier bereik kan op een gedeeld kantoornetwerk volledig bruikbaar zijn en zinloos wanneer de twee hosts in onverwante netwerken zitten die beide 10.0.0.0/8 gebruiken. Het filter laat u het routeerbare pad verkiezen en het toeval negeren.

Als een peer geen verbinding maakt, vergelijk dan het geprobeerde adres met de regel die erbij past. Schakel de handshake-logboeken in en lees het gekozen externe adres; de logregel noemt het eindpunt dat de filtering overleefde, wat nuttiger is dan de lijst met adressen die de peer bezit.

Een interfacenaamfilter aan de aankondigingskant kan het eindpunt verwijderen voordat de ontvangende kant het ooit ziet. Controleer beide nodes wanneer slechts één richting faalt.

Na de handshake gelden de toegangsregels van de overlay

Nebula-firewallregels werken binnen de overlay, nadat de tunnel is opgezet. Ze matchen hosts, groepen, poorten en protocollen, en bepalen of een pakket de lokale host mag binnenkomen of verlaten. Ze selecteren geen underlay-eindpunt.

Deze scheiding verklaart een veelvoorkomende verkeerde diagnose. Een beheerder voegt een firewallregel voor een poort toe en kan nog steeds geen verbinding maken, omdat het lighthouse-filter het enige bereikbare eindpunt heeft verwijderd. Een andere beheerder opent het adresfilter en bereikt de dienst nog steeds niet, omdat de overlay-firewall de poort weigert.

Lees de fout op de juiste laag. Een handshake die nooit voltooit, wijst op ontdekking, eindpuntfiltering of het netwerkpad. Een voltooide handshake gevolgd door een geweigerde of weggevallen dienstverbinding wijst op de overlay-firewall of de toepassing.

Lees de standaardwaarde bij het mengen van toestaan en blokkeren

De lighthouse-configuratie ondersteunt lijsten met alleen toestaan, alleen blokkeren en gemengd, en de standaardwaarde voor de niet-opgegeven rest verschilt tussen die vormen. Een gemengde lijst vereist een expliciete standaardwaarde voor de adresfamilie; aannemen dat de rest zich gedraagt zoals de vorige configuratie is hoe een werkend eindpunt stil verdwijnt.

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

Behandel de standaardwaarde als onderdeel van de regel, niet als boilerplate. Als de standaardwaarde van de familie blokkeren is, wordt elk niet-vermelde adres uitgesloten, inclusief een nieuw kantoorbereik dat werd toegevoegd nadat de configuratie was geschreven.

Noteer welke adressen bereikbaar moesten zijn en test van beide kanten. Een filter dat voor één peerpaar werkt, kan falen voor een ander paar waarvan het enige gemeenschappelijke pad een adres gebruikt dat de lijst uitsluit.

Gebruik relay wanneer geen direct eindpunt bereikbaar is

Als elk kandidaat-eindpunt wordt uitgefilterd of onbereikbaar is, is het antwoord geen bredere toestemmingslijst die adressen opnieuw toelaat die u niet vertrouwt. De relay-configuratie van Nebula biedt een alternatief peerpad wanneer directe connectiviteit niet haalbaar is.

Relay lost transport en ontdekking op, niet autorisatie, en het verbreedt de firewall niet. De overlay-firewall bepaalt nog steeds welke diensten mogen worden gebruikt, en relay maakt van lighthouse-filtering geen toegangscontrolemechanisme.

Test het relaypad met de directe eindpunten uitgeschakeld en bevestig dat de bedoelde dienst nog werkt terwijl een onbedoelde dat niet doet. Die ene test scheidt een transportreparatie van een beleidswijziging en houdt de twee lagen eerlijk.