2年越しの正直
OCNの輻輳がヤバいわよ!
NTT東西のフレッツがやっと10Gbps対応のフレッツ光クロスが発表された昨今ですが……最近またOCNの深夜時間帯(24時前後)の輻輳が酷くIPv4 PPPoEが5Mbps程度しか出ないことが頻繁に発生している。
ところでうちは現時点では光クロスはおろかいくつか開始された10G商用個人向けサービスでもエリア的にはeoくらいしか対応していない模様……
深夜の輻輳の後、明け方に突然600Mbps程度出るようになることが最近も過去にも何度かあったため実は対処可能な詰りかたをしているのじゃないかなどと勘ぐったりすることもあるものの、まあPPPoEだからってことで纏められてしまっているのでそういうことにしてくとして。
で、NTTとしてはPPPoEは限界だからDS-LiteやMAP-EなどのIPv4 over IPv6を使えってスタンスっぽい。光クロスも提供開始時点ではv6 IPoE+ v4 over v6のみの展開とリリースされている。(ただしプレスリリースに「PPPoE方式については、準備が整い次第提供予定となります。」とあるのでPPPoEも提供するみたい。)
OCNはOCN v6アルファ や OCNバーチャルコネクトと称して IPoEのVNCと、その上で利用可能なMAP-Eによるv4 over v6トンネルの提供をOCNやその他のOCNバーチャルコネクトを利用しているISPユーザーに提供している。v6アルファ/v6アルファ自体はOCN for ドコモ光を除いてレンタルルーターを含め月500円で提供されているが、MAP-E自体はこの契約がなくも利用できることが判明している。そもそもOCN以外なら最初からいらないってわかってたんだからOCNだけオプション必要なのもおかしいでしょ。
2020/6/11のリリースでv6アルファ不要で利用できることやフレッツ・ジョイントによりHGW単体で接続可能になることが明記された。
最近はNTTComやドコモなどから発売、レンタルされているルーター以外にも各社から販売されている無線LANルーターなどでもOCNバーチャルコネクトのMAP-Eを経由する接続が行えるようになったので導入の敷居はかなり下がっているものの、残念ながらうちに公式に対応しているルーターはない。(1世代あとなら対応してたんだけどな……)
OpenWrtでMAP-Eしてみる
OCNの割当アドレスのアドレスマッピングについては提供開始早々にかなりの調査がおこなわれていたのは懐しいが、ここ1年で色々と情報も増えたようでOpenWrtで接続できそうだったので試してみた。うまくいかなかったり行き詰まったりして一晩かかったけど疎通確認はできた。
うちのネット環境は2年前から特に大きな変化はない(端末はけっこうかわったけど)のでそちらを参照。
v6プラスのエントリであるが、以下のエントリが結構参考になった。
あくまでも疎通確認を目的とした実験として、仮想マシン上のルーターにおいて接続を行い、他のマシンからの接続のルーティングは行っていない。が、まあ通常通り設定すればいいだろう。
実験環境
Arch Linux (Linux 5.5.8-arch1-1 #1 SMP PREEMPT Fri, 06 Mar 2020 00:57:33 +0000 x86_64 GNU/Linux)のラップトップ上のVirtualboxにて最新のOpenWrt x86_64 (OpenWrt 19.07.2 r10947-65030d81f3, kernel: 4.14.171)を展開した。
関与するネットワーク機器としてはHGW(RT-500KI), Aterm WG2600HP2であり、ラップトップはこのAtermに866.7 MBit/sリンクの無線LANで接続されている。(ping2.5ms)
下準備
手元にちょうどいいOpenWrtルーターはなかった(つかえそうなやつは先日こわれてしまった)ので、前述のとおりVboxにVMを建てた。別にVBoxである必要なくて何でもいいんだけどとりあえず勝手がわかってるもので。
VirtualBoxにおけるOpenWrtの初期設定はおおよそWikiにある通りだが、今回はIPv6ネットワークが必須なので最初から多少ガイドに逆らっている。
まず、VMには以下の3つのネットワークアダプタを接続した。
- eth0: hostonly adapter
- eth1: NAT adapter
- eth2: bridge adapter (to Wi-Fi)
v6を回すためブリッジアダプターは欠かせなかったが、NATアダプターは今回はなくてよかったかもしれない。
最初のうちはv4(PPPoE)をeth1、v6をeth2から回していたが……別に今おもえばeth2でよかったこれ。どうせLAN側にはならないんだし。
とりあえず用意したVMにSSHして諸々の初期設定をし、インターネットに接続を確認できたらopkgで map
とcurl
のパッケージは追加しておく。
また、マッピングルールも計算しておく。大概のアドレスは例のツールで網羅されているはず。OCNの2400:4000::/22以下のアドレスはip6prefixlen 38,ip4prefixlen 20らしい。ツールにOCNアドレスを入力すると「未対応のプレフィックス(一部地域のみ対応)」とアラートが表示されるが、これだけが出るなら多分問題なく計算できている。
IPv6インタフェースの設定
自分は初期設定においてDHCPv6のインタフェースwan6をただeth2に向けるだけの設定をしていたが、この場合HGWが/60のサブネットを割り当てるためIPv6 PDがMAP-EのCEとprefixが一致せず疎通できない原因となることが後に判明した。このことはYAMAHAのv6プラス設定例でも明記されている。
もとのは停止し、複製したインターフェスwan6sを用意したので以後それで表記するが、このwan6sのCustom delegated IPv6-prefix (ip6prefix
) にHGWがRAで広告しているものと同じ64のprefixを指定することで(健全なルーターにはみえなくなったが)ひとまずこの問題が回避でき、インターネットに疎通がとれる。
ひとまずこの段階でpingやcurlによるhttpリクエストがv6で通るか確認しておくとよいだろう。
MAP-Eの設定
やっとこさ本題。
先に計算したマッピングデータをもとに、インタフェースの設定をする……のだが、ここで2つの問題が発生した。
BRのアドレスがわからない!
luciのインタフェース設定から「MAP / LW4over6」を選択し、項目を埋めていけばよいのだが、肝心なことを忘れていた。BR、すなわちトンネル対向のIPアドレスを把握していなかった。
JPNEのv6プラスにおいてこのアドレスが 2404:9200:225:100::64
であることは有名であるが、OCNのBRアドレスは公開されていない。どうやら回線ごとに異るとの説もある。
どうやら公式の方法としてはここに掲載されているようなAPIから取得できるみたいなのだが、残念ながらAPIキーはわからない。
何か手段はないかと探っていたところ、どうやらHGWのパケットフィルタのログからこのIPアドレスを発見できるという。そういやOCN管轄の謎のIPアドレスからのパケットがパケットフィルタのログに以前でていたのを思い出し確認してみたところ、まさにそれらしきアドレスからCEのIPアドレスへのログがみつかった。
1 |
2. 2020/3/10 09:04:19 SRC=2001:03**:****:0000:0000:0000:0000:****/- DST=2400:41**:****:**00:00**:**10:0000:****/- 4 table=filter |
どうやら、これがBRのアドレスのよう。アドレスの後にある4
はIPIPトンネルのプロトコル番号である。
もしパケットフィルタのログに出ていない場合、出口v4アドレスの割当ポートのうちのいずれかに適当なパケット(HTTPでよい)を投げるとパケットフィルタのログに出てくる。(ところでこのIPアドレスをぐぐるとヒステリックになってる人がでてくるくらいなので伏せる必要もなさそう)
設定が保存できない!
無事BRアドレスがわかったので各フィールドを入力し保存しようとしたところ、保存ボタンをおしてもスピナーがぐるぐる回るだけで先にすすめない。保存できてるのかとおもい モーダルを閉じるも、変更は反映されていない。コンソールをみてみると、2種類のJSエラーが発生していることが確認できた。バグ?
仕方ないのでSSHから直接設定を弄ることにする。ほんとはuciからやるべきだろうけどめんどいので直接config編集。
あ、そうそう、/lib/netifd/proto/map.sh
を編集してlegacy modeを有効化するのも忘れずに。
で、 /etc/config/network
の当該インタフェースの設定は以下のようになった。例の計算スクリプトはOpenWrtで使える形式で出力してくれているので親切。(まあそのためのものだから……)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
config interface 'wan_mape' option proto 'map' option type 'map-e' option peeraddr '2001:03**:**::*' option ipaddr '180.xx.xx.x' option ip4prefixlen '20' option ip6prefix '2400:41**:****:**00::' option ip6prefixlen '38' option ealen '18' option psidlen '6' option offset '6' option encaplimit 'ignore' list tunlink 'wan6s' config interface 'wan6s' option ifname 'eth2' option encaplimit 'ignore' option proto 'dhcpv6' option reqaddress 'try' list ip6prefix '2400:41**:****:**00::/64' option reqprefix 'auto' |
firewallのzoneは/etc/config/firewall
で追加すればいい。こっちはucsでやった。
この状態でwan6s, wan_mapeを順に起動すると wan_mape_ としてCEのアドレスをもった仮想インタフェースが起動する。
疎通テスト
接続の確認
まずはpingを飛ばしてみる。接続直後は返事の帰ってこないことがあったが、30秒ほどおいてみると問題なくつながる。
1 |
root@OpenWrt:~# ping -4 blog.hinaloe.net -c 4<br />PING blog.hinaloe.net (163.44.172.137): 56 data bytes<br />64 bytes from 163.44.172.137: seq=0 ttl=51 time=22.174 ms<br />64 bytes from 163.44.172.137: seq=1 ttl=51 time=21.695 ms<br />64 bytes from 163.44.172.137: seq=2 ttl=51 time=20.236 ms<br />64 bytes from 163.44.172.137: seq=3 ttl=51 time=20.994 ms<br /><br />--- blog.hinaloe.net ping statistics ---<br />4 packets transmitted, 4 packets received, 0% packet loss<br />round-trip min/avg/max = 20.236/21.274/22.174 ms<br /> |
当然ながらこれだけでは経由しているネットワークが確認できないのでIPアドレスを確認してみる。
1 2 |
# curl -4 ipaddr.ga 180.**.*.* |
ところで、ipaddr.gaにはJSONでIPアドレス以外の情報も簡易的に返す機能を用意していた。これを使うと、逆引きホストやリクエストポートの確認ができる。
1 2 3 |
# curl -4 ipaddr.ga/all.json {"ip":"180.**.**.*","country_code":"JP","host":"p********-ipoe.ipoe.ocn.ne.jp","ua":"curl\/7.66.0","port":"1327","lang":null,"ref":null,"method":"GET","encoding":null,"mime":"*\/* ","forwarded":""} |
portがMAP-Eによる割当範囲内であることも確認できる。
また、tracerouteも叩いてみた。最初に表示されるルーターはPPPoEではふだん4番目あたりにやっと表れる 153.149.204.*
のもの。BRが県域ネットワーク外にあるためなのかな、などと。
1 2 3 4 5 6 7 8 9 |
traceroute to blog.hinaloe.net (163.44.172.137), 30 hops max, 46 byte packets 1 153.149.204.82 (153.149.204.82) 16.166 ms 11.862 ms 13.749 ms 2 153.149.204.81 (153.149.204.81) 14.724 ms 13.804 ms 11.595 ms 3 211.0.208.78 (211.0.208.78) 49.629 ms 80.360 ms 12.721 ms 4 ae1.transit1.nihonbashi.vectant.ne.jp (163.139.128.162) 21.569 ms ae0.transit1.nihonbashi.vectant.ne.jp (163.139.128.158) 24.257 ms 19.211 ms 5 202.215.242.50 (202.215.242.50) 27.642 ms 21.772 ms 24.064 ms 6 unused-133-130-013-018.interq.or.jp (133.130.13.18) 29.623 ms 21.443 ms 24.275 ms 7 unused-133-130-014-142.interq.or.jp (133.130.14.142) 40.600 ms 23.144 ms 22.711 ms 8 v163-44-172-137.a069.g.tyo1.static.cnode.io (163.44.172.137) 25.776 ms 21.459 ms 24.685 ms |
自宅PPPoEのIPとBRの出口アドレスを相互にtracerouteしたところ同様のルートで少なからず遠回りしているような経路がみえる。仕方ないが。(IPoEのPOIはH30/3の資料で東京と大阪にしかないしまあそういうこと。まあPOIは以降の2年間でいくつも開設されているが。)
スピードテスト
speedtest.netのCLIツールが様々なCPUアーキテクチャ向けにバイナリで提供されているのでこれをDLして利用する。今回はx86_64VMなのでそれ用のものを使用している。
1 2 |
# curl -OL https://bintray.com/ookla/download/download_file?file_path=ookla-speedtest-1.0.0-x86_64-linux.tgz # tar xzf download_file?file_path\=ookla-speedtest-1.0.0-x86_64-linux.tgz |
比較的安定し、意識せずともv4アドレスで接続できるサーバーとしてOPEN Project (via 20G SINET) (15047)を相手取り、帯域幅測定を何度かおこなった。(楽天モバイルなどの提供するサーバーはIPv6に対応しているため、オプションを指定されないとそちらが優先されかねない)
1 2 3 4 5 6 7 8 9 10 11 |
# ./speedtest --server-id=15047 Speedtest by Ookla Server: OPEN Project (via 20G SINET) - Tokyo (id = 15047) ISP: NTT Latency: 21.44 ms (1.47 ms jitter) Download: 112.24 Mbps (data used: 202.3 MB) Upload: 92.78 Mbps (data used: 58.1 MB) Packet Loss: 0.0% Result URL: https://www.speedtest.net/result/c/d067100b-3b15-46dc-97ad-fa6562b2aa61 |
ホストのArchでも同様にPPPoE経由で同サーバーを利用した測定をつづけて行ったが、PPPoEの空いている時間帯(下り600Mbps)や混雑している時間帯(下り10Mbps以下)などを問わずして安定して下り100~110Mbps、上り90-100Mbpsあたりを得られた。
VMで行っているもあるだろうが、よくも悪くも回線の混雑度の影響を受けていない。様子をみている限り、必ずしもPPPoEより速いわかではなく、むしろ異常に混雑している時以外はPPPoEの方が速いことの方が多い。上りについては混雑時でもPPPoEの方が速い。うちでは。
何故か接続がきれる
接続直後は問題ないのだが、数時間放置しているとIPv6のパケットが入ってこなくなる。VMでブリッジしているためかもしれないし、RA proxyをするわけでもなく雑にDHCPv6を使用しているためかも原因はよくわかっていないが、外部のv6アドレスに(あるいはLAN内についても)pingを送っても帰ってこなくなったりする。パケットキャプチャをみてもどうも外向きに問題があるようには見えない。当然ながらコネクションプールには余裕しかないので謎。RA Relayあたりの設定……とか経路設定が正しくないとかありそうだけどよくわからん、すこし違うきがする。経路みても問題なさそうだし……まあWLANのVMだし仕方ないか(?)
まとめ
VM上にOpenWrtのルーターを建ててMAP-Eのトンネルが張れることを確認するやつをやった。
手を動かしてみるとトンネル自体は結構単純なIPIPトンネルであることが確認できたりしたものの、マップルールの計算とか複雑だったり通知方法が標準化されてるわけではなかったりするのは少し厄介ともわかった。
あと、IPoEは必ずしもPPPoEより速いとは限らないし、その上を通したトンネルが速いとも限らない。もちろんPOI拡張性などといった接続上のメリットもあるが。
追記のコーナー
ねぼけ眼でやったのとか途中あいちゃったとかで色々わすれてるところがあったので指摘大歓迎。
ポートセットが使いきれてなくない?
ほんまや……
1 |
opkg install iptables-mod-ipopt |
上記gistのとおりSNATにマッチングルールを追加する。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
--- map.sh.org 2020-03-15 03:20:30.938435300 +0000 +++ map.sh 2020-03-15 03:22:21.508257718 +0000 @@ -140,6 +140,7 @@ json_add_string snat_ip $(eval "echo \$RULE_${k}_IPV4ADDR") json_close_object else + local mark=10 for portset in $(eval "echo \$RULE_${k}_PORTSETS"); do for proto in icmp tcp udp; do json_add_object "" @@ -147,11 +148,13 @@ json_add_string target SNAT json_add_string family inet json_add_string proto "$proto" + json_add_string mark "$mark" json_add_boolean connlimit_ports 1 json_add_string snat_ip $(eval "echo \$RULE_${k}_IPV4ADDR") json_add_string snat_port "$portset" json_close_object done + mark=`expr $mark + 1` done fi if [ "$type" = "map-t" ]; then |
v6プラスでは16*15の240のポートしか割当られないらしいが、OCNでは16*63の1008ポートが割り当てられるらしい。実に4倍以上。240のままじゃあれなのでとりあえず倍の480まで使うようにしておいた。SNATテーブルの様子はiptables -t nat -L -v
で確認できるが、もし公開用に4桁ポートを使うつもりでもあれば頭10組くらいは飛しておいてもいいかもしれない。とりあえずそんなことは考えずに480ポートをFIFOで割り当てるようにしてみた。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 |
## /etc/firewall.user # This file is interpreted as shell script. # Put your custom iptables rules here, they will # be executed with each firewall (re-)start. # Internal uci firewall chains are flushed and recreated on reload, so # put custom rules into the root chains e.g. INPUT or FORWARD or into the # special user chains, e.g. input_wan_rule or postrouting_lan_rule. iptables -t nat -A PREROUTING -m statistic --mode nth --every 30 --packet 0 -j MARK --set-mark 10 iptables -t nat -A PREROUTING -m statistic --mode nth --every 30 --packet 1 -j MARK --set-mark 11 iptables -t nat -A PREROUTING -m statistic --mode nth --every 30 --packet 2 -j MARK --set-mark 12 iptables -t nat -A PREROUTING -m statistic --mode nth --every 30 --packet 3 -j MARK --set-mark 13 iptables -t nat -A PREROUTING -m statistic --mode nth --every 30 --packet 4 -j MARK --set-mark 14 iptables -t nat -A PREROUTING -m statistic --mode nth --every 30 --packet 5 -j MARK --set-mark 15 iptables -t nat -A PREROUTING -m statistic --mode nth --every 30 --packet 6 -j MARK --set-mark 16 iptables -t nat -A PREROUTING -m statistic --mode nth --every 30 --packet 7 -j MARK --set-mark 17 iptables -t nat -A PREROUTING -m statistic --mode nth --every 30 --packet 8 -j MARK --set-mark 18 iptables -t nat -A PREROUTING -m statistic --mode nth --every 30 --packet 9 -j MARK --set-mark 19 iptables -t nat -A PREROUTING -m statistic --mode nth --every 30 --packet 10 -j MARK --set-mark 20 iptables -t nat -A PREROUTING -m statistic --mode nth --every 30 --packet 11 -j MARK --set-mark 21 iptables -t nat -A PREROUTING -m statistic --mode nth --every 30 --packet 12 -j MARK --set-mark 22 iptables -t nat -A PREROUTING -m statistic --mode nth --every 30 --packet 13 -j MARK --set-mark 23 iptables -t nat -A PREROUTING -m statistic --mode nth --every 30 --packet 14 -j MARK --set-mark 24 iptables -t nat -A PREROUTING -m statistic --mode nth --every 30 --packet 15 -j MARK --set-mark 25 iptables -t nat -A PREROUTING -m statistic --mode nth --every 30 --packet 16 -j MARK --set-mark 26 iptables -t nat -A PREROUTING -m statistic --mode nth --every 30 --packet 17 -j MARK --set-mark 27 iptables -t nat -A PREROUTING -m statistic --mode nth --every 30 --packet 18 -j MARK --set-mark 28 iptables -t nat -A PREROUTING -m statistic --mode nth --every 30 --packet 19 -j MARK --set-mark 29 iptables -t nat -A PREROUTING -m statistic --mode nth --every 30 --packet 20 -j MARK --set-mark 30 iptables -t nat -A PREROUTING -m statistic --mode nth --every 30 --packet 21 -j MARK --set-mark 31 iptables -t nat -A PREROUTING -m statistic --mode nth --every 30 --packet 22 -j MARK --set-mark 32 iptables -t nat -A PREROUTING -m statistic --mode nth --every 30 --packet 23 -j MARK --set-mark 33 iptables -t nat -A PREROUTING -m statistic --mode nth --every 30 --packet 24 -j MARK --set-mark 34 iptables -t nat -A PREROUTING -m statistic --mode nth --every 30 --packet 25 -j MARK --set-mark 35 iptables -t nat -A PREROUTING -m statistic --mode nth --every 30 --packet 26 -j MARK --set-mark 36 iptables -t nat -A PREROUTING -m statistic --mode nth --every 30 --packet 27 -j MARK --set-mark 37 iptables -t nat -A PREROUTING -m statistic --mode nth --every 30 --packet 28 -j MARK --set-mark 38 iptables -t nat -A PREROUTING -m statistic --mode nth --every 30 --packet 29 -j MARK --set-mark 39 iptables -t nat -A OUTPUT -m statistic --mode nth --every 30 --packet 0 -j MARK --set-mark 10 iptables -t nat -A OUTPUT -m statistic --mode nth --every 30 --packet 1 -j MARK --set-mark 11 iptables -t nat -A OUTPUT -m statistic --mode nth --every 30 --packet 2 -j MARK --set-mark 12 iptables -t nat -A OUTPUT -m statistic --mode nth --every 30 --packet 3 -j MARK --set-mark 13 iptables -t nat -A OUTPUT -m statistic --mode nth --every 30 --packet 4 -j MARK --set-mark 14 iptables -t nat -A OUTPUT -m statistic --mode nth --every 30 --packet 5 -j MARK --set-mark 15 iptables -t nat -A OUTPUT -m statistic --mode nth --every 30 --packet 6 -j MARK --set-mark 16 iptables -t nat -A OUTPUT -m statistic --mode nth --every 30 --packet 7 -j MARK --set-mark 17 iptables -t nat -A OUTPUT -m statistic --mode nth --every 30 --packet 8 -j MARK --set-mark 18 iptables -t nat -A OUTPUT -m statistic --mode nth --every 30 --packet 9 -j MARK --set-mark 19 iptables -t nat -A OUTPUT -m statistic --mode nth --every 30 --packet 10 -j MARK --set-mark 20 iptables -t nat -A OUTPUT -m statistic --mode nth --every 30 --packet 11 -j MARK --set-mark 21 iptables -t nat -A OUTPUT -m statistic --mode nth --every 30 --packet 12 -j MARK --set-mark 22 iptables -t nat -A OUTPUT -m statistic --mode nth --every 30 --packet 13 -j MARK --set-mark 23 iptables -t nat -A OUTPUT -m statistic --mode nth --every 30 --packet 14 -j MARK --set-mark 24 iptables -t nat -A OUTPUT -m statistic --mode nth --every 30 --packet 15 -j MARK --set-mark 25 iptables -t nat -A OUTPUT -m statistic --mode nth --every 30 --packet 16 -j MARK --set-mark 26 iptables -t nat -A OUTPUT -m statistic --mode nth --every 30 --packet 17 -j MARK --set-mark 27 iptables -t nat -A OUTPUT -m statistic --mode nth --every 30 --packet 18 -j MARK --set-mark 28 iptables -t nat -A OUTPUT -m statistic --mode nth --every 30 --packet 19 -j MARK --set-mark 29 iptables -t nat -A OUTPUT -m statistic --mode nth --every 30 --packet 20 -j MARK --set-mark 30 iptables -t nat -A OUTPUT -m statistic --mode nth --every 30 --packet 21 -j MARK --set-mark 31 iptables -t nat -A OUTPUT -m statistic --mode nth --every 30 --packet 22 -j MARK --set-mark 32 iptables -t nat -A OUTPUT -m statistic --mode nth --every 30 --packet 23 -j MARK --set-mark 33 iptables -t nat -A OUTPUT -m statistic --mode nth --every 30 --packet 24 -j MARK --set-mark 34 iptables -t nat -A OUTPUT -m statistic --mode nth --every 30 --packet 25 -j MARK --set-mark 35 iptables -t nat -A OUTPUT -m statistic --mode nth --every 30 --packet 26 -j MARK --set-mark 36 iptables -t nat -A OUTPUT -m statistic --mode nth --every 30 --packet 27 -j MARK --set-mark 37 iptables -t nat -A OUTPUT -m statistic --mode nth --every 30 --packet 28 -j MARK --set-mark 38 iptables -t nat -A OUTPUT -m statistic --mode nth --every 30 --packet 29 -j MARK --set-mark 39 |
雑に再起動してポートの分散していることを確認できた。
ところで、書いてから気づいたけどfirewall.user
はシェルスクリプトなので雑にループ書いた方がフレキシビリティだとかも含めいいきがした。ので変えてみた。大方NanoPi NEO2をv6プラスのルーターにする 後編 – がとらぼのスクリプトを流用させてもらった。
1 2 3 4 5 6 7 8 9 10 11 12 |
units=32 rule=1 while [ $rule -le $units ];do mark=`expr $rule + 20` pn=`expr $rule - 1` iptables -t nat -A PREROUTING -m statistic --mode nth --every $units --packet $pn -j MARK --set-mark $mark iptables -t nat -A OUTPUT -m statistic --mode nth --every $units --packet $pn -j MARK --set-mark $mark rule=`expr $rule + 1` done |
FIFOだから使い方によっては効率よくないみたいな話もあるけどまあ480あれば早々問題にはならんやろ……
VMのeth4をX395の有線LANにブリッジさせてX240を有線のみで繋ぎ、いいかんじにルーティングするやつを試行しているが、IPv6のルーティングがうまくいってないっぽい……v4はうまくLANとトンネルに振り分けられてるんだが……
なにそれスゲー気になるいったいどんな人なんだ?