Por que as tabelas net.bridge.bridge-nf-call-{arp,ip,ip6} são padronizadas para 1?

Este recurso permite aumentar o uso de ebtables com o uso de iptables no caminho da ponte para implementar uma ponte de firewall com estado (ao invés de roteador). Ele existe há muito tempo (2002) inicialmente sem alternância e fazendo parte do código da ponte: se o suporte à ponte e ao filtro de rede estivesse ativado , então era.

Então , em 2003, as alternâncias foram adicionadas . Obviamente, por motivos de compatibilidade, o padrão foi definido como ativado.

Então, com o kernel 3.18 , o recurso foi separado para seu próprio módulo de kernel nomeado br_netfilterdevido a problemas que ele poderia causar. Havia preocupações sobre a compatibilidade e já havia objetivos em desativá-lo para nftables :

Observe que isso está quebrando a compatibilidade [...] No entanto, o dano pode ser facilmente desfeito com o modprobing br_netfilter.

Além disso, o plano é que o nftables não dependa dessa camada de software, mas integre o rastreamento de conexão na camada de ponte para permitir filtragem de estado e NAT, que é a ponte que os usuários de filtro de rede parecem exigir.

O módulo do kernel agora precisa ser carregado para que o recurso funcione. Mas ainda assim, seu principal cliente conhecido, que muitas vezes seria encontrado em qualquer configuração de firewall stateful de bridge, seria o alvo iptablesphysdev que carrega automaticamente br_netfilternovamente por motivos de compatibilidade .

Portanto, em um sistema simples, br_netfilternão deve ser carregado e não deve haver nenhum sysctl disponível dentro de net.bridge: bridge-nf-call-arptables, bridge-nf-call-ip6tables, bridge-nf-call-iptables(assim como bridge-nf-filter-pppoe-tagged, bridge-nf-filter-vlan-tagged, bridge-nf-pass-vlan-input-dev) não deve aparecer.

Mas hoje em dia, há um novo cliente principal para este módulo do kernel: Docker. A maneira usual de encontrar problemas com isso é quando se executa o Docker, porque o Docker carrega explicitamentebr_netfilter para poder controlar a comunicação interna entre os contêineres e, ao mesmo tempo, filtra e descarta os pacotes encaminhados por padrão . As pessoas tendem, portanto, a encontrá-lo em uso mesmo quando não o esperam ou pensam que esse comportamento é o comportamento esperado quando não deveria mais.

Como a configuração padrão é para todo o sistema, além das pontes gerenciadas pelos Dockers, ela afetará todas as outras pontes no sistema: não apenas as pontes no namespace inicial do host, mas também as pontes em qualquer outro namespace de rede.

Da mesma forma, o iptablesphysdev carrega automaticamente apenas quando seu próprio br_netfiltermódulo ( xt_physdev) é carregado (costumava ser mais frequente do que isso antes deste patch ). Observe como na descrição do patch isso está escrito:

A melhor correção seria alterar os padrões "call-iptables" para 0 e impor a configuração explícita para 1, mas isso quebra a compatibilidade com versões anteriores .

Tudo isso faz com que a resposta a esta pergunta seja:

É por motivos de compatibilidade com versões anteriores.

Notas Adicionais.

Em um sistema em que os módulos do kernel xt_physdevnão br_netfilterestão carregados no momento, um usuário normal com permissão para executar namespaces de usuário pode fazer:

$ unshare -urnm
# iptables -A FORWARD -m physdev --physdev-is-bridged
# exit
$ 

e potencialmente interromperam a conectividade da LAN para qualquer outra tecnologia (VMs, contêineres ...) instalada no sistema que não usasse regras inúteis especiais e apenas na aparência para se proteger de

iptables -P FORWARD DROP

Os efeitos são descritos nesta página de documentação do Netfilter explicando as interações entre caminho de ponte, caminho de roteamento, ebtables e iptables: interação ebtables/iptables em uma ponte baseada em Linux . A parte 7 é especialmente útil porque descreve que tipo de proteção deve ser adicionada, como:

iptables -t nat -A POSTROUTING -s 172.16.1.0/24 -d 172.16.1.0/24 -j ACCEPT
iptables -t nat -A POSTROUTING -s 172.16.1.0/24 -j MASQUERADE

Acima, a primeira regra não faz muito sentido, porque os pacotes entre endereços na mesma LAN não são encaminhados na camada IP (ou seja, roteados), mas são encaminhados como quadros na camada Ethernet (são em ponte/comutada), de modo que a regra nunca deve corresponder, uma vez que eles não são vistos como roteados, mas em ponte e espera-se que o iptables funcione apenas na camada 3: IPv4. Mas quando br_netfilteré carregado esses tipos de "regras inúteis" se tornam necessários, senão a ação destinada apenas ao roteamento acontecerá na camada 2 no caminho da ponte (como aqui: NAT seria feito pela ponte entre dois nós na mesma LAN sem a primeira regra ).

Há um esforço contínuo (ao longo de vários anos) para se livrar de br_netfilter, mas isso requer paridade de recursos. Isso foi mais ou menos alcançado para IP e IPv6 (e acho que para ARP) com kernel 5.3, nftables e módulo de kernel nf_conntrack_bridgeque permitem nftables na bridgefamília (não no ip, ip6ou inetfamílias como br_netfiltergatilhos) para usar conntrack :

Isso fornece um substituto para a infraestrutura `br_netfilter'.

Filtragem com estado

A família bridge suporta rastreamento de conexão desde o kernel Linux 5.3.

Você só precisa corresponder às informações de estado do conntrack do seu conjunto de regras para habilitá-lo.

Para aqueles que estão familiarizados com iptables: isso fornece um substituto para br_netfilter e a correspondência -m physdev para iptables .

Mas os outros recursos também envolvendo encapsulamento/desencapsulação de VLAN ou principalmente do protocolo PPPoE ainda não estão prontos.

Além disso, desde o kernel 5.3, é possível desativar o recurso de todo o namespace de rede e ativá-lo apenas por namespace de rede ou mesmo por bridge. Mas isso requer que cada novo namespace criado (incluindo o namespace de rede inicial é tal é a necessidade) executado antecipadamente dentro dele algo como:

sysctl -w net.bridge.bridge-nf-call-arptables=0
sysctl -w net.bridge.bridge-nf-call-iptables=0
sysctl -w net.bridge.bridge-nf-call-ip6tables=0

e, em seguida, para pontes escolhidas a dedo que precisam, na criação da ponte ( ip link add ...) ou posterior ( ip link set ...):

ip link set somebridge type bridge nf_call_iptables 1

O Docker com sua configuração padrão de iptables não pode lidar com isso, então o Docker não pode ser executado ao mesmo tempo em um host com essa configuração, mas o Docker-in-Docker (na verdade em uma outra tecnologia de contêiner como LXC em vez do Docker para o mesmo razão) provavelmente seria bom, já que os padrões em cada novo namespace ainda são compatíveis com versões anteriores.