Я использую Arch Linux (32-разрядную версию) на Raspberry Pi 3.
Когда я пытаюсь добавить -j SNAT
или -j DNAT
правила для iptables
, не работает - получаю ошибку
iptables: No change/target/match by that name
Обычно у меня нет проблем с iptables. Например, стандартный INPUT
, OUTPUT
и FORWARD
есть много правил. Также, POSTROUTING
содержит MASQUERADE
Правило, которое работает нормально, чтобы разрешить внутренней локальной сети общаться с Интернетом.
Я столкнулся с SNAT
проблема при попытке разрешить Интернету отправлять трафик на общедоступный IP-адрес для доступа к машине во внутренней сети. Когда это не помогло, я попробовал более простые правила, и они тоже не сработали. Затем я попытался добавить DNAT
rules и была такая же проблема.
Я могу добавить свои более сложные правила в PREROUTING
и POSTROUTING
без указания -j DNAT
или -j SNAT
а затем они будут добавлять, и счетчики увеличиваются.
Ниже приведены несколько примеров простейших попыток добавления -j SNAT
и -j DNAT
правила и ошибки. Не важно что SNAT
или DNAT
правило, которое я пытаюсь добавить, ошибка всегда такая же, как показано ниже.
[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.
Сведения о Linux и текущие -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 ~]#
Вот список загруженных модулей ядра, которые могут быть полезны, если это поможет:
[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
В арке xt_nat
по умолчанию не загружается.
Это исправлено с помощью:
modprobe xt_nat
echo "xt_nat >> /etc/modules-load.d/iptables.conf"
В конце концов я понял это ... оказывается, что xt_nat
Необходимо загрузить модуль ядра Linux. Выполнение следующей команды для загрузки этого модуля немедленно устранило проблему.
insmod /lib/modules/`uname -r`/kernel/net/netfilter/xt_nat.ko.gz
Чтобы попытаться понять, что происходит, я решил перезагрузить Pi. В xt_nat
модуль загружается при загрузке и iptables
все еще работал правильно - разрешая добавление правил.
Поэтому, хотя я не уверен, как модуль был выгружен (поскольку он уже должен был загружаться во время загрузки), по крайней мере, сейчас он работает. Теоретически проблема не должна возникнуть снова, потому что модуль не может быть выгружен, пока -j DNAT
или -j SNAT
правило существует.