Início / unix / Perguntas / 771871
Accepted
metablaster
Asked: 2024-03-08 18:35:39 +0800 CST

nftables – pacotes multicast não correspondidos

  • 772

Eu configurei uma regra para combinar pacotes multicast da seguinte maneira:

add rule filter_4 new_out_4 meta pkttype multicast goto multicast_out_4

filter_4é uma tabela IPv4, new_out4é uma cadeia de saída e multicast_out_4é uma cadeia para lidar com tráfego somente multicast.

Aqui está uma imagem mais completa da tabela IPv4, excluindo a parte não relevante:

#!/usr/sbin/nft -f

add table filter_4

add chain filter_4 output {
    # filter = 0
    type filter hook output priority filter; policy drop;
}

add chain filter_4 multicast_out_4 {
    comment "Output multicast IPV4 traffic"
}

add chain filter_4 new_out_4 {
    comment "New output IPv4 traffic"
}

#
# Stateful filtering
#

# Established IPv4 traffic
add rule filter_4 input ct state established goto established_in_4
add rule filter_4 output ct state established goto established_out_4

# Related IPv4 traffic
add rule filter_4 input ct state related goto related_in_4
add rule filter_4 output ct state related goto related_out_4

# New IPv4 traffic ( PACKET IS MATCHED HERE )
add rule filter_4 input ct state new goto new_in_4
add rule filter_4 output ct state new goto new_out_4

# Invalid IPv4 traffic
add rule filter_4 input ct state invalid log prefix "drop invalid_filter_in_4: " counter name invalid_filter_count_4 drop
add rule filter_4 output ct state invalid log prefix "drop invalid_filter_out_4: " counter name invalid_filter_count_4 drop

# Untracked IPv4 traffic
add rule filter_4 input ct state untracked log prefix "drop untracked_filter_in_4: " counter name untracked_filter_count_4 drop
add rule filter_4 output ct state untracked log prefix "drop untracked_filter_out_4: " counter name untracked_filter_count_4 drop

Na configuração acima, o novo tráfego de saída, incluindo multicast, é correspondido por regraadd rule filter_4 output ct state new goto new_out_4

Aqui está new_out_4uma cadeia apenas com a regra multicast relevante (não funcional) que não funciona:

# Multicast IPv4 traffic ( THIS RULE DOES NOT WORK, SEE LOG OUTPUT BELOW)
add rule filter_4 new_out_4 meta pkttype multicast goto multicast_out_4

#
# Default chain action ( MULTICAST PACKET IS DROPPED HERE )
#
add rule filter_4 new_out_4 log prefix "drop new_out_4: " counter name new_out_filter_count_4 drop

Aqui está o que o log diz sobre pacotes multicast descartados:

descarte new_out_4: IN= OUT=eth0 SRC=192.168.1.100 DST=224.0.0.251 LEN=163 TOS=0x00 PREC=0x00 TTL=255 ID=27018 DF PROTO=UDP SPT=5353 DPT=5353 LEN=143

O pacote descartado foi enviado para o endereço de destino 224.0.0.251, este é o endereço multicast, deveria ser correspondido pela regra multicast em new_out_4cadeia e deveria ser processado por multicast_out_4cadeia, mas não foi.

Em vez disso, o pacote não foi correspondido e foi descartado pela regra de descarte padrão na new_out_4cadeia acima, consulte o comentário (Ação da cadeia padrão).

Obviamente isto significa que a regra multicast não funciona.

Por que a regra multicast não funciona?

Esperado:

meta pkttype multicastcorresponde ao endereço de destino224.0.0.251

EDITAR:

Informações do sistema:
Kernel: 6.5.0-0.deb12.4-amd64
teve o mesmo problema com o kernel anterior 6.1

