ID do caso de teste: N/A
Data: 2013/05/13
SO: N/A
Testador: -
Módulo de erro: filtragem
Descrição: O usuário precisa de uma maneira de definir políticas para controlar se as entradas BIB e de sessão são criadas ou não. Neste ponto, o módulo chama uma função vazia.
Observações: A RFC não define as políticas; espera-se que sejam definidos pelo usuário. Imagino que o NAT64 deve funcionar como o iptables, no sentido de que outros módulos do kernel podem ser anexados a ele e aplicar lógica.
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.
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.
Comentários muito úteis
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 cadeiaPREROUTING
mangle
da tabela mangle, ou após a tradução na cadeiaPOSTROUTING
.Então você pode fazer coisas assim:
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 cadeiaPOSTROUTING
. Isso permite que você supere certas limitações do uso das cadeiasPRE-
ePOSTROUTING
, como não poder corresponder na interface de entrada nas cadeiasPOSTROUTING
. Por exemplo:Se você não quiser usar o IPTables, também há uma maneira alternativa de bloquear o tráfego usando
ip rule
, por exemplo: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ãoip rule
é provavelmente mais leve que o IPTables, porqueip 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.