Nebula-vuurtoringfilters teenoor firewall: wat elkeen blokkeer

Kyk na ’n Nebula-handskud vanaf die verkeerde kant en die twee meganismes lyk uitruilbaar. Die een bepaal watter adresse ’n nodus aan die vuurtoring rapporteer en watter afgeleë adresse dit sal probeer; die ander bepaal wat mag deurkom sodra die tonnel bestaan. ’n Filter kan ’n verbinding stop voordat enige firewallreël geëvalueer word, en ’n firewallreël kan nie ’n eindpunt herstel wat deur ontdekking verwyder is nie. Die twee lae beantwoord verskillende vrae, en die volgorde waarin hulle optree is die sleutel.

Volg een verbinding deur vier fases: die plaaslike adres wat geadverteer word, die afgeleë eindpunt wat oorweeg word, die handskud en die overlay-verkeer. Elke fase het sy eie konfigurasie en sy eie foutprofiel.

Begin by die plaaslike adres wat die nodus adverteer

local_allow_list filtreer hierdie gasheer se plaaslike adresse voordat hulle aan vuurtorings gerapporteer word. Die inskrywings kan adresreekse wees, en die konfigurasie ondersteun ook patrone vir koppelvlakname. Dit is nuttig wanneer ’n gasheer containerbrûe of ekstra tonnelkoppelvlakke het wat nie portureindpunte moet word nie.

Gaan die gasheer se koppelvlakke na en vra watter een ’n afgeleë portuur werklik kan bereik. ’n Docker-brugadres is plaaslik aan daardie gasheer en nutteloos vir ’n portuur in ’n ander netwerk. Om dit te adverteer mors ontdekking en kan ’n portuur na ’n adres stuur wat nooit antwoord nie. Enigiets wat ’n portuur nie kan routeer nie, is geraas in die vuurtoring se antwoord.

’n Smal toelaatlys is hier veiliger as ’n breë weierlys. As slegs toelaat-inskrywings teenwoordig is, word die ongespesifiseerde res uitgesluit; om later ’n weier-inskrywing by te voeg verander die versteklogika en verg sy eie hersiening. Daardie verandering verdien ’n tweede blik op die verstek.

Kyk dan na die keuse van die afgeleë eindpunt

remote_allow_list filtreer die adresse wat hierdie gasheer vir ’n afgeleë portuur sal oorweeg tydens ’n handskud. Dit geld vir die onderlaagadres, nie vir die overlay-adres wat die portuur ná die tonnel sal gebruik nie.

’n Privaat reeks kan heeltemal bruikbaar wees op ’n gedeelde kantoornetwerk en betekenisloos wanneer die twee gashere in onverwante netwerke sit wat albei 10.0.0.0/8 gebruik. Die filter laat jou die routeerbare pad verkies en die toevalligheid ignoreer.

Wanneer ’n portuur nie kan koppel nie, vergelyk die adres wat probeer word met die reël wat daarby pas. Aktiveer die handskudlogboeke en lees die gekose afgeleë adres; die logreël noem die eindpunt wat filtering oorleef het, wat nuttiger is as die lys adresse wat die portuur besit.

’n Koppelvlaknaamfilter aan die adverteerkant kan die eindpunt verwyder voordat die ontvangende kant dit ooit sien. Kontroleer albei nodusse wanneer slegs een rigting misluk.

Ná die handskud geld die overlay-toegangsreëls

Nebula-firewallreëls werk binne die overlay, nadat die tonnel gevestig is. Hulle pas gashere, groepe, poorte en protokolle, en hulle besluit of ’n pakket die plaaslike gasheer mag binnekom of verlaat. Hulle kies nie ’n onderlaag-eindpunt nie.

Hierdie skeiding verduidelik ’n algemene verkeerde diagnose. ’n Operateur voeg ’n firewallreël vir ’n poort by en kan steeds nie koppel nie, want die vuurtoringfilter het die enigste bereikbare eindpunt verwyder. ’n Ander operateur maak die adresfilter oop en kan steeds nie die diens bereik nie, want die overlay-firewall verwerp die poort.

Lees die fout op die regte laag. ’n Handskud wat nooit voltooi nie, dui op ontdekking, eindpuntfiltering of die netwerkpad. ’n Voltooide handskud gevolg deur ’n geweierde of weggegooide diensverbinding dui op die overlay-firewall of die toepassing.

Lees die verstek wanneer toelaat en weier gemeng word

Die vuurtoringkonfigurasie ondersteun slegs-toelaat-, slegs-weier- en gemengde lyste, en die verstek vir die ongespesifiseerde res verskil tussen daardie vorms. ’n Gemengde lys het ’n eksplisiete verstek vir die adresfamilie nodig; om aan te neem die res gedra hom soos die vorige konfigurasie is hoe ’n werkende eindpunt stilweg verdwyn.

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

Behandel die verstek as deel van die reël, nie as boilerplate nie. As die familieverstek weier, word elke adres wat nie gelys is nie uitgesluit, insluitend ’n nuwe kantoorreeks wat ná die konfigurasie bygevoeg is.

Teken aan watter adresse bedoel was om bereikbaar te wees en toets van albei kante. ’n Filter wat vir een portuurpaar werk, kan vir ’n ander paar misluk wie se enigste gemene pad ’n adres gebruik wat die lys uitsluit.

Gebruik relay wanneer geen direkte eindpunt bereikbaar is nie

As elke kandidaat-eindpunt uitgefilter of onbereikbaar is, is die antwoord nie ’n wyer toelaatlys wat adresse heropneem wat jy nie vertrou nie. Nebula se relay-konfigurasie bied ’n alternatiewe portuurpad wanneer direkte verbinding nie werkbaar is nie.

Relay los vervoer en ontdekking op, nie magtiging nie, en dit verbreed nie die firewall nie. Die overlay-firewall besluit steeds watter dienste gebruik mag word, en die relay maak nie van vuurtoringfiltering ’n toegangsbeheermeganisme nie.

Toets die relay-pad met die direkte eindpunte gedeaktiveer en bevestig dat die beoogde diens steeds werk terwyl ’n onbedoelde een nie werk nie. Daardie enkele toets skei ’n vervoeroplossing van ’n beleidsverandering en hou die twee lae eerlik.