Lighthouse-filtre i Nebula kontra firewall: hvad hvert lag blokerer

Se på et Nebula-handshake fra den forkerte ende, og de to mekanismer virker udskiftelige. Den ene afgør, hvilke adresser en node fortæller lighthouset om, og hvilke fjernadresser den vil forsøge; den anden afgør, hvad der må passere, når tunnelen findes. Et filter kan stoppe en forbindelse, før nogen firewallregel evalueres, og en firewallregel kan ikke genoplive et endpoint, som discovery fjernede. De to lag besvarer forskellige spørgsmål, og rækkefølgen, de virker i, er nøglen.

Følg én forbindelse gennem fire faser: den lokale adresse, der annonceres, det fjernendpoint, der overvejes, handshaket og trafikken i overlayet. Hver fase har sin egen konfiguration og sit eget fejlsignatur.

Start ved den lokale adresse, som noden annoncerer

local_allow_list filtrerer denne hosts lokale adresser, før de rapporteres til lighthouses. Posterne kan være adresseområder, og konfigurationen understøtter også mønstre for grænsefladenavne. Det er nyttigt, når en host har containerbroer eller ekstra tunnelgrænseflader, som ikke bør blive peer-endpoints.

Gennemgå hostens grænseflader, og spørg hvilke en fjern-peer faktisk kan nå. En Docker-bro-adresse er lokal for den host og ubrugelig for en peer i et andet netværk. At annoncere den spilder discovery og kan sende en peer mod en adresse, der aldrig svarer. Alt, som en peer ikke kan route til, er støj i lighthouse-svaret.

En smal tilladelsesliste er sikrere her end en bred blokeringsliste. Hvis der kun findes tilladelsesposter, udelukkes resten, som ikke er angivet; tilføjer man senere en blokeringspost, ændres standardlogikken og kræver sin egen gennemgang. Den ændring fortjener et andet blik på standarden.

Se derefter på valget af fjernendpoint

remote_allow_list filtrerer de adresser, som denne host vil overveje for en fjern-peer under et handshake. Det gælder underlay-adressen, ikke overlay-adressen, som peeren bruger, når tunnelen er oppe.

Et privat område kan være helt brugbart på et delt kontornetværk og meningsløst, når de to hosts sidder i ubeslægtede netværk, der begge bruger 10.0.0.0/8. Filteret lader dig foretrække den rutbare vej og ignorere tilfældigheden.

Når en peer ikke kan forbinde, sammenlign den adresse, der forsøges, med reglen, der matcher den. Slå handshake-logfilerne til, og læs den valgte fjernadresse; loglinjen navngiver det endpoint, som overlevede filtreringen, hvilket er mere nyttigt end listen over adresser, peeren ejer.

Et filter for grænsefladenavne på annonceringssiden kan fjerne endpointet, før modtagersiden overhovedet ser det. Kontrollér begge noder, når kun én retning fejler.

Efter handshaket gælder overlayets adgangsregler

Nebula-firewallregler virker inde i overlayet, efter tunnelen er etableret. De matcher hosts, grupper, porte og protokoller og afgør, om en pakke må komme ind i eller forlade den lokale host. De vælger ikke et underlay-endpoint.

Denne adskillelse forklarer en almindelig fejldiagnose. En operatør tilføjer en firewallregel for en port og kan stadig ikke forbinde, fordi lighthouse-filteret fjernede det eneste nåbare endpoint. En anden operatør åbner adressefilteret og kan stadig ikke nå tjenesten, fordi overlay-firewallen afviser porten.

Læs fejlen på det rigtige lag. Et handshake, der aldrig fuldføres, peger på discovery, endpoint-filtrering eller netværksvejen. Et fuldført handshake efterfulgt af en afvist eller droppet tjenesteforbindelse peger på overlay-firewallen eller applikationen.

Læs standarden, når tillad og bloker blandes

Lighthouse-konfigurationen understøtter lister med kun tillad, kun bloker og blandede, og standarden for resten, som ikke er angivet, er forskellig mellem de former. En blandet liste kræver en eksplicit standard for adressefamilien; at antage, at resten opfører sig som den tidligere konfiguration, er hvordan et fungerende endpoint stille forsvinder.

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

Behandl standarden som en del af reglen, ikke som boilerplate. Hvis familiens standard er bloker, udelukkes hver adresse, der ikke er listet, inklusive et nyt kontorområde, som blev tilføjet, efter konfigurationen blev skrevet.

Notér, hvilke adresser der skulle kunne nås, og test fra begge sider. Et filter, der virker for ét peer-par, kan fejle for et andet par, hvis eneste fælles vej bruger en adresse, som listen udelukker.

Brug relay, når intet direkte endpoint kan nås

Hvis hvert kandidat-endpoint er filtreret ud eller uopnåeligt, er svaret ikke en bredere tilladelsesliste, der igen optager adresser, du ikke stoler på. Nebulas relay-konfiguration giver en alternativ peer-vej, når direkte forbindelse ikke er farbar.

Relay løser transport og discovery, ikke autorisation, og det udvider ikke firewallen. Overlay-firewallen afgør stadig, hvilke tjenester der må bruges, og relay gør ikke lighthouse-filtrering til en adgangskontrolmekanisme.

Test relay-vejen med de direkte endpoints deaktiveret, og bekræft, at den tilsigtede tjeneste stadig virker, mens en utilsigtet ikke gør. Den ene test skiller en transportrettelse fra en politikændring og holder de to lag ærlige.