Filtres del far de Nebula enfront del tallafoc: què bloqueja cadascun

Mireu un handshake de Nebula des del costat equivocat i els dos mecanismes semblen intercanviables. Un decideix quines adreces un node explica al far i quines adreces remotes provarà; l'altre decideix què pot passar quan el túnel ja existeix. Un filtre pot aturar una connexió abans que s'avaluï cap regla del tallafoc, i una regla del tallafoc no pot reviure un punt final que el descobriment ha eliminat. Les dues capes responen preguntes diferents, i l'ordre en què actuen és la clau.

Seguiu una connexió per quatre etapes: l'adreça local anunciada, el punt final remot considerat, el handshake i el trànsit de la capa superposada. Cada etapa té la seva configuració i la seva empremta de fallada.

Comenceu per l'adreça local que anuncia el node

local_allow_list filtra les adreces locals d'aquest amfitrió abans que s'informin als fars. Les entrades poden ser rangs d'adreces, i la configuració també admet patrons de nom d'interfície. Això és útil quan l'amfitrió té ponts de contenidors o interfícies de túnel addicionals que no haurien de convertir-se en punts finals per als parells.

Recorreu les interfícies de l'amfitrió i pregunteu a quines pot arribar realment un parell remot. Una adreça de pont Docker és local per a aquell amfitrió i inútil per a un parell en una altra xarxa. Anunciar-la malbarata el descobriment i pot enviar un parell cap a una adreça que no respon mai. Tot allò a què un parell no pot encaminar és soroll a la resposta del far.

Una llista d'autoritzacions estreta és més segura aquí que una llista de denegacions àmplia. Si només hi ha entrades d'autorització, la resta no especificada queda exclosa; afegir una entrada de denegació més tard canvia la lògica per defecte i necessita la seva pròpia revisió. Aquest canvi mereix una segona mirada al valor per defecte.

Després observeu la selecció del punt final remot

remote_allow_list filtra les adreces que aquest amfitrió considerarà per a un parell remot durant un handshake. S'aplica a l'adreça de la xarxa subjacent, no a l'adreça de la capa superposada que el parell farà servir després que el túnel estigui aixecat.

Un rang privat pot ser perfectament utilitzable en una xarxa d'oficina compartida i no tenir cap sentit quan els dos amfitrions són en xarxes no relacionades que totes dues fan servir 10.0.0.0/8. El filtre us permet preferir el camí encaminable i ignorar la coincidència.

Quan un parell no es pot connectar, compareu l'adreça que s'intenta amb la regla que li correspon. Activeu els registres del handshake i llegiu l'adreça remota seleccionada; la línia del registre anomena el punt final que ha sobreviscut al filtratge, cosa més útil que la llista d'adreces que posseeix el parell.

Un filtre de nom d'interfície al costat que anuncia pot eliminar el punt final abans que el costat que rep el vegi. Comproveu tots dos nodes quan només falla una direcció.

Després del handshake s'apliquen les regles d'accés de la capa superposada

Les regles del tallafoc de Nebula operen dins de la capa superposada, després que el túnel s'estableixi. Coincideixen amb amfitrions, grups, ports i protocols, i decideixen si un paquet pot entrar o sortir de l'amfitrió local. No seleccionen un punt final de la xarxa subjacent.

Aquesta separació explica un diagnòstic erroni habitual. Un operador afegeix una regla de tallafoc per a un port i encara no es pot connectar, perquè el filtre del far ha eliminat l'únic punt final accessible. Un altre operador obre el filtre d'adreces i encara no arriba al servei, perquè el tallafoc de la capa superposada rebutja el port.

Llegiu la fallada a la capa correcta. Un handshake que no es completa mai apunta al descobriment, al filtratge de punts finals o al camí de xarxa. Un handshake completat seguit d'una connexió de servei rebutjada o descartada apunta al tallafoc de la capa superposada o a l'aplicació.

Llegiu el valor per defecte quan barregeu autoritzar i denegar

La configuració del far admet llistes només d'autorització, només de denegació i mixtes, i el valor per defecte per a la resta no especificada difereix entre aquestes formes. Una llista mixta necessita un valor per defecte explícit per a la família d'adreces; suposar que la resta es comporta com la configuració anterior és com un punt final que funcionava desapareix en silenci.

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

Tracteu el valor per defecte com a part de la regla, no com a text plantilla. Si el valor per defecte de la família és denegar, tota adreça no llistada queda exclosa, inclòs un nou rang d'oficina afegit després d'escriure la configuració.

Anoteu quines adreces havien de ser accessibles i proveu des de tots dos costats. Un filtre que funciona per a una parella de parells pot fallar per a una altra parella si el seu únic camí comú fa servir una adreça que la llista exclou.

Feu servir el relay quan cap punt final directe sigui accessible

Si tots els punts finals candidats queden filtrats o no són accessibles, la resposta no és una llista d'autoritzacions més àmplia que readmet adreces en què no confieu. La configuració de relay de Nebula ofereix un camí alternatiu per als parells quan la connectivitat directa no és viable.

El relay resol el transport i el descobriment, no l'autorització, i no eixampla el tallafoc. El tallafoc de la capa superposada encara decideix quins serveis es poden fer servir, i el relay no converteix el filtratge del far en un mecanisme de control d'accés.

Proveu el camí del relay amb els punts finals directes desactivats i confirmeu que el servei volgut encara funciona mentre que un de no volgut no ho fa. Aquesta única prova separa una correcció de transport d'un canvi de política i manté les dues capes honestes.