Nebula-lighthouse-filter kontra brannmur: kva kvar av dei blokkerer

Sjå på ein Nebula-handshake frå feil ende, og dei to mekanismane verkar utskiftbare. Den eine avgjer kva adresser ein node fortel lighthouse om og kva eksterne adresser han vil prøve; den andre avgjer kva som får passere når tunnelen finst. Eit filter kan stoppe ei tilkopling før noka brannmurregel vert vurdert, og ei brannmurregel kan ikkje gjenopplive eit endepunkt som oppdaginga fjerna. Dei to laga svarar på ulike spørsmål, og rekkjefølgja dei verkar i, er nøkkelen.

Fylg éi tilkopling gjennom fire trinn: den annonserte lokale adressa, det eksterne endepunktet som vert vurdert, handshaken og trafikken i overlayet. Kvart trinn har si eiga konfigurering og sitt eige feilsignatur.

Start ved den lokale adressa som noden annonserer

local_allow_list filtrerer dei lokale adressene til denne verten før dei vert rapporterte til lighthouses. Oppføringane kan vere adresseområde, og konfigureringa støttar òg mønster for grensesnittnamn. Det er nyttig når ein vert har containerbruer eller ekstra tunnelgrensesnitt som ikkje bør bli peer-endepunkt.

Gå gjennom grensesnitta til verten og spør kva ein ekstern peer faktisk kan nå. Ei Docker-bru-adresse er lokal for den verten og ubrukeleg for ein peer i eit anna nett. Å annonsere ho sløser med oppdaginga og kan sende ein peer mot ei adresse som aldri svarar. Alt ein peer ikkje kan rute til, er støy i lighthouse-svaret.

Ei smal tillatingsliste er tryggare her enn ei brei blokkeringsliste. Viss berre tillatingsoppføringar finst, vert resten som ikkje er angjeven utelukka; å leggje til ei blokkeringsføring seinare endrar standardlogikken og krev si eiga gjennomgang. Den endringa fortener eit nytt blikk på standarden.

Sjå deretter på valet av eksternt endepunkt

remote_allow_list filtrerer adressene denne verten vil vurdere for ein ekstern peer under ein handshake. Det gjeld underlay-adressa, ikkje overlay-adressa peeren brukar når tunnelen er oppe.

Eit privat område kan vere heilt brukbart på eit delt kontornett og meiningslaust når dei to vertane sit i ubeslekta nett som begge brukar 10.0.0.0/8. Filteret lèt deg føretrekkje den rutbare vegen og ignorere tilfeldet.

Når ein peer ikkje får tilkopling, samanlikn adressa som vert prøvd med regelen som passar til ho. Slå på handshake-loggene og les den valde eksterne adressa; logglinja namngjev endepunktet som overlevde filtreringa, noko som er nyttigare enn lista over adresser peeren eig.

Eit filter for grensesnittnamn på annonseringssida kan fjerne endepunktet før mottaksida i det heile ser det. Kontroller begge nodane når berre éi retning feilar.

Etter handshaken gjeld tilgangsreglane i overlayet

Nebula-brannmurreglar verkar inne i overlayet, etter at tunnelen er etablert. Dei matchar vertar, grupper, portar og protokollar, og avgjer om ein pakke kan kome inn i eller forlate den lokale verten. Dei vel ikkje eit underlay-endepunkt.

Denne delinga forklarar ein vanleg feildiagnose. Ein operatør legg til ei brannmurregel for ein port og kan framleis ikkje kople til, fordi lighthouse-filteret fjerna det einaste nåbare endepunktet. Ein annan operatør opnar adressefilteret og når framleis ikkje tenesta, fordi overlay-brannmuren avviser porten.

Les feilen på rett lag. Ein handshake som aldri vert fullført, peikar på oppdaging, endepunktfiltrering eller nettverksvegen. Ein fullført handshake etterfylgd av ei avvist eller forkasta tenestetilkopling peikar på overlay-brannmuren eller applikasjonen.

Les standarden når tillate og blokkere vert blanda

Lighthouse-konfigureringa støttar lister med berre tillate, berre blokkere og blanda, og standarden for resten som ikkje er angjeven, er ulik mellom desse formene. Ei blanda liste treng ein eksplisitt standard for adressefamilien; å tru at resten oppfører seg som den førre konfigureringa, er korleis eit fungerande endepunkt stille forsvinn.

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

Handter standarden som ein del av regelen, ikkje som boilerplate. Viss standarden til familien er blokkere, vert kvar adresse som ikkje er oppført utelukka, òg eit nytt kontorområde som vart lagt til etter at konfigureringa vart skriven.

Noter kva adresser som var meint å vere nåbare, og test frå begge sider. Eit filter som verkar for eitt peer-par, kan feile for eit anna par der den einaste felles vegen brukar ei adresse lista utelukkar.

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

Viss kvart kandidat-endepunkt er filtrert bort eller unåeleg, er svaret ikkje ei breiare tillatingsliste som slepp inn adresser du ikkje stolar på igjen. Relay-konfigureringa til Nebula gjev ein alternativ peer-veg når direkte tilkopling ikkje er gjennomførleg.

Relay løyser transport og oppdaging, ikkje autorisasjon, og det utvidar ikkje brannmuren. Overlay-brannmuren avgjer framleis kva tenester som kan brukast, og relay gjer ikkje lighthouse-filtrering til ein tilgangskontrollmekanisme.

Test relay-vegen med dei direkte endepunkta deaktiverte og stadfest at den tiltenkte tenesta framleis verkar medan ei utilsikta ikkje gjer det. Den eine testen skil ei transportretting frå ei policyendring og held dei to laga ærlege.