-12日目
YAMAHA RTX830 をSSHで設定する
カバさんルータから卒業すべく、イマドキなインターネッツに対応してて、イマドキなVPN張れて、内部にDNSサーバがあって、安定して動作する安価なルータを探してたら、RTX 830なるものがあると知り、安くなってたのでかっちった。
更新履歴 見出しにジャンプ
日時 | 内容 |
---|---|
2020-05-24 |
|
2020-07-30 |
|
2020-08-21 |
|
2020-08-22 |
|
2022-11-19 |
|
RTX830を選んだ理由 見出しにジャンプ
ヤマハネットワーク製品の仕様比較
documents for Yamaha network products
IPv6 implementation for YAMAHA RT series
NVR510は小型ONUに対応しているが、地元産のオーガニックなVDSLから伸びる古き良き電話線]なので私にはあまり関係ない。
NEC UNIVERGE IX2215やIX2106辺りも視野に入れたが、 内部DNSサーバは無さそう(当時) Appleデバイスに対応したDNSシンクホールはできなさそう なので却下。
結局必要十分ということでRTX830にした。
後に分かったことだが、RTX830にできないことといえばLAN1をLAN側、LAN2をWAN側に割り当てると、タグVLAN(トランクポート)とLAN分割機能(アクセスポート)の共存がRTX単体では不可能なことだ。例えば、LAN3があるRTX1210では可能だ。
用意するもの 見出しにジャンプ
- ルータ本体
ヤマハ ギガアクセスVPNルーターRTX830 1台 ds-2141528
ヤマハ ギガアクセスVPNルーター RTX1220
ヤマハ ギガアクセスVPNルーター RTX1210
ヤマハ ギガアクセスVoIPルーターNVR510 1台 ds-2141530
- シリアルコンソールケーブル
なきゃないでWebGUIからのtelnetなりSSHなりすれば良い
【CISCO互換ケーブル】FTDI chipset USB RJ45 コンソールケーブル
- 届く長さのCat.6A辺りのUTPなLANケーブル
間違って買ってしまったCat.7でも良い
エレコム LANケーブル CAT6A 3m ツメが折れない ブルー LD-GPAT/BU30
- Wi-Fiアクセスポイント
(に降格したWi-Fiルータでも良い)
今時ならWi-Fi6対応のゲーミングWi-Fiルータをブリッジで繋げれば良いと思う
逸般人ははんぺんでもよい
接続 見出しにジャンプ
公式オンラインマニュアル一覧
変な金具の使い方も載ってる
manual release for RT Series
コンセント繋げて電源入れてLANケーブル繋がってれば、ブラウザから192.168.100.1
にアクセスするとWeb GUIが開く。
インターフェースの状態・リンク速度の表示 見出しにジャンプ
LAN1インターフェースの状態
> show status lan1
LAN1
説明:
IPアドレス: 192.168.100.1/24
イーサネットアドレス: ac:44:f2:12:34:56
動作モード設定: Type (Link status)
PORT1: 1000BASE-T Full Duplex (Link up)
PORT2: 1000BASE-T Full Duplex (Link Down)
PORT3: 1000BASE-T Full Duplex (Link up)
PORT4: 1000BASE-T Full Duplex (Link up)
最大パケット長(MTU): 1500 オクテット
プロミスキャスモード: OFF
送信パケット: 70819465 パケット(76958625544 オクテット)
IPv4(全体/ファストパス): 21509110 パケット / 19409183 パケット
IPv6(全体/ファストパス): 49142002 パケット / 46703175 パケット
受信パケット: 33830180 パケット(9127903946 オクテット)
IPv4: 11384615 パケット
IPv6: 22038521 パケット
未サポートパケットの受信: 238296
LAN2(WAN)インターフェースの状態
> show status lan2
LAN2
説明: hogera
IPアドレス:
イーサネットアドレス: ac:44:f2:12:34:56
動作モード設定: Auto Negotiation (100BASE-TX Full Duplex)
最大パケット長(MTU): 1500 オクテット
プロミスキャスモード: OFF
送信パケット: 34105546 パケット(9143530151 オクテット)
IPv4(全体/ファストパス): 9388277 パケット / 7672370 パケット
IPv6(全体/ファストパス): 24645196 パケット / 23004373 パケット
受信パケット: 71333885 パケット(77231763617 オクテット)
IPv4: 16806322 パケット
IPv6: 54318754 パケット
受信オーバーフロー: 6430
CPUやメモリ使用率の表示 見出しにジャンプ
> show environment detail
RTX830 BootROM Ver. 1.01
RTX830 FlashROM Table Ver. 1.02
RTX830 Rev.15.02.26 (Wed Sep 7 12:36:21 2022)
main: RTX830 ver=00 serial=MISERARENAIYO MAC-Address=ac:44:f2:12:34:56 MAC-Address=ac:44:f2:12:34:56
CPU: 0%(5sec) 0%(1min) 0%(5min) メモリ: 44% used
CPU0: 1%(5sec) 0%(1min) 1%(5min)
CPU1: 0%(5sec) 0%(1min) 0%(5min)
パケットバッファ: 0%(small) 0%(middle) 5%(large) 0%(huge) used
...
Web GUI 見出しにジャンプ
Web GUIで大まかな設定は出来るようになっているが、少々分かりにくいのと、整合性の保証がないので、設定後はSSH等でconfigを確認しよう。
ヤマハルーター Web GUI 操作マニュアル RTX830 Webgui.pdf
ユーザーの設定 見出しにジャンプ
管理タブ -> アクセス管理 -> ユーザーの設定 で管理パスワードと、SSHで接続でき、管理ユーザーへの昇格ができるユーザー名のある一般ユーザーを作成しておく。
順番を間違えると権限で詰むので注意(本体MicroSD + USB + Downloadボタン同時押しで工場出荷状態からやり直せる)。
Web GUIでconfigのエクスポート 見出しにジャンプ
管理 -> 保守 -> CONFIGファイルの管理で設定をバックアップできる。
ここでは、configの表示show config
とログイン情報を合わせたファイルをエクスポート/インポートできる。
SSH 見出しにジャンプ
TELNET複数セッション機能、SSHサーバー機能 コマンド
パスワード認証でSSH 見出しにジャンプ
SSHでの無名ログインがよく分からなかったので、Web GUIでユーザをつくって接続。
ssh [email protected]
[email protected]'s password:
RTX830 Rev.15.02.14 (Thu Dec 19 10:43:21 2019)
Copyright (c) 1994-2019 Yamaha Corporation. All Rights Reserved.
To display the software copyright statement, use 'show copyright' command.
XX:XX:XX:XX:XX:XX, XX:XX:XX:XX:XX:XX
Memory 256Mbytes, 2LAN
>
文字化け 見出しにジャンプ
環境によって適切な文字コードは変わる。en.ascii
かja.utf8
を選択した。
4.20 コンソールの言語とコードの設定
- console character ja.sjis
+ console character ja.utf8
コンソール表示文字数の設定 見出しにジャンプ
一行が長いconfigの一覧性やコピペする時の使い勝手の為に、コンソールの横幅を大きくする。
4.21 コンソールの表示文字数の設定
- console columns 80
+ console columns 1024
一行が長いconfigはコピペ時に切れてしまうので、VSCodeのTerminalやconfigファイルを直接書き込む等の工夫が必要。
コンソールにsyslogを表示 見出しにジャンプ
- console info off
+ console info on
4.23 コンソールにシステムメッセージを表示するか否かの設定
ログレベル 見出しにジャンプ
# # SYSLOG configuration # syslog notice on syslog info on syslog debug off
エラー: このコマンドは管理レベルでのみ使用できます 見出しにジャンプ
administrator
で 所謂sudo
のように昇格できる。
> save
エラー: このコマンドは管理レベルでのみ使用できます
> administrator
Password:
# save
設定の保存 見出しにジャンプ
RTXのコマンドは実行した瞬間に適用され、電源が入っていれば設定が保持される。
電源を切っても設定を保持できるように、不揮発性メモリに書き込む必要がある。
> administrator
Password:
# save
セーブ中... CONFIG0 終了
# exit
>
> administrator
Password:
不揮発性メモリに保存されていない設定変更があります
# quit
新しい設定を保存しますか? (Y/N)Y
セーブ中... CONFIG0 終了
>
SSHの鍵認証 見出しにジャンプ
まずはクライアントで鍵ペアの生成
ssh-keygen -t ed25519
Generating public/private rsa key pair.
Enter file in which to save the key (/home/sbn/.ssh/id_rsa): rtx830_id_ed25519
~~
ls
rtx830_id_ed25519 rtx830_id_ed25519.pub
sftpでRTX本体のフラッシュメモリに送る
sftp [email protected]
[email protected]'s password:
Connected to 192.168.100.1.
sftp> ls
dashboard system
administratorのpasswordじゃないとPermission Denied
sftp> mkdir pub
sftp> ls
dashboard pub system
sftp> cd pub
sftp> put rtx830_id_ed25519.pub .
Uploading rtx830_id_ed25519.pub to /pub/./rtx830_id_ed25519.pub
rtx830_id_ed25519.pub 100% 98 133.9KB/s 00:00
sftp> ls
rtx830_id_ed25519.pub
sftp> exit
ssh [email protected]
[email protected]'s password:
Connected to 192.168.100.1.
> administrator
Password:
# sshd authorized-keys filename sbn path=/pub/rtx830_id_ed25519.pub
# save
# exit
> exit
telnet・Web GUIの無効化 見出しにジャンプ
4.34 TELNET サーバーへアクセスできるホストの設定
36.1.2 HTTP サーバーへアクセスできるホストの設定
SSHが確実にできる環境が出来れば、telnetやhttpdで入れないようにした方がセキュア。
telnetd host none
httpd host none
確認
$ telnet 192.168.100.1 Trying 192.168.100.1... telnet: Unable to connect to remote host: Connection refused
シャットダウン・再起動 見出しにジャンプ
再起動はコマンドがあるが、シャットダウンは電源ボタンをブチッで良いんか?良いんかなぁ...
restart
configの変更履歴 見出しにジャンプ
> show config list
No. Date Time Size Sects Comment
----- ---------- -------- ------- ------- ------------------------------------
* 0 2021/02/23 18:54:46 5587 367/367
0.1 2021/02/23 18:53:38 5615 364/364
0.2 2021/02/23 18:53:06 5622 365/365
----- ---------- -------- ------- ------- ------------------------------------
外部メモリ 見出しにジャンプ
configやsyslogをsftpでバックアップ 見出しにジャンプ
RTXに鍵認証でSSHできるようにしてあれば、サクッとSFTPでconfigやsyslogを取得できる。
echo "get system/config config.txt" | sftp rtx
# RTXのsyslogを取得
$rtxsysloglist = (wsl -- echo 'ls -1t /sd1/syslog*' `| sftp rtx) | Where-Object { $_ -match "^/sd1/syslog.*$" }
$rtxsysloglist
$rtxsysloglist | Select-Object -First 2 | ForEach-Object {
wsl -- echo "get -p $_ /mnt/e/rtxsyslog/" `| sftp rtx
}
RTXをWLXのsyslogサーバにするLuaスクリプト 見出しにジャンプ
rt.socket.udp() Lua言語のライブラリ関数
のサンプルスクリプトを少し弄っただけ。
rtxconfig/listen-syslog.lua at main · nyanshiba/rtxconfig
WLXのログのうち、STAの接続要請, DFS, チャンネル自動選択をRTXのsyslogに流す。
ログメッセージリファレンス WLX212技術資料
Fast DFS非対応のWLX212では、DFSチャンネル選択範囲にW52を選ぶが、集合住宅では隣家も同時刻にDFSするため、W52帯は混雑してしまう。
DFS チャンネル選択範囲でW52のチャンネルのみを選択すると、レーダー検出によりチャンネルが移動したときに1分間の通信途絶を防ぐことができます。
自動チャンネル変更機能 WLX212技術資料
このようにWLXのログを収集してDFSが発生する大方の時刻が分かれば、適切な時刻にチャンネル再選択を設定でき、快適な周波数帯への切り戻しを早められる。
> show status lua running
# terminate lua all
46.4 Lua スクリプトの走行状態の表示
46.5 Lua スクリプトの強制終了
インターネット接続 見出しにジャンプ
IPv6 IPoE 見出しにジャンプ
大人の事情で輻輳しがちなIPv4 PPPoEに代わり、IPv6 IPoEネイティブ方式およびIPv4 over IPv6を使えるように設定する。
IPv6 implementation for YAMAHA RT series
フレッツ光のひかり電話契約なしの場合RAプロキシ、ひかり電話あり・光クロスの場合はDHCPv6-PDでPrefixを取得する。
フレッツ 光ネクスト インターネット(IPv6 IPoE)接続
フレッツ 光クロス インターネット(IPv6 IPoE)接続
IPv6 IPoE対応機能
これらの設定を行うと、IPv6インターネットとサービス情報サイト(NGN IPv6)に接続可能。フレッツ契約情報を確認・変更したり、NGN網内の速度計測ができる。
NGN IPv4は別途PPPoEの設定が必要。
サービス情報サイト(IPv6 / NTT東日本)への接続 : コマンド設定
接続方法|サービス情報サイト|フレッツ公式|NTT東日本
Web GUIを使用してRAプロキシを構成すると、下記のようなconfigを取り出すことができる。暗黙的に設定されているデフォルトconfigも交えて解説を挟む。
config | 説明 |
---|---|
#
# IPv6 configuration
#
ipv6 routing on
ipv6 max auto address 16
+ ipv6 prefix 1 ra-prefix@lan2::/64 l_flag=on a_flag=on
ipv6 source address selection rule prefix
#
# LAN configuration
#
+ ipv6 lan1 address ra-prefix@lan2::1/64
+ ipv6 lan1 rtadv send 1 o_flag=on
+ ipv6 lan1 dhcp service server
+ description lan2 hogera
+ ipv6 lan2 dhcp service client ir=on
+ ngn type lan2 ntt
|
IPv6 IPoE対応機能 |
+ ipv6 lan2 secure filter in 101000 101001 101002 101003
+ ipv6 lan2 secure filter out 101099 dynamic 101080 101081 101082 101083 101084 101085 101098 101099
#
# IPv6 filter configuration
#
+ ipv6 filter 101000 pass * * icmp6 * *
~~
#
# IPv6 dynamic filter configuration
#
+ ipv6 filter dynamic 101080 * * ftp
~~
|
|
#
# LAN configuration
#
ipv6 lan1 rtadv send 1 o_flag=on rdnss=rdnss
#
# DNS configuration
#
+ dns host lan1
+ dns service fallback on
no dns server
+ dns server dhcp lan2
dns srcport 10000-10999
dns cache use on
dns cache max entry 256
+ dns server select 500000 dhcp lan2 any .
+ dns private address spoof on
dns notice order dhcp me server
dns notice order dhcpv6 me
dns notice order msext me server
|
|
57.30 IPv6 の動的フィルタによって管理されているコネクションの表示
> show ipv6 connection
LAN2[out]
INITIATOR Session Channel
---------------------------------------------------------------------
2001:db8:b0ba:10ee:59:59:01:41 4 4
2001:db8:b0ba:10ee:a2:a2:f00:f00 15 15
fe80::ae44:f2ff:fe12:3456 1 1
Session: 20 Channel: 20
ステートフルDHCPv6, ステートレスDHCPv6, SLAAC RDNSS 見出しにジャンプ
IPv6アドレス自動設定には、ステートフルDHCPv6, ステートレスDHCPv6, SLAACがある。
クライアントOSのIPv6実装検証から見たネットワーク運用における課題の考察 デジタルプラクティス
IPv6ホストのアドレス設定(ステートレス、ステートフル、DHCPv6)
IPv6アドレス自動設定にはマルチキャスト通信が多用される。スイッチはLANにいないMACアドレスを全てのポートにフラッディングするため、マルチキャストとして動作する。冗談みたいな話だが、これがスマートフォンなどの無線端末を頻繫に起こし、バッテリー持ちが悪くなってしまう。これを軽減するためのRFCがあるので、RTXのconfigに落とし込んでみた。
5. Best Practices for IPv6 Neighbor Discovery RFC 8273: Unique IPv6 Prefix per Host
30.3.1 ルーター広告で配布するプレフィックスの定義
30.3.3 ルーター広告の送信の制御
- ipv6 prefix 1 ra-prefix@lan2::/64 preferred_lifetime=1800 valid_lifetime=3600 a_flag=off
+ ipv6 prefix 1 ra-prefix@lan2::/64 preferred_lifetime=604800 valid_lifetime=2592000 a_flag=on
ipv6 prefix 2 fdca::/64 preferred_lifetime=1800 valid_lifetime=3600 a_flag=off
- ipv6 lan1 rtadv send 1 2 m_flag=on o_flag=off prf_flag=high max-rtr-adv-interval=686 min-rtr-adv-interval=514 adv-default-lifetime=3600 adv-reachable-time=30000 adv-retrans-time=0 mtu=1500 rdnss=2
+ ipv6 lan1 rtadv send 1 2 m_flag=off o_flag=on prf_flag=medium max-rtr-adv-interval=600 min-rtr-adv-interval=200 adv-default-lifetime=1800 adv-reachable-time=300000 adv-retrans-time=10000 mtu=1500 rdnss=2
しかし、実際にRAプロキシ環境でWiresharkでRouter Advertisementパケットをみると、RFC 8273以前の問題でipv6 prefix
やipv6 interface rtadv send
の多くが無視されていることが分かった。
ヤマハネットワークエンジニア会 | RAプロキシでipv6 interface rtadv sendの多くが変更できない
RAはWiresharkのキャプチャフィルタip6 host ff02::1
, 表示フィルタicmpv6.type == 134
で絞り込める
Internet Control Message Protocol v6
Type: Router Advertisement (134)
Code: 0
Checksum: 0x039f [correct]
[Checksum Status: Good]
Cur hop limit: 64
Flags: 0x40, Other configuration, Prf (Default Router Preference): Medium
+ 0... .... = Managed address configuration: Not set
+ .1.. .... = Other configuration: Set
..0. .... = Home Agent: Not set
+ ...0 0... = Prf (Default Router Preference): Medium (0)
.... .0.. = Proxy: Not set
.... ..0. = Reserved: 0
+ Router lifetime (s): 1800
+ Reachable time (ms): 300000
+ Retrans timer (ms): 10000
ICMPv6 Option (Source link-layer address : ac:44:f2:12:34:56)
ICMPv6 Option (MTU : 1500)
ICMPv6 Option (Prefix information : 2001:db8:b0ba:10ee::/64)
Type: Prefix information (3)
Length: 4 (32 bytes)
Prefix Length: 64
Flag: 0xc0, On-link flag(L), Autonomous address-configuration flag(A)
1... .... = On-link flag(L): Set
+ .1.. .... = Autonomous address-configuration flag(A): Set
..0. .... = Router address flag(R): Not set
...0 0000 = Reserved: 0
+ Valid Lifetime: 2592000
+ Preferred Lifetime: 604800
Reserved
Prefix: 2001:db8:b0ba:10ee::
ICMPv6 Option (Prefix information : fdca::/64)
Type: Prefix information (3)
Length: 4 (32 bytes)
Prefix Length: 64
Flag: 0x80, On-link flag(L)
1... .... = On-link flag(L): Set
+ .0.. .... = Autonomous address-configuration flag(A): Not set
..0. .... = Router address flag(R): Not set
...0 0000 = Reserved: 0
+ Valid Lifetime: 2592000
+ Preferred Lifetime: 604800
Reserved
Prefix: fdca::
ICMPv6 Option (Recursive DNS Server fdca::1)
DHCPv6-PD環境では状況が異なるかもしれないが、
IP 通信網から送信されるルータ広告メッセージにおける Managed address configuration、および Other configuration の値は「0」
IP通信網サービスのインタフェース -フレッツシリーズ- - ip-int-flets-1.pdf
IP 通信網は、RFC2461 に規定されている NDP(Neighbor Discovery Protocol)に基づき、ルータ広告(Router Advertisement)メッセージを端末機器に送信しますが、ルータ広告の Other stateful configuration 及び Managed address configuration flag が 1 に設定される場合があります。なお、IP 通信網は Information-Request には対応しておりません
gijyutsu_sankou_cross_next_light.pdf
少なくともRAプロキシ環境ではステートレス/ステートフルDHCPv6は不可能で、SLAACのみ可能だ。
A, M, O flagを誤った組み合わせで設定すると、アドレス設定に失敗して通信が途切れるため注意が必要だ。
RAによるアドレス情報配布
OpenStack Docs: IPv6
Stateful DHCPv6 | NetworkAcademy.io
RFC 4861 - Neighbor Discovery for IP version 6 (IPv6)
RFC 8273: Unique IPv6 Prefix per Host
ipv6 prefix 1 ra-prefix@lan2::/64
の代わりに2001:db8:b0ba:10ee::/64
とべた書きするとpreferred_lifetime
,valid_lifetime
が反映された。しかし半固定運用されてしまっている日本のIPv6ではあまり意味を持たない。- RAはMinRtrAdvInterval
min-rtr-adv-interval
からMaxRtrAdvIntervalmax-rtr-adv-interval
の範囲でランダムな間隔をとるが、デフォルトから変わらない範囲内だった。
RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - DHCPv6でRFC 4191ルータ優先度
prf_flag=high
は効かず、常にmediumなのは痛い。
IPv6セキュリティ概説-プロトコル編- - s3-kitaguchi.pdf - このほか、"omniboxで検索するとLANの他の端末にクエリ内容が丸見え"なことで悪名高いmDNS
224.0.0.251
ff01::fb
をはじめとするマルチキャスト通信には、それぞれ予約されたL2アドレス01:00:5e:00:00:fb
33:33:00:00:00:fb
が使われる。
IPv6 Multicast Address Space Registry
これをRTXのIGMP/MLD機能ipv6 lan1 mld static ff01::fb include
やL2フィルタethernet filter 353 reject-nolog *:*:*:*:*:* *:*:*:00:00:fb
で破棄することはできない。特定のマルチキャストを破棄したり、フラッディングを抑制して無線端末のバッテリーを持たせるには、別途IGMP/MLD snoopingに対応するマネージドL2スイッチが必要だ。
大規模IPv6無線LANにおける制御用マルチキャストパケットの観測と分析 情報学広場:情報処理学会電子図書館
30.8.2 MLD の静的な設定
9.2 インターフェースへの適用の設定
9.1 フィルター定義の設定
UNIVERGE IXのようにルータにIGMP snooping機能を持たせている場合もある。IGMPには対応しているがMLDは未対応。
IPマルチキャスト : FAQ : UNIVERGE IXシリーズ | NEC
WebGUIで追加されるconfig(既定値を明示) | 説明 |
---|---|
#
# IPv6 configuration
#
ipv6 prefix 1 ra-prefix@lan2::/64 l_flag=on a_flag=on
ipv6 prefix 2 fdca::/64 l_flag=on a_flag=off
ipv6 nd ra-rdnss 2 fdca::1 lifetime=infinity
#
# LAN configuration
#
ipv6 lan1 address ra-prefix@lan2::1/64
ipv6 lan1 address fdca::1/64
ipv6 lan1 rtadv send 1 2 m_flag=off o_flag=on rdnss=2
ipv6 lan1 dhcp service off
#
# DNS configuration
#
dns notice order dhcpv6 none
|
|
+ ipv6 prefix 1 ra-prefix@lan2::/64 a_flag=off
+ ipv6 prefix 2 fdca::/64 a_flag=off
ipv6 nd ra-rdnss 2 fdca::1 lifetime=infinity
ipv6 lan1 address ra-prefix@lan2::1/64
ipv6 lan1 address fdca::1/64
+ ipv6 lan1 rtadv send 1 2 m_flag=on o_flag=on rdnss=2
ipv6 lan1 dhcp service server
dns notice order dhcpv6 none
|
|
+ ipv6 prefix 1 ra-prefix@lan2::/64 a_flag=on
ipv6 lan1 address ra-prefix@lan2::1/64
+ ipv6 lan1 rtadv send 1 m_flag=off o_flag=on
ipv6 lan1 dhcp service server
dns notice order dhcpv6 me
|
|
IPv4 over IPv6 見出しにジャンプ
IPv6に対応していないサービスを利用するため、IPv4接続を併用する。これをIPv4/IPv6デュアルスタックという。
IPv4 over IPv6はIPv6 IPoE接続にISPとのトンネルを張って、IPv4インターネットを使えるようにする。
フレッツ系のISPで使われるIPv4アドレス共有技術には様々な種類があり、RTXの新しめの機種はその多くに対応しているが、全てに対応できるわけではない。
IPv6 IPoE + IPv4 over IPv6接続 対応機種 documents for Yamaha network products
IPv6(IPoE/IPv4 over IPv6)接続確認済みリスト|動作検証情報|サポートデスク|AtermStation
使いたいルータで終端できなければ二重ルータ(二重NAT)が必要になり、パフォーマンス低下や不安定化を招く。
IPv4 over IPv6のトンネル方式として代表的なMAP-EとDS-Liteがある。表にあるヤマハの設定例を見ればわかるように、DS-Lite動的IP契約にはNAPTの設定がない。IPv4 PPPoE同様にMAP-EはCPE側でNAPTするためポート開放(静的NAPT)が可能なのに対し、DS-LiteはISP側でNAPTするCGNATのため不可能だ。通常のインターネット利用では、昨今ただでさえIPv6のSPIやらWi-Fi 6やらで機能が詰め込まれがちなCPE側の負荷が減らせる利点でもある。
IPv4 over IPv6動的IP契約では、IPアドレスが動的(半固定)であること、IPv4アドレスを他の契約者と共有するため利用可能ポートが制限されている点にも注意が必要だ。
動的IPはIPv4 PPPoE同様にDDNSすれば済むが、使えないポートがあるとリモートアクセスVPN然り、ゲームサーバ然り、使用するポート番号が定められているサービスを建てられない。
IPv4 over IPv6のポート開放や利用可能ポートの問題を解消する方法に、IPv4 PPPoEを併用したマルチセッションがある。巷のCPEなら複数台必要なところ、RTX1台で複数のトンネルやPPPoEセッションおよびルーティングが可能だ。IPv4 over IPv6有効化とともにPPPoEセッションが潰される狭量な(寧ろマルチセッションが許されている方が寛容、感謝しかない)ISPでは、余ったフレッツのPPPoEセッション上限で別のISPに浮気するか、グローバルIPを持つクラウドサーバにリバースプロキシをこしらえてリッスンするほかない。
DS-Lite(transix)のIPoE(IPv4 over IPv6)だとエルデンリングでポート開放できないからPPPoE接続を併用する
VNE | トンネル方式 | CPE側でNAPT (=ポート開放) |
利用可能ポート数[要出典] | RTXで終端 | PPPoEとマルチセッション[要出典] |
---|---|---|---|---|---|
MFEED transix 工事・障害情報 transix 接続設定例 - RTpro IPIPトンネリング せっかくのIPoE化もDS-liteの制限で台無しだったので、代替策を考えた|しょっさん|note |
DS-Lite | X | 1024 12800のISPあり |
O | ※PPPoEが別料金のISPあり |
AsahiNet v6コネクト v6 コネクト接続設定例 - RTpro IPv4 over IPv6(DS-Lite)V6コネクト徹底解剖.最大TCPセッション数測定 - YouTube |
DS-Lite | X | 4000程度 | O | O |
UCOM光 アルテリア・ネットワークス株式会社 | 障害情報 クロスパス ( Xpass ) 接続設定例 - RTpro |
DS-Lite | X | O | ※クロスパス方式で併用可能なISPあり | |
JPNE v6プラス サポート情報 | 日本ネットワークイネイブラー株式会社 v6プラス対応機能- RTpro |
MAP-E | O | 240 | O | ※PPPoEと併用できないISPあり |
NTTCom OCNバーチャルコネクト OCN バーチャルコネクトサービスの工事・故障情報一覧 | NTT Com お客さまサポート OCNバーチャルコネクト対応機能- RTpro |
MAP-E | O | 1008 | O | O |
BIGLOBE IPv6オプション IPv6オプション:BIGLOBE会員サポート |
MAP-E |
O |
X |
- | |
BBIX IPv6高速ハイブリッド 障害・メンテナンス情報 | インターネット・固定電話 | ソフトバンク BBIX の IPv4 over IPv6 技術は 4rd/SAM ではありません |
IPIP | X | X | - |
Web GUIで追加されるOCNバのconfig | 説明 |
---|---|
#
# IP configuration
#
+ ip route default gateway tunnel 1
|
IPv4 over IPv6のトンネルインターフェースを、静的経路やimplicit経路がないときのデフォルトゲートウェイに設定する。BGPでもやっていない限り、RTXをNAPT箱として使っている限りはインターネットにある殆どのホストはこのデフォルト経路を通ることになる。 |
#
# LAN configuration
#
+ ip lan1 address 192.168.100.1/24
|
一般的に家庭用CPEで使われるルータ自身およびデフォルトゲートウェイのIPアドレスは |
#
# TUNNEL configuration
#
+ no tunnel enable all
### TUNNEL 1 ###
+ tunnel select 1
+ tunnel encapsulation map-e
+ tunnel map-e type ocn
+ ip tunnel mtu 1460
+ ip tunnel secure filter in 400003 ...
+ ip tunnel secure filter out 400013 ...
+ ip tunnel nat descriptor 20000
+ tunnel enable 1
#
# IP filter configuration
#
+ ip filter 400000 reject 10.0.0.0/8 * * * *
~~
#
# IP dynamic filter configuration
#
+ ip filter dynamic 400080 * * ftp
~~
|
|
#
# NAT Descriptor configuration
#
+ nat descriptor type 20000 masquerade
nat descriptor address inner auto
+ nat descriptor address outer 20000 map-e
nat descriptor timer 20000 900
|
57.14 動的 NAT ディスクリプタのアドレスマップの表示
既定の
|
# # DHCP configuration # dhcp service server dhcp server rfc2131 compliant except remain-silent dhcp scope 1 192.168.100.2-192.168.100.191/24 |
LAN1の端末には |
# # DNS configuration # |
IPv4 over IPv6で追加のDNS設定はなく、IPv6 IPoEのDNSサーバが使われる。 |
IPv4 PPPoE 見出しにジャンプ
マルチセッション 見出しにジャンプ
IPv4 over IPv6とPPPoEでマルチセッションの設定をし、静的経路を設定してマルチホーミングを行うことで、IPv4 over IPv6特有の問題に対処したり、ロードバランスで帯域を有効活用できる。
同時接続する場合の設定ヒント/アイディア RTシリーズのPPPoEに関するFAQ
マルチホーミング
config | 説明 |
---|---|
#
# IP configuration
#
- ip route default gateway tunnel 1
- ip route default gateway tunnel 1 filter 500000 gateway pp 1
+ ip route default gateway tunnel 1 hide gateway pp 1 weight 0
#
# IP filter configuration
#
ip filter 500000 restrict * * * * *
|
8.1.7 IP の静的経路情報の設定
|
#
# LAN configuration
#
ip lan1 address 192.168.100.1/24
#
# PP configuration
#
pp disable all
### PP 1 ###
+ pp select 1
+ description pp softether
+ pp keepalive interval 30 retry-interval=30 count=12
+ pp always-on on
+ pppoe use lan2
+ pppoe auto disconnect off
+ pp auth accept pap chap
+ pp auth myname [email protected] open
+ ppp lcp mru on 1454
ppp lcp pfc off
ppp lcp acfc off
ppp ipcp vjc off
+ ppp ipcp ipaddress on
+ ppp ipcp msext on
+ ppp ccp type none
+ ip pp secure filter in 200003 200020 200021 200022 200023 200024 200025 200030 200032
+ ip pp secure filter out 200013 200020 200021 200022 200023 200024 200025 200026 200027 200099 dynamic 200080 200081 200082 200083 200084 200085 200098 200099
+ ip pp nat descriptor 1000
+ pp enable 1
#
# IP filter configuration
#
+ ip filter 200000 reject 10.0.0.0/8 * * * *
~~
ip filter 400000 reject 10.0.0.0/8 * * * *
~~
#
# IP dynamic filter configuration
#
+ ip filter dynamic 200080 * * ftp
~~
ip filter dynamic 400080 * * ftp
~~
|
|
#
# NAT Descriptor configuration
#
+ nat descriptor type 1000 masquerade
nat descriptor address inner 1000 auto
nat descriptor address outer 1000 ipcp
nat descriptor timer 1000 900
nat descriptor type 20000 masquerade
nat descriptor address inner 20000 auto
nat descriptor address outer 20000 map-e
nat descriptor timer 20000 900
|
NAPTタイマも修正する |
#
# DNS configuration
#
dns host lan1
dns service fallback on
+ dns server pp 1
dns server dhcp lan2
dns server select 500000 dhcp lan2 any .
+ dns server select 500001 pp 1 any . restrict pp 1
dns private address spoof on
|
Web GUIで追加するとDNSリカーシブサーバのDNSサーバ選択はこのようになるが、これではあまり意味がないので修正する。 |
プッシュ通知はPPPoEで 見出しにジャンプ
プッシュ通知が正しく受け取れるようにNAPTタイマ, SPIのタイマを設定したにも拘らず、あるいはNAPTタイマを変更できないDS-Lite動的IP契約で、プッシュ通知が遅れたり届かなかったりする場合、SPIだけ気にすればよいIPv4/IPv6デュアルスタックが望ましい。しかし、現実問題IPv6 LANが1つしかつくれない設計が残っており、「IPv4シングルスタックVLAN」+ 「タイマの怪しいCGNAT」の組み合わせもあり得る。
そこで、IPv4 PPPoEとマルチセッションし、プッシュ通知の通信をルーティングすることで、 推しの配信通知をリアルタイムに受け取れるようにする。
#
# IP configuration
#
- ip route default gateway tunnel 1
- ip route default gateway tunnel 1 filter 500000 gateway pp 1
- ip route default gateway tunnel 1 hide gateway pp 1 weight 0
+ ip route default gateway pp 1 filter 45223 45228 hide gateway tunnel 1 hide gateway pp 1 weight 0
#
# IP filter configuration
#
+ ip filter 45223 pass * 17.0.0.0/8 tcp * 2197,5223
+ ip filter 45228 pass 192.168.100.0/22 device-provisioning.googleapis.com,firebaseinstallations.googleapis.com,mtalk.google.com tcp * https,5228-5230
注意が必要なのは、FQDNフィルター機能を静的経路に使うとき、送信元アドレスがAny*
, 0.0.0.0/0
だとノーマルパスのレイテンシが大幅に増えることだ。スピードテストのレイテンシやジッタには表れないが、pingコマンドの最初のパケットは回線難民のように遅延する。これは実際のWebブラウジング体験を大きく損なうことに繋がる。192.168.100.0/24
など、LAN1の範囲に限定するとよい。
RTXのip route default gateway、別に長くても何ともないがFQDNフィルタを使った場合だけRTTが倍になることが分かった。にゃーん
— しばにゃん (@shibanyan_1) August 18, 2022
FCMメッセージについて | Firebase Cloud Messaging
Apple ソフトウェア製品で使われている TCP および UDP ポート - Apple サポート (日本)
Apple 製のデバイスで Apple プッシュ通知が届かない場合 - Apple サポート (日本)
8.1.7 IP の静的経路情報の設定
FQDN フィルター機能
ロードバランス 見出しにジャンプ
これまではPPPoEとのマルチセッションを主に冗長化や、特定の通信のみ逃がすのに使ってきた。
しかしマルチホーミングには冗長化以外にも、複数のIPv4 PPPoEおよびIPv4 over IPv6セッションを利用してロードバランスする使い道がある。
8.1.7 IP の静的経路情報の設定
フィルタ型ルーティング
私がインターネットで利用できるポート数は、IPv4 over IPv6の1024ポート, PPPoE x2の13,1070ポート, IPv6 IPoEの2^64ポート合わせて計18,446,744,073,709,683,710ポートだ。
1ページ当たりのTCPコネクション数が異常でNAPT性能のベンチマークになると有名な通称"ニチバンベンチ"も、マルチセッションにより豊富なポート数があれば怖くない。
製品ブランド|ニチバン株式会社:製品情報サイト
※IPv4 over IPv6の方, NAPT性能の低いCPEをお使いの方, 不正アクセスとされてしまいそうな自治体にお住まいの方はF5注意
大人の事情がなければ、理論上IPv4 PPPoEの方がIPv4 over IPv6より高速なのだが、実際は輻輳している場合が多くロードバランスすると足を引っ張ってしまう。日本のインターネット事情では、NTEガチャも必須要件だろう。これにより物理回線のスループットを最大限生かし切ることができる。
#
# IP configuration
#
- ip route default gateway tunnel 1
- ip route default gateway tunnel 1 filter 500000 gateway pp 1
- ip route default gateway tunnel 1 hide gateway pp 1 weight 0
- ip route default gateway pp 1 filter 45223 45228 hide gateway tunnel 1 hide gateway pp 1 weight 0
+ ip route default gateway pp 1 filter 42556 42719 45223 45228 hide gateway tunnel 1 hide gateway pp 1 hide
#
# IP filter configuration
#
+ ip filter 42556 pass 192.168.100.0/22 * tcp * 25565
+ ip filter 42719 pass 192.168.100.0/22 sessionserver.mojang.com,id.heroku.com,cli-auth.heroku.com,verify.salesforce.com tcp * https
- 例えば、Minecraft(42556, 42719番)とHeroku Salesforce(42719番)のログインがロードバランスされるとサービスが利用できなくなる。
[MC-253237] "Failed to verify username" error prevents playing on some servers and LAN - Jira
同じ宛先IPアドレスなら同じ経路を使うので、IP検証するサービスでない限り影響はない。 - 宛先IPアドレスをFQDNで指定するなら、送信元アドレスの指定も忘れずに。
FQDN フィルター機能
Luaで自動NNI/NTEガチャ 見出しにジャンプ
大人の事情で輻輳しがちなPPPoEセッションの中に、当たり外れがあるのはご存知だろうか。
StarlinkのRTTを上回ることもままあるフレッツのPPPoEは、更に遠い月に電話局があるのかというとそういう訳ではない。NNI/NTEの収容数がキャパを超えていても、その形態から設備増強がしづらく、需要時に輻輳しRTTおよび回線速度低下を招いている。ベストエフォートとはいえ、需要家として、パケロスを加速させて迷惑をかけたくない。
実は収容毎に混雑具合にばらつきがあるため、接続・切断を繰り返すことで接続先が変わり、快適なPPPoEセッションを得られる場合がある。これを俗に「NTEガチャ」と呼ぶらしい。
NTEガチャの流れ
- pp1を切断する。
pp always-on on
の間隔で再接続されないよう、使用不許可にする。
55.6.2 相手先の使用不許可の設定
55.6.7 切断
6.2.1 常時接続の設定
57.3 各相手先の状態の表示
pp disable 1
disconnect pp 1
show status pp 1
- 既存の通信が迷子になるので、フローテーブルを消去する。
マルチホーム環境では別のPPPoEセッションやIPv4 over IPv6にフォールバックするので、インターネット接続が維持される。
55.4.14 NAT アドレステーブルのクリア
55.4.7 IP の動的経路情報のクリア
clear nat descriptor dynamic 1000
clear ip dynamic routing
- 20-30分程度待つ。
- pp1を接続する。
pp always-on on
の間隔(デフォルト1分)待たずに再接続するなら、
55.6.1 相手先の使用許可の設定
55.6.6 発信
pp enable 1
connect pp 1
show status pp 1
- 結果が良ければNTEガチャ終了。結果が悪ければ1.に戻る。
これらを電源喪失やケーブル差し替えの度に手動で行うのは骨が折れるため、NTEガチャをLuaスクリプトで自動化した。
rtxconfig/nte-gacha.lua at main · nyanshiba/rtxconfig
-- 該当したら切断するハズレNNI/NTEブラックリスト (show status pp NUM の PP IP Address Remote)
ntetbl = {
nil,
'198.51.100.74',
'198.51.100.69',
'198.51.100.102',
'203.0.113.71',
'203.0.113.72',
'203.0.113.73'
}
ブラックリストを速度の遅いPPPoEセッションのshow status pp NUM
のPP IP Address Remoteアドレスに置き換える。LocalはグローバルIPアドレスが付与されている。
> show status pp 1
PP[01]:
~~
PP IP Address Local: 192.0.2.37, Remote: 203.0.113.71
CCP: None
syslogなら PPP/IPCP up
で探せる。
83162: 2038/01/18 17:03:33: PP[02] PPP/IPCP up (Local: 192.0.2.32, Remote: 203.0.113.71)
83426: 2038/01/18 17:23:34: PP[02] PPP/IPCP up (Local: 100.64.243.21, Remote: 198.51.100.74)
92424: 2038/01/19 12:08:09: PP[01] PPP/IPCP up (Local: 100.64.32.156, Remote: 198.51.100.74)
92495: 2038/01/19 12:14:08: PP[01] PPP/IPCP up (Local: 192.0.2.230, Remote: 203.0.113.71)
92529: 2038/01/19 12:43:33: PP[01] PPP/IPCP up (Local: 100.64.58.252, Remote: 198.51.100.102)
92576: 2038/01/19 12:47:02: PP[01] PPP/IPCP up (Local: 192.0.2.157, Remote: 203.0.113.73)
UnnumberedRemote: None
をブラックリストに入れるには、nil
を追記する
「numbered」と「unnumbered」は、どう違うのですか? FAQ for YAMAHA RT Series / PPP
PPPoEセッション数が2でない場合は、書き換えが必要だ
-- PPPoEセッションが5つあることを想定している(セッションプラスの最大)
for i = 1, 5 do
if not(get_pp_status(i)) then
peer_num = i
break
end
end
-- 5つのPPPoEセッションが継っている場合、ランダムにガチャする
if not(peer_num) then
math.randomseed(os.time())
peer_num = math.random(5)
end
リポジトリ同梱のput-lua.shを使用して、LuaスクリプトをRTXの外部メモリに保存し、schedule at
コマンドを使用して定期的に実行するとよい。
37.1 スケジュールの設定
レート制限はISPによるが、当環境では20分間隔未満では途中で失敗PPPoEセッションは継っていません
するようだ。
schedule at 4 */* *:6,26,46:26 * lua nte-gacha.lua
切断して再ガチャを促すLuaスクリプトもある。
「ガチャ」というだけあって、そこそこスピードテスト結果がよいセッションを引いたとき、本当に最適なサーバか分からないためだ。
繋がっているPPPoEセッションのRTTの90パーセンタイル値を比較し、悪い方を落とす。
syslogで当たりのNTEを引きやすかった曜日・時間帯を確認し、schedule at
に設定するとよい。
rtxconfig/nte-regacha.lua at main · nyanshiba/rtxconfig
比較のために、ip route
でそれぞれのPPPoEセッションにstatic routeされている必要がある。
CloudflareのPublic DNSを指しているが、あくまでインターネット区間のRTTを計測する例示であり比較になるとは思わない。
-- 2つのPPPoEセッションを比較して、RTTが悪い方を落としてnte-gacha.luaによる再ガチャを促す
-- それぞれのPPPoEセッションを使うようにstatic routeされている前提
if measure_rtt('1.1.1.1') > measure_rtt('1.1.1.2') then
pp_disconnect(1)
else
pp_disconnect(2)
end
サービス情報サイト 見出しにジャンプ
デフォルトでフレッツのPPPoEセッション上限は2で、1つインターネット接続に利用しても1セッションの枠が余る。
サービス内容|フレッツ・セッションプラス|法人のお客さま|NTT東日本
これはPPPoEマルチセッションやサービス情報サイト(NGN IPv4)に接続するためのものだ。
サービス情報サイト(IPv4 / NTT東日本)への接続 : コマンド設定
#
# PP configuration
#
### PP 4 ###
pp select 4
description pp v4flets-east
pp auth myname [email protected] guest
#
# DNS configuration
#
dns server select 100002 pp 2 any .v4flets-east.jp
PADIタイムアウト 見出しにジャンプ
PPPOE[XX] Disconnected, cause [PPPoE: PADI Timeout]
ログ(syslog)にこんなメッセージが出て来たけど、何これ? FAQ for YAMAHA RT Series / Syslog
FAQ for YAMAHA RT Series / 障害切り分け手順
DHCP 見出しにジャンプ
グローバルIPv6アドレスをステートレスDHCPv6で自動割り当てしているように、プライベートIPv4アドレスも同様にDHCPで自動割り当てしたい。
サーバになる端末のMACアドレスに対するプライベートIPアドレスの固定は、本来端末側で行うべきだが、RTXが同一セグメントに複数のDHCPスコープを定義できることを利用して、比較的確実に集中管理できる。
config | 説明 |
---|---|
#
# DHCP configuration
#
dhcp service server
|
DHCPサーバ機能を有効にし、RTXがプライベートIPv4アドレスを配布する。DHCPクライアントはブリッジや二重NAT環境、プライベートネットワーク内に別のDHCPサーバがある場合に使う。 |
#
# LAN configuration
#
ip lan1 address 192.168.100.1/24
#
# DHCP configuration
#
- dhcp server rfc2131 compliant except remain-silent
+ dhcp server rfc2131 compliant on
- dhcp scope 1 192.168.100.2-192.168.100.191/24
+ dhcp scope 1 192.168.100.64-192.168.100.127/24 gateway 192.168.100.1
|
DHCPで払い出すアドレス範囲を決める。
|
+ dhcp scope lease type 11 bind-only
+ dhcp scope 11 192.168.100.2-192.168.100.63/24 gateway 192.168.100.1
+ dhcp scope bind 11 192.168.100.2 01 00 00 5e 00 53 00
+ dhcp scope bind 11 192.168.100.21 01 00 00 5e 00 53 f1
+ dhcp scope bind 11 192.168.100.22 01 00 00 5e 00 53 f2
|
プライベートIPアドレスをDHCPで固定する。
ipcalc 192.168.100.0/26 Network: 192.168.100.0/26 Netmask: 255.255.255.192 = 26 Broadcast: 192.168.100.63 ipcalc 192.168.100.64/26 Network: 192.168.100.64/26 Netmask: 255.255.255.192 = 26 Broadcast: 192.168.100.127 ipcalc 192.168.100.0/25 Network: 192.168.100.0/25 Netmask: 255.255.255.128 = 25 Broadcast: 192.168.100.127 12.1.4 DHCP スコープの定義
Ethernet Numbers
端末毎にリースの更新が必要だ。
|
dhcp scope option 1 subnet_mask=255.255.255.0 router=192.168.100.1 domain=. interface_mtu=1500 ntp_server=192.168.100.1 vendor_specific=01,04,00,00,00,02,02,04,00,00,00,01 tz_string=4a,53,54,2d,39 tz_database=41,73,69,61,2f,54,6f,6b,79,6f domain_search_list=2e
dhcp scope option 11 subnet_mask=255.255.255.0 router=192.168.100.1 dns=192.168.100.1 domain=. interface_mtu=1500 ntp_server=192.168.100.1 vendor_specific=01,04,00,00,00,02,02,04,00,00,00,01 tz_string=4a,53,54,2d,39 tz_database=41,73,69,61,2f,54,6f,6b,79,6f domain_search_list=2e
|
DHCPオプションでサブネットマスクやDNSサーバ、NTPサーバ等を併せて自動設定させる。内容はスコープ毎に変えられる。
"JST-9" | Format-Hex
Label: String (System.String) <56261791>
Offset Bytes Ascii
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
------ ----------------------------------------------- -----
0000000000000000 4A 53 54 2D 39 JST-9
"Asia/Tokyo" | Format-Hex
Label: String (System.String) <707D4ABA>
Offset Bytes Ascii
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
------ ----------------------------------------------- -----
0000000000000000 41 73 69 61 2F 54 6F 6B 79 6F Asia/Tokyo
DHCPオプション FAQ for YAMAHA RT Series / TCP/IP |
#
# Ethernet Filter configuration
#
no ethernet filter 1 pass-nolog dhcp-bind 1
no ethernet filter 11 pass-nolog dhcp-bind 11
#
# LAN configuration
#
no ethernet lan1 filter in 1 11
#
# Schedule configuration
#
schedule at 99 +60 * no ethernet lan1 filter in
|
IPアドレスは端末側で自由に設定できてしまう。 |
Wake On LAN 見出しにジャンプ
RT自身が直結しているLANインタフェース以外にMagic Packetを送信することはできない
Wake On LAN
> show arp
カウント数: 7
インタフェース IPアドレス MACアドレス TTL(秒)
LAN1(port1) 192.168.100.2 00:00:5e:00:53:00 383
LAN1(port4) 192.168.100.21 00:00:5e:00:53:f1 897
LAN1 192.168.100.22 00:00:5e:00:53:f2 393
wol send lan1 00:00:5e:00:53:00 192.168.100.2
遠隔地からのWOLはディレクテッドブロードキャスト192.168.100.255
を使うが、これはデフォルトで破棄される。
NTP 見出しにジャンプ
RTXはSNTPサーバ・クライアントに対応しており、インターネットやNGNのNTPサーバで時刻合わせを行い、LANからの時刻問い合わせに応答できる。
ntpsec-ntpdateでNTPのベンチマーク 見出しにジャンプ
NTPの性質上、RTTが変動したり(jitterが大きい)、非対称ルーティングで行きと帰りのRTTが大きく異なる環境では正確な時刻合わせが難しい。そのため、NAPTが挟まったりRTTが変動しがちなIPv4 PPPoEよりも、IPv6 IPoEで問い合わせた方がよさそうだ。
ntp.nict.jp
はStratum 1で、尚且つIPv4/IPv6デュアルスタックだ。
NICT 公開 NTP サービス
IPv6 IPoE環境では、DHCPv6のオプションでNGNのSNTPサーバアドレスが通知される。プライマリとセカンダリ2つが通知されているが、3つめがあるという噂もある。
フレッツNGN環境・・・IPv6環境でのNTPサーバー:こっそりと。 - livedoor Blog
RFC 4075 - Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6
> show status ipv6 dhcp
DHCPv6 status
LAN1 [server]
state: reply
LAN2 [client]
state: established
server:
~~
SNTP server[1]: 2404:1a8:1102::b
SNTP server[2]: 2404:1a8:1102::a
57.27 DHCPv6 の状態の表示
本当にSNTP server[1]
が最速なのか、はたまたStratum 1のNICTを使うべきなのか。
ntpdig ntp.nict.jp
2036-02-07 06:28:15.640370 (+0900) +0.003544 +/- 0.016075 ntp.nict.jp 2001:ce8:78::2 s1 no-leap
ntpdig 2404:1a8:1102::b
2036-02-07 06:28:16.848818 (+0900) +0.000432 +/- 0.005337 2404:1a8:1102::b s2 no-leap
NGNのSNTPサーバはpingに応答しないので、ntpdで実際にクエリを送ってベンチマークした。
/etc/ntp.conf
にNTPサーバを列挙
ベンチマーク用途なら構わないが、実際にntp.confを設定する際にはBCP223とLeap Smearing(time.google.com
,time.aws.com
が採用)を混ぜるべきでない。
DeepL翻訳: GoogleのNTPサーバーは、数秒単位で正確な時間が必要なだけなら、優れたサーバーです。しかし、それ以上に正確にUTCを追いかけたいのであれば、使うべきではありません。
Best Practices for Connecting to NTP Servers | RIPE Labs
RFC 8633: Network Time Protocol Best Current Practices
うるうさび | Public NTP | Google Developers
Amazon Time Sync is now available over the internet as a public NTP service
# For more information about this file, see the ntp.conf(5) man page.
# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (https://www.pool.ntp.org/join.html).
#pool 2.fedora.pool.ntp.org iburst
server 2404:1a8:1102::b iburst
server 2404:1a8:1102::a iburst
server 2404:1a8:1102::c iburst
server ntp.nict.jp iburst
# Reduce the maximum number of servers used from the pool.
- crondで継続的に
ntpq -peers
を実行し
7-47/20 * * * * /usr/sbin/ntpq --peers --width 1000 >> ~/ntpq-peers.log
remote refid st t when poll reach delay offset jitter
=======================================================================================================
*2404:1a8:1102::a 133.243.236.19 2 u 424 1024 377 12.1162 0.1173 0.2105
+2404:1a8:1102::b 133.243.236.18 2 u 251 1024 377 12.3800 -0.3326 0.2219
+2404:1a8:1102::c 133.243.236.19 2 u 262 1024 377 12.5095 0.0779 0.3047
-2001:ce8:78::2 .NICT. 1 u 892 1024 377 31.1017 1.2856 2.6171
...
./ntpq-summary.ps1
delay sort by [remote, StandardDeviation, Sum, Average, Maximum, Minimum]: StandardDeviation
remote Count Average Sum Maximum Minimum StandardDeviation Property
------ ----- ------- --- ------- ------- ----------------- --------
2404:1a8:1102::b 726 12.5691947658402 9125.23540000002 12.8409 1.3587 0.428803495900749 delay
2404:1a8:1102::a 726 12.5219961432507 9090.96920000001 12.8328 0.0697 0.495338872189885 delay
2404:1a8:1102::c 726 12.4926334710743 9069.65189999996 12.8337 0 0.683078749331647 delay
2001:ce8:78::2 725 33.0027975172412 23927.0281999999 37.9781 3.0622 2.25944840116679 delay
jitter sort by [remote, StandardDeviation, Sum, Average, Maximum, Minimum]: Average
remote Count Average Sum Maximum Minimum StandardDeviation Property
------ ----- ------- --- ------- ------- ----------------- --------
2404:1a8:1102::b 726 0.401240909090909 291.3009 2.2845 0.0468 0.424318160354816 jitter
2404:1a8:1102::c 726 0.746102892561983 541.6707 2.2262 0.1325 0.676005521303636 jitter
2001:ce8:78::2 725 1.1334484137931 821.750099999998 2.6171 1.0387 0.417041735147126 jitter
2404:1a8:1102::a 726 1.78392465564739 1295.1293 7.3903 0.1239 2.71238156302911 jitter
遅延delay
が大きければ必ずしも時刻合わせに支障をきたすRTT変動jitter
が大きいとは限らず、NGN網内の代替SNTPサーバSNTP server[2]
はjitterが大きいようだった。ただ、インターネット上にあるStratum 1のNICTntp.nict.jp
も決してよいとはいえず、素直に下流であるStratum 2のNGNの優先SNTPサーバSNTP server[2]
を使うべきと判明した。
# ntpdate 2404:1a8:1102::b
定期的にNTPで時刻合わせ 見出しにジャンプ
毎日12時34分56秒にntpdate
を実行する例。ISPの資料やLuaでのRTT監視によると、混雑していない未明の中途半端な時刻に実行するとよいだろう。
DNSの可視化検討 JANOG49 Meeting
37.1 スケジュールの設定
schedule at 1 */* 12:34:56 * ntpdate 2404:1a8:1102::b syslog
NTPの時刻合わせの精度を向上させるLuaスクリプト 見出しにジャンプ
そもそもRTXのSNTPサーバは秒単位でしか調整しないため、精度に難がある。
IPv6 IPoEではDHCPv6のオプションでSNTPサーバ通知されるため、対応しているLinuxのntpdなら直接ミリ秒単位で時刻合わせするが、その他OSやIPv4シングルスタックなVLANでNGNのSNTPサーバを利用するにはRTXに頼ることになる。
# ntpdate 2404:1a8:1102::b
2022/06/05 18:18:16 +0second
そこで、SNTPの問い合わせを連続して行い(丁度ntpdのiburstと似てる)、+0second
が連続したら終了するLuaスクリプトを書いてみた。
-- DHCPv6で降ってきたNGNのNTPサーバリストを取得
function get_dhcpv6_ntp()
local rtn, str = rt.command('show status ipv6 dhcp')
return {string.match(str, /SNTP\sserver\[\d\]:\s([\w:]+)\s+/g)}
end
ntptbl = get_dhcpv6_ntp()
-- table.insert(ntptbl, '2404:1a8:1102::c')
-- 複数のNTPサーバで時刻合わせする関数
function accur_ntpdate(tbl)
local result = {}
for i, v in ipairs(tbl) do
-- 時刻合わせの直前にsleepを噛ますとよいかも?
rt.sleep(1)
local rtn, str = rt.command($'ntpdate ${v}')
table.insert(result, string.match(str, '([+-]%d)second'))
end
return table.concat(result)
end
-- 2つのNTPサーバとの時刻合わせ結果が+0になるまで合わせなおす
while (timediff ~= '+0+0') do
timediff = accur_ntpdate(ntptbl)
print(timediff)
end
rtxconfig/accurate-ntp.lua at main · nyanshiba/rtxconfig
RTXをSNTPサーバにする 見出しにジャンプ
#
# DHCP configuration
#
+ dhcp scope option 1 ntp_server=192.168.100.1
#
# SNTPD configuration
#
+ sntpd service on
sntpd host lan1
SNTPサーバー機能
15.1.8 DHCP オプションの設定
FAQ for YAMAHA RT Series / TCP/IP DHCPオプション
RTX810をSNTPサーバにする(+DHCPでオプション配布) - Humanity
DHCPオプションでRTX本機192.168.100.1
で稼働するSNTPサーバを通知すれば、WindowsやApple iOSが使ってくれる……とは限らないようだ。
Windows、ローカルNTPがあるにも拘わらず頑なにtime\.windows\.comで時刻を合わせようとして失敗したら時計ズレたままなの草
— しばにゃん (@shibanyan_1) April 23, 2022
実際は各OS思い思いにtime.windows.com
, time.google.com
, time.apple.com
に問い合わせる。しかもWindowsに限っては、123/udp
がパケットフィルタで破棄されると時刻合わせに失敗したままになる目も当てられない仕様だ。
静的DNSレコードを使うとRTXに問い合わせを捻じ曲げられる。
dns static a time.apple.com 192.168.100.1 ttl=3600
dns static aaaa time.apple.com fdca::1 ttl=3600
dns static a time-ios.apple.com 192.168.100.1 ttl=3600
dns static aaaa time-ios.apple.com fdca::1 ttl=3600
dns static a time-macos.apple.com 192.168.100.1 ttl=3600
dns static aaaa time-macos.apple.com fdca::1 ttl=3600
dns static a time.google.com 192.168.100.1 ttl=3600
dns static aaaa time.google.com fdca::1 ttl=3600
dns static a time1.google.com 192.168.100.1 ttl=60
dns static aaaa time1.google.com fdca::1 ttl=60
dns static a time2.google.com 192.168.100.1 ttl=60
dns static aaaa time2.google.com fdca::1 ttl=60
dns static a time3.google.com 192.168.100.1 ttl=60
dns static aaaa time3.google.com fdca::1 ttl=60
dns static a time4.google.com 192.168.100.1 ttl=60
dns static aaaa time4.google.com fdca::1 ttl=60
dns static a time.windows.com 192.168.100.1 ttl=3600
WindowsでRTXのSNTPを利用する 見出しにジャンプ
設定 -> 時刻と言語を確認してtime.windows.com
が設定されているときは、w32tm
にRTXのSNTPを手動で設定するとよい。
- W32Timeサービスを有効化
# サービスを起動し、スタートアップ時に実行するよう設定する
Set-Service -Name W32Time -StartupType Automatic -Status Running
# 確認
Get-Service -Name W32Time | Select-Object DisplayName,Name,StartType,Status
DisplayName Name StartType Status
----------- ---- --------- ------
Windows Time W32Time Automatic Running
- w32tmでSNTPサーバを設定
w32tm /query /status
閏インジケーター: 3 (同期未実行)
階層: 0 (未指定)
精度: -23 (ティックごとに 119.209ns)
ルート遅延: 0.0000000s
ルート分散: 0.0000000s
参照 ID: 0x00000000 (未指定)
最終正常同期時刻: 未指定
ソース: Local CMOS Clock
ポーリング間隔: 10 (1024s)
w32tm /config /manualpeerlist:192.168.100.1 /syncfromflags:manual /update
コマンドは正しく完了しました。
w32tm /resync
再同期コマンドをローカル コンピューターに送信しています
コマンドは正しく完了しました。
w32tm /query /status
閏インジケーター: 0 (警告なし)
階層: 2 (二次参照 - (S)NTP で同期)
精度: -23 (ティックごとに 119.209ns)
ルート遅延: 0.0004251s
ルート分散: 8.3588899s
参照 ID: 0xC0A86401 (ソース IP: 192.168.100.1)
最終正常同期時刻: 2021/04/24 8:32:59
ソース: 192.168.100.1
ポーリング間隔: 10 (1024s)
- 帳尻合わせの様子を確認
w32tm /stripchart /computer:192.168.100.1 /period:60
192.168.100.1 [192.168.100.1:123] を追跡中。
現在の時刻は 2021/04/24 8:33:18 です。
08:33:18, d:+00.0002926s o:+00.5909824s [ | * ]
w32tm /monitor /computers:ntp.nict.jp
ntp.nict.jp[133.243.238.243:123]:
ICMP: 28ms 遅延
NTP: +0.4193414s ローカル コンピューターの時刻からのオフセット
RefID: 'NICT' [0x5443494E]
階層: 1
警告:
逆名前解決が最適な方法です。タイム パケット内の
RefID フィールドは NTP 実装間で異なっており、IP
アドレスを使用していない場合があるため、名前が正しくない可能性があります。
w32tm /stripchart /computer:ntp.nict.jp /period:60
ntp.nict.jp [XXX.XXX.XXX.XXX:XXX] を追跡中。
現在の時刻は 2020/08/21 20:23:24 です。
20:23:24, d:+00.0227694s o:+00.4145991s [ |* ]
20:24:24, d:+00.0224138s o:+00.4136462s [ |* ]
20:25:24, d:+00.0220661s o:+00.4127709s [ |* ]
20:26:24, d:+00.0225493s o:+00.4122641s [ |* ]
20:27:25, d:+00.0213942s o:+00.4107398s [ |* ]
~~
21:39:26, d:+00.0239230s o:+00.3665131s [ |* ]
21:40:26, d:+00.0226257s o:+00.3653180s [ |* ]
21:41:26, d:+00.0215479s o:+00.3643673s [ |* ]
Windows タイム サービスのツールと設定 | Microsoft Learn
第3回 w32tmコマンドとレジストリによるWindows Timeサービスの制御:Windowsネットワーク時刻同期の基礎とノウハウ(改訂版)(1/4 ページ) - @IT
NAT 見出しにジャンプ
NAPT 見出しにジャンプ
1つの外側IPv4アドレス(IPCPやMAP-Eで降ってきたグローバルIPアドレス)を複数の内側アドレス(プライベートIP)で共有するために、変換テーブルを持ちステートフルに動作する。これをNAPT(ヤマハはIPマスカレード)という。
IPアドレス及びポートをNATは1:1、NAPTは1:多で変換する。その対応関係は静的NATや静的NAPTのconfig構文からも読み取れる。
config | 説明 |
---|---|
#
# NAT Descriptor configuration
#
nat descriptor log off
nat descriptor backward-compatibility 2
|
NAPTのポートマッピング・パケットフィルタには様々なタイプがあり、対戦ゲームやVoIPがP2P通信を始める際のUDPホールパンチングの可否に影響する。これを俗に「NAT越え」と呼ぶ。 |
- nat descriptor masquerade remove df-bit on
+ nat descriptor masquerade remove df-bit off
|
NAPTを通過するパケットのDon't Fragmentビットを無視させる、Path MTU Blackholeの回避策が有効になっているが、Path MTU Discoveryが効かない状態はスループットの低下を招くので無効にする。 |
#
# PP configuration
#
### PP 1 ###
pp select 1
ip pp nat descriptor 1000
#
# TUNNEL configuration
#
### TUNNEL 1 ###
tunnel select 1
ip tunnel nat descriptor 20000
#
# NAT Descriptor configuration
#
nat descriptor type 1000 masquerade hairpin=off
nat descriptor type 20000 masquerade hairpin=off
|
|
nat descriptor timer 1000 900
- nat descriptor timer 1000 tcpfin 60
+ nat descriptor timer 1000 tcpfin 120
# nat descriptor timer 1000 protocol=udp port=domain 10
+ nat descriptor timer 1000 protocol=udp port=ntp 30
+ nat descriptor timer 1000 protocol=udp port=https 120
+ nat descriptor timer 1000 protocol=udp 300
+ nat descriptor timer 1000 protocol=tcp 7440
+ nat descriptor timer 1000 protocol=icmp 60
|
|
nat descriptor address outer 1000 ipcp
- nat descriptor masquerade incoming 1000 reject
+ nat descriptor masquerade incoming 1000 discard
|
|
- nat descriptor masquerade port range 1000 60000-64095 49152-59999 44096-49151
+ nat descriptor masquerade port range 1000 32768-65534
|
NAPTでは
CPE用途では、最初のポート範囲を使い切るのも困難と思うが...。 |
~~ nat descriptor address outer 20000 map-e |
Web GUIでv6プラスやOCNバーチャルコネクトを選択すると、外側アドレス(グローバルIPアドレス)に |
NAPTの統計情報は下記コマンドで確認できる。
60.19 IP マスカレードで使用しているセッション数の表示
show nat descriptor masquerade session summary
NAT/IPマスカレード 動作タイプ : 2
Interface Desc Num Outer Address Current/Max Peak
------------------- ---------- --------------------------- ----------- -----
PP[01](1) 1000 ipcp/198.51.100.2 214/65534 214
PP[02](1) 2000 ipcp/203.0.113.4 211/65534 211
PP[03](1) 1000 ipcp 0/65534 0
PP[04](1) 2000 ipcp 0/65534 0
TUNNEL[1](1) 20000 map-e/192.0.2.8 138/65534 138
------------------- ---------- --------------------------- ----------- -----
NAPTのアドレスマップは下記コマンドで確認できる。
57.14 動的 NAT ディスクリプタのアドレスマップの表示
> show nat descriptor address 1000 detail
NAT/IPマスカレード 動作タイプ : 2
参照NATディスクリプタ : 1000, 適用インタフェース : PP[01](1)
Masqueradeテーブル
外側アドレス: ipcp/198.51.100.170
ポート範囲: 32768-65534 30 セッション
プロトコル 内側アドレス 宛先 マスカレード TTL(秒)
UDP 192.168.100.1.4500 *.*.*.*.* 4500 static
UDP 192.168.100.1.500 *.*.*.*.* 500 static
TCP 192.168.100.7.59024 203.0.113.232.443 62918 48
TCP 192.168.100.7.58579 203.0.113.65.443 33535 7411
TCP 192.168.100.7.58588 192.0.2.148.5223 36601 7212
TCP 192.168.100.8.60053 192.0.2.136.5223 38390 7340
TCP 192.168.101.69.59803 192.0.2.135.5223 39667 7246
...
ポート開放 見出しにジャンプ
プライベートネットワーク内のListenポートに静的IPv4 NAPT/IPマスカレード/ポートフォワーディング/ポートマッピングし、パケットフィルタの穴あけを行うことを、合わせて俗に「ポート開放」と呼ぶ。
IPv6では通常NAPTしないため、パケットフィルタの穴あけだけ行えばよいが、アプリケーションや相手クライアントがIPv6に対応している必要がある。
- RTXでMinecraft Java Editionサーバ用のポート
25565/tcp
を解放する例
config | 説明 |
---|---|
#
# PP configuration
#
### PP 1 ###
pp select 1
ip pp nat descriptor 1000
#
# TUNNEL configuration
#
### TUNNEL 1 ###
tunnel select 1
ip tunnel nat descriptor 20000
#
# NAT Descriptor configuration
#
nat descriptor type 1000 masquerade hairpin=off
nat descriptor type 20000 masquerade hairpin=off
|
のマルチセッションを想定 |
nat descriptor type 1000 masquerade
+ nat descriptor masquerade static 1000 1 192.168.102.2 tcp 25565
|
NAPTされた非対称ネットワークの場合、グローバルIPアドレス:25565宛に接続してきても、LANのどの端末にマッピングすればよいか分からない。 IPv4 PPPoEで
|
#
# PP configuration
#
### PP 1 ###
pp select 1
+ ip pp secure filter in ... 41255
+ ip pp secure filter out ... dynamic ... 43900 ...
ip pp nat descriptor 1000
#
# IP filter configuration
#
+ ip filter 41255 pass-log * 192.168.102.2 tcp * 25565
#
# IP dynamic filter configuration
#
...
ip filter dynamic 43900 * * tcp syslog=on timeout=7440
...
|
インターネットからの接続を受け入れるには、推奨フィルタに含まれる動的フィルタ(SPI)に穴あけが必要。 |
#
# IP filter configuration
#
+ ip filter 42255 pass-nolog * * tcp 25565 *
#
# IP configuration
#
- ip route default gateway tunnel 1
+ ip route default gateway pp 1 filter 42255 gateway tunnel 1
|
L2TP/IPsecなど特定のポートで待ち受ける必要のあるサービスで、一部のポート番号しか使えないIPv4 over IPv6 (動的IP契約)に代わって0-65535全てのポートが使えるIPv4 PPPoEとマルチセッション、つまり非対称ルーティング環境では、静的ルートの設定変更も必要。 42255番のフィルタで |
- OSのファイアウォールの設定
例えば...
New-NetFirewallRule -DisplayName "Allow Inbound Minecraft Server" -Direction Inbound -LocalPort 25565 -Protocol TCP -RemoteAddress Any -Action Allow
Windows PowerShell を使用した高度なセキュリティ管理機能を備えた windows Defender ファイアウォール (Windows 10) - Windows security | Microsoft Docs
New-NetFirewallRule
- アプリケーションを起動して、Listenしているか確認
Get-NetTCPConnection | Select-String "25565"
netstat -an | Select-String "25565"
- LANの外からnmapで確認(TCPポートスキャン)
nmap -Pn -p 25565 グローバルIPまたはFQDN
Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-14 18:54 JST
Nmap scan report for example.com (グローバルIPまたはFQDN)
Host is up.
PORT STATE SERVICE
25565/tcp open minecraft
Nmap done: 1 IP address (1 host up) scanned in 2.63 seconds
RTX830でポート開放ができなくて何時間も格闘してた。明日鯖機再起動で変わらなかったら、現在アクセスポイントと化してるカバさんルータの出番かもしれない。
— しばにゃん@home (@shibanyan_1) June 13, 2020
逆NAT 見出しにジャンプ
逆NAT、つまり全世界のインターネットをRTXのNAT配下に収めることで、ちょうど順方向のNATがグローバルIPアドレスをプライベートIPアドレスに変換するように、任意のグローバルIPアドレス宛の通信を別のアドレスに捻じ曲げられる。
逆NAT, 逆IPマスカレード…とは? FAQ for YAMAHA RT Series / NAT&IP Masquerade
Twice NAT機能
NATディスクリプター コマンド仕様
以前こんなことがあった
うげ、EdgeってGoogle Public DNSがハードコードされてんの?TP-Linkかよ pic.twitter.com/s29EHCC7tr
— しばにゃん (@shibanyan_1) July 18, 2022
下記はGoogle Public DNSへの名前解決を、破棄せずOpenDNSやAdGuardへの問い合わせに改ざんする例。
非暗号化通信に限るが、タイムアウトさせることなく通信先を改ざんできる。
トルコのISPが偽Google Public DNSを運用:Geekなぺーじ
始める | Public DNS | Google Developers
DNSSEC General Availability – OpenDNS
AdGuard DNS moves to new addresses
- 逆NAT用のNATディスクリプタではNAPT(IPマスカレード)しないので、
nat
#
# NAT Descriptor configuration
#
nat descriptor type 1000 masquerade hairpin=off
~~
nat descriptor type 1002 nat
- 名前解決(53/udp宛)のアドレスマップを30秒で消す(本来は5秒が望ましい)
nat descriptor timer 1002 protocol=udp port=domain 30
- 予期せぬ発呼を防止
静的 NAT のみを使用する場合には、nat descriptor address outer コマンドとnat descriptor address inner コマンドの設定に注意する必要がある。初期値がそれぞれ ipcp と auto であるので、例えば何らかの IP アドレスをダミーで設定しておくことで動的動作しないようにする。
23.6 静的 NAT エントリの設定
nat descriptor address outer 1002 0.0.0.0 nat descriptor address inner 1002 0.0.0.0
- 逆NATはOutbound、つまりNATディスクリプタに"入っていく"方向にかかる。NATディスクリプタの外側にGoogle Public DNS
8.8.8.8
、内側にインターネットおよびOpenDNS208.67.222.222
がある。
nat descriptor static 1002 3 8.8.8.8=208.67.222.222 1
nat descriptor static 1002 4 8.8.4.4=208.67.220.220 1
- 動的パケットフィルタ
syslog=on
では、OUT方向の8.8.8.8
への通信として記録されるから、OpenDNSがHTTPS RRにNOERROR NOANSWERを返す仕様を利用して動作確認するとよい。
AdGuardならブロックされるアドレスで確認するとよいだろう。
dig @8.8.8.8 nyanshiba.com type65
- 非対称な逆NATでは、Google Public DNSのアドレスマップが残っているときに、正規のOpenDNSへの通信がタイムアウトする。
マルチホームなら別の経路に逃がすか、端からタイムアウトしても構わないアドレスを使うのがよい。逆NATを適用するPPやトンネルインターフェースを通らなければよい。
8.1.7 IP の静的経路情報の設定
dig @208.67.222.222 nyanshiba.com type65
#
# IP configuration
#
ip route 208.67.222.222 gateway tunnel 1
ip route 208.67.220.220 gateway tunnel 1
- 逆NATを適用
#
# PP configuration
#
### PP 1 ###
pp select 1
ip pp nat descriptor 1000 reverse 1002
パケットフィルタ 見出しにジャンプ
RTXのWeb GUIでインターネット接続設定を行った際に適用される推奨フィルタには、日常的にあまり意識しないようなパケットフィルタ設定が含まれている。
Web GUI「プロバイダー接続」で設定されるIPフィルターの解説
ファイアウォール機能のセキュリティレベル7
動的フィルタ(SPI)が設定されている時点でファイアウォールとしては十分機能するのだが、特にIPv6の推奨フィルタは必要最低限の簡素なもので、Ingress Filteringが全く考慮されていない。
@ykatombn氏の設定を丸パクリベースに、パケットフィルタを設定していく。syslogの有効無効やVLANの影響で範囲が異なる点以外はほぼ同じか私の方が雑なので、こちらの記事を参考にされたほうがよい。
RFC 6092を読んでヤマハルータのIPv6/v4フィルタ設定 - Qiita
Internet | |||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
RTX830
|
|||||||||||||||||||||||||||||||||||||||||||||||
PC | PC | PC |
重複したconfigの統合 見出しにジャンプ
9.1.26 フィルタリングによるセキュリティの設定
ルーターconfigの最適化
#
# PP configuration
#
### PP 1 ###
pp select 1
ip pp secure filter in 200003 ...
### PP 2 ###
pp select 2
- ip pp secure filter in 201003 ...
+ ip pp secure filter in 200003 ...
#
# TUNNEL configuration
#
### TUNNEL 1 ###
tunnel select 1
- ip tunnel secure filter in 400003 ...
+ ip tunnel secure filter in 200003 ...
#
# IP filter configuration
#
ip filter 200003 reject 192.168.100.0/24 * * * *
...
- ip filter 201003 reject 192.168.100.0/24 * * * *
- ...
- ip filter 400003 reject 192.168.100.0/24 * * * *
- ...
動的フィルタ 見出しにジャンプ
RTXの動的フィルタは一般的にStatefull Packet Inspection(SPI)と呼ばれるもので、Web GUIでインターネット接続を設定したときにデフォルトで挿入される、推奨フィルタにも使われている。
インターネットからの通信は基本的に廃棄し、LANからの通信は許可する動作を、双方向通信のTCP/IPで実現する。
ちょうど、家
の中から外へは自由に開き戸を開けられ、出先:443/tcp
への用事を済ませたらドアを閉じるような挙動になるが、家:49152/tcp
号室のドアが空いている間は、出先:443/tcp
からの有象無象は自由に出入りできる。
これをAddress and Port-Dependent Filteringといい、出入りできる"間"を動的フィルタのタイマやNAPTタイマで設定する。
#
# PP configuration
#
### PP 1 ###
pp select 1
- ip pp secure filter in 200003 200020 200021 200022 200023 200024 200025 200030 200032
+ ip pp secure filter in 200003 200020 200021 200022 200023 200024 200025 200030
- ip pp secure filter out 200013 200020 200021 200022 200023 200024 200025 200026 200027 200099 dynamic 200080 200081 200082 200083 200084 200085 200098 200099
+ ip pp secure filter out 200013 200020 200021 200022 200023 200024 200025 42900 dynamic 43110 43900 43010 43100 43000 43910 43920
#
# IP filter configuration
#
- ip filter 200099 pass * * * * *
+ ip filter 42900 pass 192.168.100.0/22 *
+ ip filter 49999 reject * *
+ ip filter 80000 pass * * udp * https
- ip filter 200026 restrict * * tcpfin * www,21,nntp
- ip filter 200027 restrict * * tcprst * www,21,nntp
- ip filter 200032 pass * 192.168.100.0/24 tcp * ident
#
# IP dynamic filter configuration
#
+ ip filter dynamic 43000 * * ntp syslog=on timeout=2
- ip filter dynamic 200081 * * domain
+ ip filter dynamic 43010 * * domain syslog=off timeout=5
- ip filter dynamic 200082 * * www
+ ip filter dynamic 43100 * * filter 80000 syslog=off timeout=120
+ ip filter dynamic 43110 * * www syslog=off timeout=7440
- ip filter dynamic 200080 * * ftp
- ip filter dynamic 200083 * * smtp
- ip filter dynamic 200084 * * pop3
- ip filter dynamic 200085 * * submission
- ip filter dynamic 200098 * * tcp
+ ip filter dynamic 43900 * * tcp syslog=on timeout=7440
- ip filter dynamic 200099 * * udp
+ ip filter dynamic 43910 * * udp syslog=on timeout=300
+ ip filter dynamic 43920 * * ping syslog=off timeout=60
- ip filter dynamic timer tcp-syn-timeout=30 tcp-fin-timeout=5 tcp-idle-time=3600 udp-idle-time=30 dns-timeout=5
+ ip filter dynamic timer tcp-syn-timeout=30 tcp-fin-timeout=120 tcp-idle-time=7440 udp-idle-time=120 dns-timeout=5
ip/ipv6 interface secure filter in/out
のconfigを流し込むと、即時反映される。
静的フィルタip/ipv6 filter
を評価順に適用して、dynamic
の後に動的フィルタip/ipv6 filter dynamic
を評価順に並べる。DNSdomain
, QUICfilter 80000
,ntp
がudp
の前にあるのはそのためだ。
動的フィルタはSPIに欠かせないが、負荷が高く遅延の増加に繋がるため、最小限の評価で済むよう頻繫にフローが作成されるプロトコル(HTTP >= DNS >>> QUIC > NTP)を前に並べるとよい。ログは最小限であるべきなので、分かっているプロトコルはsyslog=off
にしよう。 8.1.25 フィルタリングによるセキュリティーの設定
30.7.2 IPv6 フィルタの適用- HTTPS
443/tcp
でWebサイトを閲覧するとき、ip filter 42900
をきっかけに200099
43110
- 列挙した静的フィルタの末尾に全てのパケットを破棄する
default
フィルタが暗黙的に適用されるが、パケットフィルタを列挙せずにsecure filter in
を有効化できないため、49999番を使用するとよい。
IPパケット・フィルタ機能の基本 FAQ for YAMAHA RT Series / IP Packet Filter - IPv4 PPPoEやMAP-EなどのIPv4 NAT環境でNATタイマの設定をしたように、動的フィルタにも同様のタイマを設定する。
8.1.14 動的フィルターの定義
30.7.3 IPv6 動的フィルターの定義 ip filter dynamic timer
はIPv6にも影響する
8.1.15 動的フィルタのタイムアウトの設定
Yamahaルーターのドキュメント化されていない情報(2): buiの雑記帳:buimemo- QUIC
443/udp
はip filter dynamic
で使えるmnemonicがないので、静的フィルタip/ipv6 filter
で定義した80000
番を参照する。
RTシリーズでサポートしているニーモニック / 動的フィルター mnemonic table - パケットの多いHTTP
www
(80/tcp
,443/tcp
), や非暗号化DNSdomain
(53/udp
)と、静的フィルタでないとタイプが分からないICMPping
は、動的フィルタで許可ログを取らないsyslog=off
。
#
# LAN configuration
#
- ipv6 lan2 secure filter in 101000 101001 101002 101003
+ ipv6 lan2 secure filter in 101000 101002 101003
- ipv6 lan2 secure filter out 101099 dynamic 101080 101081 101082 101083 101084 101085 101098 101099
+ ipv6 lan2 secure filter out 62900 dynamic 63110 63900 63000 63010 63100 63910 63920
#
# IPv6 filter configuration
#
- ipv6 filter 101099 pass * * * * *
+ ipv6 filter 62900 pass ra-prefix@lan2::/64 *
+ ipv6 filter 69999 reject * *
+ ipv6 filter 80000 pass * * udp * https
- ipv6 filter 101001 pass * * tcp * ident
#
# IPv6 dynamic filter configuration
#
+ ipv6 filter dynamic 63000 * * ntp syslog=off timeout=2
- ipv6 filter dynamic 101081 * * domain
+ ipv6 filter dynamic 63010 * * domain syslog=off timeout=5
- ipv6 filter dynamic 101082 * * www
+ ipv6 filter dynamic 63100 * * filter 80000 syslog=off timeout=300
+ ipv6 filter dynamic 63110 * * www syslog=off timeout=7440
- ipv6 filter dynamic 101080 * * ftp
- ipv6 filter dynamic 101083 * * smtp
- ipv6 filter dynamic 101084 * * pop3
- ipv6 filter dynamic 101085 * * submission
- ipv6 filter dynamic 101098 * * tcp
+ ipv6 filter dynamic 63900 * * tcp syslog=on timeout=7440
- ipv6 filter dynamic 101099 * * udp
+ ipv6 filter dynamic 63910 * * udp syslog=on timeout=300
+ ipv6 filter dynamic 63920 * * ping6 syslog=off timeout=60
- IPv6も同様に
#
# FASTPATH configuration
#
- ip flow timer tcp 900
+ ip flow timer tcp 7440
- ip flow timer udp 30
+ ip flow timer udp 300
- ip flow timer icmp 30
+ ip flow timer icmp 60
- ip flow timer slow 30
+ ip flow timer slow 120
- フローテーブルも同様に。
8.1.34 フローテーブルの各エントリの寿命を設定する slow
スロータイマ。2MSL待つため2分に変更。
BCP38/84 見出しにジャンプ
こんなパケットが届いてしまった、、、
自宅まで素早く届いた詐称パケットたちを、家庭用CPEがせっせと弾いてくれてる。わいわい(全然嬉しくないhttps://t.co/q7awTDLNFk pic.twitter.com/ro32DVozaa
— しばにゃん (@shibanyan_1) October 6, 2022
偽装パスポートは、空港の時点で落とすべきだよね。
より厳密な解釈では、ISPから割り当てられたアドレスを送信元アドレスとして利用した通信のみが正常であり、割り当てられたものとは異なるアドレスを送信元アドレスとして利用している場合は正常ではない
送信元検証 | IIJの技術 | インターネットイニシアティブ(IIJ)
IPアドレス・スプーフィング攻撃(ip spoofing)に対処するフィルタを教えて下さい。FAQ for YAMAHA RT Series / IP Packet Filter
RFC 2827: Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing
RFC 3704: Ingress Filtering for Multihomed Networks
BCP38とCAIDA spoofer – JPNIC Blog
State of IP Spoofing
第152回 ソムリエの嗜みと文書管理の重要性!市場?史上?初!!スペシャル « podcast - #セキュリティのアレ
送信元を詐称した通信を遮断する|Aterm®WG2600HS2 ユーザーズマニュアル
internet service providers (ISPs) should implement ACLs at the subscriber edges. Doing so ensures that only inbound traffic originating from subnets is allocated to respective customers.
Two Simple Ways to Thwart DDoS Attacks | NETSCOUT
Bogon filtering - Wikipedia
BGP Filter Guides – BGP Filter Guide – Guidance on BGP Filtering
BGPの経路情報を元にuRPFを用いてIngress Filteringを行う手法。Fullbogonともなるとconfigが肥大し、頻回の更新を求められるためBGPは有効だ。
ASNを持っていればピアリングを申請できる。
Bogon Reference: via BGP | Team Cymru
https://www.team-cymru.org/Services/Bogons/fullbogons-ipv4.txt
https://www.team-cymru.org/Services/Bogons/fullbogons-ipv6.txt
NSP-Security-JP(NSP-SEC-JP)Update JANOG17 - 13-1_nsp-sec-jp.pdf
RIPE Anti-Spoofing Task Force HOW-TO — RIPE Network Coordination Centre
Bogon Routes Report - bgp.he.net
In general, you don't have to. If you're a small business, implementing BCP38 is the responsibility of your ISP, be they dialup, cablemodem, DSL, or 'fiber'. The faster your connection, the more important it is.
As noted above, while any filtering your in-house router/firewall will apply will be egress filtering, that doesn't make it useless, by any means.
Information for small businesses - BCP38
外向きのフィルタを用意する必要性を感じないかもしれないが、余計なパケットをインターネットに流すべきでない。マスクをしてOutboundをフィルタしよう。
#
# LAN configuration
#
- ipv6 lan2 secure filter in 101000 101002 101003
+ ipv6 lan2 secure filter in 101000 101002 101003 61200
- ipv6 lan2 secure filter out 62900 dynamic 63110 63900 63000 63010 63100 63910 63920
+ ipv6 lan2 secure filter out 62200 62900 dynamic 63110 63900 63000 63010 63100 63910 63920
#
# PP configuration
#
### PP 1 ###
pp select 1
- ip pp secure filter in 200003 200020 200021 200022 200023 200024 200025 200030
+ ip pp secure filter in 41200 200020 200021 200022 200023 200024 200025 200030
- ip pp secure filter out 200013 200020 200021 200022 200023 200024 200025 42900 dynamic 43110 43900 43010 43100 43000 43910 43920
+ ip pp secure filter out 42200 200020 200021 200022 200023 200024 200025 42900 dynamic 43110 43900 43010 43100 43000 43910 43920
#
# IP filter configuration
#
- ip filter 200000 reject 10.0.0.0/8 * * * *
- ip filter 200001 reject 172.16.0.0/12 * * * *
- ip filter 200002 reject 192.168.0.0/16 * * * *
- ip filter 200003 reject 192.168.100.0/24 * * * *
- ip filter 200010 reject * 10.0.0.0/8 * * *
- ip filter 200011 reject * 172.16.0.0/12 * * *
- ip filter 200012 reject * 192.168.0.0/16 * * *
- ip filter 200013 reject * 192.168.100.0/24 * * *
+ ip filter 41200 reject 0.0.0.0/8,10.0.0.0/8,36.0.64.81,100.64.0.0/10,127.0.0.0/8,169.254.0.0/16,172.16.0.0/12,192.0.0.0/24,192.0.2.0/24,192.88.99.0/24,192.168.0.0/16,198.18.0.0/15,198.51.100.0/24,203.0.113.0/24,224.0.0.0/3 *
+ ip filter 42200 reject * 0.0.0.0/8,10.0.0.0/8,36.0.64.81,100.64.0.0/11,100.96.0.0/12,127.0.0.0/8,169.254.0.0/16,172.16.0.0/12,192.0.0.0/24,192.0.2.0/24,192.88.99.0/24,192.168.0.0/16,198.18.0.0/15,198.51.100.0/24,203.0.113.0/24,224.0.0.0/3
ip filter 42900 pass 192.168.100.0/22 *
- ip filter 200026 restrict * * tcpfin * www,21,nntp
- ip filter 200027 restrict * * tcprst * www,21,nntp
- ip filter 200032 pass * 192.168.100.0/24 tcp * ident
#
# IPv6 filter configuration
#
+ ipv6 filter 61200 reject ::/3,2001:2::/48,2001:10::/28,2001:db8::/32,2002::/16,ra-prefix@lan2::/64,3ffe::/16,4000::/2,8000::/1 *
+ ipv6 filter 62200 reject * ::/3,2001:2::/48,2001:10::/28,2001:db8::/32,2002::/16,ra-prefix@lan2::/64,3ffe::/16,4000::/2,8000::/1
ipv6 filter 62900 pass ra-prefix@lan2::/64 *
- ipv6 filter 101001 pass * * tcp * ident
ICMP 見出しにジャンプ
#
# LAN configuration
#
- ipv6 lan2 secure filter in 101000 101002 101003 61200
+ ipv6 lan2 secure filter in 61100 61110 101003 61200
- ipv6 lan2 secure filter out 62200 62900 dynamic 63110 63900 63000 63010 63100 63910 63920
+ ipv6 lan2 secure filter out 62100 62110 62200 62900 dynamic 63110 63900 63000 63010 63100 63910 63920
#
# IPv6 filter configuration
#
- ipv6 filter 101000 pass * * icmp6 * *
- ipv6 filter 101002 pass * * udp * 546
+ ipv6 filter 61100 pass ra-prefix@lan2::/64,::,fe80::/64 ra-prefix@lan2::/64,fe80::/64,ff02::/16 icmp6 3,134-136
+ ipv6 filter 61110 pass-log fe80::/64 fe80::/64 udp 547 546
+ ipv6 filter 62100 pass ra-prefix@lan2::/64,::,fe80::/64 ra-prefix@lan2::/64,fe80::/64,ff02::/16 icmp6 1,133,135,136
+ ipv6 filter 62110 pass-log fe80::/64 ff02::1:2 udp 546 547
- NDP, DHCPv6を許可する
#
# LAN configuration
#
- ipv6 lan2 secure filter in 61100 61110 101003 61200
+ ipv6 lan2 secure filter in 61100 61110 101003 61200 61300
- ipv6 lan2 secure filter out 62100 62110 62200 62900 dynamic 63110 63900 63000 63010 63100 63910 63920
+ ipv6 lan2 secure filter out 62100 62110 62200 62300 62310 62900 dynamic 63110 63900 63000 63010 63100 63910 63920
#
# PP configuration
#
### PP 1 ###
pp select 1
- ip pp secure filter in 41200 200020 200021 200022 200023 200024 200025 200030
+ ip pp secure filter in 41200 200020 200021 200022 200023 200024 200025 41300
- ip pp secure filter out 42200 200020 200021 200022 200023 200024 200025 42900 dynamic 43110 43900 43010 43100 43000 43910 43920
+ ip pp secure filter out 42200 42300 42310 200020 200021 200022 200023 200024 200025 42900 dynamic 43110 43900 43010 43100 43000 43910 43920
#
# IP filter configuration
#
- ip filter 200030 pass * 192.168.100.0/24 icmp * *
+ ip filter 41300 pass-log * * icmp 3,11,12
+ ip filter 42300 pass-log 192.168.100.0/22 * icmp 3,8,11,12
+ ip filter 42310 reject * * icmp
#
# IPv6 filter configuration
#
- ipv6 filter 101000 pass * * icmp6 * *
+ ipv6 filter 61300 pass-log * ra-prefix@lan2::/64 icmp6 1-4,128
+ ipv6 filter 62300 pass-log ra-prefix@lan2::/64 * icmp6 1-4,128,129
+ ipv6 filter 62310 reject * * icmp6
- 許可すべきICMP
ping
: LANからのEcho Request(ICMP Type 8, ICMPv6 Type 128), WANからの戻りEcho Reply(ICMP Type 0, ICMPv6 Type 129)は動的フィルタが許可する
IPv4インターネットからのEcho RequestはRTXが答えるのでip filter
ではなくip stealth
で設定traceroute
mtr
: Time Exceeded(ICMP Type 11, ICMPv6 Type 3)
#Windows10 Pro (1909) で #tracert がOKだったり、NGだったりするのは、 #RTX が何かしてる? - Togetter- Path MTU Discovery: Fragmentation required(ICMP Type 3 Code 4), Packet too Big(ICMPv6 Type 2)
- Destination Unreachable(ICMP Type 3, ICMPv6 Type 1)
TCPやUDPの代わりに返答されることもあるので、静的フィルタで許可が必要 - Parameter Problem(ICMP Type 12, ICMPv6 Type 4)
- 破棄すべきICMP
- source quench(ICMP Type 4)
- timestamp req(ICMP Type 13)
- timestamp reply(ICMP Type 14)
- info request(ICMP Type 15)
- info reply(ICMP Type 16)
- mask request(ICMP Type 17)
- mask reply(ICMP Type 18)
不正アクセス検知機能(IDS)
Internet Control Message Protocol - Wikipedia
Internet Control Message Protocol for IPv6 - Wikipedia
RFC 4890: Recommendations for Filtering ICMPv6 Messages in Firewalls - SAD DNS: Port Unreachable(ICMP Type 3 Code 3, ICMPv6 Type 1 Code 4)
SAD DNSのICMP rate limitを用いたサイドチャネル攻撃について - knqyf263's blog
SAD DNSの仕組み
私の理解では、偽の権威DNS -> キャッシュDNSの関係に限らず、偽のキャッシュDNS -> DNSフォワーダでも成立する[要出典]。RTXのDNSリカーシブサーバはEDNS0に対応しているもののTCPフォールバック機能がない。LinuxカーネルのようにICMPのrate limitがあるという情報はないのでSAD DNS脆弱性はないかもしれない。
できればICMP Type 3 Code 3を返したくないが、RTXのIPパケットフィルタではICMP Type 3 Code 3とPMTUDに使われるCode 4を見分けられない。
ICMPパケットにはポート番号の概念がない。RTXは、外向きのICMPをIdentifierフィールドをみてNAPTする。返すべきでない、少なくとも外向きのICMPはIPv4もIPv6同様にRTX本機・LAN内のクライアント双方のパケットフィルタ設定が必要だ。
2.4. プロトコルの扱い NATディスクリプター機能 概要
#
# IP configuration
#
+ ip filter source-route on
+ ip filter directed-broadcast on
+ ip stealth all
ip icmp echo-reply send on
ip icmp echo-reply send-only-linkup off
- ip icmp mask-reply send on
+ ip icmp mask-reply send off
- ip icmp parameter-problem send off
+ ip icmp parameter-problem send on
ip icmp redirect send on
ip icmp redirect receive off
- ip icmp time-exceeded send on rebound=off
+ ip icmp time-exceeded send on rebound=on
- ip icmp timestamp-reply send off
+ ip icmp timestamp-reply send off
- ip icmp unreachable send on rebound=off
+ ip icmp unreachable send on rebound=on
#
# IPv6 configuration
#
no ipv6 stealth
ipv6 rh0 discard on
ipv6 icmp echo-reply send on
ipv6 icmp echo-reply send-only-linkup off
- ipv6 icmp parameter-problem send off
+ ipv6 icmp parameter-problem send on
ipv6 icmp redirect send on
ipv6 icmp redirect receive off
ipv6 icmp time-exceeded send on rebound=off
ipv6 icmp unreachable send on rebound=off
ipv6 icmp packet-too-big send on
- IPv4のsource routeオプション, 廃止されたIPv6のType 0 Routing HeaderをRTX全体で破棄する。
source-routeオプション付きIPパケットに対するフィルタリング FAQ for YAMAHA RT Series / IP Packet Filter
30.1.5 タイプ 0 のルーティングヘッダ付き IPv6 パケットを破棄するか否かの設定
RFC 5095: Deprecation of Type 0 Routing Headers in IPv6 - directed broadcast address
192.168.100.255
をRTX全体で破棄する。もちろんこれはL3の話で、L2分離でもしない限り同一セグメントからの192.168.100.255
には応答する。
directed broadcastパケットのフィルタリング FAQ for YAMAHA RT Series / IP Packet Filter - RTX宛のパケット起因のICMP unreachableおよびTCP RSTを抑制するには
ip/ipv6 stealth
を使う
13.1.12 ステルス機能の設定 - RTX宛でないパケット起因のICMPは
ip/ipv6 icmp
を使う
ICMP の設定
IPIPとマップルール 見出しにジャンプ
#
# IPv6 configuration
#
ipv6 source address selection rule prefix
#
# LAN configuration
#
- ipv6 lan2 secure filter in 61100 61110 101003 61200 61300
+ ipv6 lan2 secure filter in 61000 61100 61110 61200 61300
- ipv6 lan2 secure filter out 62100 62110 62200 62300 62310 62900 dynamic 63110 63900 63000 63010 63100 63910 63920
+ ipv6 lan2 secure filter out 62010 62100 62110 62200 62300 62310 62900 dynamic 63110 63900 63000 63010 63100 63910 63920
#
# IPv6 filter configuration
#
- ipv6 filter 101003 pass * * 4
+ ipv6 filter 61000 pass-log 2001:380:a120::9 ra-prefix@lan2::c6:3364:a300:0100/128 4
+ ipv6 filter 62010 pass ra-prefix@lan2::c6:3364:a300:0100/128 2001:380:a120::9 4
- MAP-EやDS-Liteに必要な、IPv4/IPv6変換機用IPv6アドレス
2001:db8:b0ba:10ee:c6:3364:a300:0100
からの
RFC 6052: IPv6 Addressing of IPv4/IPv6 Translators
BR・AFTR2001:380:a120::9
(NTT東)へのIPIP4
を許可する。誤って破棄されている場合は、下記のようなsyslogが発生する。
2222/02/22 02:22:22: LAN2 Rejected at IN(69999) filter: IPv4(tunnel) 2001:380:a120::9 > 2001:db8:b0ba:10ee:c6:3364:a300:0100
IPv4 over IPv4トンネル、IPv4 over IPv6トンネルでは外側IPヘッダーのプロトコル番号に4番が用いられ、IPv6 over IPv4トンネル、IPv6 over IPv6トンネルでは41番が用いられます。 IPIPパケットの受信インターフェースにフィルターを適用している場合は、これらのプロトコル番号のパケットの通過を許可してください。 IPIPトンネリング
#
# LAN configuration
#
ipv6 lan2 secure filter in 61000 61100 61110 61200 61300
- ipv6 lan2 secure filter out 62010 62100 62110 62200 62300 62310 62900 dynamic 63110 63900 63000 63010 63100 63910 63920
+ ipv6 lan2 secure filter out 62010 62011 62100 62110 62200 62300 62310 62900 dynamic 63110 63900 63000 63010 63100 63910 63920
#
# IPv6 filter configuration
#
+ ipv6 filter 62011 pass-log ra-prefix@lan2::1/128 rule.map.ocn.ad.jp tcp * https
- OCNバーチャルコネクトのマップルール取得時、RTXのエメフェラルポートは随分低いポートから使うようで、
ipv6 source address selection rule prefix
に従うため、ipv6 lan1 address
のra-prefix@lan2::1/128
。誤って破棄されている場合は、下記のようなsyslogが発生する。
2222/02/22 02:22:22: LAN2 Rejected at OUT(62221) filter: TCP 2001:db8:b0ba:10ee::1.2232 > 2600:9000:21**:****:c:3c50:880:93a1.https
Map Rule Server URL Specification
Specifications Remarks URI https://rule.map.ocn.ad.jp/?ipv6Prefix=<address>&ipv6PrefixLength=<prefixLength>&code=<API Key>
Embed <IPv6 address>
and<prefix length>
allocated to CEExample of URI: https://rule.map.ocn.ad.jp/?ipv6Prefix=2400:4050:XXX:&ipv6PrefixLength=YY&code=Abag9k2RFgerkljgsirSDEFgwada
引っ越し先でのネットワーク環境整備: MAP-E - ばびぶべぼ研究室
MAP-E(OCN) - 学習帳@ainoniwa.net
# # DNS configuration # dns service recursive
- FQDN指定するには、DNSリカーシブサーバが動作している必要がある。
FQDN フィルター機能
DNSリカーシブサーバに問い合わせさえすれば、TTLに関係なくFQDNタイマが切れるまでIPアドレスのテーブルが保持される。
#
# IP filter configuration
#
+ ip filter fqdn timer 172800 auto=on
- TTLの長いAレコードを持つ場合、FQDNフィルター機能が効かない場合がある。 8.1.16 FQDN フィルターで使用するキャッシュのタイマーの設定
NetBIOS 見出しにジャンプ
Web GUIでインターネット接続設定をした際に自動で適用されるヤマハ推奨フィルタには、NetBIOS over TCP/IPを破棄するフィルタが含まれる。
なぜポート137,138,139(NetBIOS,便利な機能)を、フィルタするんですか?FAQ for YAMAHA RT Series / Windows
無用な発呼を抑えるフィルタ設定例 FAQ for YAMAHA RT Series / Config
RTシリーズでサポートしているニーモニック / TCPポート番号 mnemonic table
そのほか、Amp攻撃に使われやすいプロトコル、トロイの木馬に使われた前歴があるポート番号など、ブロックすべきポートは数多ある。しかしconfigが冗長になってキリがない。
2.9. Port blocking Fetch Standard
動的フィルタがSPIの役割を果たし、WAN側からのパケットはデフォルト破棄される。逆にLAN側からのパケットはそのSPIip/ipv6 pp/tunnel/lan2 secure filter out
を開放するので、十分にケアしなければならない。
お前が始めた物語だろ
NetBIOS over TCP/IPはDHCPオプションで無効化しているからLAN側が発呼することはまずないのだが、ポート番号は複数指定できるのでその例示として。NEC系のHGWでよく見るAtermのフィルタにはNFS2049/
もう少しあったので、そちらも追加した。
パケットフィルタエントリ 初期値 ローカルルータモード初期値一覧|Aterm®WX7800T8 ユーザーズマニュアル
Aterm BL902HW のファイアーウォールの初期設定
#
# LAN configuration
#
ipv6 lan2 secure filter in 61000 61100 61110 61200 61300
- ipv6 lan2 secure filter out 62010 62100 62110 62200 62300 62310 62900 dynamic 63110 63900 63000 63010 63100 63910 63920
+ ipv6 lan2 secure filter out 62010 62011 62100 62110 62200 62210 62220 62300 62310 62900 dynamic 63110 63900 63000 63010 63100 63910 63920
#
# PP configuration
#
### PP 1 ###
pp select 1
- ip pp secure filter in 41200 200020 200021 200022 200023 200024 200025 41300
+ ip pp secure filter in 41200 41300
- ip pp secure filter out 42200 42300 42310 200020 200021 200022 200023 200024 200025 42900 dynamic 43110 43900 43010 43100 43000 43910 43920
+ ip pp secure filter out 42200 42300 42310 42210 42220 42900 dynamic 43110 43900 43010 43100 43000 43910 43920
#
# IP filter configuration
#
- ip filter 200020 reject * * udp,tcp 135 *
- ip filter 200021 reject * * udp,tcp * 135
- ip filter 200022 reject * * udp,tcp netbios_ns-netbios_ssn *
- ip filter 200023 reject * * udp,tcp * netbios_ns-netbios_ssn
- ip filter 200024 reject * * udp,tcp 445 *
- ip filter 200025 reject * * udp,tcp * 445
+ ip filter 42210 reject * * tcp,udp 135,netbios_ns-netbios_ssn,445,2049,1243,5351,12345,27374,31785,31789,31791 *
+ ip filter 42220 reject * * tcp,udp * 135,netbios_ns-netbios_ssn,445,2049,1243,5351,12345,27374,31785,31789,31791
#
# IPv6 filter configuration
#
+ ipv6 filter 62210 reject * * tcp,udp 135,netbios_ns-netbios_ssn,445,2049,1243,5351,12345,27374,31785,31789,31791 *
+ ipv6 filter 62220 reject * * tcp,udp * 135,netbios_ns-netbios_ssn,445,2049,1243,5351,12345,27374,31785,31789,31791
注意が必要なのは、エメフェラルポートが含まれる点だ。DNSリカーシブサーバのポートランダマイズ範囲を広げている環境でip/ipv6 pp/tunnel/lan2 secure filter out
に適用すると巻き込まれてしまう。私はVLAN環境なのでNetBIOS over TCP/IPフィルタはip/ipv6 lan1/N secure filter in
に指定することになるが、自ずとDNSリカーシブサーバへの通信を許可するフィルタと併せて適用することになるため、破棄を免れている。
VLAN 見出しにジャンプ
RTXが対応しているVLAN方式にはポート分離機能, LAN分割機能, タグVLANがある。
LAN Type | ポート分離機能 | LAN分割機能 | タグVLAN |
---|---|---|---|
VLAN間ルーティング・IPパケットフィルタ(異なるセグメント) 部門ごとに社内ネットワークを構成する(LAN1ポートをグループに分ける) IPv6 IPoE対応機能 - RTpro |
X | O | O |
RTXでアクセスポート(= RTX単体でVLANをつくれる) | O | O | X |
トランクポート | X | X | O |
スイッチやAPでのVLAN(マルチSSID) タグVLANを設定する 部門ごとに無線ネットワークを分割 : ルーター + 無線LANアクセスポイント Web GUI設定 ゲスト用の無線ネットワークを設定 : ルーター コマンド設定 + 無線LANアクセスポイント Web GUI設定 LANポート設定 WLX212技術資料 - RTpro |
|||
ポートミラーリング(Wiresharkでパケットキャプチャ)と併用 4.45 ポートミラーリング機能の設定 - RTpro |
|||
タグVLAN(トランクポート)とLAN分割機能(アクセスポート)の併用 | 物理インターフェース単位で可 = LAN3インターフェースのある機種のみ = RTX830は非対応 |
VLANはLANを安全にする機能ではない。本来「うちのLANには繋げられないな...」というユーザや機器を繋げても害がないようフィルタリングしなければならない。
性善説に基づくLANと性悪説に基づくLANが混在する環境をつくっていると意識して、気を引き締めてconfigを流し込もう。
タグVLAN 見出しにジャンプ
config | 説明 |
---|---|
#
# LAN configuration
#
lan type lan1 1000-fdx speed-downshift=off energy-saving=on
ip lan1 address 192.168.100.1/24
ip lan1 proxyarp off
- ip lan1 arp log off
+ ip lan1 arp log on
ip lan1 dhcp service server
ipv6 lan1 address ra-prefix@lan2::1/64
ipv6 lan1 rtadv send 1 o_flag=on
ipv6 lan1 dhcp service server
+ description lan1/1 home
+ vlan lan1/1 802.1q vid=101 name=VLAN101
+ ip lan1/1 address 192.168.101.1/24
ip lan1/1 proxyarp off
+ ip lan1/1 arp log on
+ description lan1/2 guest
+ vlan lan1/2 802.1q vid=102 name=VLAN102
+ ip lan1/2 address 192.168.102.1/24
ip lan1/2 proxyarp off
+ ip lan1/2 arp log on
+ description lan1/3 server
+ vlan lan1/3 802.1q vid=103 name=VLAN103
+ ip lan1/3 address 192.168.103.1/24
ip lan1/3 proxyarp off
+ ip lan1/3 arp log on
|
ipcalc 192.168.100.0/22 Network: 192.168.100.0/22 Netmask: 255.255.252.0 = 22 Broadcast: 192.168.103.255 ipcalc 192.168.103.0/24 Network: 192.168.103.0/24 Netmask: 255.255.255.0 = 24 Broadcast: 192.168.103.255 プライベートIPアドレスに使える範囲は決まっているので、その中から選んで設定しよう。 VLANのIPパケットフィルタ設定を見ると、
このことから、
でフィルタした方がよい。この項では3. VLANのパケットフィルタしかケアしないので、1. 2.は別項へのパーマリンクを参照されたし。 |
#
# DHCP configuration
#
dhcp service server
dhcp server rfc2131 compliant except remain-silent
- dhcp scope 1 192.168.100.2-192.168.100.191/24
+ dhcp scope 1 192.168.100.20-192.168.100.191/24
+ dhcp scope 2 192.168.101.20-192.168.101.191/24
+ dhcp scope 3 192.168.102.20-192.168.102.191/24
+ dhcp scope 4 192.168.103.20-192.168.103.191/24
+ dhcp scope option 1 dns=192.168.100.1 ntp_server=192.168.100.1
+ dhcp scope option 2 dns=192.168.100.1 ntp_server=192.168.100.1
+ dhcp scope option 3 dns=192.168.100.1 ntp_server=192.168.100.1
+ dhcp scope option 4 dns=192.168.100.1 ntp_server=192.168.100.1
|
|
#
# LAN configuration
#
ip lan1 address 192.168.100.1/24
# + ip lan1 secure filter in 42200 42210 42220 42900
# + ip lan1 secure filter out 41200 41900
ip lan1/1 address 192.168.101.1/24
+ ip lan1/1 secure filter in 42200 42210 42220 42900
+ ip lan1/1 secure filter out 41200 41900
ip lan1/2 address 192.168.102.1/24
+ ip lan1/2 secure filter in 42200 42210 42220 42900
+ ip lan1/2 secure filter out 41200 41900
ip lan1/3 address 192.168.103.1/24
+ ip lan1/3 secure filter in 49999
+ ip lan1/3 secure filter out 49999
#
# PP configuration
#
# ### PP 1 ###
# pp select 1
# pppoe use lan2
# - ip pp secure filter in 200003 ...
# + ip pp secure filter in 200004 ...
# - ip pp secure filter out 200013 ...
# + ip pp secure filter out 200014 ...
# #
# # TUNNEL configuration
# #
# no tunnel enable all
# ### TUNNEL 1 ###
# tunnel select 1
# tunnel encapsulation ipip/map-e
# - ip tunnel secure filter in 200003 ...
# + ip tunnel secure filter in 200004 ...
# - ip tunnel secure filter out 200013 ...
# + ip tunnel secure filter out 200014 ...
#
# IP filter configuration
#
ip filter 41200 reject 0.0.0.0/8,10.0.0.0/8,...
ip filter 42200 reject * 0.0.0.0/8,10.0.0.0/8,...
ip filter 42210 reject * * tcp,udp 135,netbios_...
ip filter 42220 reject * * tcp,udp * 135,netbios_...
+ ip filter 41900 pass * 192.168.100.0/22
ip filter 42900 pass 192.168.100.0/22 *
ip filter 49999 reject * *
|
57.4 IP の経路情報テーブルの表示
Implementing BCP38 - BGP.guru
|
#
# LAN configuration
#
- ip lan1/2 secure filter in 42200 42210 42220 42900
+ ip lan1/2 secure filter in 253123 256867 42200 42210 42220 42900
- ip lan1/2 secure filter out 41200 41900
+ ip lan1/2 secure filter out 253124 256768 41200 41900
#
# IP filter configuration
#
+ ip filter 253123 pass-log 192.168.100.0/22 192.168.100.1 udp * domain,ntp
+ ip filter 253124 pass-nolog 192.168.100.1 192.168.100.0/22 udp domain,ntp *
+ ip filter 256867 pass-log 0.0.0.0,192.168.100.0/22 192.168.100.1,192.168.101.1,192.168.102.1,192.168.103.1,255.255.255.255 udp dhcpc dhcps
+ ip filter 256768 pass-log 192.168.100.1,192.168.101.1,192.168.102.1,192.168.103.1 192.168.100.0/22,255.255.255.255 udp dhcps dhcpc
#
# DNS configuration
#
- dns host lan1
+ dns host lan1 lan1/1 lan1/2 lan1/3
#
# SNTPD configuration
#
sntpd service on
- sntpd host lan1
+ sntpd host lan1 lan1/1 lan1/2 lan1/3
|
VLAN間通信をBogonフィルタで破棄する前に、DHCPとDNSは許可しないとWAN側との通信すら開始できない。
|
#
# LAN configuration
#
ip lan1/2 secure filter in 253123 256867 42200 42210 42220 42900
- ip lan1/2 secure filter out 253124 256768 41200 41900
+ ip lan1/2 secure filter out 253124 256768 222222 41200 41900 dynamic 222222
#
# IP filter configuration
#
+ ip filter 222222 pass-nolog 192.168.100.0/26 192.168.100.0/22 tcpsyn * 22,80,5201
+ ip filter dynamic 222222 192.168.100.0/26 192.168.100.0/22 filter 222222 syslog=on timeout=6
|
TCPKeepAlive yes
Host hoge
User fuga
HostName 192.168.102.2
IdentityFile ~/.ssh/ssh_id_ed25519
ServerAliveInterval 5
動的フィルタの状態は下記コマンドで確認できる。ちょうど
57.29 動的フィルタによって管理されているコネクションの表示 57.30 IPv6 の動的フィルタによって管理されているコネクションの表示 |
#
# LAN configuration
#
ip lan1 secure filter in
ip lan1 secure filter out
- ip lan1/1 secure filter in 253123 256867 42200 42210 42220 42900
+ ip lan1/1 secure filter in 253123 256867 251910 42200 42210 42220 42900 dynamic 251910
ip lan1/1 secure filter out 253124 256768 41200 41900
ip lan1/2 secure filter in 253123 256867 42200 42210 42220 42900
- ip lan1/2 secure filter out 253124 256768 222222 41200 41900 dynamic 222222
+ ip lan1/2 secure filter out 253124 256768 222222 251910 41200 41900 dynamic 222222 251910
#
# IP filter configuration
#
+ ip filter 251910 pass-nolog 192.168.100.0/23 192.168.102.2 tcpsyn * printer,9100
+ ip filter dynamic 251910 192.168.100.0/23 192.168.102.2 filter 251910 syslog=on timeout=240
|
|
#
# LAN configuration
#
ipv6 lan1 address ra-prefix@lan2::1/64
+ ipv6 lan1 secure filter in 253123 62100 62110 62200 62210 62220 62900
+ ipv6 lan1 secure filter out 253124 61100 61110 61200 61900
# + ipv6 lan1/1 address dhcp-prefix@lan2::10:0:0:0:1/64
+ ipv6 lan1/1 secure filter in 69999
+ ipv6 lan1/1 secure filter out 69999
# + ipv6 lan1/2 address dhcp-prefix@lan2::20:0:0:0:1/64
+ ipv6 lan1/2 secure filter in 69999
+ ipv6 lan1/2 secure filter out 69999
# + ipv6 lan1/3 address dhcp-prefix@lan2::30:0:0:0:1/64
+ ipv6 lan1/3 secure filter in 69999
+ ipv6 lan1/3 secure filter out 69999
#
# IPv6 filter configuration
#
ipv6 filter 61100 pass ra-prefix@lan2::/64,::,fe80::/64 ra-prefix@lan2::/64,fe80::/64,ff02::/16 icmp6 3,134-136 #RA NDP
ipv6 filter 62100 pass ra-prefix@lan2::/64,::,fe80::/64 ra-prefix@lan2::/64,fe80::/64,ff02::/16 icmp6 1,133,135,136 #RS NDP
ipv6 filter 61110 pass-log fe80::/64 fe80::/64 udp 547 546 # dhcpv6 s -> c
ipv6 filter 62110 pass-log fe80::/64 ff02::1:2 udp 546 547 # dhcpv6 c -> s
ipv6 filter 61200 reject ::/3,2001:2::/48,...
ipv6 filter 62200 reject * ::/3,2001:2::/48,...
ipv6 filter 62210 reject * * tcp,udp 135,netbios...
ipv6 filter 62220 reject * * tcp,udp * 135,netbios...
+ ipv6 filter 61900 pass * ra-prefix@lan2::/64
ipv6 filter 62900 pass ra-prefix@lan2::/64 *
ipv6 filter 69999 reject * *
+ ipv6 filter 253123 pass-log ra-prefix@lan2::/64 fdca::1 udp * domain,ntp
+ ipv6 filter 253124 pass-nolog fdca::1 ra-prefix@lan2::/64 udp domain,ntp *
|
IPv6環境でのVLANだが、RAプロキシでは1つのVLANのみだから
57.6 IPv6 の経路情報の表示 |
LAN分割機能 見出しにジャンプ
LAN分割機能はRTXのスイッチインターフェースLAN1やLAN3を異なるセグメントに分割して、L3ルーティングおよびパケットフィルタを可能にする機能だ。
タグVLANのトランクポートと異なり、LANケーブル一本で繋がった配下の端末やスイッチは、分割後の1つのセグメントにのみ繋がる(アクセスポート)。
LAN分割機能
部門ごとに社内ネットワークを構成する(LAN1ポートをポート別に分ける)
#
# LAN configuration
#
+ lan type lan1 port-based-option=divide-network
- ip lan1 address 192.168.100.1/24
+ ip vlan1 address 192.168.100.1/24
- ip lan1 proxyarp on
+ ip vlan1 proxyarp on
+ ip vlan1 secure filter in ...
+ ip vlan1 secure filter out ...
- ipv6 lan1 address ra-prefix@lan2::1/64
+ ipv6 vlan1 address ra-prefix@lan2::1/64
- ipv6 lan1 rtadv send 1 o_flag=on
+ ipv6 vlan1 rtadv send 1 o_flag=on
- ipv6 lan1 dhcp service server
+ ipv6 vlan1 dhcp service server
+ ip vlan2 address 192.168.101.1/24
+ ip vlan2 secure filter in ...
+ ip vlan2 secure filter out ...
タグVLANではlan1/N
表記だったのがvlanN
表記な点はあるが、VLAN間パケットフィルタは同様に可能だ。
#
# VLAN Port Mapping configuration
#
+ vlan port mapping lan1.3 vlan1
+ vlan port mapping lan1.4 vlan1
RTX830のようなスイッチインタフェースが1個lan1
の機種は、デフォルトで基本機能と同様にlan1.N = vlanNの一対一の対応になる。
vlan port mapping
で対応関係を変更できる。
自社サーバを公開する | ルーター設定例 | ネットワーク機器(中国) | ヤマハ株式会社
RTX1200+SWX2200 VLAN双方向フィルター設定 | 優技録
YAMAHAルータの実機・検証 第5回 自社サーバを公開する - 株式会社ネディア │ネットワークの明日を創る。
RTX1210とFWX120の動的フィルタと静的フィルタをようやく克服する(2) - NW屋的日常徒然日記
RTXルーターで、一方向からアクセスできるDMZを構築する - Qiita
ヤマハルータのフィルタ機能に関する動き - Qiita
YAMAHA RTX系 ip filterの書き方(我流w) - sidetech
リモートアクセスVPN 見出しにジャンプ
「ギガアクセスVPNルーター」と銘打っているだけあって、様々な方式の拠点間(トンネルモード)やリモートアクセス(トランスポートモード)VPNに対応している。
ルーター/ファイアウォールの技術資料 対応機種 documents for Yamaha network products
L2TP/IPsecでのリモートアクセスVPNは、現代でも比較的使えるレベルのセキュリティと互換性を兼ね備えた方式だ。
L2TP/IPsecを使用したリモートアクセス : Web GUI設定
L2TP/IPsec
iOSからリモートアクセスする
Android 12以降のAOSPはL2TP/IPsecに非対応となっているが、執筆時点でヤマハルータはトランスポートモードのIKEv2/IPsecに対応していない。
YAMAHA RTシリーズルータとスマートフォンの相互接続事例
下記ドキュメントのようなことはできない点に注意が必要だ。
Androidからリモートアクセスする
Web GUI設定の変更箇所 | 説明 |
---|---|
#
# LAN configuration
#
ip lan1 proxyarp off
#
# PP configuration
#
### PP anonymous ###
pp select anonymous
pp bind tunnel2
pp auth request mschap-v2
pp auth username [user] [password]
+ pp auth username [user] [password]
+ pp auth username [user] [password]
ppp lcp pfc off
ppp lcp acfc off
- ppp ipcp vjc off
+ ppp ipcp vjc on
ppp ipcp ipaddress on
ppp ipcp msext on
- ppp ccp type none
+ ppp ccp type stac
- ip pp remote address pool dhcp
+ ip pp remote address pool 192.168.100.128-192.168.100.159
ip pp mtu 1258
pp enable anonymous
#
# TUNNEL configuration
#
### TUNNEL 2 ###
tunnel select 2
tunnel encapsulation l2tp
ipsec tunnel 1
- ipsec sa policy 1 1 esp aes-cbc sha-hmac
+ ipsec sa policy 1 1 esp aes256-cbc sha256-hmac
- ipsec ike keepalive use 1 off
+ ipsec ike keepalive use 1 on dpd 60 2 0
- ipsec ike nat-traversal 1 on
+ ipsec ike nat-traversal 1 on keepalive=300 force=off type=1
ipsec ike pre-shared-key 1 text [pre-shared-key]
ipsec ike remote address 1 any
ipsec tunnel outer df-bit copy
- l2tp tunnel disconnect time off
+ l2tp tunnel disconnect time 60
ip tunnel tcp mss limit auto
tunnel enable 2
|
|
#
# PP configuration
#
### PP anonymous ###
pp select anonymous
+ ip pp secure filter in 253123 225510 42200 42210 42220 42900 225510
+ ip pp secure filter out 253124 41200 41900
#
# IP filter configuration
#
+ ip filter 225510 pass-log 192.168.100.128/27 192.168.100.2 tcpsyn * 22,5510
+ ip filter dynamic 225510 192.168.100.128/27 192.168.100.2 filter 225510
#
# DNS configuration
#
- dns notice order msext me server
+ dns notice order msext me
|
ipcalc 192.168.100.128/27 Network: 192.168.100.128/27 Netmask: 255.255.255.224 = 27 Broadcast: 192.168.100.159 DHCPは使わないのでDHCPスコープの設定もパケットフィルタも必要ないが、代わりにIPCP MS 拡張 |
#
# IP configuration
#
- ip route default gateway tunnel 1 hide gateway pp 1 weight 0
+ ip route default gateway pp 1 filter 200110 gateway tunnel 1 hide gateway pp 1 weight 0
# ip route 203.0.113.0/24 gateway pp 1 filter 200110
#
# LAN configuration
#
ip lan1 address 192.168.100.1/24
#
# PP configuration
#
### PP 1 ###
- ip pp secure filter in ... 200100 200101 200102 200103
+ ip pp secure filter in ... 200100
#
# IP filter configuration
#
- ip filter 200100 pass * 192.168.100.1 udp * 500
+ ip filter 200100 pass-log 203.0.113.0/24 192.168.100.1 udp * 500,1701,4500
- ip filter 200101 pass * 192.168.100.1 esp
- ip filter 200102 pass * 192.168.100.1 udp * 4500
- ip filter 200103 pass * 192.168.100.1 udp * 1701
+ ip filter 200110 pass 192.168.100.1 203.0.113.0/24 udp 500,1701,4500 *
#
# NAT Descriptor configuration
#
nat descriptor type 1000 masquerade
nat descriptor address outer 1000 ipcp
nat descriptor masquerade static 1000 1 192.168.100.1 udp 500
- nat descriptor masquerade static 1000 2 192.168.100.1 esp
nat descriptor masquerade static 1000 3 192.168.100.1 udp 4500
- nat descriptor masquerade static 1000 4 192.168.100.1 udp 1701
nat descriptor type 20000 masquerade
nat descriptor address outer 20000 map-e
#
# IPSEC configuration
#
ipsec auto refresh on
ipsec transport 2 1 udp 1701
#
# L2TP configuration
#
l2tp service on
|
|
show status pp anonymous
show status l2tp tunnel 2
57.20 L2TP の状態の表示
VPN(L2TP/IPsec)接続ができない
構成プロファイルでiPhoneを自動VPN接続 見出しにジャンプ
Appleデバイスでは、「VPNオンデマンド」でVPNへの自動接続ができる。
Appleデバイス導入でのVPNの概要 - Apple サポート (日本)
AppleデバイスのL2TPのMDM設定 - Apple サポート (日本)
iOSの構成プロファイルは通常、macOSで利用可能な「Apple Configurator 2」で生成する。しかし中身はplist、ほぼxmlなのでWindows上のテキストエディタで作成可能だ。
VPN | Apple Developer Documentation
An OnDemand VPN iOS profile for iPad and iPhone that automatically connects you to different VPNs (e.g. Meraki, FRITZ!Box and Streisand) | Blog-Entry: https://thomas-witt.com/auto-connect-your-ios-device-to-a-vpn-when-joining-an-unknown-wifi-d1df8100c4ba
構成プロファイル | 説明 |
---|---|
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>PayloadContent</key>
<array>
<!-- ondemand-pppv4 (Cellular or Public Wi-Fi) -->
<dict>
<key>UserDefinedName</key>
<string>ondemand-pppv4</string>
<key>PayloadDisplayName</key>
<string>ondemand-pppv4</string>
<key>PayloadOrganization</key>
<string>ホームネットワーク</string>
<key>PayloadIdentifier</key>
<string>com.example.vpn.ondemand-pppv4</string>
<key>PayloadUUID</key>
<string>658ae34d-2384-4b4f-8db0-8dbf0047ba0c</string>
<!-- VPN -->
<key>VPNType</key>
<string>L2TP</string>
<!-- VPN.IPSec -->
<key>IPSec</key>
<dict>
<key>AuthenticationMethod</key>
<string>SharedSecret</string>
<key>LocalIdentifierType</key>
<string>KeyID</string>
<key>SharedSecret</key>
<string>secret</string>
</dict>
<!-- VPN.IPv4 -->
<key>IPv4</key>
<dict>
<key>OverridePrimary</key>
<integer>1</integer>
</dict>
<!-- VPN.PPP -->
<key>PPP</key>
<dict>
<key>AuthName</key>
<string>user</string>
<key>AuthPassword</key>
<string>password</string>
<key>CommRemoteAddress</key>
<string>example.com</string>
</dict>
<!-- VPN.VPN -->
<key>DisconnectOnIdle</key>
<integer>1</integer>
<key>DisconnectOnIdleTimer</key>
<integer>120</integer>
<key>EnforceRoutes</key>
<integer>1</integer>
<key>ExcludeLocalNetworks</key>
<integer>0</integer>
<key>IncludeAllNetworks</key>
<integer>0</integer>
<key>OnDemandEnabled</key>
<integer>1</integer>
<key>OnDemandRules</key>
<array>
<dict>
<key>InterfaceTypeMatch</key>
<string>WiFi</string>
<key>SSIDMatch</key>
<array>
<string>ssid1</string>
<string>ssid2</string>
</array>
<key>Action</key>
<string>Disconnect</string>
</dict>
<dict>
<key>InterfaceTypeMatch</key>
<string>Cellular</string>
<key>Action</key>
<string>Connect</string>
</dict>
<dict>
<key>InterfaceTypeMatch</key>
<string>WiFi</string>
<key>Action</key>
<string>Connect</string>
</dict>
<dict>
<!-- VPN Default state -->
<key>Action</key>
<string>Connect</string>
</dict>
</array>
<key>OnDemandUserOverrideDisabled</key>
<integer>1</integer>
<key>OverridePrimary</key>
<integer>0</integer>
<key>PayloadType</key>
<string>com.apple.vpn.managed</string>
<key>PayloadVersion</key>
<integer>1</integer>
</dict>
</array>
<key>PayloadDescription</key>
<string>Always #StayHome</string>
<key>PayloadDisplayName</key>
<string>OnDemand L2TP/IPsec</string>
<key>PayloadIdentifier</key>
<string>com.example.ondemand-l2tp-ipsec</string>
<key>PayloadOrganization</key>
<string>example.com</string>
<key>PayloadRemovalDisallowed</key>
<false/>
<key>PayloadType</key>
<string>Configuration</string>
<key>PayloadUUID</key>
<string>f3e5d06c-1ad0-444b-b595-3937aee94d6f</string>
<key>PayloadVersion</key>
<integer>1</integer>
</dict>
</plist>
|
|
|
|
|
|
Netvolante無料DDNS 見出しにジャンプ
ヤマハルータを購入すると、ネットボランチDDNSの永続ライセンスが無料でついてくる。DDNSを使うと、動的IPのIPv4 PPPoEの設定や半固定のIPv6 IPoEを名前解決で引けるようになる。
トンネルインターフェースを使うIPv4 over IPv6は対応していない。
コマンドを使用してホストアドレス・電話アドレスの登録/削除を行う FAQ for YAMAHA RT Series / ネットボランチDNSサービス
ネットボランチ DNS サービスの設定
ネットボランチDDNSはインタラクティブなコマンドで設定する。既に設定されたnetvolante-dns hostname...
を流し込んでも無効な点に注意。
日本のIPv6インターネットにおいてDDNSする意味があるかは微妙だが、IPv6アドレスを持つLAN2インターフェースのDDNSにも対応している。
設定例にあるipv6 source address selection rule lifetime
はグローバルIPv4アドレスを含む場合があるためお勧めしない。
IPv6に対応していますか? FAQ for YAMAHA RT Series / ネットボランチDNSサービス
34.6 ホスト名の登録
Netvolante DDNSを利用するには、Outboudの2002/tcp
をパケットフィルタで許可されている必要がある。
ネットボランチDNSサービスが使えない FAQ for YAMAHA RT Series / ネットボランチDNSサービス
STATUS LEDが消えない 見出しにジャンプ
STATUS LEDは初期設定では限られた障害の検知しか表示しない
FAQ for YAMAHA RT Series / STATUS LED
57.69 STATUS LED の情報の表示
DNSリカーシブサーバ 見出しにジャンプ
DNSの名前解決があって初めて3-way handshakeが始まり、通信を開始できる。それだけDNSの応答速度は快適なインターネットライフに欠かせない。
ヤマハルータは競合他社製品に比べDNS設定が豊富だ。本来、別途フルリゾルバを必要とするような複雑な設定がルータ単体で完結するのは、非常に魅力的。
一般的に、スタブリゾルバとキャッシュDNS(フルリゾルバ)の間に入るリゾルバをDNSプロキシ, DNSフォーワーダと呼ぶ。ヤマハがDNSリカーシブサーバと呼ぶRTXのDNSフォワーダは、DNSキャッシュ機能を持つ。
DNSリカーシブサーバって何ですか? FAQ for YAMAHA RT Series / TCP/IP
#
# DNS configuration
#
dns host lan1
dns service recursive
dns service fallback on
- dns srcport 10000-10999
+ dns srcport 1024-65535
dns cache use on
dns cache max entry 256
+ dns domain .
- dns notice order dhcp me server
+ dns notice order dhcp none
- dns notice order dhcpv6 me
+ dns notice order dhcpv6 none
- dns notice order msext me server
+ dns notice order msext me
-
DNSの名前解決があって初めてWebサイトなどのHTTP通信を開始できる。
注意が必要なのは、NGNのDNSサーバがIPv6シングルスタックな点。IPv6 IPoEと併せて設定するIPv4 over IPv6にはDNSサーバがないが、DNSリカーシブサーバを経由してIPv6 DNSでA/AAAAレコード双方を名前解決可能だ。
しかし、EDNS0 Client SubnetやIP Anycastが適切に機能せず、回線速度を生かせない可能性がある。
IPv4 PPPoEの設定を行ってISPのDNSサーバのIPv4アドレスを取得し、DNSリカーシブサーバを適切に設定した上で、IPv4 over IPv6を使わないかマルチホーミングすることで軽減可能だ。 -
オープンリゾルバにならないよう、パケットフィルタ側で設定が必要。念のためインターフェースも絞っておく。
VLAN環境ではlan1
をlan
などに変更する。
24.13 DNS サーバーへアクセスできるホストの設定
オープンリゾルバー(Open Resolver)に対する注意喚起について FAQ for YAMAHA RT Series / Security -
キャッシュポイズニング対策のソースポートランダマイズに
dns srcport 10000-10999
は控えめ過ぎると思ったので、Ciscoに倣ってエメフェラルポートの最大範囲1024-65535
にしている。
24.12 DNS 問い合わせパケットの始点ポート番号の設定
RTシリーズのDNS機能におけるキャッシュポイズニングの脆弱性について FAQ for YAMAHA RT Series / Security
Cisco Prime Network Registrar 10.0 Caching and Authoritative DNS User Guide - Managing Caching DNS Server [Cisco Prime Network Registrar] - Cisco
DNSキャッシュポイズニングの原因・対策・その理由:DNSキャッシュポイズニングの影響と対策(後編)(3/4 ページ) - @IT
RFC 6056 - Recommendations for Transport-Protocol Port Randomization
経路中で落とされる場合も考えられるので、要注意。
QUICやHTTP/3で利用を避けるべき送信元ポートの議論についての考察 - show log @yuyarin -
show dns cache
で見る限り、DNSキャッシュは256dns cache max entry 256
で事足りる。エントリ数を増やさなければ高速で、端末側にDNSキャッシュがない場合もDNS rebindingから保護してくれるので有効にしておいたほうがよい。
パケットフィルタに欠かせないFQDNフィルター機能の動作にも必要だ。
24.14 DNS キャッシュを使用するか否かの設定
24.15 DNS キャッシュの最大エントリ数の設定
57.65 DNSキャッシュの表示 -
DHCPオプションと同様に
dns domain .
24.3 DNS ドメイン名の設定 -
dns notice order dhcp me server
はDNSリカーシブサーバのIPv4アドレスip lan1 address
とdns server
コマンドで設定したIPアドレスを通知するが、DNSシンクホールを貫通するためDNSリカーシブサーバのみme
、あるいはDHCPスコープ毎に通知の有無を変えたいなら無効none
。
dns notice order msext
も同様に。L2TP/IPsec VPNに必要だから無効にしない。
dns notice order dhcpv6 me
はipv6 lan1 address
に設定されたGUAを通知するが、ULAをRDNSSで通知する設定をしたためnone
。
24.6 DHCP/DHCPv6/IPCP MS 拡張で DNS サーバーを通知する順序の設定
DNSシンクホール 見出しにジャンプ
顧客のインターネット体験を蔑ろにするトラッカーをDNSレベルで拒否する。
多様な行動データを元に顧客のニーズを中心としたブランド価値を提供し、迅速かつ効果的にユーザー体験をアクセラレーション・ブーストすべきところ、 昨今は数字を追い求めるあまり、視覚を占有し帯域を占有するノイズか、過剰なターゲティングが刺さる一部の属性の生活を蝕むものとなりがちだ。
安全で高速な、oEmbedのような規格が望まれる。
その回避策に、DNSレベルで「予期しない発呼」を防止し、無意味な通信を減らして快適なブラウジングと環境への配慮を実現する「DNSシンクホール」がある。
DNS情報の静的登録 FAQ for YAMAHA RT Series / 予期しない発呼
DNSシンクホールを用いた悪意あるFQDNに対する通信観測システムの運用
有名どころはPi-holeと思う。
pi-hole/pi-hole: A black hole for Internet advertisements
AdguardTeam/AdGuardHome: Network-wide ads & trackers blocking DNS server
しかしDNSプロキシは反復問い合わせしないため、CNAME Cloakingを見破れないから、djbdnsやunboundでフルリゾルバを構築して自宅に置くのが一般的だ。
ゾーン単位でなくワイルドカードや正規表現でルールを書く点もいただけない。
CNAME Cloaking, the dangerous disguise of third-party trackers | by Romain Cointepas | NextDNS | Medium
B向けならFortiGuardがある。PublicなフルリゾルバでいうとCloudflare DNSやOpenDNS、AdGuardなどがよく知られている。
Web Filter Lookup | FortiGuard
1.1.1.1 for Families Set up Cloudflare 1.1.1.1 resolver · Cloudflare 1.1.1.1 docs
Home Internet Security | OpenDNS
パブリックAdGuard DNSサーバーに接続する方法 | AdGuard DNS
iOS14の暗号化DNSサポートと広告ブロック | 280blocker
ヤマハルータのDNSリカーシブサーバもフルリゾルバでないので同様の問題があるが、静的DNSレコードや問い合わせの内容に応じたDNSサーバーの選択を駆使して、高速なDNSシンクホールを実現する。
- FQDN フィルター機能
DNSリカーシブサーバdns cache use on
を利用する機能。あくまでもIPパケットフィルタなので、破棄されるとクライアントがタイムアウトするまで待つことになり、用途に合わない。
ワイルドカードと複数指定が出来るのが特徴。
#
# IP filter configuration
#
ip filter NUM reject-nolog * *.google-analytics.com,doubleclick.net,...
-
内部データベース参照型URLフィルター
URLフィルターはHTTP(TCP)のみの対応で、目的に沿わない。
HTTPリダイレクトするか、TCP RSTを返せる点は特徴的で、connectivitycheckの改ざんに使えるかもしれない。わいわい
#
# LAN configuration
#
url lan2 filter out 1 2 3 4 1000
#
# TUNNEL configuration
#
## TUNNEL 1 ###
tunnel select 1
url tunnel filter out 1 2 3 4 1000
#
# URL filter configuration
#
url filter use on
url filter port 80 8080
url filter reject off
url filter 1 reject http://static.ess.apple.com/connectivity.txt *
url filter 2 reject http://connectivitycheck.gstatic.com/generate_204 *
url filter 3 reject http://proxy-safebrowsing.googleapis.com *
url filter 1000 pass * *
トラッカーの調査 見出しにジャンプ
調査方法 | 説明 |
---|---|
FouAnalytics - Ads By Domain | 普段利用しているウェブサイトが、どれだけトラッカーを芋づる式に読み込んでいるのかを視覚化してくれるサービス。
|
example.com - urlscan.io | 情報セキュリティ関係者御用達?のWebサービス。ドメインを |
Trackers | Better | 有名どころのトラッカーは網羅されている。運営元やトラッカーの種類が集約されている。 |
Web Filter Lookup | FortiGuard | B向けのDNSシンクホールのルールを検索できる |
OpenDNS Community > Domain Tagging | C向けのDNSシンクホールのルールを検索・貢献できる |
Appプライバシーレポート | Apple iOSやiPad OSで使えるアクセスログ機能 |
Firefox DevTools | F12 |
Wireshark · Go Deep. |
キャプチャフィルタ: src port 53 CaptureFilters LANおよびタグVLAN環境で利用可能なポートミラーリング機能を使うと、Wiresharkでパケットキャプチャが可能。本体のDownloadボタンを押したときに 42.15 DOWNLOAD ボタンを押した時に実行する機能の設定 キャプチャ対象ポートを切り替えるLuaスクリプトや rtxconfig/switch-capture-port.lua at main · nyanshiba/rtxconfig ポートミラーリングの有効無効を切り替えるスクリプトを公開している。 rtxconfig/switch-port-mirroring.lua at main · nyanshiba/rtxconfig |
パケットフィルタのsyslog | IPv4の名前解決クエリ内容に限りパケットフィルタで捕まえられる。長期でログをとっておくと、怪しい通信の調査や検索に役立つ。IPv6に非対応な点と、組織で実施する場合は法に触れないよう注意が必要だ。
92573: 2222/02/22 22:22:22: PP[01] IP Commencing: UDP 192.168.100.1:40930 > 1.1.1.1:53 (DNS Query [GooGLe.com] from 36.0.64.81)
|
ドライブと Google サイトのファイアウォールとプロキシの設定 - Google Workspace 管理者 ヘルプ
Appプライバシーレポート 見出しにジャンプ
Inspecting App Activity Data | Apple Developer Documentation
「App のネットワークアクティビティ」には、過去 7 日間のうちに App から直接、あるいは App 内のコンテンツからアクセスされたドメインが表示されます
App プライバシーレポートについて - Apple サポート (日本)
「Appプライバシーレポート」の「最もコンタクトされたドメイン」を眺めながら効率よくDNSシンクホールを煮詰めていこう pic.twitter.com/C2fjqdr7uk
— しばにゃん (@shibanyan_1) December 28, 2021
# /mnt/e/iPhoneで最新のAppプライバシーレポートを取得
$AppPrivacyReport = Get-ChildItem "/mnt/e/iPhone" | Where-Object Name -match "App_Privacy_Report" | Select-Object -Last 1
# ndjsonをjson, PSObjectに変換
$AppPrivacyReportContent = (Get-Content -LiteralPath $AppPrivacyReport) -split "\r?\n" | ForEach-Object -Begin {"["} -End {"]"} {
$_ + ','
} | ConvertFrom-Json
Trackers on Alexa Top 500 News sites (ordered by popularity) | Betterを参考に、名の知れたTrackerを調査。
RTXでDNSシンクホールしている当環境では、FacebookやGoogle Fontsくらいしかヒットしない。
サブドメインは纏められhits
に加算されるため、静的DNSレコード設定には不向き。あくまでも現状確認に使える。
$AppPrivacyReportContent | Where-Object {$_.domain -match "google-analytics|doubleclick|googlesyndication|googleadservices|googletagservices|scorecardresearch|fonts.googleapis|chartbeat|quantserve|chartbeat|facebook|criteo|crwdcntrl|adnxs|platform.twitter|rubiconproject|openx|rlcdn|adsrvr|amazon-adsystem|googletagmanager|adadvisor|moatads|newrelic|casalemedia|krxd|demdex|imrworldwide"} | Sort-Object -Property timeStamp | Sort-Object -Property firstTimeStamp | Format-Table @{expression={"{0:yyyy-MM-ddTHH:mm:ss.fff}" -f $_.firstTimeStamp};label="firstTimeStamp"},context,@{expression={"{0:N0}" -f $_.domain};label="domain";a="right"},contextVerificationType,type,domainType,bundleID,domainOwner,hits -AutoSize
firstTimeStamp context domain contextVerificationType type domainType bundleID domainOwner hits
-------------- ------- ------ ----------------------- ---- ---------- -------- ----------- ----
2040-02-06T01:34:19.096 graph.facebook.com 0 networkActivity 1 com.burbn.instagram Facebook, Inc. 12
2040-02-06T10:37:36.303 gifu-np.co.jp fonts.googleapis.com 2 networkActivity 2 com.twitter.twitter.beta.testflight 1
2040-02-06T14:44:22.057 chunichi.co.jp fonts.googleapis.com 2 networkActivity 2 com.twitter.twitter.beta.testflight 1
2040-02-06T16:54:18.592 ripe.net fonts.googleapis.com 1 networkActivity 2 com.apple.mobilesafari 1
2040-02-06T17:06:17.470 ripe.net fonts.googleapis.com 1 networkActivity 2 com.apple.mobilesafari 1
2040-02-06T17:07:25.784 apnic.net fonts.googleapis.com 1 networkActivity 2 com.apple.mobilesafari 1
2040-02-06T19:06:11.850 gizmodo.jp fonts.googleapis.com 2 networkActivity 2 com.google.GoogleDigitalEditions 2
レポートにあるAppのBundle ID一覧
iPhoneおよびiPadのネイティブAppのバンドルID - Apple サポート (日本)
$AppPrivacyReportContent.bundleID | Get-Unique
Twitter for iPhoneのレポートに絞り込む。
アプリ内ブラウザのトラヒックを覗くと、TLの広告にPrefetch掛けているのが分かる。
$AppPrivacyReportContent | Where-Object {$_.domain -And $_.bundleID -eq 'com.atebits.Tweetie2'} | Sort-Object -Property timeStamp | Sort-Object -Property firstTimeStamp | Format-Table @{expression={"{0:yyyy-MM-ddTHH:mm:ss.fff}" -f $_.firstTimeStamp};label="firstTimeStamp"},context,@{expression={"{0:N0}" -f $_.domain};label="domain";a="right"},contextVerificationType,type,domainType,bundleID,domainOwner,hits -AutoSize
$AppPrivacyReportContent | Where-Object {$_.bundleId -match "com.ss.iphone.ugc.Ame"} | Sort-Object -Property timeStamp | Sort-Object -Property firstTimeStamp | Format-Table @{expression={"{0:yyyy-MM-ddTHH:mm:ss.fff}" -f $_.firstTimeStamp};label="firstTimeStamp"},context,@{expression={"{0:N0}" -f $_.domain};label="domain";a="right"},contextVerificationType,type,domainType,bundleID,domainOwner,hits -AutoSize | code -
Firefox DevTools 見出しにジャンプ
なぜかこの界隈で圧倒的なシェアを誇るWeb標準ブラウザ「Firefox」は、独自のブラックリストやShimを持つことでプライバシー重視かつ高速に動作し、DevToolsの使い勝手もよい。
AndroidならADBで繋がっていればFenixをリモートデバッグできる。
about:debugging — Firefox Source Docs documentation
iPhoneはレスポンシブデザインビューでUser-Agentを偽装できる。モバイルだけ読み込まれるトラッカーの調査は十分可能だ。
All keyboard shortcuts — Firefox Source Docs documentation
- 膨大なトラッカーを読み込む怪しいドメインを右クリックし、"URLをブロック"して動作をみていく。
- 動作に問題なければ静的DNSレコードに設定する。
Tracking や Socialtracking となっている既知のトラッカーも、他のブラウザではブロックされないため同様に。
- 元のRRのTTLを
浸透待ちしたくないとき、DNSキャッシュを削除する- RTXのDNSリカーシブサーバ:
clear dns cache
55.4.11 DNS キャッシュのクリア - iOS, Android: 端末の再起動
- Windows:
ipconfig /flushdns
- Firefox:
about:networking#dns
-> DNSキャッシュを削除 - Chromium Edge:
edge://net-internals/#dns
-> Clear host cache
- RTXのDNSリカーシブサーバ:
- セキュアでない接続を示す はDNSシンクホールの成果かもしれないし、単にスキームがhttpかもしれない。
"URLで絞り込み"で初期化initiator:
が何のスクリプトで行われたかソートできる。PageXray by FouAnalyticsで芋づる式に読み込んでいるのが分かるように、逆に最小限のルールでブロックできてしまう事がわかる。これには欧州が巻き起こした一台ブーム「Cookieバナー」も含まれる。
GDPRの何がダメってスマホが短くなることよな https://t.co/ZcbqPEhwOq
— しばにゃん (@shibanyan_1) February 1, 2022
⚙ -> HAR形式ですべてコピー/保存 を使うと、一括処理しやすい。
($buzz.log.entries.request | Where-Object bodySize -eq 0) | Select-Object {$_.headers.value[0]} -Unique
静的DNSレコード 見出しにジャンプ
静的DNSレコードを設定すると、そのFQDN(完全一致)の該当するタイプの問い合わせにRTX自ら応答し、dns server select
やdns server
に問い合わせされない。
Answer セクションに回答となる DNS レコードが 1 つセットされるだけで、Authority/Additional セクションには DNS レコードがセットされない
24.11 静的 DNS レコードの登録
想定された用途はプライベートIPアドレスにネームを付けることと思うが、他にもDNSシンクホールという面白い使い道がある。
この項では主にDNSシンクホール用途を例に解説する。ブロックすべきドメインの調べ方はDNSシンクホール以下を見てほしい。
静的DNSレコードには二通りの指定方法がある。ip host
はAとPTRレコードを同時に設定する機能があるが、AAAAレコード(IPv6)に対応しないため、dns static
で設定する。
因みに、UNIVERGE IXではコマンドリファレンスの25. DNS 編にあるdns host
がRTXのdns static
に近そうで、A/AAAAレコードを設定できる。しかし、HTTPS RRを扱う必要があるためiOS 14/macOS 11対応はできそうにない。
IX2000/IX3000 シリーズ コマンドリファレンス マニュアル : UNIVERGE IXシリーズ | NEC
静的DNSレコードでIPv4は0.0.0.0
, IPv6は::
を指定すると、名前解決を失敗させ、タイムアウトなく安全に通信をブロックできる。
これはCloudflareやAdGuard DNSと同じブロック手法だ。こちらのTTLは3600秒(1時間)。
Set up Cloudflare 1.1.1.1 resolver · Cloudflare 1.1.1.1 docs
Bogonに127.0.0.2
を返すDNSシンクホールも存在する。
Bogon Reference: via DNS | Team Cymru
dns static
はTTLを指定しなければ1秒だが、これではOSのスタブリゾルバやブラウザのDNSキャッシュに残らず若干のパフォーマンスの低下を招くので、86400秒(1日)とする。
誤った設定が浸透してしまうと、RTXのDNSキャッシュは下記コマンドで削除できるが、
55.4.11 DNS キャッシュのクリア
clear dns cache
クライアント側のDNSキャッシュを削除して回る羽目になるので、こなれていないうちはttl=1
やttl=60
から始めるとよいだろう。
DNS rebinding対策で、OSのスタブリゾルバやブラウザがTTLを下限60秒としている場合が多いため、直ちに浸透することを期待しないほうがよい。
「DNSの浸透」とアプリケーションのキャッシュ:Geekなぺーじ
lua dns-static-helper.lua example.com nyanshiba.com
dns static a example.com 0.0.0.0 ttl=86400
dns static aaaa example.com :: ttl=86406
dns static a nyanshiba.com 0.0.0.0 ttl=86400
dns static aaaa nyanshiba.com :: ttl=86400
私のconfigには静的DNSレコードが3000件ほどあるが、動作に支障はない。
一つずつ設定するのは骨が折れるので、ヘルパースクリプトを書いている。TTLの末尾が変則的なのは、シングルスタックかデュアルスタックかを明示するためだ。
ping4.lua Luaスクリプトの基礎
string.split() Lua言語のライブラリ関数
rtxconfig/dns-static-helper.lua at main · nyanshiba/rtxconfig
サブディレクトリを提供する短縮URLサービスを拒否するときは、静的DNSレコードを使う。サブドメインを提供するDDNSはdns server select
を使う。
urlscan.io cutt.ly - Twitter検索 / Twitter
@dnss cutt.ly 1
dns static a cutt.ly 0.0.0.0 ttl=1
dns static aaaa cutt.ly :: ttl=1
微々たる差と思うが、RTXの負荷を上げないためにコンパイルするとよい
環境変数PWD Lua スクリプト機能
46.3 Lua コンパイラの実行
git clone rtxconfig -o upstream
cd rtxconfig/lua
../put-lua.sh dns-static-helper.lua
set PWD=sd1:/lua luac -o dns-static-helper.luac -s dns-static-helper.lua
エイリアスを設定しておくと、楽に叩ける
コンソール:変数、エイリアス、マクロ、ヒストリー
alias dnss="lua dns-static-helper.luac"
静的DNSレコードではトラッキングやフィッシングを拒否するだけでなく、余計な外部リソースを減らしてロード時間を減らしたり、ペイウォールを回避したり、インターネットに向けたNTPクエリをローカルに向けることが可能だ。
-
dns staticにはcname/nsが指定できるから、それを使ったら一括設定できるのでは?CNAME Cloakingも見破れるのでは?
-> 端末からの問い合わせがあるのは通常HTTPS/AAAA/Aレコードで、DNSリカーシブサーバはそれをプロキシ・キャッシュするだけで反復問い合わせを行わないため、CNAMEの問い合わせがRTXから行われることはない。そのため、DNSシンクホール用途でdns static cname/nsを指定する意義はない。 -
AppleのDoH
https://doh.dns.apple.com/dns-query
や(未契約の)iCloud Private Relaymask.icloud.com
がDNSシンクホールに穴をあけることはない。
Enable encrypted DNS - WWDC20 - Videos - Apple Developer
挙動を見ると、静的DNSレコードでブロックすべきではなさそうだ。NOERROR NOANSWERを返す必要がある。
iCloud Private Relayに向けたネットワークやWebサーバの準備 - サポート - Apple Developer
自動CDNガチャ 見出しにジャンプ
IP AnycastやClient Subnetが効くように設定しても、サービス側が対応していなければ意味がない。
> Akamai support ECS only for the some resolvers like Google's 8.8.8.8 and OpenDNS
— しばにゃん (@shibanyan_1) September 28, 2022
えぇ…
確かにTwitterはAnycastもECSも対応していない場合が多くて、そりゃCDNガチャの効果あるわけだなという感想https://t.co/nbVriNxVwx
RTTを計測して、最も結果が良かったIPアドレスを静的に設定することで、輻輳気味のときでもTLを途切れなくスクロールできるようにする。
IPv4 over IPv6やNTEガチャの方が効果は高い。名前解決を改ざんして静的に向けることのリスクや、理想的に動作したときに限り効果が見込めることを理解した上で試してみよう。
rtxconfig/twitter-cdn-gacha.lua at main · nyanshiba/rtxconfig
クエリ内容でDNSサーバを変える 見出しにジャンプ
24.10 DNS 問い合わせの内容に応じた DNS サーバーの選択
複数プロバイダ同時接続機能のための追加コマンド
自宅とオフィスで使う(2)
静的DNSレコードはワイルドカード指定できない(そういう目的のコマンドではない)。
ゾーンがサービス毎やセッション毎に生えてくるような、サブドメインが推測できないサービスは個別に書く必要性が出てくる。
タイムアウトするような誤った設定がなければ、パフォーマンスの影響は少ないものの、あらゆる名前解決のオーバーヘッドになるため、推測可能なら静的DNSレコードで済ませるべき。
dns server select 1 2a10:50c0::ad1:ff edns=off any .videoplayerhub.com
dns server select 2 2a10:50c0::ad2:ff edns=off any .openx.net
dns server select 3 2a10:50c0::ad1:ff edns=off any .permutive.app
dns server select 4 2a10:50c0::ad2:ff edns=off any footprintdns.com
dns server select 5 208.67.220.220 edns=off any disqus.com
dns server select 6 208.67.222.123 edns=off any .qualtrics.com
dns server select 7 reject any *.px-cloud.net
ヤマハの解説では要領を得ないと思うが、a/aaaa/anyは後方一致。*
はサブドメインを一括指定するワイルドカードにはならず、ワイルドカードリソースレコードのクエリを任意のDNSサーバに向けることになる。
RFC 4592: The Role of Wildcards in the Domain Name System
一方rejectのときは完全一致のため、前方/後方一致にはワイルドカードが必須だ。
実際に機能しているか、dns server select NUM 0.0.0.0
などでタイムアウトさせて確認するべき。
AdGuardはAの問い合わせに0.0.0.0を返すが、OpenDNSはAに146.112.61.0/24を返す。いずれもHTTPS RRにはNOERROR NOANSWERを返す。
What are the Cisco Umbrella Block Page IP Addresses? – Cisco Umbrella
フィッシングに使われるDDNSを一括拒否 見出しにジャンプ
無料DDNSサービスは便利な一方、悲しいことにフィッシングに使われがちなのでブロックする。
On the trail of malicious dynamic DNS domains - Cisco Umbrella
サブドメインを提供するDDNSはdns server select
、FQDN固定で、サブディレクトリを提供する短縮URLサービスには静的DNSレコードdns static
を使う。
dns server select 8 reject any *.ddns.net dns server select 9 reject any *dns.org
良性のDDNSはこれより若番に許可ルールを書くか、固定IPなら静的DNSレコードを書いてしまうのも手だ。
某プライバシー企業の広告に鼻〇そを飛ばす映像(閲覧注意)
EDNS0とClient Subnet 見出しにジャンプ
TwitterのTLをスクロールする際、画像が抜けてしまう現象がないだろうか。
EDNS Client Subnet(ECS)が使えると、最適なCDNが選択され快適なTwitterライフが送れるかもしれない。
any
でHTTPS RRを許可し、ECSに対応しているFQDNならPublic DNSを使う。
Why test only with Google's resolver??Non-Anycast CDNs may be hesitant to support ECS because it increases the load on their DNS servers, so some CDNs like Akamai support ECS only for the some resolvers like Google's 8.8.8.8 and OpenDNS because these resolvers are used by so many users. EDNS Client Subnet Checker - CDN Planet
GoogleのサービスがIP Anycastを使用する一方、Facebook, TwitterやAppleが利用する一部のCDN(の権威DNS)はECSに対応しているようなので、ECSに対応していると思しきOpenDNSにEDNS0で問い合わせる。
Google Public DNSでなくOpenDNSを選ぶのは7割方クエリ時間で、OpenDNSを一部にしか使わないのはクエリ時間とプライバシーが半々だ。
# dns server select 9 reject any *.px-cloud.net
# no dns server select 10
dns server select 11 2620:119:53::53 edns=on any .aaplimg.com
dns server select 12 2620:119:35::35 edns=on any .apple-dns.net
dns server select 13 2620:0:ccc::2 edns=on any icloud.com
dns server select 14 2620:119:53::53 edns=on any .apple
dns server select 15 2620:119:35::35 edns=on any abs.twimg.com
dns server select 16 208.67.222.123 edns=on a .albtls.t.co
dns server select 17 2620:119:35::35 edns=on any r.facebook.com
dns server select 18 2620:0:ccd::2 edns=on any instagram.com
dns server select 19 2620:0:ccd::2 edns=on any ton.twimg.com
# dns server select 20 2404:1a8:7f01:a::3 edns=on aaaa .
# dns server select 21 1.1.1.1 edns=on a . restrict pp 1
因みにdig +subnet
は当てにならないので注意が必要だ。
Question
Does Google DNS/OpenDNS support +subnet parameter of dig command?Answer
No, they only refer to real client IP of UDP packet for DNS query.
If you want to test for a certain geo-mapping(for example, Korea in this scenario), you should do it on the location.
Again, Google DNS/OpenDNS doesn't refer to +subnet=1.1.1.1 but a real client IP, and +subnet=1.1.1.1 parameter is ignored from command below.
Does Google DNS/OpenDNS support +subnet parameter of dig command?
RTXのDNSリカーシブサーバはedns=on
でもTCPフォールバックしない。
DNSリカーシブサーバって何ですか? FAQ for YAMAHA RT Series / TCP/IP
dig google.com txt
;; Truncated, retrying in TCP mode.
../../../lib/isc/netmgr/tcpdns.c:315: fatal error: RUNTIME_CHECK(result == ISC_R_SUCCESS) failed
Aborted (core dumped)
つまり、DNSリカーシブサーバを使う限りパケットフィルタに53/tcpを通す設定は不要だ。
iOS 14/macOS 11対応 見出しにジャンプ
RTXのDNSリカーシブサーバでDNSシンクホールを実現するとき、静的DNSレコードでA/AAAAレコードを0.0.0.0
, ::
に改変しても、Appleデバイスでブロック漏れが発生してしまう。
表面的な挙動は、初回アクセスではブロックされたものの、リロードやページ遷移でブロック漏れが見える、あるいは読み込み時間が体感大きくなる、といったものだ。iOS 15.2以降で使えるAppプライバシーレポートで容易に確認できる。
- 原因の一つは、HTTPS RR(Type65)の
ipv4hint
,ipv6hint
による投機的な接続。
summerday2021-https-rr - 11-yamaguchi.pdf
正確に言えば、DNS over HTTPS(DoH)でない非暗号化DNSにもHTTPS RRを問い合わせる、Appleのスタブリゾルバ実装。
draft-ietf-dnsop-svcb-https-11 - Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)
“HTTPSレコード”って知ってる?今知るべき4つの注意点 | IIJ Engineers Blog
その実装自体は問題なく、今後Appleデバイスに限らず増える可能性すらあるので対応が必要だ。
draft-ietf-tls-esni-15 - TLS Encrypted Client Hello
1500289 - Please allow regular ESNI (without DoH)
サイトの HTTP3 化と DNS HTTPS RR および Alt-Svc Header によるアドバタイズ | blog.jxck.io
しかしDNSリカーシブサーバはHTTPS RRのクエリをプロキシし、(恐らくそのまま)キャッシュする一方で、dns static
に設定できるクエリタイプにHTTPS RRはない。RTXではHTTPS RRを扱えない。
Fastlane対応を見るにAppleと蜜月の仲と思われる[要出典]Ciscoは、UmbrellaをバイパスするApple実装を回避するため、OpenDNSはHTTPS RRのクエリに対しNOERROR NOANSWERを返答する。
As such designations would result in queries bypassing Umbrella, the Umbrella resolvers return a REFUSED response for queries for the HTTPS DNS record type, meaning that such designations would not be discovered.
DNS Resolver Selection in iOS 14 and macOS 11 – OpenDNS
DNS Resolver Selection in iOS 14 and macOS 11 – Cisco Umbrella
一部の企業や学校のネットワークでは、その方針によりすべてのネットワークトラフィックの監査を行うことが求められる場合があります
ネットワークのDNSリゾルバから「no error no answer」応答またはNXDOMAIN応答のいずれかを返し、Private Relayトラフィックで使用される以下のホスト名のDNS解決を回避することです。DNS解決のタイムアウトを発生させたり、Private Relayサーバに送信されたIPパケットを通知なくドロップしたりすることは避けてください。クライアントのデバイスでの遅延につながる可能性があります。
iCloud Private Relayに向けたネットワークやWebサーバの準備 - サポート - Apple Developer
つまりOpenDNSを利用すれば、HTTPS RRを安全にブロックし、RTXでDNSシンクホールを実現できるという寸法だ。
dns server select NUM 208.67.220.123 edns=off any nyanshiba.com
dig www.nyanshiba.com type65
; <<>> DiG 9.18.7 <<>> www.nyanshiba.com type65
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40028
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.nyanshiba.com. IN HTTPS
- もう一つの原因は、CNAMEを再問い合わせするAppleのスタブリゾルバ実装。
HTTPS RRが設定されていないサービス、ほぼ自動的にHTTPS RRに対応するCloudflare CDNを利用するサービスを除いてもブロック漏れが発生する。
Speeding up HTTPS and HTTP/3 negotiation with... DNS | The Cloudflare Blog
Good-bye ESNI, hello ECH!
Apple iOSのスタブリゾルバはRFC 2181に倣って、CNAMEに付随するAAAA/Aレコードを再問い合わせする。ここでのClientはキャッシュDNS(フルリゾルバ)を指すと思うが、Appleはそれに近い実装を取り入れているようだ。
浸透いうな先生にRFC 2181を教えて頂いて、信頼次第でCNAMEを再検索する概念を知る
— しばにゃん (@shibanyan_1) May 17, 2022
> Clients should assume that other recordsmay have come from the server's cache. ~authoritative answers are required, ~should query again, using the cnamehttps://t.co/c9aaORfrKPhttps://t.co/G2J3u17dSA
RFC 2181: Clarifications to the DNS Specification
kDNSServiceFlagsReturnIntermediates | Apple Developer Documentation
つまり、dns static a
が設定されたFQDNのCNAMEの再問い合わせを防止するためには、AAAA/HTTPS RRを持たないFQDNもブロックする必要がある。
AAAAレコードはこのヘルパースクリプトのように、Apex(CNAMEが不可)を除き常にdns static aaaa
を設定する。
HTTPS RRは以下のようにOpenDNSへHTTPS RRをフォールバックさせることで対応する。
正直契約しているISPのキャッシュDNSの実装に問題があるなど特段の理由がなければ、キャッシュポイズニングのリスクが大きいPublic DNSを初めとするオープンリゾルバを利用すべきでないのだが、HTTPS RRの否定応答を返してもらうだけの用途なので全てのクエリタイプを流すよりはマシと認識している。
# プライマリ 多分ECS非対応なので、IP Anycast
dns server select 20 2404:1a8:7f01:a::3 edns=on aaaa .
dns server select 21 1.1.1.1 edns=on a . restrict pp 1
# フォールバック
dns server select 32 1.1.1.1 edns=on a . restrict pp 2
dns server select 33 dhcp lan2 edns=on a .
dns server select 35 dhcp lan2 edns=on mx .
dns server select 36 dhcp lan2 edns=on ns .
# OpenDNSへHTTPS RRをフォールバック
dns server 208.67.220.123 edns=off
no dns server pp
no dns server dhcp
通常restrict pp
節は、dns server select pp
と組み合わせて使うことで、PPPoEセッション切断時のフォールバックが機能する。
Cloudflare DNS1.1.1.1
が指定されているのは、dns server select 20 dhcp lan2
でないのも同じく、ICMPやクエリ時間を監視して、最速のDNSサーバに切り替えるLuaスクリプトを前提としているからだ。
この影響で、5chのAdGuardスレでもCDNのFQDNが挙げられるなど混乱が見られる。
再問い合わせされるCDNのFQDNをdns static
に追加で設定すれば一応ブロックされるが、configが肥大するだけでなく、良性のドメインを巻き込んでしまうためオススメできない。
- CNAMEの再検索は悪いことだけではない。
DNSプロキシはCNAME Cloakingを見破れないと説明したが、逆に言えば一部反復問い合わせするAppleデバイスはCNAME Cloakingを見破れるということだ。
初回アクセスは、通常の問い合わせの応答で投機的に?接続してしまうから完全なブロックはできないが。
a8.net|eloqua|criteo|fathom|salesforceliveagent|salesforceiq|2o7|omtrdc|acton
- dns server select 30 208.67.220.220 edns=off any .omtrdc.net
- dns server select 31 208.67.220.220 edns=off any .2o7.net
+ dns server select 32 2a10:50c0::ad1:ff edns=off any .at-o.net
+ dns server select 33 reject any *.salesforceliveagent.com
CNAMEクローキング: DNSを使ったサードパーティCookieの隠蔽
cname-trackers/combined_disguised_trackers_rpz.txt at master · AdguardTeam/cname-trackers
easylist/easyprivacy_specific_cname.txt at master · easylist/easylist
-
Apple iOSのスタブリゾルバは非常に高速だが、CNAMEを多用するサービスで初回アクセスのオーバーヘッドをユーザ側で減らすには、DNSシンクホールやECS, クエリ時間に基づくDNSサーバ選択など高速なDNS設定が有効といえる。また、Androidに比べかなりバーストするので、DNS RRLも考慮したい。
RTXのDNSキャッシュを無効化、つまりDNSリカーシブサーバを使わない設定は、Appleデバイスのある環境ではお勧めしない。 -
Happy Eyeballsで遅延は誤差レベルになっているとはいえ、デュアルスタック環境ではAのクエリはAAAAの50msも後に問い合わせなければならず、Appleデバイスでは更に先立ってHTTPS RRが要求される凄惨な状況だ。そんな中、運が良ければフォールバックなく1回のHTTPS RRクエリで投機的に接続できる
ipv4hint
,ipv6hint
を破棄してしまうのは勿体ない。
dig crypto.cloudflare.com type65 +short
1 . alpn="http/1.1,h2" ipv4hint=162.159.137.85,162.159.138.85 ech=AEb+DQBC4wAgACAz7DBuIBh4jFwrS02jCruHYjFcr3McVdCL4ONaBVjgQgAEAAEAAQATY2xvdWRmbGFyZS1lc25pLmNvbQAA ipv6hint=2606:4700:7::a29f:8955,2606:4700:7::a29f:8a55
Happy Eyeballs Version 2 (RFC 8305):Geekなぺーじ
iOS Developer Library : ネットワーク処理において犯しがちな誤りの回避 Avoiding Common Networking Mistakes
そこで、dns server
のOpenDNSにフォールバックする前に、既知のHTTPS RRを持つドメインをdns server select
でany
許可することで、レイテンシ向上を図る。現状その殆どがCloudflare、あっても一部のビッグテックだが。
# ECS対応も兼ねる
dns server select 17 2620:119:35::35 edns=on any r.facebook.com
dns server select 18 2620:0:ccd::2 edns=on any instagram.com
# dns server select 19 2620:0:ccd::2 edns=on any ton.twimg.com
# AAAA/AはNGN・ISPのキャッシュDNSに問い合わせる
# dns server select 20 2404:1a8:7f01:a::3 edns=on aaaa .
# dns server select 21 1.1.1.1 edns=on a . restrict pp 1
# HTTPS RRを許可する
dns server select 22 1.1.1.1 edns=on any itunes.apple.com restrict pp 1
dns server select 23 1.1.1.1 edns=on any www.google.com restrict pp 1
dns server select 24 1.1.1.1 edns=on any www.google.co.jp restrict pp 1
dns server select 25 1.1.1.1 edns=on any discord.gg restrict pp 1
dns server select 26 1.1.1.1 edns=on any discordapp.net restrict pp 1
dns server select 27 1.1.1.1 edns=on any .cloudflare.com restrict pp 1
dns server select 28 1.1.1.1 edns=on any .jsdelivr.net restrict pp 1
dns server select 29 1.1.1.1 edns=on any .fontawesome.com restrict pp 1
# dns server select 30 1.1.1.1 edns=on a . restrict pp 2
# dns server select 31 dhcp lan2 edns=on a .
# OpenDNSでHTTPS RRをブロック
# dns server 208.67.220.123 edns=off
EDNS0とClient Subnetを目的としたdns server select
のany
指定は、IPv6が優先される(ことを期待する)デュアルスタック環境でa/aaaaそれぞれ指定する意味が薄いからだ。
一方、これらはHTTPS RRを含める意味のany
指定だ。
ホストによって参照するDNSサーバを変える 見出しにジャンプ
original-sender
[設定値] : DNS 問い合わせの送信元の IP アドレスの範囲
24.10 DNS 問い合わせの内容に応じた DNS サーバーの選択
の指定方法が要領を得ないので、メモ
dns server select 21 1.1.1.1 edns=on a . 192.168.100.0-192.168.100.63 restrict pp 1
dns server select 22 1.1.1.2 edns=on 1.0.0.2 edns=on a . 192.168.100.64-192.168.103.254
_dns.resolver.arpa 見出しにジャンプ
iOS 16のスタブリゾルバがDoT/DoHリゾルバ情報の自動設定を見据えたdraft-ietf-add-ddrに対応した。
Improve DNS security for apps and servers - WWDC22 - Videos - Apple Developer
draft-ietf-add-ddr-10 - Discovery of Designated Resolvers
DNSとドメイン名に関連した標準化の動向(IETF) (続)DNSプロトコルの進化 2021 - c2-fujiwara-2-2.pdf
しかし非暗号化DNSを扱うDNSシンクホールの趣旨から逸れるため、直ちに利用される訳ではなさそうだが、逆引きがPublic DNSに漏れる点も含めてよろしくないので.arpa
ごとNGNのDNSに向けている。
.ARPA Domain
24.7 プライベートアドレスに対する問い合わせを処理するか否かの設定
dns server select 34 dhcp lan2 edns=off any .arpa
dns private address spoof on
Luaで最速のDNSサーバに切り替える 見出しにジャンプ
dns server
やdns server select
にDNSサーバを複数指定したとき、代替DNSサーバが使われることは滅多にない。
アクセス集中だけでなく、DNS RRL(Response Rate Limiting)も考慮すると、代替DNSサーバの応答速度が優先DNSサーバと同等かそれ以上に高速な状況が推測できる。
技術解説:「DNS Reflector Attacks(DNSリフレクター攻撃)」について
オープンリゾルバ(Open Resolver)に対する注意喚起 - JPNIC
かといって代替DNSサーバに固定するわけにもいかず。
PPPoEから降ってくるISPのDNSは接続先によって変わるため、dns server pp
のような用意された構文を使わざるを得ないし、
Public DNSなら更に複数のDNSサーバが用意されており、それぞれのパフォーマンスが微妙に偏っていて、かつ変動する場合がある。
そこで、優先/代替DNSサーバをランダムに入れ替えたり、最適なDNSサーバをRTTまたはクエリ時間で決定するLuaスクリプトを公開した。
ランダム
math.randomseed(os.time())
r = math.random(4)
tbl = {
'208.67.222.222',
'2620:119:35::35',
'208.67.222.222',
'2620:119:53::53'
}
rt.command($'dns server ${tbl[r]}')
Public DNSはICMPでRTTを計測して評価する
rtxconfig/public-dns-gacha.lua at main · nyanshiba/rtxconfig
-- (ICMP Echo Replyが返ってくる)DNSサーバのリスト
tbl = {
-- OpenDNS
-- https://en.wikipedia.org/wiki/OpenDNS#DNS
'208.67.222.222',
'208.67.220.220',
'208.67.222.123',
'208.67.220.123',
'208.67.222.2',
'208.67.220.2',
'2620:119:35::35',
'2620:119:53::53',
'2620:119:35::123',
'2620:119:53::123',
'2620:0:ccc::2',
'2620:0:ccd::2'
}
ISPやNGNのDNSなど、Echo Replyが帰ってこないDNSサーバはクエリ時間で評価する
rtxconfig/hidden-dns-gacha.lua at main · nyanshiba/rtxconfig
show status pp 1
PP[01]:
~~
IPCP Local: IP-Address Primary-DNS(198.51.100.128) Secondary-DNS(203.0.113.153), Remote: IP-Address
~~
show status pp 2
PP[02]:
~~
IPCP Local: IP-Address Primary-DNS(192.0.2.37) Secondary-DNS(203.0.113.71), Remote: IP-Address
~~
上記のような環境でhidden-dns-gacha.luaを実行すると、下記のような逆NATのconfigが生成される。
#
# PP configuration
#
### PP 1 ###
pp select 1
ip pp nat descriptor 1000 reverse 1002
### PP 2 ###
pp select 2
ip pp nat descriptor 2000 reverse 2002
#
# NAT Descriptor configuration
#
nat descriptor type 1002 nat
nat descriptor timer 1002 protocol=udp port=domain 30
nat descriptor address outer 1002 0.0.0.0
nat descriptor address inner 1002 0.0.0.0
nat descriptor static 1002 1 1.1.1.1=198.51.100.128 1
nat descriptor static 1002 2 198.51.100.128=1.1.1.1 1
# 同上
nat descriptor static 2002 1 1.1.1.1=203.0.113.71 1
nat descriptor static 2002 2 203.0.113.71=1.1.1.1 1
#
# DNS configuration
#
dns server select 20 2404:1a8:7f01:a::3 edns=on aaaa .
dns server select 21 1.1.1.1 edns=on a . restrict pp 1
逆NAT, 逆IPマスカレード…とは? FAQ for YAMAHA RT Series / NAT&IP Masquerade
23.2 インタフェースへの NAT ディスクリプタ適用の設定
config例が1.1.1.1になっているのは、逆NATのフォールバック先をBogonでなく実際のDNSサーバにしておいた方がタイムアウトせず、パケットフィルタに手を加えずに済むからだ。利用しているISPのDNSがECSに対応していない[要出典]のも、Cloudflare DNSがIP Anycastを使う点になぞらえている。
グローバルIPアドレスをプライベート用途に使うCiscoに倣っている訳ではない……と思う。お行儀が悪くてすまぬ。
WLC仮想IPアドレス1.1.1.1 - Cisco
RTTの集計は、数分間時間をかけてIPv4で測定し、集計は算術平均や中央値は使わず、最大値や99パーセンタイルを使ってほしい。それこそが電話アプリの開発者が気にするところだから。
— 音風景の管理人 (@kamedo2) August 23, 2022
QoS 見出しにジャンプ
DNS(53/udp)の名前解決があって初めて3-way handshake(SYN, SYN/ACK, ACK)が始まり、通信を開始できる。Outboundのパケット優先度は快適なインターネットライフに欠かせない。
FAQ for YAMAHA RT Series / Queue (QoS機能)
優先制御のふるまい
制御できるのは出力トラフィックだけです。 入力トラフィックを制御することはできません
帯域制御のふるまい
帯域制御 見出しにジャンプ
Dynamic Traffic Control 見出しにジャンプ
優先順位の高いパケットが多くなると優先順位の低いパケットは 大きな遅延が発生したり送信されないことがあります
FAQ for YAMAHA RT Series / Queue
FIFOや盲目的な優先制御では、パケットバッファにパケットが溜まりRTTが増加してしまう。これをBufferbloatと呼ぶ。
Bufferbloat and Internet Speed Test - Waveform
しかしRTX、少なくとも階層型QoSや帯域制御キューイングCBQ(queue interface class property
のmaxburst/minburst/packetsize
)に対応していないRTX830は、EdgerouterやMikrotik, OpenWrtのようにSQM(Smart Queue Management)やfq_codel同等の動作を実現できない。
階層型QoS
26.10 クラスの属性の設定
26.3 キューイングアルゴリズムタイプの選択
これでは特にWAN側が詰まりがちなVDSL環境では、QoEが著しく低下してしまう。
Using RIPE Atlas to Predict Users' Quality of Experience | RIPE Labs
そこで、SQMにできる限り近いQoSを実現するために、帯域制御「Dynamic Traffic Control」を採用した。
Dynamic Traffic Controlでは、リアルタイム性が重視されるデータやロスを最小限 に抑えたいデータを帯域が大きく変動するデータから守りつつ、インタフェース の帯域を有効活用する
Dynamic Traffic Control
#
# LAN configuration
#
speed lan2 100m
queue lan2 type shaping shaping-level=1
queue lan2 default class 2
queue lan2 length 200
- 帯域制御を選択。Dynamic Traffic Controlは帯域制御に毛が生えたようなもので、ほどよい優先制御的な性質を持つ。
26.3 キューイングアルゴリズムタイプの選択 - VDSL配線方式の当環境では、モデム交換とNTEガチャを行った結果、実測100Mbpsの上り帯域がある(fast.comはアテにならないよ!)。
フレッツ 光ネクスト マンション・ハイスピードタイプ/マンションタイプ(集合住宅向け) | フレッツ 光ネクスト | フレッツ光公式 | NTT東日本
このとき、95%の95m
にすると良いらしいが、パケットバッファが溢れてしまうのと、少しでも帯域が惜しいので100m
としている。
Set Upload and Download to a value a value 95% of the speeds you measured.
Setting QoS If You Can't Use CoDel - Bufferbloat.net
VDSLはいずれにせよ100BASE-TX
だからよいが、1G契約で数百Mbps出る場合は、1000m
でなく常に出せる帯域に設定しないとパケットが並ばずに送出されてしまうため意味がない。
Dynamic Traffic Control : コマンド設定
26.1 インタフェース速度の設定
クラス分け 見出しにジャンプ
パケット優先度・種類別にクラス分けする。優先制御ではクラス(パケット優先度, IP Precedence +1)単位で並び替えられ、帯域制御では同じ帯域・パケットバッファに押し込まれる運命共同体になる。
26.2 クラス分けのためのフィルター設定
対応インタフェース FAQ for YAMAHA RT Series / Queue
config | 説明 |
---|---|
#
# LAN configuration
#
speed lan2 100m
queue lan2 type shaping shaping-level=1
queue lan2 default class 2
+ queue lan2 class filter list 6 4
queue lan2 length 200
+ queue lan2 class property 8 bandwidth=1m,100m
#
# Queueing configuration
#
queue class filter 4 8 ip * * udp,icmp * ntp
queue class filter 6 8 ipv6 * * udp,icmp6 * ntp
|
|
#
# LAN configuration
#
- queue lan2 class filter list 6 4
+ queue lan2 class filter list 14 6 4
queue lan2 length 200
+ queue lan2 class property 7 bandwidth=5m,100m
#
# Queueing configuration
#
+ queue class filter 14 7 ip * * udp 32768-65535 50000-50100
|
|
#
# LAN configuration
#
- queue lan2 class filter list 14 6 4
+ queue lan2 class filter list 26 24 14 6 4
queue lan2 length 200
+ queue lan2 class property 7 bandwidth=5m,100m
#
# Queueing configuration
#
+ queue class filter 24 7 ip * * tcpsyn
+ queue class filter 26 7 ipv6 * * tcpsyn
|
|
#
# LAN configuration
#
- queue lan2 class filter list 26 24 14 6 4
+ queue lan2 class filter list 26 24 14 34 6 4
queue lan2 length 200
queue lan2 class property 7 bandwidth=5m,100m
#
# Queueing configuration
#
+ queue class filter 34 7 ip * * tcpflag=0x0018/0x00ff * 25565
+ queue class filter 36 7 ipv6 * * tcpflag=0x0018/0x00ff * 25565
|
|
#
# LAN configuration
#
- queue lan2 class filter list 26 24 14 34 6 4
+ queue lan2 class filter list 44 26 24 14 34 6 4
queue lan2 length 200
+ queue lan2 class property 6 bandwidth=85m,100m
#
# Queueing configuration
#
+ queue class filter 44 6 ip * * udp * 500,4500
|
|
#
# LAN configuration
#
- queue lan2 class filter list 44 26 24 14 34 6 4
+ queue lan2 class filter list 44 26 24 14 46 34 6 4
queue lan2 length 200
+ queue lan2 class property 6 bandwidth=85m,100m
#
# Queueing configuration
#
+ queue class filter 46 6 ipv6 ra-prefix@lan2::/64 a.upload.youtube.com tcpflag=0x0010/0x0017 * https
|
|
#
# LAN configuration
#
- queue lan2 class filter list 44 26 24 14 46 34 6 4
+ queue lan2 class filter list 44 56 54 26 24 14 46 34 6 4
queue lan2 length 200
+ queue lan2 class property 5 bandwidth=2m,100m
#
# Queueing configuration
#
+ queue class filter 54 5 ip * 1.1.1.1 udp * domain
+ queue class filter 56 5 ipv6 * * udp * domain
|
|
#
# LAN configuration
#
- queue lan2 class filter list 44 56 54 26 24 14 46 34 6 4
+ queue lan2 class filter list 44 56 54 26 24 14 46 66 64 34 6 4
- queue lan2 length 200
+ queue lan2 length 200 200 172 200
+ queue lan2 class property 3 bandwidth=400k,100m
#
# Queueing configuration
#
+ queue class filter 64 3 ip * * tcpflag=0x0010/0x00ff
+ queue class filter 66 3 ipv6 * * tcpflag=0x0010/0x00ff
|
RTXをCPEとして利用する🤔場合、多少のパケロスは許容されるから、TCP ACKのパケットバッファ減らして輻輳時にパケットを落とすといったお行儀の悪い施策が可能だ。
シーケンスが崩れるだけなので、優先制御には適用すべきでない。 |
#
# LAN configuration
#
- queue lan2 class filter list 44 56 54 26 24 14 46 66 64 34 6 4
+ queue lan2 class filter list 44 56 54 26 24 14 46 66 64 34 6 4 86 84
- queue lan2 length 200 200 172
+ queue lan2 length 600 600 172 200
+ queue lan2 class property 1 bandwidth=200k,100m
+ queue lan2 class property 2 bandwidth=5m,100m
queue lan2 class property 3 bandwidth=400k,100m
queue lan2 class property 4 bandwidth=2m,100m
queue lan2 class property 5 bandwidth=2m,100m
queue lan2 class property 6 bandwidth=85m,100m
queue lan2 class property 7 bandwidth=5m,100m
queue lan2 class property 8 bandwidth=1m,100m
#
# Queueing configuration
#
queue class filter 44 6 ip * * udp * 500,4500
queue class filter 56 5 ipv6 * * udp * domain
queue class filter 54 5 ip * 1.1.1.1 udp * domain
queue class filter 26 7 ipv6 * * tcpsyn
queue class filter 24 7 ip * * tcpsyn
queue class filter 14 7 ip * * udp 32768-65535 50000-50100
queue class filter 46 6 ipv6 ra-prefix@lan2::/64 a.upload.youtube.com tcpflag=0x0010/0x0017 * https
queue class filter 66 3 ipv6 * * tcpflag=0x0010/0x00ff
queue class filter 64 3 ip * * tcpflag=0x0010/0x00ff
queue class filter 34 7 ip * * tcpflag=0x0018/0x00ff * 25565
queue class filter 6 8 ipv6 * * udp,icmp6 * ntp
queue class filter 4 8 ip * * udp,icmp * ntp
+ queue class filter 84 precedence ip * *
+ queue class filter 86 precedence ipv6 * *
|
BRKEWN-2003.pdf - Cisco Live QoS - DSCP(Differentiated Services Code Point)とは
show status qos length
LAN2
キューイングタイプ: shaping
インタフェース速度: 1g
[キュー長]
クラス 上限 エンキュー回数 デキュー 現在 ピーク 記録日時
成功 / 失敗 回数
------ ----- --------------------- ---------- ----- ----- -------------------
1 500 670745/ 2206 670745 0 00 2022/10/23 14:59:34
2 1000 9291614/ 5872 9291614 0 600 2022/10/23 20:21:08
3 170 241011/ 97 241011 0 172 2022/10/23 19:03:20
5 10 40117/ 0 40117 0 2 2022/10/23 20:38:01
6 200 2/ 0 2 0 1 2022/10/24 04:44:50
7 10 9768/ 0 9768 0 5 2022/10/23 16:59:28
8 10 258982/ 0 258982 0 2 2022/10/24 09:14:05
------ ----- --------------------- ---------- ----- ----- -------------------
show status qos bandwidth
LAN2
キューイングタイプ: shaping
インタフェース速度: 1g
[帯域]
クラス 設定帯域 使用帯域 (%) ピーク 記録日時
------- ---------------------- ------------ ------ -------------------
1 200k,100m 70.2k (< 1%) 9.73m 2022/10/17 12:30:03
2 5m,100m 30.3k (< 1%) 98.4m 2022/10/23 20:16:39
3 400k,100m 256k (< 1%) 60.9m 2022/10/13 23:47:25
5 2m,100m 879 (< 1%) 43.4k 2022/10/17 08:27:51
6 85m,1g 0 ( 0%) 192 2022/10/20 04:44:55
7 2m,100m 176 (< 1%) 22.2k 2022/10/20 16:12:08
8 1m,100m 536 (< 1%) 226k 2022/10/14 09:55:24
------- ---------------------- ------------ ------ -------------------
クラス数: 7
保証帯域合計: 95600k
キューを長くしたとき、パケットバッファの割り当てを超えてはならない。もし超えるなら設定変更が必要だ。 |
tcpflag 見出しにジャンプ
mnemonicにないTCP Flagの立ったパケットを引っ掛けるにはtcpflag=FLAG_VALUE/FLAG_MASK
, tcpflag!=FLAG_VALUE/FLAG_MASK
を使う。
RT52pro Rev.4.02.07 リリースノート
プロトコルの識別子 FAQ for YAMAHA RT Series / IP Packet Filter
hex | bin | hex | bin | hex | bin | |
---|---|---|---|---|---|---|
TCPのフラグと | 0x0002 | 0000 0010 | 0x0012 | 0001 0010 | 0x00c2 | 1100 0010 |
FLAG_MASKの | 0x00ff | 1111 1111 | 0x0002 | 0000 0010 | 0x0017 | 0001 0111 |
論理積(AND)がFLAG_VALUE | 0x0002 | 0000 0010 | 0x0002 | 0000 0010 | 0x0002 | 0000 0010 |
tcpflag= | 0x0002/0x00ff | 0x0002/0x0002 | 0x0002/0x0017 | |||
SYNだけ | SYN/ACKなども含む | SYN/ECN/CWR/PSHを含み、SYN/ACKは含まない |
FLAG_VALUE=最小限のtcpflagとし、FLAG_MASKは、引っ掛けるtcpflagに一致するビットと、拒否するビットを立てたものになる。多く立っていれば厳格に、少なく立っていれば緩く一致する。
FLAG_MASKを0xffにすればFLAG_VALUE以外のパケットを絶拒し、FLAG_MASKが同じならFLAG_VALUEが立っているパケットは一応ヒットすると覚えればよい。
優先制御 見出しにジャンプ
queue class filter
などの設定は帯域制御と変わらない。queue lan2 class property
は不要だ。
優先制御
優先制御 : コマンド設定
優先制御(TOS値) : コマンド設定
speed lan2 100m
queue lan2 type priority shaping-level=1
queue lan2 class filter list ...
### PP 1 ###
pp select 1
queue pp type priority
queue pp class filter list ...
### PP 2 ###
pp select 2
queue pp type priority
queue pp class filter list ...
### TUNNEL 1 ###
tunnel select 1
queue tunnel class filter list ...
NGNのQoS 見出しにジャンプ
6.2 データパケットに設定する転送優先度識別子
表 6-1:DSCP 値と転送品質クラスの対応(IPv4)
最優先クラス 高優先クラス 優先クラス ベストエフォートクラス サービスタイプフィールド(IPv4)に設定する DSCP 値 101110 100000 001000 000000 表 6-2:DSCP 値と転送品質クラスの対応(IPv6)
最優先クラス 高優先クラス 優先クラス ベストエフォートクラス トラヒッククラスフィールド(IPv6)に設定する DSCP 値 101110 100000 001000 000000
フレッツではこのようにDSCP値が予約されており、勝手にベストエフォートクラス以外にL3マーキングしたパケットは転送が保証されなかったり、破棄されたりする仕様だ。
ip tos supersede
コマンドでベストエフォートクラス以外にマーキングすると、IPv4 PPPoEではスループットの差は見られなかったが、IPv4 over IPv6では明らかにスループットが低下した。
IPIPトンネル機能で、以下の通信においてカプセル化されたパケットのIPヘッダーの、ToSフィールドおよびTraffic Classフィールドが外側のIPヘッダーにコピーされないバグを修正した
Rev.14.01.33リリースノート
LANからのOutboundパケットを許可するフィルタを流用して、ToS値をベストエフォートクラスにL3マーキングすることで、不具合を回避する。
8.1.27 IP パケットの TOS フィールドの書き換えの設定
#
# IP configuration
#
+ ip tos supersede 1 normal precedence=0 42900
#
# IP filter configuration
#
ip filter 42900 pass 192.168.100.0/22 *
備忘録: 【RTX1210】【RTX810】NTT(西)NGNにおけるIPv6通信で、パケットの優先制御情報によっては通信できなくなる問題と対応
IXシリーズはNGNのQoSに対応できそうだ。
QoS : FAQ : UNIVERGE IXシリーズ | NEC
RTXにIPv6のトラフィッククラスフィールドを任意に設定する機能はないので、VLAN間SSHのタイムアウトを設定するのと同様にSSH configにL3マーキングしないよう設定する。
IPQoS none
Host hoge
User fuga
...
VDSL環境の回線速度改善 見出しにジャンプ
令和ともあろうに、世の中にはFTTHに対応していない集合住宅が数多く残っている。
コロナ禍の需要増加による回線速度低下に耐えかねて、さまざまな施策を行ったので参考になれば幸いだ。
方法 | 効果↓ | 難易度 | お行儀 |
---|---|---|---|
FTTH(失敗) 建った時から終わってた |
????? | ∞ | ★★★★★ |
VDSLモデムの交換 下り70/上り30Mbpsしか出ない VH-100<3>E<\N> はVH-100<4>E<\N> に交換しよう |
★★★★★ | ★★★★★ | ★★★★★ |
NTEガチャ IPv4 PPPoEはサーバに必要だし、実はIPv4 over IPv6より速い |
★★★★★ | ★★★☆☆ | ☆☆☆☆☆ |
DNSシンクホール トラッカーなど余計なリソース読み込みを減らして、FTTHより早くWebサイトを表示させる |
★★★★☆ | ★★★★☆ | ★★☆☆☆ |
DNSサーバガチャ 1ミリ秒でも早く、コネクションを始めたい |
★★★☆☆ | ★★★☆☆ | ★☆☆☆☆ |
PPPoEマルチセッション 物理回線のスループットの限界をめざす |
★★☆☆☆ | ★★☆☆☆ | ★★★☆☆ |
QoS 名前解決や3-way Handshakeを素早く済ませて、RTTを有効活用 |
★☆☆☆☆ | ★★★☆☆ | ★★★★★ |
CDNガチャ ECSやIP Anycastに任せてられない! |
★☆☆☆☆ | ★★★★☆ | ☆☆☆☆☆ |
光コラボ契約におけるFTTH交渉の流れ 見出しにジャンプ
FTTHは回線速度に大きく影響するRTTが小さく、電話局とONU間では電源が不要なため災害にも強い。
NTT東は保守の都合から集合住宅のFTTH化を推進しており、無料キャンペーンをやるほどだ。
結果としてはFTTHは失敗したが、VDSLモデムを交換することで回線速度向上に成功した。
-
マンションの管理会社に連絡する
NTT東とCATV系の設備がある。それぞれに確認するようにと返答 -
契約しているISPのチャットサポートに問い合わせる
フレッツとの直接契約でなく、コラボ光のため。
テクニカルサポートに電話するようにと返答
オペレータによるチャットサービスのご案内 | OCN -
ISPのテクニカルサポートに電話
OCNテクニカルサポート お問い合わせ窓口 混雑状況 | 個人向けOCNお客さまサポート
SMSで下記を案内される
インターネット遅くない!?なんで…なの!? | OCN -
再度テクニカルサポート
今度は人間のサポートが対応。カスタマーズフロントに案内される -
ISPのカスタマーズフロント
VDSLから光配線に変えたい
テクニカルサポートの方に光配線方式の契約の中でも2種類あり、100M据え置きか1G契約変更と言われた。
契約変更は光配線に変わってから可能で、ISP側では何ともならないので管理会社からNTT東へ連絡するようにと -
NTT東 116
ISPは言わずマンション名だけを伝えて、光配線方式への変更の予定があるか確認した。
数年前に既に1度試みたが、配管の都合で断念とのこと。稀によくあるらしい。VDSLの継続がほぼ確定した。
打開するには管理会社から配管を全部屋に...💸💸 -
ISPのオペレータによるチャット
現在Bフレッツ時代のVDSLモデムVH-100<3>E<\N>
を使用中だが、新しい型が存在すること、モデムを新調して快適になったという信憑性不明の話があったため、「白いプラスチックが経年劣化と熱で焦げ色に変色し、RJ-45ジャックの部分が熱で変形したのか挿しづらいから新しいモデルに交換できないか」と交渉。 -
ISPのテクニカルサポート
ISPからNTTへ折り返ししてくれた。 -
NTT東 故障受付
VH-100<3>E<\N>
は郵送での交換が可能
回線の接続には問題ないものの、回線速度への影響も触れたが好意的な対応だった。
VH-100<4>E<\N>
が送られてくる -
昨日の今日でVDSL終端装置が配達される
IPv6, PPPoE共に下り回線速度が70 -> 80-90Mbps, 上りが30 -> 90-100Mbpsに向上
発熱も常識的な範囲に収まった。
界隈ではお勧めされていないコラボ光ではあるものの、契約中のISPやNTT東の対応がスムーズで助かった。
続報があればお伝えしようと思う。
遅いVDSLやADSLを高速化するスピードアップの裏技 - Qiita
おすすめスピードテストサーバ 見出しにジャンプ
fast.comをはじめとするマルチコネクション時のスピードテスト結果で一喜一憂しないで欲しいので、アテになるスピードテストサーバを列挙しておく。
- サービス情報サイト(NTT東日本) -> フレッツ光 通信速度測定
- フレッツ速度測定サイト(NTT西日本)
インターネットではなく、NGN閉域網の速度計測を行うことで、輻輳の原因がISPなのかフレッツ網・ラストワンマイルかを切り分けできる。
フレッツ系の回線でサービス情報サイトへの接続設定が必要。 - iNoniusスピードテスト
おすすめ - Speedtest
サーバ/地域によっては参考にならない
高速なサーバは以下の通り
— nanra28 (@Nanra28_) September 28, 2022
1 IPA CyberLab 400G
2 i3D. net
3 GSL Networks
4 Rakuten Mobile, Inc
順に100Gbpsのサーバからの測定結果を貼っておきます
他のサーバは全て10Gbps以下であり、サーバ側のネットワーク状態の影響を受けやすいと思われます。 pic.twitter.com/Umf7JuJMFd
- fast.com -> 詳細を表示
輻輳に有利な多重コネクション, PSH/ACK, IPv6の結果を表示するため、単一コネクション, ACK, IPv4で遅いと感じているなら参考にならない。
参考になるとすれば単位がmsのRTT(いわゆるping値)。例えば、設備投資を怠っているISPや小規模なISP、東京・大阪と距離がある地域、集合住宅のVDSL配線方式では値が大きくなりがちだ。
News & Views コラム:オンラインゲームとインターネットの遅延 – JPNIC Blog
LuaでRTTを監視する 見出しにジャンプ
rtxconfig/log-rtt.lua at main · nyanshiba/rtxconfig
Speedtestを自動化して回線速度を監視したい - 俺の外付けHDD
ネットワークエンジニアのための ヤマハルーター実践ガイド
ヤマハルーターでつくるインターネットVPN [第5版]
マスタリングTCP/IP―入門編―(第6版)
NVIDIA GeForce RTX 2080 SUPER Founders Edition Graphics Card スーパーファウンダーズエディショングラフィックスカード