Nebulas fyrfilter kontra brandvägg: vad var och en blockerar

Titta på en Nebula-handskakning från fel ände och de två mekanismerna verkar utbytbara. Den ena avgör vilka adresser en nod berättar för fyren och vilka fjärradresser den kommer att försöka; den andra avgör vad som får passera när tunneln finns. Ett filter kan stoppa en anslutning innan någon brandväggsregel utvärderas, och en brandväggsregel kan inte återuppliva en slutpunkt som upptäckten tog bort. De två lagren svarar på olika frågor, och ordningen de verkar i är nyckeln.

Följ en anslutning genom fyra steg: den annonserade lokala adressen, den övervägda fjärrslutpunkten, handskakningen och trafiken i överlagret. Varje steg har sin egen konfiguration och sin egen felsignatur.

Börja vid den lokala adress som noden annonserar

local_allow_list filtrerar den här värdens lokala adresser innan de rapporteras till fyrar. Posterna kan vara adressområden, och konfigurationen stöder även mönster för gränssnittsnamn. Det är användbart när en värd har containerbryggor eller extra tunnelgränssnitt som inte bör bli peer-slutpunkter.

Gå igenom värdens gränssnitt och fråga vilka en fjärrpeer faktiskt kan nå. En Docker-bryggadress är lokal för den värden och oanvändbar för en peer i ett annat nät. Att annonsera den slösar upptäckt och kan skicka en peer mot en adress som aldrig svarar. Allt en peer inte kan routa till är brus i fyrets svar.

En smal tillåtelselista är säkrare här än en bred blockeringslista. Om bara tillåtelseposter finns utesluts resten som inte angetts; att lägga till en blockeringspost senare ändrar standardlogiken och kräver sin egen granskning. Den ändringen förtjänar en andra titt på standarden.

Observera sedan valet av fjärrslutpunkt

remote_allow_list filtrerar de adresser som den här värden överväger för en fjärrpeer under en handskakning. Det gäller underlagsadressen, inte överlagsadressen som peeren använder när tunneln är uppe.

Ett privat område kan vara helt användbart i ett delat kontorsnät och meningslöst när de två värdarna sitter i orelaterade nät som båda använder 10.0.0.0/8. Filtret låter dig föredra den routbara vägen och ignorera sammanträffandet.

När en peer inte kan ansluta, jämför adressen som prövas med regeln som matchar den. Slå på handskakningsloggarna och läs den valda fjärradressen; loggraden namnger slutpunkten som överlevde filtreringen, vilket är mer användbart än listan över adresser som peeren äger.

Ett gränssnittsnamnsfilter på annonseringssidan kan ta bort slutpunkten innan mottagarsidan ens ser den. Kontrollera båda noderna när bara en riktning misslyckas.

Efter handskakningen gäller överlagrets åtkomstregler

Nebulas brandväggsregler verkar inne i överlagret, efter att tunneln upprättats. De matchar värdar, grupper, portar och protokoll och avgör om ett paket får komma in i eller lämna den lokala värden. De väljer ingen underlagsslutpunkt.

Den här uppdelningen förklarar en vanlig feldiagnos. En operatör lägger till en brandväggsregel för en port och kan fortfarande inte ansluta, eftersom fyrfiltret tog bort den enda nåbara slutpunkten. En annan operatör öppnar adressfiltret och når fortfarande inte tjänsten, eftersom överlagrets brandvägg avvisar porten.

Läs felet på rätt lager. En handskakning som aldrig slutförs pekar på upptäckt, slutpunktsfiltrering eller nätverksvägen. En slutförd handskakning följd av en avvisad eller tappad tjänstanslutning pekar på överlagrets brandvägg eller på applikationen.

Läs standarden när tillåt och blockera blandas

Fyrkonfigurationen stöder listor med bara tillåt, bara blockera och blandade, och standarden för resten som inte angetts skiljer sig mellan dessa former. En blandad lista behöver en uttrycklig standard för adressfamiljen; att anta att resten beter sig som den tidigare konfigurationen är hur en fungerande slutpunkt tyst försvinner.

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

Behandla standarden som en del av regeln, inte som boilerplate. Om familjens standard är blockera utesluts varje adress som inte listas, inklusive ett nytt kontorsområde som lades till efter att konfigurationen skrevs.

Anteckna vilka adresser som var avsedda att vara nåbara och testa från båda sidor. Ett filter som fungerar för ett peer-par kan misslyckas för ett annat par vars enda gemensamma väg använder en adress som listan utesluter.

Använd relay när ingen direkt slutpunkt är nåbar

Om varje kandidatslutpunkt filtreras bort eller är onåbar är svaret inte en bredare tillåtelselista som åter släpper in adresser du inte litar på. Nebulas relay-konfiguration ger en alternativ peer-väg när direkt anslutning inte är genomförbar.

Relay löser transport och upptäckt, inte auktorisering, och det vidgar inte brandväggen. Överlagrets brandvägg avgör fortfarande vilka tjänster som får användas, och relay gör inte fyrfiltrering till en åtkomstkontrollmekanism.

Testa relay-vägen med de direkta slutpunkterna avstängda och bekräfta att den avsedda tjänsten fortfarande fungerar medan en oavsiktlig inte gör det. Det enda testet skiljer en transporträttelse från en policyändring och håller de två lagren ärliga.