Erro ao adicionar regras iptables snat ou dnat no linux

2

Estou usando o Arch Linux (a versão de 32 bits) em um Raspberry Pi 3.

Quando tento adicionar as regras -j SNAT ou -j DNAT a iptables , isso não funciona - recebo um erro

iptables: No change/target/match by that name

Normalmente não tenho problemas com o iptables. Por exemplo, o padrão INPUT , OUTPUT e FORWARD tem muitas regras. Além disso, POSTROUTING contém uma regra MASQUERADE que está funcionando bem para permitir que a LAN interna converse com a Internet.

Encontrei o problema SNAT ao tentar permitir que a Internet envie tráfego para o IP público para acessar uma máquina na rede interna. Quando isso não funcionou, tentei regras mais simples e elas também não funcionaram. Então tentei adicionar as regras DNAT e tive o mesmo problema.

Eu posso adicionar minhas regras mais complexas ao PREROUTING e POSTROUTING sem especificar o -j DNAT ou -j SNAT e eles serão adicionados, e os contadores serão incrementados.

Abaixo estão alguns exemplos das tentativas mais simples de adicionar as regras -j SNAT e -j DNAT e os erros. Não importa qual SNAT ou DNAT regra eu tente adicionar, o erro é sempre o mesmo mostrado abaixo.

[root@hostname ~]# iptables -F PREROUTING -t nat
[root@hostname ~]# iptables -A PREROUTING -t nat -d $public_IP -j DNAT --to-destination $internal_IP
iptables: No chain/target/match by that name.

[root@hostname ~]# iptables -F POSTROUTING -t nat
[root@hostname ~]# iptables -A POSTROUTING -t nat -o teql+ -j SNAT --to-source $public_IP
iptables: No chain/target/match by that name.

Detalhes do Linux e configuração atual do -t nat :

[root@hostname ~]# uname -a
Linux hostname.local 4.4.37-1-ARCH #1 SMP Fri Dec 9 19:03:41 MST 2016 armv7l GNU/Linux

[root@hostname ~]# iptables -nvL -t nat
Chain PREROUTING (policy ACCEPT 18 packets, 1184 bytes)
pkts bytes target     prot opt in     out     source               destination

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination
600 37155 MASQUERADE  all  --  *      teql+   0.0.0.0/0            0.0.0.0/0
[root@hostname ~]#

Aqui está uma lista de módulos Kernel carregados que talvez sejam relevantes caso isso aconteça:

[root@hostname ~]# lsmod | grep ip
ipt_REJECT              1543  142
nf_reject_ipv4          3223  1 ipt_REJECT
ipt_MASQUERADE          1223  1
nf_nat_masquerade_ipv4  2893  1 ipt_MASQUERADE
iptable_nat             1812  1
nf_nat_ipv4             5573  1 iptable_nat
nf_nat                 15506  2 nf_nat_ipv4,nf_nat_masquerade_ipv4
nf_conntrack_ipv4      13768  7
nf_defrag_ipv4          1684  1 nf_conntrack_ipv4
nf_conntrack          101220  5 nf_nat,nf_nat_ipv4,xt_conntrack,nf_nat_masquerade_ipv4,nf_conntrack_ipv4
iptable_filter          1665  1
ip_tables              12280  2 iptable_filter,iptable_nat
x_tables               17670  5 ip_tables,ipt_MASQUERADE,xt_conntrack,iptable_filter,ipt_REJECT
ipv6                  370087  20
    
por bao7uo 23.12.2016 / 12:55

1 resposta

0

Então eu descobri isso eventualmente ... Acontece que o módulo de kernel xt_nat Linux precisa ser carregado. A execução do seguinte comando para carregar esse módulo corrigiu o problema imediatamente.

insmod /lib/modules/'uname -r'/kernel/net/netfilter/xt_nat.ko.gz

Para tentar descobrir o que estava acontecendo, decidi reiniciar o Pi. O módulo xt_nat carregado na inicialização e iptables ainda estavam funcionando corretamente - permitindo que as regras fossem adicionadas.

Então, embora eu não tenha certeza de como o módulo foi descarregado (visto que já deveria estar carregando no momento da inicialização), pelo menos está funcionando agora. Em teoria, o problema não deve ocorrer agora porque o módulo não pode ser descarregado enquanto existir uma regra -j DNAT ou -j SNAT .

    
por 06.01.2017 / 08:31