Filtros do farol do Nebula contra a firewall: o que cada um bloqueia

Observe um handshake do Nebula pelo lado errado e os dois mecanismos parecem intercambiáveis. Um decide quais endereços um nó anuncia ao farol e quais endereços remotos tentará; o outro decide o que pode passar depois que o túnel existe. Um filtro pode deter uma conexão antes que qualquer regra de firewall seja avaliada, e uma regra de firewall não pode reanimar um endpoint que a descoberta removeu. As duas camadas respondem a perguntas diferentes, e a ordem em que agem é a chave.

Acompanhe uma conexão por quatro etapas: o endereço local anunciado, o endpoint remoto considerado, o handshake e o tráfego na camada sobreposta. Cada etapa tem a sua própria configuração e a sua própria assinatura de falha.

Comece pelo endereço local que o nó anuncia

local_allow_list filtra os endereços locais deste host antes de serem reportados aos faróis. As entradas podem ser faixas de endereços, e a configuração também aceita padrões de nome de interface. Isso é útil quando um host tem pontes de contêineres ou interfaces de túnel adicionais que não devem tornar-se endpoints de pares.

Percorra as interfaces do host e pergunte a quais um par remoto consegue realmente chegar. Um endereço de ponte Docker é local para esse host e inútil para um par em outra rede. Anunciá-lo desperdiça a descoberta e pode enviar um par para um endereço que nunca responde. Tudo aquilo para o qual um par não consegue rotear é ruído na resposta do farol.

Uma lista de permitidos estreita é mais segura aqui do que uma lista de bloqueados ampla. Se existirem apenas entradas de permissão, o restante não especificado fica excluído; acrescentar depois uma entrada de bloqueio altera a lógica padrão e exige a sua própria revisão. Essa mudança merece um segundo olhar sobre o valor padrão.

Depois observe a seleção do endpoint remoto

remote_allow_list filtra os endereços que este host vai considerar para um par remoto durante um handshake. Aplica-se ao endereço da camada subjacente, não ao endereço da camada sobreposta que o par usará depois que o túnel estiver de pé.

Uma faixa privada pode ser perfeitamente utilizável numa rede de escritório partilhada e sem sentido quando os dois hosts estão em redes não relacionadas que ambas usam 10.0.0.0/8. O filtro permite preferir o caminho encaminhável e ignorar a coincidência.

Quando um par não consegue ligar-se, compare o endereço que está a ser tentado com a regra que lhe corresponde. Ative os registos do handshake e leia o endereço remoto selecionado; a linha do registo nomeia o endpoint que sobreviveu à filtragem, o que é mais útil do que a lista de endereços que o par possui.

Um filtro de nome de interface do lado que anuncia pode remover o endpoint antes de o lado recetor o ver. Verifique ambos os nós quando apenas uma direção falha.

Depois do handshake aplicam-se as regras de acesso da camada sobreposta

As regras de firewall do Nebula operam dentro da camada sobreposta, depois de o túnel estar estabelecido. Correspondem a hosts, grupos, portas e protocolos, e decidem se um pacote pode entrar ou sair do host local. Não selecionam um endpoint da camada subjacente.

Esta separação explica um diagnóstico errado comum. Um operador acrescenta uma regra de firewall para uma porta e continua sem conseguir ligar-se, porque o filtro do farol removeu o único endpoint alcançável. Outro operador abre o filtro de endereços e continua sem chegar ao serviço, porque a firewall da camada sobreposta rejeita a porta.

Leia a falha na camada correta. Um handshake que nunca se completa aponta para a descoberta, para a filtragem de endpoints ou para o caminho de rede. Um handshake concluído seguido de uma ligação ao serviço rejeitada ou descartada aponta para a firewall da camada sobreposta ou para a aplicação.

Leia o valor padrão ao misturar permissão e bloqueio

A configuração do farol suporta listas apenas de permitidos, apenas de bloqueados e mistas, e o valor padrão para o restante não especificado difere entre essas formas. Uma lista mista precisa de um padrão explícito para a família de endereços; assumir que o restante se comporta como a configuração anterior é como um endpoint que funcionava desaparece em silêncio.

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

Trate o valor padrão como parte da regra, não como texto de modelo. Se o padrão da família for bloquear, todos os endereços não listados ficam excluídos, incluindo uma nova faixa de escritório acrescentada depois de a configuração ser escrita.

Anote quais endereços deveriam ser alcançáveis e teste dos dois lados. Um filtro que funciona para um par de pares pode falhar para outro par cujo único caminho comum usa um endereço que a lista exclui.

Use relay quando nenhum endpoint direto estiver alcançável

Se todos os endpoints candidatos forem filtrados ou ficarem inalcançáveis, a resposta não é uma lista de permitidos mais ampla que volte a admitir endereços em que não confia. A configuração de relay do Nebula oferece um caminho alternativo para o par quando a conetividade direta não é viável.

O relay resolve transporte e descoberta, não autorização, e não alarga a firewall. A firewall da camada sobreposta continua a decidir que serviços podem ser usados, e o relay não transforma a filtragem do farol num mecanismo de controlo de acesso.

Teste o caminho relay com os endpoints diretos desativados e confirme que o serviço pretendido continua a funcionar enquanto um não pretendido não funciona. Esse único teste separa uma correção de transporte de uma mudança de política e mantém as duas camadas honestas.