nftables bridge corresponde a pacotes locais

Question

Estou usando o Arch linux e configurei uma bridge com bridge-utils. Agora eu gostaria de firewall. Eu gostaria de soltar alguns pacotes passando por essa ponte, permitindo que essa máquina se comunique livremente com a que está por trás da ponte. Eu costumo lidar com esses casos, combinando iifname lo , mas infelizmente não coincide com meus pacotes.

novamente , esperamos que com mais clareza

• Eu tenho duas máquinas, master e slave .
• master tem duas placas ethernet. Um conectado ao resto da minha rede, o outro para slave
• Desejo que master envie qualquer coisa para slave
• Quero filtrar o tráfego do restante da minha rede para slave on master

Eu gostaria de fazer isso usando nftables. Você tem alguma ideia?

    

Answer 1

A interface lo não é uma interface ethernet. Ele não tem um endereço de camada de link e certamente não pode fazer parte de uma ponte. Portanto, não há como iifname lo corresponder.

O layout da ponte ainda é organizado de forma semelhante ao layout ip, mas funciona na camada 2: os quadros Ethernet que são alternados (em vez de roteados) entrarão na cadeia de encaminhamento. Os quadros Ethernet que são para o host entrarão na cadeia de entrada, os quadros Ethernet vindos do host entrarão na cadeia de saída.

Vamos supor que a rede seja assim:

LAN <--------> eth0 master eth1 <--------> slave
                   (bridge0)

com eth0 e eth1 escravizados em bridge0 .

Portanto, com uma única ponte no host, esse conjunto de regras "vazio" é suficiente para isolar slave , enquanto permite master de tráfego irrestrito com LAN e slave , usando apenas uma política de descarte com a cadeia de encaminhamento .

#!/usr/sbin/nft -f

flush ruleset

table bridge filter {
    chain input {
        type filter hook input priority -200; policy accept;
    }

    chain forward {
        type filter hook forward priority -200; policy drop;
    }

    chain output {
        type filter hook input priority 200; policy accept;
    }
}

Certamente é normal esperar que o ARP funcione nos dois sentidos (senão slave não será capaz de fazer muito no nível do IP):

nft add rule bridge filter forward ether type arp accept

Agora, se a LAN tiver permissão para fazer ping de slave , mas não o contrário:

nft add rule bridge filter forward oif eth1 ip protocol icmp icmp type echo-request accept
nft add rule bridge filter forward iif eth1 ip protocol icmp icmp type echo-reply accept

Observe que o uso de nftables no nível da ponte ainda é um pouco limitado (mas mais limpo) em comparação com o iptables, porque ainda não há integração conntrack a partir de hoje. Então, até onde eu sei, nenhum firewall stateful está disponível.

Assim, algumas tarefas geralmente fáceis podem parecer estranhas, por exemplo: permitir ssh (possivelmente remoto) IP 203.0.113.3 . Ele se transforma em: permitir o tráfego nos dois sentidos, exceto para a sincronização inicial não permitida do escravo para a LAN:

nft add rule bridge filter forward oif eth1 ip saddr 203.0.113.3 ip protocol tcp tcp dport 22 accept
nft add rule bridge filter forward iif eth1 ip daddr 203.0.113.3 ip protocol tcp tcp sport 22 tcp flags != syn accept

Se houver mais de uma ponte em master , as regras e / ou as políticas padrão talvez precisem ser adaptadas.