Вот мои ip6tables
правила:
# ip6tables -t nat -L -v
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 DNAT all eth0 any anywhere 2001:470:4a71:f170::/64 to:fdde:ad00:beef:0:91f5:6dd4:e66f:cf5b
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 19 packets, 1936 bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 19 packets, 1936 bytes)
pkts bytes target prot opt in out source destination
0 0 MASQUERADE all any eth0 fdde:ad00:beef::/64 anywhere
0 0 MASQUERADE udp any eth0 fd11:22::/64 anywhere
0 0 MASQUERADE tcp any eth0 fd11:22::/64 anywhere
Я вижу, что пакеты уходят через eth0
. tshark
Вот один представительный пакет (полученный на интерфейсе wpan0
):
221 480.196225356 fd11:22::703c:ef83:a03d:7e1b ? 2600:1f1c:c93:da00:76c2:1dbd:72c2:d063 TCP 94 [TCP Retransmission] 49998 ? 50000 [SYN] Seq=0 Win=9 Len=0 MSS=474 WS=1 SACK_PERM=1 TSval=2889901 TSecr=0
Я хочу, чтобы эти пакеты проходили через фильтр MASQUERADE, поэтому их исходные адреса перезаписываются на IPv6-адрес хоста в сети Ethernet ( eth0
). Однако этого не происходит, хотя я ожидал, что пакеты будут соответствовать правилам ip6tables. Фактически, пакет даже не соответствует ни одному из правил MASQUERADE (что подтверждается счетчиком pkts
). Я не уверен, как это отладить --- кто-нибудь знает, почему эти пакеты не маскируются?
Что я пробовал:
- Удалить все
conntrack
записи:conntrack -f ipv6 -D
- Перезагрузите машину.
Спасибо за вашу помощь!
Редактировать:
Вот еще полезный вывод:
# ip6tables-save -c
# Generated by ip6tables-save v1.6.0 on Sun Sep 2 11:44:06 2018
*filter
:INPUT ACCEPT [1812:134308]
:FORWARD ACCEPT [22:1760]
:OUTPUT ACCEPT [1782:210084]
COMMIT
# Completed on Sun Sep 2 11:44:06 2018
# Generated by ip6tables-save v1.6.0 on Sun Sep 2 11:44:06 2018
*nat
:PREROUTING ACCEPT [1:137]
:INPUT ACCEPT [1:137]
:OUTPUT ACCEPT [41:5757]
:POSTROUTING ACCEPT [41:5757]
[0:0] -A PREROUTING -d 2001:470:4a71:f170::/64 -i eth0 -j DNAT --to-destination fdde:ad00:beef:0:91f5:6dd4:e66f:cf5b
[0:0] -A POSTROUTING -s fdde:ad00:beef::/64 -o eth0 -j MASQUERADE
[0:0] -A POSTROUTING -s fd11:22::/64 -o eth0 -p udp -j MASQUERADE
[0:0] -A POSTROUTING -s fd11:22::/64 -o eth0 -p tcp -j MASQUERADE
COMMIT
# Completed on Sun Sep 2 11:44:06 2018
# ip -6 link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
link/ether b8:27:eb:96:eb:75 brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether b8:27:eb:c3:be:20 brd ff:ff:ff:ff:ff:ff
4: tap0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 06:8a:53:01:68:f2 brd ff:ff:ff:ff:ff:ff
5: wpan0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 500
link/none
# ip -6 -brief address
lo UNKNOWN ::1/128
eth0 UP 2001:470:4a71:f000::11/64 fe80::ba27:ebff:fe96:eb75/64
wpan0 UNKNOWN fdde:ad00:beef:0:cc1e:c6e2:8252:e44b/64 fd11:22::1c4d:925:de45:9d30/64 fe80::1c4d:925:de45:9d30/64 fe80::2ccb:f19:edce:c49e/64
# ip -6 route
2001:470:4a71:f000::/64 dev eth0 proto kernel metric 256 pref medium
fd11:22::/64 dev wpan0 proto kernel metric 256 pref medium
fdde:ad00:beef::/64 dev wpan0 proto kernel metric 256 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
fe80::/64 dev wpan0 proto kernel metric 256 pref medium
default via 2001:470:4a71:f000::1 dev eth0 metric 1024 pref medium
решение1
Оказывается, это из-за того, что контрольная сумма TCP была неправильной (в стеке TCP хоста была ошибка). Видимо, tshark
по умолчанию это не отображается, но это приводило к тому, что ip6tables не маскировал исходный адрес.
Спасибо всем за попытку помочь. Что касается предложения kasperd, то, как оказалось, похожее решение работает в моих настройках (у меня /60, а не /48), поэтому я попробую отойти от ip6tables.
Редактировать: У меня теперь все работает без NAT. Спасибо за предложение.
решение2
ОК, у меня была та же проблема. Решение оказалось простым, просто запустите: "ip6tables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT"
Проблема в том, что код ip6tables по умолчанию не загружает модуль conntrack, поэтому правила statefull прозрачно не работают.
А для бригады "IPv6 не нуждается в NAT!" - иногда он вам НУЖЕН, например, если вы хотите запустить контейнеры Docker на AWS. Он не поддерживает DHCP PD, поэтому вам придется использовать NAT.