nftables: v1.0.6 (Lester Gooch #5)

firewall

1 respostas

  1. Best Answer

    Tendo reproduzido (e completado as partes que faltam) a configuração com algumas entradas adicionais, como:

    nft insert rule filter_4 new_out_4 counter meta pkttype host counter

    na verdade, a propriedade meta pkttypedeste skbuff é hostdiferente da esperada multicastpara um pacote multicast de saída. Observe que quando esta palavra-chave foi introduzida , tratava-se de entrada, não de saída:

    src: Adiciona suporte para pkttype na meta expressão

    Se você quiser corresponder ao campo pkttype do skbuff, você deve usar a seguinte sintaxe:

    nft adicionar regra filtro ip entrada meta pkttype PACKET_TYPE

    onde PACKET_TYPE pode ser: unicast, broadcast e multicast.

    Na verdade, o equivalente direto do iptables é o módulo de correspondência pkttype :

    pkttype

    Este módulo corresponde ao tipo de pacote da camada de enlace .

    [!] --pkt-type {unicast|broadcast|multicast}

    # iptables-translate -A OUTPUT -m pkttype --pkt-type multicast
nft 'add rule ip filter OUTPUT pkttype multicast counter'

    Juntando tudo isso, quando um pacote IP de saída (roteamento: camada 3) é criado, ele ainda não atingiu sua camada 2 (camada de enlace), portanto seu skbuff não reflete o que ele pode se tornar, se é que pretende fazê-lo mais tarde .

    O que realmente deveria ser testado é a propriedade do endereço IP em relação à pilha de roteamento, e não a propriedade do pacote em relação à Ethernet. iptablesfornece para isso o addrtypemódulo match :

    addrtype

    Este módulo combina pacotes com base em seu tipo de endereço . [...]

    Sua tradução sugere o que realmente deveria ser usado: a fibexpressão:

    # iptables-translate -A OUTPUT -m addrtype --dst-type MULTICAST
nft 'add rule ip filter OUTPUT fib daddr type multicast counter'

    EXPRESSÕES FIB

    fib {saddr | daddr | mark | iif | oif} [. ...] {oif | oifname | type}

    Uma expressão fib consulta a fib (base de informações de encaminhamento) para obter informações como o índice da interface de saída que um determinado endereço usaria. A entrada é uma tupla de elementos usada como entrada para as funções de pesquisa fib.

    Não há exemplo direto para multicast. O exemplo mais próximo é mais complexo sobre descartar um pacjet não destinado a um endereço na interface de entrada, onde o multicast está nas 3 exceções:

    # drop packets to address not configured on incoming interface
filter prerouting fib daddr . iif type != { local, broadcast, multicast } drop

    Portanto, basta substituir onde quer que seja usado em um gancho de saída (ou pós-roteamento):

    meta pkttype multicast

    com:

    fib daddr type multicast

    Em um gancho de entrada (ou pré-roteamento), embora a propriedade skbuff provavelmente corresponda à propriedade IP, para ser consistente, ela também deve ser substituída exatamente da mesma forma, também por:

    fib daddr type multicast

    O comando de teste abaixo, usado conjuntamente em outro host na LAN (para testar a entrada) e no host (para testar a saída):

    socat -d -d UDP4-DATAGRAM:224.0.0.251:5555,bind=:5555,ip-add-membership=224.0.0.251:eth0 -

    corresponderá corretamente fib daddr type multicastna entrada e na saída.

    Observação importante:

    Acredito que a questão foi abordada acima, mas observe, entretanto, que o multicast não pode ser rastreado adequadamente pelo conntrack do Netfilter , porque ele não pode associar uma resposta usando outro endereço de origem unicast ao endereço de destino multicast da consulta inicial: eles diferem, então considera o responda como um outro (novo) fluxo em vez de associá-los e considerar tal resposta como parte do fluxo anterior. Portanto, esse tipo de fluxo nunca aparecerá no estado ESTABLISHED com conntrack ou o conntrack -Lcomando. O conjunto de regras deve ser adaptado para isso: não pode depender apenas de ct state established,relatedregras, mas isso está além do escopo desta questão.

    • 1

relate perguntas