☰

ip6tablesは送信元アドレスをマスカレードしません

tag-icon • tag-icon iptables ip6tables
ip6tablesは送信元アドレスをマスカレードしません

私のルールは次のとおりです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。 代表的なパケットの 1 つを以下に示します (インターフェイス で受信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 アドレスに書き換えられるようにしたいのですが ( eth0)。しかし、パケットが ip6tables ルールに一致することを期待しているにもかかわらず、これは起こりません。実際、パケットは MASQUERADE ルールのいずれにも一致していません (カウンタによって確認pkts)。これをデバッグする方法がよくわかりません。これらのパケットがマスカレードされない理由を知っている人はいますか?

私が試したこと:

  1. すべてのconntrackエントリを削除します:conntrack -f ipv6 -D
  2. マシンを再起動します。

ご協力いただきありがとうございます！

編集：

さらに役立つ出力を以下に示します。

# 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 さんの提案に関して、私の設定では同様の解決策が機能することがわかりました (/48 ではなく /60 を使用しています)。そのため、ip6tables の使用をやめてみることにします。

編集: NAT なしでセットアップが動作するようになりました。提案していただきありがとうございます。

答え2

はい、私も同じ問題を抱えていました。解決策は簡単でした。「ip6tables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT」を実行するだけです。

問題は、ip6tables コードがデフォルトで conntrack モジュールをロードしないため、ステートフル ルールが透過的に機能しないことです。

「IPv6 には NAT は必要ない」という人たちもいますが、AWS で Docker コンテナを実行する場合など、場合によっては NAT が必要になります。DHCP PD はサポートされていないため、NAT を使用するしかありません。

関連情報