Linuxルータでiptablesを使った場合、Game Console(Nintendo Switch)のナット判定をタイプAまたはタイプBにすることはできたのですが、nftablesでゲームコンソールをNAT越えさせるという記事は他に見当たりません。所謂ニチバンベンチはクリアできても、ナット判定はタイプDとなってしまい、NAT越えできない場合がほとんどです。
そこで、iptablesでナットタイプBになる例を参考にしながら試行錯誤した結果、Nintendo SWITCHはタイプB、PSはタイプ2にすることができたので備忘録として挙げてみました。
当方の環境はフレッツ光クロスでOCNバーチャルコネクト（プロバイダはぷらら）です。（つまり、DHCPv6-PD + map-e OCNバーチャルコネクトで、他のフレッツ光ではひかり電話あり+OCNバーチャルコネクトの環境と同じです。）早速ですが、/usr/local/sbin/nft.shとして以下のようにしました。なおパラメータは例の計算機で算出しています。
要点は以下の通りです。
1. udpは ct countにて1ポートセットあたり16接続まで許可し、それ以上は次のポートセットに流れるようにした。
2. icmpは、udpと同じ記述にした。※１
3. tcpについては、別途vmapを用意しパケットにマーキングしてから、それぞれmap-e_chain$markに飛ばしトラフィックを分散させるようにした。
以上です。
ちなみに以下の二行（※２）がないと、なぜかタイプD/タイプ3判定になってしまいます。
なお、/etc/sysctl.conf、radvd、dhcp serverの設定、firewall設定、lan側インターフェイスの設定などについては本稿では触れていませんので悪しからずご了承ください。
今回は以上です。それでは。
追記１：2023/04/03現在のOpenWRTスナップショット版（kmod-nft-connlimitパッケージをインストール）で上述のスクリプトのnft設定部分がほぼ同じものを適用したところ、OpenWRTでもニチバンベンチクリアかつナットタイプ判定Bにできました。
追記２:2023/04/15: Debian 12にアップグレード後、接続確立後しばらくしてから、dhclientが起動されずにWAN側のIPv6接続が切断され結果としてIPv4接続も切れてしまうのですが、/etc/rc.localに以下を先頭に記述することで接続断の回避ができました。
※１注釈:1 https://datatracker.ietf.org/doc/html/draft-ietf-softwire-map-03 より
"If a MAP CE receives an ICMP message having ICMP identifier field in ICMP header, NAT44 in the MAP CE must rewrite this field to a specific value assigned from the port-set. BR and other CEs must handle this field similar to the port number in the TCP/UDP header upon receiving the ICMP message with ICMP identifier field."
"CEがICMPヘッダーにICMP identifierを含むICMPメッセージを受信する場合、CE内のNAT44はこのフィールドをポートセットから割り当てられた特定の値に書き換えなければならない。BRと他のCEは、ICMP identifierを含むICMPメッセージを受信する場合、このフィールドをTCP/UDPヘッダーのポート番号と同様に扱わなければならない。"
※１注釈:2 注釈:1の通り、外部からmap-eルータにnping(nmapパッケージに含まれる)で、ルータのIPアドレスとID(map-eで割り振られたポート番号のいずれか)を指定してecho requestすると、firewall設定で制限されていない限り、map-e routerはecho replayを返します。(割り振られたポート番号以外を指定するとecho replayは基本的には帰ってきません。)
そこで、iptablesでナットタイプBになる例を参考にしながら試行錯誤した結果、Nintendo SWITCHはタイプB、PSはタイプ2にすることができたので備忘録として挙げてみました。
当方の環境はフレッツ光クロスでOCNバーチャルコネクト（プロバイダはぷらら）です。（つまり、DHCPv6-PD + map-e OCNバーチャルコネクトで、他のフレッツ光ではひかり電話あり+OCNバーチャルコネクトの環境と同じです。）早速ですが、/usr/local/sbin/nft.shとして以下のようにしました。なおパラメータは例の計算機で算出しています。
#!/bin/sh
PFX=2400:4050:5c71:af00::
PLEN=56
GWA=1
BR='2001:380:a120::9'
CE='2400:4050:5c71:af00:99:f171:c600:2f00'
IP4='153.241.113.198'
PSID=47
#対抗ルータのアドレスはradvdumpで確認できます。
FGW=fe80::aaaa:bbbb:cccc:dddd
WANDEV='enp1s0f0'
LANDEV='enp1s0f1'
TUNDEV='tun0'
# TYPE: [ OCN | V6P ]
TYPE='OCN'
if [ "$TYPE" = "OCN" ]; then \
lp=63
nxps=1024 # next port set
elif [ "$TYPE" = "V6P" ]; then \
lp=15
nxps=4096 # next port set
else
echo Unknown TYPE: $TYPE
exit 1
fi
ip -6 addr add $CE dev $WANDEV
ip -6 addr add $PFX$GWA/$PLEN dev $LANDEV
ip -6 tunnel add $TUNDEV mode ip4ip6 remote $BR local $CE dev $WANDEV encaplimit none
ip link set dev $TUNDEV mtu 1460 up
ip -4 addr add $IP4/32 dev $TUNDEV
ip -6 route add default proto static metric 20 \
nexthop via $FGW dev $WANDEV weight 10
ip route add default proto static metric 20 \
nexthop dev $TUNDEV weight 10
## configure nftables
## clear nftables
nft flush ruleset
## add map-e_filter table
nft add table ip map-e_filter
nft add chain ip map-e_filter POSTROUTING { type filter hook postrouting priority 0\; }
nft add rule ip map-e_filter POSTROUTING iifname $TUNDEV tcp flags \& syn == syn tcp option maxseg size set rt mtu
nft add rule ip map-e_filter POSTROUTING oifname $TUNDEV tcp flags \& syn == syn tcp option maxseg size set rt mtu
## 2023/04/09 map-e_mangle テーブルを追加
## add map-e_mangle table
nft add table ip map-e_mangle
nft add chain ip map-e_mangle FORWARD { type filter hook forward priority 0 \; }
## add map-e_nat table
nft add table ip map-e_nat
## ※２
nft add chain ip map-e_nat PREROUTING { type nat hook prerouting priority 0 \; }
nft add chain ip map-e_nat OUTPUT { type nat hook output priority 0 \; }
nft add chain ip map-e_nat POSTROUTING { type nat hook postrouting priority 0 \; }
rule=1
while [ $rule -le $lp ] ; do
mark=`expr $rule`
portl=`expr $rule \* $nxps + $PSID \* 16`
portr=`expr $portl + 15`
nft add chain ip map-e_nat map-e_chain$mark
nft add rule ip map-e_nat map-e_chain$mark meta l4proto tcp snat to $IP4:$portl-$portr persistent
nft add rule ip map-e_nat POSTROUTING oifname $TUNDEV ip protocol udp ct count 16 counter snat to $IP4:$portl-$portr
nft add rule ip map-e_nat POSTROUTING oifname $TUNDEV ip protocol icmp ct count 16 counter snat to $IP4:$portl-$portr
rule=`expr $rule + 1`
done
## tcp用 vmapの作成
nft add rule ip map-e_nat POSTROUTING oifname $TUNDEV ip protocol tcp numgen inc mod $lp offset 1 vmap {`rule=1; while [ $rule -le $lp ]; do echo -n $rule:" "jump map-e_chain$rule," "; rule=$((rule+1));done`}
#### local messy setups below
## 2023/04/09 追加
nft add rule ip map-e_mangle FORWARD 'oifname' $TUNDEV 'tcp flags & (syn|rst) == syn tcp option maxseg size 1400-65495 counter tcp option maxseg size set rt mtu'
当方の環境はDebianなので、このスクリプトをchmod +xにして、起動時に/etc/rc.localから呼び出しています。要点は以下の通りです。
1. udpは ct countにて1ポートセットあたり16接続まで許可し、それ以上は次のポートセットに流れるようにした。
2. icmpは、udpと同じ記述にした。※１
3. tcpについては、別途vmapを用意しパケットにマーキングしてから、それぞれmap-e_chain$markに飛ばしトラフィックを分散させるようにした。
以上です。
ちなみに以下の二行（※２）がないと、なぜかタイプD/タイプ3判定になってしまいます。
nft add chain ip map-e_nat PREROUTING { type nat hook prerouting priority 0 \; }
nft add chain ip map-e_nat OUTPUT { type nat hook output priority 0 \; }
なお、interface enp1s0f0(wan側 /etc/network/interfaces.d/enp1s0f0)は以下のようにしています。
auto enp1s0f0 iface enp1s0f0 inet6 dhcp accept_ra 2 request_prefix 1参考までに、起動時にdhcpv6がrebindし、interfaceがアップされない場合があります。この場合、応急措置ですが、/var/lib/dhcp/dhclient6.enp1s0f0.leasesを削除（またはrename）してから、
sudo ifdown enp1s0f0 sudo ifup enp1s0f0とするか再起動すると、当方の環境で確認しただけですが、大抵通信できるようになっていますので、通信が開始されない場合一度試してみてください。
なお、/etc/sysctl.conf、radvd、dhcp serverの設定、firewall設定、lan側インターフェイスの設定などについては本稿では触れていませんので悪しからずご了承ください。
今回は以上です。それでは。
追記１：2023/04/03現在のOpenWRTスナップショット版（kmod-nft-connlimitパッケージをインストール）で上述のスクリプトのnft設定部分がほぼ同じものを適用したところ、OpenWRTでもニチバンベンチクリアかつナットタイプ判定Bにできました。
追記２:2023/04/15: Debian 12にアップグレード後、接続確立後しばらくしてから、dhclientが起動されずにWAN側のIPv6接続が切断され結果としてIPv4接続も切れてしまうのですが、/etc/rc.localに以下を先頭に記述することで接続断の回避ができました。
dhclient -6 -v -pf /run/dhclient6.enp1s0f0.pid -lf /var/lib/dhcp/dhclient6.enp1s0f0.leases -I -P -N -df /var/lib/dhcp/dhclient.enp1s0f0.leases enp1s0f0
※１注釈:1 https://datatracker.ietf.org/doc/html/draft-ietf-softwire-map-03 より
"If a MAP CE receives an ICMP message having ICMP identifier field in ICMP header, NAT44 in the MAP CE must rewrite this field to a specific value assigned from the port-set. BR and other CEs must handle this field similar to the port number in the TCP/UDP header upon receiving the ICMP message with ICMP identifier field."
"CEがICMPヘッダーにICMP identifierを含むICMPメッセージを受信する場合、CE内のNAT44はこのフィールドをポートセットから割り当てられた特定の値に書き換えなければならない。BRと他のCEは、ICMP identifierを含むICMPメッセージを受信する場合、このフィールドをTCP/UDPヘッダーのポート番号と同様に扱わなければならない。"
※１注釈:2 注釈:1の通り、外部からmap-eルータにnping(nmapパッケージに含まれる)で、ルータのIPアドレスとID(map-eで割り振られたポート番号のいずれか)を指定してecho requestすると、firewall設定で制限されていない限り、map-e routerはecho replayを返します。(割り振られたポート番号以外を指定するとecho replayは基本的には帰ってきません。)
nping --icmp-id 6xxxx AA.BB.CC.DD Starting Nping 0.7.80 ( https://nmap.org/nping ) at 2023-04-04 00:27 JST SENT (0.0194s) ICMP [WW.XX.YY.ZZ > AA.BB.CC.DD Echo request (type=8/code=0) id=6xxxx seq=1] IP [ttl=64 id=57877 iplen=28 ] RCVD (0.0223s) ICMP [AA.BB.CC.DD > WW.XX.YY.ZZ Echo reply (type=0/code=0) id=6xxxx seq=1] IP [ttl=54 id=62016 iplen=28 ] SENT (1.0196s) ICMP [WW.XX.YY.ZZ > AA.BB.CC.DD Echo request (type=8/code=0) id=6xxxx seq=3] IP [ttl=64 id=57877 iplen=28 ] RCVD (1.0221s) ICMP [AA.BB.CC.DD > WW.XX.YY.ZZ Echo reply (type=0/code=0) id=6xxxx seq=3] IP [ttl=54 id=62181 iplen=28 ] SENT (2.0213s) ICMP [WW.XX.YY.ZZ > AA.BB.CC.DD Echo request (type=8/code=0) id=6xxxx seq=3] IP [ttl=64 id=57877 iplen=28 ] RCVD (2.0238s) ICMP [AA.BB.CC.DD > WW.XX.YY.ZZ Echo reply (type=0/code=0) id=6xxxx seq=3] IP [ttl=54 id=62381 iplen=28 ] SENT (3.0229s) ICMP [WW.XX.YY.ZZ > AA.BB.CC.DD Echo request (type=8/code=0) id=6xxxx seq=4] IP [ttl=64 id=57877 iplen=28 ] RCVD (3.0254s) ICMP [AA.BB.CC.DD > WW.XX.YY.ZZ Echo reply (type=0/code=0) id=6xxxx seq=4] IP [ttl=54 id=62538 iplen=28 ] SENT (4.0246s) ICMP [WW.XX.YY.ZZ > AA.BB.CC.DD Echo request (type=8/code=0) id=6xxxx seq=5] IP [ttl=64 id=57877 iplen=28 ] RCVD (4.0274s) ICMP [AA.BB.CC.DD > WW.XX.YY.ZZ Echo reply (type=0/code=0) id=6xxxx seq=5] IP [ttl=54 id=62730 iplen=28 ] Max rtt: 2.816ms | Min rtt: 2.416ms | Avg rtt: 2.585ms Raw packets sent: 5 (140B) | Rcvd: 5 (140B) | Lost: 0 (0.00%) Nping done: 1 IP address pinged in 4.06 seconds
コメント
コメントを投稿