Filtros do faro de Nebula fronte á devasa: que bloquea cada un

Mire unha aperta de mans de Nebula desde o lado equivocado e os dous mecanismos parecen intercambiables. Un decide que enderezos anuncia un nodo ao faro e que enderezos remotos intentará; o outro decide que pode pasar unha vez que existe o túnel. Un filtro pode deter unha conexión antes de que se avalíe calquera regra de devasa, e unha regra de devasa non pode revivir un extremo que o descubrimento eliminou. As dúas capas responden preguntas distintas, e a orde na que actúan é a clave.

Siga unha conexión por catro etapas: o enderezo local anunciado, o extremo remoto considerado, a aperta de mans e o tráfico da capa superposta. Cada etapa ten a súa propia configuración e a súa propia sinatura de fallo.

Comece polo enderezo local que anuncia o nodo

local_allow_list filtra os enderezos locais deste equipo antes de que se informen aos faros. As entradas poden ser rangos de enderezos, e a configuración tamén admite patróns de nome de interface. Iso é útil cando un equipo ten pontes de contedores ou interfaces de túnel adicionais que non deberían converterse en extremos de pares.

Percorra as interfaces do equipo e pregunte a cales pode chegar realmente un par remoto. Un enderezo de ponte Docker é local para ese equipo e inútil para un par noutra rede. Anuncialo desperdicia o descubrimento e pode enviar un par cara a un enderezo que nunca responde. Todo aquilo ao que un par non pode encamiñar é ruído na resposta do faro.

Unha lista de permitidos estreita é máis segura aquí que unha lista de denegados ampla. Se só hai entradas de permiso, o resto non especificado queda excluído; engadir unha entrada de denegación despois cambia a lóxica predeterminada e necesita a súa propia revisión. Ese cambio merece unha segunda ollada ao valor predeterminado.

Despois observe a selección do extremo remoto

remote_allow_list filtra os enderezos que este equipo considerará para un par remoto durante unha aperta de mans. Aplícase ao enderezo da rede subxacente, non ao enderezo da capa superposta que o par usará unha vez levantado o túnel.

Un rango privado pode ser perfectamente utilizábel nunha rede de oficina compartida e intrascendente cando os dous equipos están en redes non relacionadas que ambos usan 10.0.0.0/8. O filtro permítelle preferir a ruta encamiñábel e ignorar a coincidencia.

Cando un par non logra conectarse, compare o enderezo que se está probando coa regra que lle corresponde. Active os rexistros da aperta de mans e lea o enderezo remoto seleccionado; a liña do rexistro nomea o extremo que sobreviviu ao filtrado, o que é máis útil que a lista de enderezos que posúe o par.

Un filtro de nome de interface no lado que anuncia pode eliminar o extremo antes de que o lado receptor o vexa sequera. Revise ambos os nodos cando só falla unha dirección.

Tras a aperta de mans aplícanse as regras de acceso da capa superposta

As regras de devasa de Nebula operan dentro da capa superposta, despois de que o túnel se establece. Coinciden con equipos, grupos, portos e protocolos, e deciden se un paquete pode entrar ou saír do equipo local. Non seleccionan un extremo da rede subxacente.

Esta separación explica un diagnóstico erróneo habitual. Un operador engade unha regra de devasa para un porto e segue sen poder conectarse, porque o filtro do faro eliminou o único extremo alcanzábel. Outro operador abre o filtro de enderezos e segue sen chegar ao servizo, porque a devasa da capa superposta rexeita o porto.

Lea o fallo na capa correcta. Unha aperta de mans que nunca se completa apunta ao descubrimento, ao filtrado de extremos ou á ruta de rede. Unha aperta de mans completada seguida dunha conexión de servizo rexeitada ou descartada apunta á devasa da capa superposta ou á aplicación.

Lea o valor predeterminado ao mesturar permiso e denegación

A configuración do faro admite listas só de permitidos, só de denegados e mixtas, e o valor predeterminado para o resto non especificado difire entre esas formas. Unha lista mixta necesita un valor predeterminado explícito para a familia de enderezos; supoñer que o resto se comporta como a configuración anterior é como un extremo que funcionaba desaparece en silencio.

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

Trate o valor predeterminado como parte da regra, non como texto de modelo. Se o valor predeterminado da familia é denegar, todo enderezo non listado queda excluído, incluído un novo rango de oficina engadido despois de escribir a configuración.

Anote que enderezos debían ser accesíbeis e probe desde ambos os lados. Un filtro que funciona para unha parella de pares pode fallar para outra parella cuxa única ruta común usa un enderezo que a lista exclúe.

Use relay cando non haxa ningún extremo directo alcanzábel

Se cada extremo candidato queda filtrado ou inaccesíbel, a resposta non é unha lista de permitidos máis ampla que volva admitir enderezos nos que non confía. A configuración de relay de Nebula ofrece unha ruta alternativa para o par cando a conectividade directa non é viábel.

O relay resolve o transporte e o descubrimento, non a autorización, e non amplía a devasa. A devasa da capa superposta segue decidindo que servizos poden usarse, e o relay non converte o filtrado do faro nun mecanismo de control de acceso.

Probe a ruta do relay cos extremos directos desactivados e confirme que o servizo previsto segue funcionando mentres que un non previsto non o fai. Esa única proba separa unha corrección de transporte dun cambio de política e mantén honestas as dúas capas.