Jool: Precisa habilitar recursos semelhantes a firewall no NAT64

As mudanças que planejamos se mostraram insuficientes.

Isso permanecerá um problema em aberto no Jool 3.3.

Este é outro problema que provavelmente seria corrigido natural e indiretamente transformando o Jool em um driver de dispositivo .

Jool intercepta e rouba pacotes antes dos filtros do iptables, então não há como firewall traduzir o tráfego a menos que seja feito por uma máquina separada e adjacente.

Como eu mencionei antes no e-mail, este não é realmente o caso. Jool rouba o pacote para que ele não atravesse a tabela filter do IPTables, mas você ainda pode acessar o pacote antes da tradução na cadeia PREROUTING mangle da tabela mangle, ou após a tradução na cadeia POSTROUTING .

Então você pode fazer coisas assim:

### IPv6 -> IPv4 direction
# Block ICMPv6 (e.g., echo requests) destined for 192.0.2.1 before Jool grabs the packet
ip6tables -t mangle -I PREROUTING -d 64:ff9b::192.0.2.1 -p icmpv6 -j DROP
# Same, but let the packet pass through Jool for translation before dropping it
iptables -t mangle -I POSTROUTING -d 192.0.2.1 -p icmp -j DROP

### IPv4 -> IPv6 direction
# Drop ICMPv4 (e.g., echo replies) from 192.0.2.1 before Jool grabs the packet
iptables -t mangle -I PREROUTING -s 192.0.2.1 -p icmp -j DROP
# Same, but let the packet pass through Jool before dropping it
sudo ip6tables -t mangle -I POSTROUTING -s 64:ff9b::192.0.2.1 -p icmpv6 -j DROP

Outra coisa que vale a pena apontar é que quaisquer marcas definidas no pacote na cadeia PREROUTING sobrevivem à tradução de Jool e estão disponíveis para correspondência na cadeia POSTROUTING . Isso permite que você supere certas limitações do uso das cadeias PRE- e POSTROUTING , como não poder corresponder na interface de entrada nas cadeias POSTROUTING . Por exemplo:

# Mark (IPv4) packets arriving on interface eth0 with the value 0x42
iptables -t mangle -I PREROUTING -i eth0 -j MARK --set-mark 0x42
# Now we can check for that mark in the (IPv6) POSTROUTING chain
ip6tables -t mangle -I POSTROUTING -m mark --mark 0x42 -j DROP

Se você não quiser usar o IPTables, também há uma maneira alternativa de bloquear o tráfego usando ip rule , por exemplo:

# Drop outgoing IPv4 packets with dst=192.0.2.1 (after Jool has translated it from IPv6):
ip -4 rule add to 192.0.2.1 prohibit
# Similarly, drop outgoing IPv6 packets with src=64:ff9b::192.0.2.1 dst=2001:db8::1
ip -6 rule add from 64:ff9b::192.0.2.1 to 2001:db8::1 prohibit

Observe que filtrar usando ip rule dessa maneira é mais limitado do que usar IPTables, pois permite apenas corresponder em cabeçalhos de camada 3 (sem portas TCP/UDP etc.), e só pode filtrar _after_ Jool traduziu um pacote. No entanto, se essas restrições forem boas, então ip rule é provavelmente mais leve que o IPTables, porque ip rule se conecta à infraestrutura de roteamento do kernel, que precisa processar todos os pacotes de qualquer maneira, enquanto o IPTables é completamente opcional; você pode executar o Jool muito bem sem ter nenhum dos módulos do kernel IPTables carregados.

Em resumo, acho que isso é mais um problema de documentação, não um recurso ausente. Pelo menos não vejo sentido em duplicar a funcionalidade fornecida por outras partes do kernel no próprio Jool.

Certo, aqui está o status:

Como eu disse neste comentário , não vejo nenhum problema com a filtragem no mangle, mas algumas documentações do iptables sim (aparentemente) . Eu não conheço o raciocínio, então não vou desencorajá-lo nem encorajá-lo.

Por outro lado, agora que o Jool pode ser incluído em um namespace, a filtragem pode ser feita nas cadeias de encaminhamento . Isso pode não parecer tão limpo quanto poderia ser, mas não é diferente de se Jool fosse um driver de dispositivo.

Então, de qualquer forma, parece que isso não é mais um problema.

Fechamento.