Nebula-lighthouse-filtre kontra brannmur: hva hver av dem blokkerer

Se på en Nebula-handshake fra feil ende, og de to mekanismene virker utskiftbare. Den ene avgjør hvilke adresser en node forteller lighthouse om og hvilke eksterne adresser den vil forsøke; den andre avgjør hva som får passere når tunnelen finnes. Et filter kan stoppe en tilkobling før noen brannmurregel vurderes, og en brannmurregel kan ikke gjenopplive et endepunkt som oppdagelsen fjernet. De to lagene svarer på ulike spørsmål, og rekkefølgen de virker i, er nøkkelen.

Følg én tilkobling gjennom fire trinn: den annonserte lokale adressen, det eksterne endepunktet som vurderes, handshaken og trafikken i overlayet. Hvert trinn har sin egen konfigurasjon og sitt eget feilsignatur.

Start ved den lokale adressen som noden annonserer

local_allow_list filtrerer denne vertens lokale adresser før de rapporteres til lighthouses. Oppføringene kan være adresseområder, og konfigurasjonen støtter også mønstre for grensesnittnavn. Det er nyttig når en vert har containerbroer eller ekstra tunnelgrensesnitt som ikke bør bli peer-endepunkter.

Gå gjennom vertens grensesnitt og spør hvilke en ekstern peer faktisk kan nå. En Docker-bro-adresse er lokal for den verten og ubrukelig for en peer i et annet nett. Å annonsere den sløser med oppdagelsen og kan sende en peer mot en adresse som aldri svarer. Alt en peer ikke kan rute til, er støy i lighthouse-svaret.

En smal tillatelsesliste er tryggere her enn en bred blokkeringsliste. Hvis bare tillatelsesoppføringer finnes, utelukkes resten som ikke er angitt; å legge til en blokkeringsføring senere endrer standardlogikken og krever sin egen gjennomgang. Den endringen fortjener et nytt blikk på standarden.

Se deretter på valget av eksternt endepunkt

remote_allow_list filtrerer adressene denne verten vil vurdere for en ekstern peer under en handshake. Det gjelder underlay-adressen, ikke overlay-adressen peeren bruker når tunnelen er oppe.

Et privat område kan være helt brukbart på et delt kontornett og meningsløst når de to vertene sitter i ubeslektede nett som begge bruker 10.0.0.0/8. Filteret lar deg foretrekke den rutbare veien og ignorere tilfeldigheten.

Når en peer ikke får tilkobling, sammenlign adressen som forsøkes med regelen som passer til den. Slå på handshake-loggene og les den valgte eksterne adressen; logglinjen navngir endepunktet som overlevde filtreringen, noe som er mer nyttig enn listen over adresser peeren eier.

Et filter for grensesnittnavn på annonseringssiden kan fjerne endepunktet før mottakersiden i det hele tatt ser det. Kontroller begge nodene når bare én retning feiler.

Etter handshaken gjelder overlayets tilgangsregler

Nebula-brannmurregler virker inne i overlayet, etter at tunnelen er etablert. De matcher verter, grupper, porter og protokoller, og avgjør om en pakke kan komme inn i eller forlate den lokale verten. De velger ikke et underlay-endepunkt.

Denne delingen forklarer en vanlig feildiagnose. En operatør legger til en brannmurregel for en port og kan fortsatt ikke koble til, fordi lighthouse-filteret fjernet det eneste nåbare endepunktet. En annen operatør åpner adressefilteret og når fortsatt ikke tjenesten, fordi overlay-brannmuren avviser porten.

Les feilen på riktig lag. En handshake som aldri fullføres, peker på oppdagelse, endepunktfiltrering eller nettverksveien. En fullført handshake etterfulgt av en avvist eller forkastet tjenestetilkobling peker på overlay-brannmuren eller applikasjonen.

Les standarden når tillat og blokker blandes

Lighthouse-konfigurasjonen støtter lister med bare tillat, bare blokker og blandede, og standarden for resten som ikke er angitt, er forskjellig mellom disse formene. En blandet liste trenger en eksplisitt standard for adressefamilien; å anta at resten oppfører seg som den forrige konfigurasjonen, er hvordan et fungerende endepunkt stille forsvinner.

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

Behandle standarden som en del av regelen, ikke som boilerplate. Hvis familiens standard er blokker, utelukkes hver adresse som ikke er oppført, også et nytt kontorområde som ble lagt til etter at konfigurasjonen ble skrevet.

Noter hvilke adresser som var ment å være nåbare, og test fra begge sider. Et filter som virker for ett peer-par, kan feile for et annet par der den eneste felles veien bruker en adresse listen utelukker.

Bruk relay når ingen direkte endepunkter er nåbare

Hvis hvert kandidat-endepunkt er filtrert bort eller unåelig, er svaret ikke en bredere tillatelsesliste som slipper inn adresser du ikke stoler på igjen. Nebulas relay-konfigurasjon gir en alternativ peer-vei når direkte tilkobling ikke er gjennomførbar.

Relay løser transport og oppdagelse, ikke autorisasjon, og det utvider ikke brannmuren. Overlay-brannmuren avgjør fortsatt hvilke tjenester som kan brukes, og relay gjør ikke lighthouse-filtrering til en tilgangskontrollmekanisme.

Test relay-veien med de direkte endepunktene deaktivert og bekreft at den tiltenkte tjenesten fortsatt virker mens en utilsiktet ikke gjør det. Den ene testen skiller en transportretting fra en policyendring og holder de to lagene ærlige.