Estou usando o Arch Linux (a versão de 32 bits) em um Raspberry Pi 3.
Quando tento adicionar qualquer regra -j SNAT
ou a , não funciona - recebo uma mensagem de erro-j DNAT
iptables
iptables: No change/target/match by that name
Eu normalmente não tenho problemas com iptables. Por exemplo, o padrão INPUT
e OUTPUT
tem FORWARD
muitas regras. Além disso, POSTROUTING
contém uma MASQUERADE
regra que está funcionando bem para permitir que a LAN interna converse com a Internet.
Eu encontrei o SNAT
problema ao tentar permitir que a Internet enviasse tráfego para o IP público para chegar a 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 DNAT
regras e tive o mesmo problema.
Posso adicionar minhas regras mais complexas ao PREROUTING
e POSTROUTING
sem especificar o -j DNAT
ou -j SNAT
e então elas serão adicionadas e os contadores serão incrementados.
Abaixo estão alguns exemplos das tentativas mais simples de adicionar regras e erros -j SNAT
. -j DNAT
Não importa o que 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 -t nat
configuração atual:
[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 podem ser relevantes caso ajude:
[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
No Arch
xt_nat
não é carregado por padrão.Isso é corrigido com:
Então eu descobri isso eventualmente ... acontece que o
xt_nat
módulo do kernel do Linux precisa ser carregado. A execução do seguinte comando para carregar esse módulo corrigiu o problema imediatamente.Para tentar descobrir o que estava acontecendo, decidi reiniciar o Pi. O
xt_nat
módulo carregou na inicialização eiptables
ainda estava funcionando corretamente - permitindo que as regras fossem adicionadas.Portanto, 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