俺の Advent Calendar 2022
-12日目

YAMAHA RTX830 をSSHで設定する

カバさんルータから卒業すべく、イマドキなインターネッツに対応してて、イマドキなVPN張れて、内部にDNSサーバがあって、安定して動作する安価なルータを探してたら、RTX 830なるものがあると知り、安くなってたのでかっちった。

更新履歴見出しにジャンプ

日時	内容
2020-05-24	Public DNSの設定 MTU値の設定重複したフィルタの統合
2020-07-30	configのエクスポート saveコマンドの意味を追記 NATセッション数の表示ローカルIPアドレスの固定セカンダリDNSサーバポート開放
2020-08-21	インターフェースの状態・リンク速度の表示 CPUやメモリ使用率の表示 DNSキャッシュの表示・削除 NTP コンソール表示文字数の設定 FQDNフィルタでのお行儀の悪いドメインのブロック QoS
2020-08-22	w32tm.exeでシステム時刻のズレを計測する方法を追記
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 コンソールケーブル

USBコンソールケーブル, CableCreation 1.8m [FTDI-FT232RL チップセット内蔵] USB-RJ45シリアルケーブル Cisco、NETGEAR、TP-Link、Linksys、Ubiquiti、Huaweiルータ/スイッチ用 Mac、Windows及びLinuxに対応ブラック

届く長さのCat.6A辺りのUTPなLANケーブル
~~間違って買ってしまったCat.7でも良い~~

エレコム LANケーブル CAT6A 3m ツメが折れないブルー LD-GPAT/BU30

Wi-Fiアクセスポイント
(に降格したWi-Fiルータでも良い)
今時ならWi-Fi6対応のゲーミングWi-Fiルータをブリッジで繋げれば良いと思う
逸般人ははんぺんでもよい

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サーバー機能
 RTFS

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 説明

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	ひかり電話なしRAプロキシ(一般的にはND Proxy)の場合、`ra-prefix@lan2::/64`といったニーモニック指定でLAN1にIPv6インターネット環境を利用できる。実際には、例えばCIDR表記で`2001:db8:b0ba:10ee::/64`に相当し、`2001:db8:b0ba:10ee::`から`2001:db8:b0ba:10ee:ffff:ffff:ffff:ffff`までの下位64bitの範囲を表す。IPv4の`0.0.0.0`に相当するのが`0000:0000:0000:0000:0000:0000:0000:0000`で、128bitもあるため連続したゼロは1度だけ`::`と省略できる。このIPv6アドレスは全世界のインターネットでGUA(Global Unicast, グローバルIPアドレス)として通用する`2000::/3`の範囲内にある。 Internet Protocol Version 6 Address Space IPv4 over IPv6やIPv4 PPPoEで使うLAN1のアドレスは、基本的にNATの中でのみ通用するプライベートIPアドレスなのに対し、IPv6は一般的にNATをしないためLAN1の端末一つ一つにグローバルIPアドレスが割り振られる。NATの負荷が減る一方、いい加減なパケットフィルタをNATが守ってくれる、なんて虫のいいことは言っていられない。ルータおよびデフォルトゲートウェイは`ra-prefix@lan2::1`、つまり`2001:db8:b0ba:10ee::1`が使われる。 56.10 インタフェースに付与されている IPv6 アドレスの表示 `> show ipv6 address lan1 LAN1 scope-id 1 [up] Received: 765753 packets 88829311 octets Transmitted: 1532257 packets 259024725 octets グローバル 2001:db8:b0ba:10ee::1/64 (lifetime: 604673/2591873) リンクローカル fe80::ae44:f2ff:fe12:3456/64 リンクローカル ff02::1/64 リンクローカル ff02::2/64 ...` DHCPv6-PDの場合は分からないが、少なくともRAプロキシの場合はRTXによりA-flag = 1, M-flag = 0, O-flag = 1のSLAAC + RDNSS方式でLAN1内の端末へアドレス自動設定・IPv6 DNSが通知される。DHCPv6のオプションによりIPv6 NTPの通知が行われる。ひかり電話や光クロス契約でDHCPv6-PD、かつHGWを挟まずRTXで直収する場合、`dhcp-prefix@lan2::/56`の範囲からIPv6 RAの最小セグメント`/64`を計256個つくることができる。HGWで`/56`を収容し、配下のRTXやNVRに`/58`や`/60`を配っても多くのセグメントを切ることができ、すべてのVLANをIPv4/IPv6デュアルスタックにできる。逸般の誤家庭がDHCPv6-PD再移譲に対応したルータやL3スイッチで`/56`直収し、配下にルータをぶら下げているのはこのためだ。フレッツ光ひかり電話を使いながら、IPoEのIPv6を自前ルータで直収する方法 - notokenの覚書ひかり電話なし環境で0-65535全てのポートが自由に使えるVLANを切る現実的な方法は、光クロスを契約する、あるいは全VLANへでのデュアルスタックを諦めて、IPv4 over IPv6の固定IPプランを契約するか、IPv4 PPPoEをNNI/NTEガチャで高速化することである。そもそもIPv4アドレスの枯渇は通信事業者側の都合で、スループットさえ出れば顧客側にIPv6を使う理由などないからだ。 DeepL翻訳: 64以上のプレフィックスを割り当てることは、IPv6標準に準拠しておらず、顧客LANの機能を破壊することになります。単一の/64では、最終顧客CPEはLAN側で1つの可能なネットワークしか持たず、サブネット、VLANの割り当て、代替SSID、同じ顧客ネットワーク内の複数のチェーンルーターなどを持つことは不可能です。 Best Current Operational Practice for Operators: IPv6 prefix assignment for end-users - persistent vs non-persistent, and what size to choose — RIPE Network Coordination Centre IPv6 IPoE対応機能ヤマハネットワークエンジニア会 \| VLAN分割下におけるIPoE IPv6について IPv6
+ 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 ~~	推奨フィルタはBCP38/84する気がないので修正する。
# # 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	DHCPv6のオプションでNGN網内のDNS`dhcp lan2`とSNTPサーバアドレスが自動取得されるので、それを使ってRTXやLAN内の端末を時刻合わせしたり、DNSリカーシブサーバに設定して名前解決する。 RFC 3646: DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) RFC 4075 - Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6 `> show status ipv6 dhcp DHCPv6 status LAN1 [server] state: reply state: reply state: reply LAN2 [client] state: established server: DNS server[1]: 2404:1a8:7f01:b::3 DNS server[2]: 2404:1a8:7f01:a::3 Domain name[1]: flets-east.jp SNTP server[1]: 2404:1a8:1102::b SNTP server[2]: 2404:1a8:1102::a` Web GUIでIPv6 IPoEおよびIPv4 over IPv6を設定すると、DNSフォワーダを持つ市販のCPEと同様に、RTX本機`ra-prefix@lan2::1`, `192.168.100.1`で動くDNSリカーシブサーバがLAN1の端末に通知され、その問い合わせをNGNのIPv6 DNS`dhcp lan2`に転送し、キャッシュする。この組み合わせならDNSリカーシブサーバ以外が自動設定されることはないが、`dns notice order`と`dns server`の組み合わせ次第ではRTXのDNSリカーシブサーバを経由しない問い合わせが発生したり、Webブラウジング全体が遅くなるため注意が必要だ。 24.6 DHCP/DHCPv6/IPCP MS 拡張で DNS サーバーを通知する順序の設定 DNS の設定既にIPv6に限りNGN網内(ISPからインターネットに出る手前)のサービス情報サイトを利用できる状態だ。名前解決が`dhcp lan2`で行われさえすれば、他のドメインはPublic DNS等を利用してもよい。IPv4/IPv6のNGN網内区間をスピードテストするには、IPv4 PPPoEでサービス情報サイトを利用する設定も必要。サービス情報サイト(NTT東) サービス情報サイト(IPv6 / NTT東日本)への接続 : コマンド設定

#
# 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

ひかり電話なしRAプロキシ(一般的にはND Proxy)の場合、ra-prefix@lan2::/64といったニーモニック指定でLAN1にIPv6インターネット環境を利用できる。実際には、例えばCIDR表記で2001:db8:b0ba:10ee::/64に相当し、2001:db8:b0ba:10ee::から2001:db8:b0ba:10ee:ffff:ffff:ffff:ffffまでの下位64bitの範囲を表す。IPv4の0.0.0.0に相当するのが0000:0000:0000:0000:0000:0000:0000:0000で、128bitもあるため連続したゼロは1度だけ::と省略できる。
このIPv6アドレスは全世界のインターネットでGUA(Global Unicast, グローバルIPアドレス)として通用する2000::/3の範囲内にある。
Internet Protocol Version 6 Address Space
IPv4 over IPv6やIPv4 PPPoEで使うLAN1のアドレスは、基本的にNATの中でのみ通用するプライベートIPアドレスなのに対し、IPv6は一般的にNATをしないためLAN1の端末一つ一つにグローバルIPアドレスが割り振られる。NATの負荷が減る一方、いい加減なパケットフィルタをNATが守ってくれる、なんて虫のいいことは言っていられない。
ルータおよびデフォルトゲートウェイはra-prefix@lan2::1、つまり2001:db8:b0ba:10ee::1が使われる。
56.10 インタフェースに付与されている IPv6 アドレスの表示

> show ipv6 address lan1 
LAN1 scope-id 1 [up]
 Received:    765753 packets 88829311 octets
 Transmitted: 1532257 packets 259024725 octets

 グローバル     2001:db8:b0ba:10ee::1/64 (lifetime: 604673/2591873)
 リンクローカル fe80::ae44:f2ff:fe12:3456/64
 リンクローカル ff02::1/64
 リンクローカル ff02::2/64
...

DHCPv6-PDの場合は分からないが、少なくともRAプロキシの場合はRTXによりA-flag = 1, M-flag = 0, O-flag = 1のSLAAC + RDNSS方式でLAN1内の端末へアドレス自動設定・IPv6 DNSが通知される。DHCPv6のオプションによりIPv6 NTPの通知が行われる。
ひかり電話や光クロス契約でDHCPv6-PD、かつHGWを挟まずRTXで直収する場合、dhcp-prefix@lan2::/56の範囲からIPv6 RAの最小セグメント/64を計256個つくることができる。HGWで/56を収容し、配下のRTXやNVRに/58や/60を配っても多くのセグメントを切ることができ、すべてのVLANをIPv4/IPv6デュアルスタックにできる。
逸般の誤家庭がDHCPv6-PD再移譲に対応したルータやL3スイッチで/56直収し、配下にルータをぶら下げているのはこのためだ。
フレッツ光ひかり電話を使いながら、IPoEのIPv6を自前ルータで直収する方法 - notokenの覚書
ひかり電話なし環境で0-65535全てのポートが自由に使えるVLANを切る現実的な方法は、光クロスを契約する、あるいは全VLANへでのデュアルスタックを諦めて、IPv4 over IPv6の固定IPプランを契約するか、IPv4 PPPoEをNNI/NTEガチャで高速化することである。そもそもIPv4アドレスの枯渇は通信事業者側の都合で、スループットさえ出れば顧客側にIPv6を使う理由などないからだ。

DeepL翻訳: 64以上のプレフィックスを割り当てることは、IPv6標準に準拠しておらず、顧客LANの機能を破壊することになります。単一の/64では、最終顧客CPEはLAN側で1つの可能なネットワークしか持たず、サブネット、VLANの割り当て、代替SSID、同じ顧客ネットワーク内の複数のチェーンルーターなどを持つことは不可能です。
Best Current Operational Practice for Operators: IPv6 prefix assignment for end-users - persistent vs non-persistent, and what size to choose — RIPE Network Coordination Centre

IPv6 IPoE対応機能
 ヤマハネットワークエンジニア会 | VLAN分割下におけるIPoE IPv6について
 IPv6

+ 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
~~

推奨フィルタはBCP38/84する気がないので修正する。

#
# 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

DHCPv6のオプションでNGN網内のDNSdhcp lan2とSNTPサーバアドレスが自動取得されるので、それを使ってRTXやLAN内の端末を時刻合わせしたり、DNSリカーシブサーバに設定して名前解決する。
RFC 3646: DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
RFC 4075 - Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6

> show status ipv6 dhcp 

DHCPv6 status

  LAN1 [server]
    state: reply
    state: reply
    state: reply

  LAN2 [client]
    state: established
    server:
      DNS server[1]: 2404:1a8:7f01:b::3
      DNS server[2]: 2404:1a8:7f01:a::3
      Domain name[1]: flets-east.jp
      SNTP server[1]: 2404:1a8:1102::b
      SNTP server[2]: 2404:1a8:1102::a

Web GUIでIPv6 IPoEおよびIPv4 over IPv6を設定すると、DNSフォワーダを持つ市販のCPEと同様に、RTX本機ra-prefix@lan2::1, 192.168.100.1で動くDNSリカーシブサーバがLAN1の端末に通知され、その問い合わせをNGNのIPv6 DNSdhcp lan2に転送し、キャッシュする。
この組み合わせならDNSリカーシブサーバ以外が自動設定されることはないが、dns notice orderとdns serverの組み合わせ次第ではRTXのDNSリカーシブサーバを経由しない問い合わせが発生したり、Webブラウジング全体が遅くなるため注意が必要だ。
24.6 DHCP/DHCPv6/IPCP MS 拡張で DNS サーバーを通知する順序の設定
 DNS の設定
既にIPv6に限りNGN網内(ISPからインターネットに出る手前)のサービス情報サイトを利用できる状態だ。名前解決がdhcp lan2で行われさえすれば、他のドメインはPublic DNS等を利用してもよい。IPv4/IPv6のNGN網内区間をスピードテストするには、IPv4 PPPoEでサービス情報サイトを利用する設定も必要。
サービス情報サイト(NTT東)
サービス情報サイト(IPv6 / NTT東日本)への接続 : コマンド設定

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はMinRtrAdvIntervalmin-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の他の端末にクエリ内容が丸見え"なことで悪名高いmDNS224.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	A-flag = 1, M-flag = 0, O-flag = 0 RA SLAACでアドレス自動設定し、DNSサーバはRDNSSで通知する方法。 DHCPv6のオプションRFC 4075で配布されたNGNのSNTPサーバアドレスをプロキシ(Linuxが対応)する前提だからか、常に"Other configuration" flag = 1のようだ。実際にNGNのSNTPサーバを配布するにはDHCPv6サーバの有効化`ipv6 lan1 dhcp service server`が必要。 RTXをDNSシンクホールにしているなら、DNSリカーシブサーバのGUAのみ通知`dns notice order dhcpv6 me`(デフォルト)するか、DHCPv6で配布せず`none`RDNSS`ipv6 nd ra-rdnss`で配布しないとブロック漏れが発生してしまう。 24.6 DHCP/DHCPv6/IPCP MS 拡張で DNS サーバーを通知する順序の設定 30.3.2 ルーター広告で配布するRDNSSオプションの定義 RTXの仕様でGUA(`ipv6 lan1 address`)がDNSリカーシブサーバのアドレスとして配布されてしまう点にも注意が必要。(日本では)滅多にないがPrefixの変更やパケットフィルタに影響しないよう、`fdca::1`のようなULAを推奨する。ULAの配布はRA RDNSSオプションのみ対応している。 Unique Local Addressに使えるのは`fc00::/7`、`fc00::`-`fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff`の範囲だ。 IANA IPv6 Special-Purpose Address Registry off-link`l_flag=off`にすると、L3専門のRTXでまるでL2分離様な動作をつくれるが、無通信時Apple iOSがWi-Fi切断とみなしてしまうため実用性がなかった。
+ 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	A-flag = 0, M-flag = 1, O-flag = 1
+ 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	A-flag = 1, M-flag = 0, O-flag = 1 `dns notice order dhcpv6 server`でDHCPv6で通知されたNGNのDNSが端末に配布される。 AndroidはRDNSSのみ対応し、DHCPv6でDNSサーバを自動設定できない。国内メーカ初！【IPv6 RA RDNSSオプション通知】に対応：IPv6通信ならAtermで決まり！ネット高速化虎の巻 \| ルータ活用コンテンツ \| AtermStation RDNSS対応小型ルータを調べてみた_佐藤秀樹_v11.pptx - bof-lt-night-2_lt_RDNSS_hideki-sato.pdf デュアルスタックならDHCPでもDNSサーバは配れるのでインターネットが使えなくなることはないのだが、EDNS0 Client Subnetの観点からA/AAAAレコードはそれぞれIPv4/IPv6で問い合わせた方がよい。つまり、RDNSSも吹く`ipv6 nd ra-rdnss 1 dhcpv6`か、DNSリカーシブサーバ側でECSに対応すればよい。 30.3.2 ルーター広告で配布するRDNSSオプションの定義

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会員サポート ~~BIGLOBE IPv6 サービス ( IPIP ) 接続設定例 - RTpro~~	MAP-E ~~IPIP~~	O X		X O	-
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箱として使っている限りはインターネットにある殆どのホストはこのデフォルト経路を通ることになる。リモートアクセスVPNなどでマルチセッションするときに、静的経路をIPv4 over IPv6以外に向けることがある。 8.1.7 IP の静的経路情報の設定 8.1.33 implicit 経路の優先度の設定
# # LAN configuration # + ip lan1 address 192.168.100.1/24	一般的に家庭用CPEで使われるルータ自身およびデフォルトゲートウェイのIPアドレスは`192.168.0.1`。一方ヤマハルータは`192.168.100.1`と3オクテット目が特徴的だ。いずれもクラスCのプライベートIPアドレス範囲`192.168.0.0/16`内で IANA IPv4 Special-Purpose Address Registry サブネットマスクが`255.255.255.0`(`/24`)、つまり`192.168.100.0/24`ならルータ`192.168.100.1`とリミテッドブロードキャスト`192.168.100.255`を除いた`192.168.100.2`から`192.168.100.254`まで使用可能だ。この中からDHCPスコープを設定して、LAN内の端末のプライベートIPアドレスを自動設定する際に、IPを固定する範囲を決められる。今後、`192.168.100.1`が出てきたらRTX本機かRTXで動くデーモン、デフォルトゲートウェイの話と捉えてほしい。
# # 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 ~~	OCNバーチャルコネクト設定例。 OCNバーチャルコネクト対応機能推奨フィルタは心もとないので修正する。
# # 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	IPv4 PPPoEではNAPTの外側IPアドレスは`ipcp`で取得するニーモニックを指定するが、MAP-E方式では利用可能ポートを生成するために`map-e`を指定する。ポートの生成にはマップルールをパケットフィルタで許可する必要がある。超凄いIPv6解説書(488ページ)を無料配布します！:Geekなぺーじ 23.4 NAT 処理の外側 IP アドレスの設定 23.5 NAT 処理の内側 IP アドレスの設定 MAP-E方式の利用可能ポートは`show nat descriptor address 20000`で確認できる `show nat descriptor address 20000 NAT/IPマスカレード動作タイプ : 2 参照NATディスクリプタ : 20000, 適用インタフェース : TUNNEL[1](1) Masqueradeテーブル外側アドレス: map-e/198.51.100.163 ...` 57.14 動的 NAT ディスクリプタのアドレスマップの表示 MAP-Eの設定を行うと、LAN1に`lifetime: INFINITY`なGUAが強制的に追加される。EUI-64ではないが、インターフェース識別子(IID)にIPv4の外側アドレスが含まれる。 `> show ipv6 address lan1 LAN1 scope-id 1 [up] Received: 923882 packets 115617838 octets Transmitted: 1927043 packets 338027615 octets グローバル 2001:db8:b0ba:10ee::1/64 (lifetime: 604673/2591873) グローバル 2001:db8:b0ba:10ee:c6:3364:a300:0100/64 (lifetime: INFINITY) > show status tunnel 1 TUNNEL[1]: 説明: インタフェースの種類: MAP-E IPv6: 2001:db8:b0ba:10ee:c6:3364:a300:0100 トンネルインタフェースは接続されています ...` 既定の`ipv6 source address selection rule prefix`では`ipv6 lan1 address ra-prefix@lan2::1`が使用されるが、何らかの事情で`lifetime`に変更するとマップルール取得以外(例えば`dns server dhcp lan2`)でもプライバシーの懸念がある固定のIIDが暗黙的に使用される点に注意が必要だ。 30.2.7 始点 IPv6 アドレスを選択する規則の設定既定のNATタイマは心もとないので修正する。 DS-LiteなどのCGNAT方式はNATをしないためRTXの負担は少ないものの、NATタイマ設定もCPE側で弄れない。これによりKeep-Aliveの長い通信、例えばプッシュ通知が届かない現象に繋がる可能性がある。
# # 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の端末には`192.168.100.0/24`のうち`192.168.100.2-192.168.100.191`の範囲を使うようだ。この範囲内のから動的あるいは固定で自動設定される。DHCPスコープの設定で変更可能。
# # 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 の静的経路情報の設定定額・常時接続の現代では、`restrict`表記ではなく、ロードバランスする設定に変更しやすい`hide`, `weight 0`を使った方がよい。 IPv4 over IPv6`tunnel 1`の冗長化にIPv4 PPPoE`pp 1`を使うconfig例になっている。このほか、一部のポート番号しか使えないIPv4 over IPv6 (動的IP契約)に代わって、定められたポート番号で待ち受ける必要のあるL2TP/IPsecのパケットをPP1に流したり、複数のトンネル・PPPoEセッションを使って物理回線のスループットを最大限引き出すロードバランスも可能だ。 IPフィルタのrestrict機能 FAQ for YAMAHA RT Series / IP Packet Filter 花粉で鼻2セッション共に輻輳して口にフォールバックされた、冗長化が無かったら死んでた — しばにゃん@home (@shibanyan_1) February 22, 2021
# # 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 ~~	新型コロナ対策のためソフトイーサ社のフレッツ用 PPPoE 実験用アクセスポイントをテレワーク用に無償開放 - ソフトイーサ Web サイトを例示に使った。フレッツIPv4 PPPoEのMTU値は1454byte FAQ for YAMAHA RT Series / PPPoE PPPoEのMTU値 8.1.4 インタフェースの MTU の設定フレッツのPPPoEでは、stac圧縮`ppp ccp type stac`をはじめ全ての圧縮は使用不可 PPP over Ethernet (PPPoE) フレッツ光を利用する際にIPヘッダ圧縮（VJ圧縮：VJ_Compression）は使用できますか。 \| よくあるご質問｜フレッツ光公式｜NTT西日本 IP通信網サービスのインタフェース　－フレッツシリーズ－ - temp21-1.pdf なので`ppp ccp type none`, 11.11.1 全パケットの圧縮タイプの設定 `ppp lcp pfc/acfc/vjc off`。 11.9.1 Van Jacobson Compressed TCP/IP 使用の設定 11.6.4 Protocol Field Compression オプション使用の設定 11.6.1 Address and Control Field Compression オプション使用の設定例によって推奨フィルタは心もとないので修正する。
# # 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

IPアドレスの変更を確認し、RTTの自動計測やスピードテストを回す

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で払い出すアドレス範囲を決める。 `except remain-silent`で除外せず、RFC 2131準拠とする DHCPサーバって何ですか？ FAQ for YAMAHA RT Series / TCP/IP 12.1.2 RFC2131 対応動作の設定 LAN1のセグメント`192.168.100.0/24`のうち、`192.168.100.1`はRTX本機およびデフォルトゲートウェイ、`192.168.100.255`はブロードキャストなので、DHCPで配布できるのは`192.168.100.2-192.168.100.254`の範囲。
+ 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で固定する。 `scope 1`は通常の自動割り当て、`scope 11`は固定のIPと対応付けられたMACアドレスを持つ端末しか入れない`bind-only`。一般的なCPEのように固定に老番を割り振るような、IPアドレスが衝突する可能性が残る運用をしなくて済む。 `192.168.100.254`まで使っていないのは、`scope 1`は`192.168.100.0/26`、`scope 11`は`192.168.100.64/26`とパケットフィルタに指定しやすい`192.168.100.0/25`からだ。 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 スコープの定義 12.1.6 DHCP アドレス割り当て動作の設定 RFC 2131の`use-clientid`が有効なので、IP固定にはchaddrフィールドのMACアドレスではなくClient-Identifierを指す。 MACアドレスが`00:00:5e:00:53:f1`のとき、type ethernet`0x01`を先頭に添えた`01 00 00 5e 00 53 f1`か`ethernet 00:00:5e:00:53:f1`と表記する。 `except use-clientid`のとき、`dhcp scope bind 11 192.168.100.21 00:00:5e:00:53:f1`と表記する。 12.1.5 DHCP 予約アドレスの設定 > show status dhcp 11 DHCPスコープ番号: 11 ネットワークアドレス: 192.168.100.0 割り当て中アドレス: 192.168.100.2 (タイプ) クライアントID: (01) 00 00 5e 00 53 00 ホスト名: WIN-2021-06-25 リース残時間: 2日 6時間 38分 42秒割り当て中アドレス: 192.168.100.21 (タイプ) クライアントID: (01) 00 00 5e 00 53 f1 リース残時間: 2日 9時間 4分 20秒割り当て中アドレス: 192.168.100.22 (タイプ) クライアントID: (01) 00 00 5e 00 53 f2 リース残時間: 2日 9時間 4分 20秒スコープの全アドレス数: 62 ... Ethernet Numbers 57.25 DHCP サーバーの状態の表示リース残時間が残っているため、既にリースされている端末に即時反映されるとは限らない。多くの場合、RTXでDHCPリリースを行ったうえ、 12.1.10 DHCP リース情報の手動削除 12.1.9 DHCP リース情報の手動追加 `dhcp manual release 192.168.100.64 # dhcp manual lease 192.168.100.2 01 00 00 5e 00 53 00` 端末毎にリースの更新が必要だ。 Windows: `ipconfig /renew` Linux: `sudo dhclient -r` `sudo dhclient` iOS: 設定 -> Wi-Fi -> AP名 (i) -> リースを更新
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サーバ等を併せて自動設定させる。内容はスコープ毎に変えられる。 `dns` 名前解決に使うDNSサーバのIPv4アドレス。DNSサーバのIPv6アドレスはDHCPv6やRA RDNSSオプションで配布する。いずれか一方さえ機能していればインターネットを利用できるが、EDNS0 Client Subnetを考慮しないとWeb表示が遅くなる。RTXのDNSリカーシブサーバを使う限りは問題ない。 `domain`, `domain_search_list` DNS名, DNSサフィックス(DNS検索ドメイン)にルートを表す`.`をバイナリで指定 `ipconfig /all`で自動で`接続固有の DNS サフィックス: .`になっていることがわかる。インターネット用語1分解説～サーチリストとは～ - JPNIC YAMAHAルータでDHCPオプションの設定 – mahori blog `ntp_server` 時刻設定に使うよう設定したSNTPサーバのIPv4アドレス。RTXのSNTPサーバのIPv6アドレスはRTX本機のGUAかULAになるが、今のところ配布する機能はない。 `time_server`はNTP/SNTP用ではないので指定しない。 If you would like to push NTP server settings to a non-windows device (Like IP Phone), use DHCP scope option 042. Do not use DHCP scope option 004 unless it is specifically mentioned in any documentation. Active Directory: Time Synchronization - TechNet Articles - United States (English) - TechNet Wiki `vendor_specific` Windowsで有効なMicrosoft Disable NetBIOS Option`01,04,00,00,00,02`, Microsoft Release DHCP Lease on Shutdown Option`02,04,00,00,00,01`を指定している。 `ipconfig /all`で自動で`NetBIOS over TCP/IP: 無効`になっていることがわかる。NetBIOSのパケットフィルタ設定関連情報 (Windows) FAQ for YAMAHA RT Series / TCP/IP [MS-DHCPE]: DHCPv4 Option Code 43 (0x2B) - Vendor-Specific Information Option \| Microsoft Learn `tz_string`, `tz_database` RFC 4833で非推奨になった`time_offset`に代わるタイムゾーン設定。 "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 Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters Adding or changing time zone settings
# # 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アドレスは端末側で自由に設定できてしまう。`dhcp-bind`型のフィルタを使うと、RTXのDHCPサーバで自動設定された端末からの通信のみに制限できる。 DHCPサーバー機能とMACアドレスフィルターの併用 DHCP認証機能 ……はずだが、DHCPに使われるARPなどを除くパケットはMACアドレスだけでなくIPv4アドレスもみるようで、ソースアドレスがIPv6では端から通過できないためデュアルスタック環境では使い物にならない。 IPv4シングルスタックのVLANでも機能しなかったのが何故かは分からなかった。IPv4射影アドレスじゃないものなぁ。 Wiresharkで観察するIPv4 Mapped IPv6アドレスを使った通信:Geekなぺーじ SSHで設定しているときにRTXとの通信ができなくならないよう、`schedule`でconfigを消去するよう仕込んでおくとよい。 YAMAHAルーター RTX1210 で、接続端末をMACアドレス制限 - Qiita

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
...

集計した
rtxconfig/ntpq-summary.ps1 at main · nyanshiba/rtxconfig

./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

4.16 NTP による時計の設定

定期的に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動作タイプ2(ポートセービングIPマスカレード)のとき、TCPはRFC 5780のEndpoint-Independent Mappingでポートを有効活用し、UDPなどその他のプロトコルはAddress( and Port?)-Dependent Mapping動作となる。 NAT動作タイプの違いについて NATディスクリプター機能概要ゲームでよくある「NATタイプ」はどう判定しているの？ Nintendo Switch の「NATタイプ」判定条件 - Qiita WebRTCの裏側にあるNATの話 - A talk on NAT behind WebRTC 実践 WebRTC 〜最新事例と開発ノウハウの紹介〜 How NAT traversal works · Tailscale いずれにせよ動的フィルタがIPアドレスとポートの組み合わせのフローを持つので、ファイアウォール機能 Address and Port-Dependent Filtering、Mappingと併せてRFC 3489のPort Restricted Cone相当の動作になる。
- nat descriptor masquerade remove df-bit on + nat descriptor masquerade remove df-bit off	NAPTを通過するパケットのDon't Fragmentビットを無視させる、Path MTU Blackholeの回避策が有効になっているが、Path MTU Discoveryが効かない状態はスループットの低下を招くので無効にする。 23.16 IP マスカレード変換時に DF ビットを削除するか否かの設定 PMTUDを効かせるには、併せてOutboundのICMP Type 3 Code 4を許可する必要がある。 Internet Control Message Protocol - Wikipedia
# # 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ディスクリプタを定義し、PPやトンネルインターフェースに適用する。 RFC 4787ではヘアピンNATをサポートするようにとあるが、P2P通信のVLAN越えは許可したくないし RFC 4787 - Network Address Translation (NAT) Behavioral Requirements for Unicast UDP Ingress Filteringやsyslogがややこしくなるので、ヘアピンNATは使わない。ヘアピン NAT 機能
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	IPv6は動的フィルタ(SPI)のタイムアウトだけ気にすればよいが、IPv4 NAT環境では併せてNATタイマの設定も必要。 `nat descriptor timer`は上から順に適用されるが、順序を指定する番号がない。正しく反映されているかconfigを取得して確認しよう。 TCP(Established)は2時間4分。非常に長いがTCP/FINで通信終了するため問題ない。 TCP/FIN`tcpfin`のタイマは既定で60秒。理にかなっていると思うが、これより短くするのはいただけない。 TCP/FIN が通過したセッションは終了するセッションなので、このタイマを短くすることで NAT テーブルの使用量を抑えることができる。 23.9 NAT の IP アドレスマップの消去タイマの設定 TIME_WAIT状態(2MSL待ち)をNAPTテーブルから消去してしまうと、サーバ側にハーフオープンのコネクションが残ってしまいお行儀が悪い。LinuxのMSL=1分を基準に2MSL=2分としている。Windows ServerはMSL=2分らしいが、パケロスしなければ1MSLでよいはずで、そもそも端末のOSが1分で切ってしまうなら無駄な話だ。 LinuxサーバーのTCPネットワークのパフォーマンスを決定するカーネルパラメータ – 3編 \| NHN Cloud Meetup 2.4.3 NAT タイムアウトに関する設定 RST または FIN が観測されていない TCP セッションや、UDP、ICMP の通信は一定時間 NAT テーブルを保持すべきである。TCP の場合、FIN が観測されてもアプリケーションの挙動を担保するために 2Maximum Segment Life(MSL)時間だけ NAT テーブルを保持してから NAT テーブルを解放すべきである。これらの NAT テーブル保持時間を変更可能である機器を選定することが望ましい IPv4アドレスの枯渇時に生じる諸課題に適切に対処するための手順書(Vol.2) \| IPv6 Promotion Council \| IPv4枯渇に係るインターネット新技術導入に向けた検討WG 分散プログラミングモデルおよびデザインパターンの考察その4 - Software Transactional Memo プッシュ通知はKeep-Aliveの長いTCPコネクションで行われる。Androidの場合TCPタイマは30分以上が求められ、Appleも同程度のようだ。ネットワークにネットワークアドレス変換 (NAT) またはステートフルパケットインスペクション (SPI) が実装されている場合は、ポート 5228 ～ 5230 経由の接続に 30 分以上のタイムアウトを実装してください。これにより、ユーザーのモバイルデバイスのバッテリー消費を抑えながら、信頼性の高い接続を提供できます。 FCMメッセージについて \| Firebase Cloud Messaging Apple 製のデバイスで Apple プッシュ通知が届かない場合 - Apple サポート (日本) プッシュ通知をネットワーク管理者目線で考える \| KUSONEKOの見る世界家庭用CPEでNAPTの負荷を減らすため、RTXにおいてもMAP-Eのポート枯渇を気にするがあまりタイマを短くすると、プッシュ通知が遅れたり受け取り損ねたりする。AndroidもiOSもつい最近IPv6に対応したのでデュアルスタック環境なら起こりづらくなっているが、NAPTのないIPv6でもSPIのタイマは影響するので設定が必要。ポート枯渇を抑えつつプッシュ通知のみタイムアウトを伸ばしたい場合は、ポートを限定するとよい。 Google Firebase Cloud Messaging(FCM): `protocol=tcp port=5228-5230 1800` Apple APNs`protocol=tcp port=2195-2197 2040`, `protocol=tcp port=5223 2040`(34分) Apple ソフトウェア製品で使われている TCP および UDP ポート - Apple サポート (日本) VNE事業者の対向ルータ(AFTR)でキャリアグレードNAT(CGNAT)するDS-Lite方式では、このタイマーをRTX側で決められない。VNE事業者は把握していて適切にタイマーが設定されていると思うが、 transix の AFTR の NAT変換テーブルについて調査してみた(途中経過)｜しょっさん｜note IPv4 over IPv6(DS-Lite)V6コネクト徹底解剖.最大TCPセッション数測定 - YouTube IPv4シングルスタックなVLANがあるなら、マルチセッションも視野に入れよう。 UDPは5分。コネクションの概念がないため、通信終了後も暫くはパケットが通過できる。 NTP`protocol=udp port=ntp`は2秒としたいところだが、最小値30秒。 `protocol=`にはニーモニック / IPプロトコルの一部、`port=`にはニーモニック / TCPポート番号が指定できる。 RTシリーズでサポートしているニーモニック / IPプロトコル mnemonic table 非暗号化DNS`protocol=udp port=domain`は10秒固定なので必要ない。 23.9 NAT の IP アドレスマップの消去タイマの設定市販のCPEがUDPのタイマを真面目に実装しているのか、設定項目を見ると不安を覚える。真面目に実装したら、Aterm病と呼ばれる始末だ。NAPT性能が公開されていない家庭用CPEに限っては ~~(全部じゃんというツッコミはなし)~~ 、枯渇を防ぐためにEDNS0 Client Subnetを諦めて、全ての名前解決をIPv6で行う方向性でのトラシューも多い。 QUIC`protocol=udp port=https`は通常のUDP`protocol=udp`同様に5分推奨、最低2分。家庭用にしては十二分な性能のあるRTXでは、家庭用CPEのようにNAPTテーブルが溢れる心配はないが、v6プラスの240ポート, OCNバの1008ポートなど、ポート枯渇の恐れはある。RTXのNATはLRU(Least Recently Used)ではなくタイマー方式のため、枯渇を防ぐには短くするほかない。 RFC 4787 (BCP)によるとUDPのタイムアウトを2分未満にしてはならず、デフォルト値としては5分以上が推奨される RFC 9000ではタイムアウトを防ぐために30秒ごとにパケットを送信することが必要であると述べられている Google ChromeのQUICの実装 “QUICHE” では15秒おきにPING Frameを送信してNATのタイムアウトを防いでいる Manageability of the QUIC Transport ProtocolではQUICは30秒のタイムアウトで動くように作られているが、それでも最低2分のタイムアウト値にするように求めている QUICとNATと - janog48-lt4-kawakami.pdf UDPというコネクションの概念がないプロトコルを使う以上、GoogleやCloudflare CDNのサービスを利用する方 ~~(全員じゃんというツッコミは以下略)~~ はできる限りIPv6を使えるようにし、大人の事情でIPv4シングルスタックになってしまったVLANにはマルチセッションでポート数を増やす方向で対処すべきだ。どうしようもない場合は実際のQUIC実装のKeep-Aliveより長いタイムアウトにーー40秒くらいに設定されたHGWが夢に出てきたことがある。「IPv6のQUICはOKだけど、IPv4はNG」という意見 IPv6とゲームの課題に向き合ったJAIPAのゲーム・エンタメWGの活動とは？ (4/4) HTTP/3対応Webサイトにアクセスしようとしたときに途中経路でUDP443が塞がれていたときのクライアントの挙動はどうなりますか？ ➢ TCPとHappy Eyeballsを行うので最初から塞がれている場合はTCPにフォールバックすることで通信ができる QUICについて話そう JANOG49 Meeting え! QUIC無効化するの？ HTTP over QUIC or TCPの接続選択を考える \| by Jun-ya Kato \| nttlabs \| Medium ICMP`ping`は60秒
nat descriptor address outer 1000 ipcp - nat descriptor masquerade incoming 1000 reject + nat descriptor masquerade incoming 1000 discard	NAPTテーブルにないインターネットからのInbound方向のパケットは`reject`、iptablesの`REJECT --reject-with tcp-reset`相当の動作にしたい。 PoC/README.md at master · sebres/PoC しかし、攻撃者にTCP RSTを返すことで「Listenすらしてません！そこにサービスはありません！」と表明するのは0-1023/tcpのみで、他は「FWでLAN守ってます」感が滲み出てしまう`discard`、iptablesの`DROP`と同じ動作になってしまう。結局デフォルトの`reject`から`discard`へ変更した。 23.10 外側から受信したパケットに該当する変換テーブルが存在しないときの動作の設定何もListenしないダミーのLinuxマシンに`forward`するとか、LOOPBACKインタフェースを使うとか、`nat descriptor masquerade static`を数万行書けば再現できるかもしれない(他力本願寺)が、設定を間違えると大惨事なのでやめておく。
- nat descriptor masquerade port range 1000 60000-64095 49152-59999 44096-49151 + nat descriptor masquerade port range 1000 32768-65534	NAPTでは CPE用途では、最初のポート範囲を使い切るのも困難と思うが...。 23.11 IP マスカレードで利用するポートの範囲の設定
~~ nat descriptor address outer 20000 map-e	Web GUIでv6プラスやOCNバーチャルコネクトを選択すると、外側アドレス(グローバルIPアドレス)に`map-e`が設定され、マップルールに従って利用可能なポート範囲が取得される。環境によってはマップルールを許可するパケットフィルタが必要だ。 IPv4 PPPoEでは`ipcp`で外側アドレスを取得する。 23.5 NAT 処理の内側 IP アドレスの設定 23.4 NAT 処理の外側 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ディスクリプタ番号`1000`のIPv4 PPPoE NATディスクリプタ番号`20000`のIPv4 over IPv6 (動的IP契約) のマルチセッションを想定
nat descriptor type 1000 masquerade + nat descriptor masquerade static 1000 1 192.168.102.2 tcp 25565	NAPTされた非対称ネットワークの場合、グローバルIPアドレス:25565宛に接続してきても、LANのどの端末にマッピングすればよいか分からない。そこで静的NAPTを設定すると、特定のポート/プロトコル宛のInbound通信を特定の端末に宛てられる。 23.8 静的 IP マスカレードエントリの設定サーバ公開用に用意したVLAN内にあるサーバ機のプライベートIPアドレスが`192.168.102.2`と想定。 IPv4 PPPoEで`25565/tcp`を待ち受ける前提で説明しているが、Minecraftに限って言えばポート番号を含められるSRVレコードに対応しているため、25565番でなくともよい。所有しているドメインにSRVに対応した権威DNSを使用していて、任意のポートに対応したサービスなら、CGNATでなければIPv4 over IPv6でもサーバを公開できる。 e.g. if `_minecraft._tcp.example.com` Protocol - wiki.vg
# # 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)に穴あけが必要。 41255番は、インターネット上のあらゆるクライアント``からLAN内のサーバ`192.168.102.2`に、プロトコル`tcp`であらゆる(エメフェラル)ポート``からサーバの`25565`ポート宛の通信を許可するフィルタを定義し、syslogに残す`pass-log`。これをPPインターフェースのInbound方向`ip pp secure filter in`に適用する。 UDPを使用するBedrock Editionに比べ、TCPを使用するJava Editionが詐称パケットを使った攻撃に晒されるリスクは低いと思うが、BCP38/84など、基本的なパケットフィルタ設定もお忘れなきよう。サーバからクライアントへのOutbound方向の戻りパケットは、既存の動的フィルタで許可される。
# # 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番のフィルタで`25565/tcp`からの通信を定義し、`ip route default gateway`でPP1をサーバ専用、その他のインターネットはIPv4 over IPv6トンネルを使うように設定する例。その他のインターネットのパフォーマンスを最大化したい場合は、ロードバランスも可能。

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 DNS8.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

↑	ip pp secure filter out [ip filter 200013] [200020]...
PP (LAN2)
↓	ip pp secure filter in [ip filter 200003] [200020]...
ip route *** gateway?
↑	ip lan1 secure filter in
LAN1
↓	ip lan1 secure filter out

IPパケット・フィルタリング機能のインタフェースへの適用位置 5. ローカルルータの内部機能の位置関係(Rev.4系) FAQ for YAMAHA RT Series / IP Packet Filter

重複した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 フィルタの適用
HTTPS443/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
QUIC443/udpはip filter dynamicで使えるmnemonicがないので、静的フィルタip/ipv6 filterで定義した80000番を参照する。
RTシリーズでサポートしているニーモニック / 動的フィルター mnemonic table
パケットの多いHTTPwww(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 address192.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トンネリング

Protocol Numbers

#
# 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 CE
Example of URI: https://rule.map.ocn.ad.jp/?ipv6Prefix=2400:4050:XXX:&ipv6PrefixLength=YY&code=Abag9k2RFgerkljgsirSDEFgwada

IP Addressing: NAT Configuration Guide, Cisco IOS Release 15M&T - Mapping of Address and Port Using Encapsulation [Cisco ASR 1000 Series Aggregation Services Routers] - Cisco

Specifications	Remarks
URI `https://rule.map.ocn.ad.jp/?ipv6Prefix=<address>&ipv6PrefixLength=<prefixLength>&code=<API Key>`	Embed `<IPv6 address>` and `<prefix length>` allocated to CE Example 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	IEEE 802.1Qタグを使ったタグVLAN環境を設定する。タグVLANではRTXのスイッチインターフェースLAN1はトランクポート動作となり、RTXの有線LANポートに挿した端末側で参加するVLANを選べてしまう。 IEEE 802.1QおよびマルチSSID機能のあるWLXなどの無線アクセスポイントでは、SSID毎に異なるタグVLANを設定し、アクセスポート相当の動作となる。 LANポート設定つまり、他のVLAN対応機器と連携したVLAN環境はタグVLANを、RTX単体でアクセスポートを作れないと目的を果たさないならLAN分割機能を使えばよい。スイッチインターフェースLAN3があるRTX1220などは、一応LAN分割機能を併用してアクセスポートをつくれる。まあこの辺りはマネージドL2スイッチの領分だろう。 VLANで使うIPアドレスの決め方クラスCのプライベートIPアドレス`192.168.100.1/24`の3オクテット目が`100`-`103`なのは、CIDR表記で`192.168.100.0/22`で括りやすく、パケットフィルタを書きやすいからだ。 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アドレスに使える範囲は決まっているので、その中から選んで設定しよう。 IANA IPv4 Special-Purpose Address Registry VLANのIPパケットフィルタ設定を見ると、`secure filter in/out`のどちらがOutbound/Inboundか要領を得ない。これはエンドポイント視点ではなく、ネットワークの中間にいる RTX視点で`in/out` を命名しているからだ。例えば`vlan lan1/2`内にいるホスト`192.168.102.64`視点でパケットの動きをみると、以下のようになる。ホストから送信された他VLAN宛のパケットは、LAN側インターフェースに入っていき`ip lan1/2 secure filter in`、LAN側インターフェースを出ていく`ip lan1 secure filter out`。インターネット宛のパケットは、LAN側インターフェースに入っていき`ip lan1/2 secure filter in`、WAN側インターフェースからインターネットに出ていく`ip pp/tunnel secure filter out`。戻りパケットがWAN側インターフェースに入り`ip pp/tunnel secure filter in`、LAN側インターフェースを出ていく`ip lan1/2 secure filter out`。同一VLAN宛のパケットは、L3ではなくL2で通信するので、ルータ・IPパケットフィルタではなくRTXのスイッチ・Ethernetフィルタで処理される。同一セグメント内の通信をフィルタしたい場合、マネージドL2スイッチが別途必要。Wi-Fi APに搭載される「プライバシーセパレータ」もシンプルではあるが同じくL2分離の一種。因みに、L2TP/IPsecリモートアクセスVPNで接続された(`vlan lan1/2`内にいない)ホスト`192.168.102.64`視点でパケットの動きをみると、以下のようになる。他VLAN宛のパケットは、PP ANONYMOUSインターフェースに入り`ip pp secure filter in`、LAN側インターフェースを出ていく`ip lan1 secure filter out`。同一セグメント宛は、LAN側インターフェースを出ていく`ip lan1/2 secure filter out`。L3 VPNなので同一セグメントであろうとルータ・IPパケットフィルタで処理される。このことから、`ip lan1/N secure filter in/out`いずれか一方でフィルタすればよさそうだ。 VLANに限らず、送信元詐称パケットは送信元でないと見分けがつかないので、インターネット: ISPのルータリモートアクセスVPN: `pp anonymous`インターフェースの`ip pp secure filter in` VLAN: `ip/ipv6 lan1/N secure filter in` でフィルタした方がよい。この項では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	DHCPスコープの追加
# # 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 * *	`lan1 secure filter in`はRTXへのSSHやWeb GUI接続に影響するので適用には注意が必要。最後まで読んでから、一度に適用しないと詰む。 IPパケット・フィルタリング機能のインタフェースへの適用位置 5. ローカルルータの内部機能の位置関係(Rev.4系) FAQ for YAMAHA RT Series / IP Packet Filter OutboundのIngress Filteringを設定 RTXを経由するVLAN間はデフォルトでL3ルーティングされるため、WAN側との通信のみ許可する必要がある。 `> show ip route detail \| grep implicit Searching ... 192.168.100.0/24 192.168.100.1 LAN1 implicit 192.168.101.0/24 192.168.101.1 LAN1/1 implicit 192.168.102.0/24 192.168.102.1 LAN1/2 implicit 192.168.103.0/24 192.168.103.1 LAN1/3 implicit` 57.4 IP の経路情報テーブルの表示 implicit経路を弄るのは難しそうなので、VLAN間通信の破棄にはIngress Filteringに使ったBogonフィルタを、WAN側との通信の許可には推奨フィルタに修正に使った既存のフィルタを適用するする。LAN2/PP/TunnelのようなWAN側インターフェースとInbound/Outboundの向きが逆なので、`lan1/N secure filter in/out`ではあべこべに適用する形になる。例えば`lan1/2 secure filter in/out`に適用されたBogonフィルタ`...,192.168.0.0/16,...`に`192.168.102.0/24`が含まれるが問題ない。同じVLAN内はL2スイッチで通信するため、ルータ`secure filter in/out`を通ることはないからだ。ヤマハの設定例と異なり、implicit経路だけでなくBCP38/84もケアするため、VLAN構成を変えても設定変更が不要だ。 ※部門間の通信を遮断する場合、次のフィルターを設定します。 ip vlan1 secure filter in 1041 1042 1043 1044 1045 1046 1047 3000 部門ごとに社内ネットワークを構成する(LAN1ポートをポート別に分ける) Implementing BCP38 - BGP.guru `lan1/N secure filter in`にBogonフィルタを適用するため、`lan1/N`を通らないRTX本機を信用するなら`lan2/pp/tunnel secure filter out`には不要。NetBIOS over TCP/IPも同様だ。ただし、Ingress Filteringの考えに沿えば、VLAN間同様にL3ルーティングされるVPNも一つのVLANインターフェースと見做してフィルタすべきだ。 InboundのIngress Filteringの調整 VLANを切る前の送信元アドレスはLAN1の範囲`192.168.100.0/24`だが、VLANを切った後は`192.168.100.0/22`の範囲をとり得る。`lan2/pp/tunnel secure filter in`でBogonフィルタを使っているなら設定変更は不要だが、`ip filter 200003 reject 192.168.100.0/24 * * * *`を使っているなら範囲を調整する必要がある。
# # 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側との通信すら開始できない。 DHCPサーバへのDHCP Discover, Request`UDP 0.0.0.0:68 > 255.255.255.255:67`, `UDP 192.168.102.64:68 > 192.168.102.1:67`, DHCPサーバやリレーエージェントからのDHCP Offer, ACK`UDP 192.168.102.1:67 > 255.255.255.255:68`, `192.168.102.64:68`は、RTXのDHCPサーバを使う以上ルータ`lan1/2 secure filter in/out`を通るので、許可する必要がある。動的フィルタ`ip filter dynamic`は対応していないので、静的フィルタ`ip filter`で書く。 RTシリーズでサポートしているニーモニック / UDPポート番号 mnemonic table 以下は設定できますが、動的フィルターとして動作しません dhcpc/dhcps/dhcpv6c/dhcpv6s 8.1.14 動的フィルターの定義 VLANを越えて、RTX本機で稼働するDNSリカーシブサーバ, SNTPサーバへの接続を許可する。 DNSはソースポートランダマイズを行う性質上、動的フィルタとは相性が悪く遅延の増加に繋がるため、DHCPとは異なる理由で静的フィルタ`ip/ipv6 filter`を使う。 `ip filter`で`pass-log`されたDNSパケットはFQDNがログ`syslog notice on`に残る一方、`ipv6 filter`では分からない違いがある。この仕様を踏まえて、DHCPやDHCPv6, RDNSSを設定するとよい。 DNSやSNTPサーバのアクセス制限の変更も忘れずに。 24.13 DNS サーバーへアクセスできるホストの設定 41.2 SNTP サーバーへのアクセスを許可するホストの設定
# # 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	管理VLAN・DHCPスコープ(`192.168.100.0/24`のうち、`192.168.100.0/26`)からのSSH`22/tcp`, HTTP(Web GUI)`80/tcp`, iperf3`5201/tcp`の越境をざっくり許可する例。動的フィルタ`ip filter dynamic`の`filter`句に静的フィルタ`ip filter`を指定しつつ、静的フィルタも適用しているのは、動的フィルタのトリガーとなるパケットを静的に通す必要があるからだ。ちょうどヤマハの推奨フィルタのように。 `filter`句に設定された`ip filter`の`pass/reject`, 送信元/宛先IPアドレスは無視されるが、トリガーに使うので正確に指定している。なお、ip filter コマンドの IP アドレスは無視される。 pass/reject の引数も同様に無視される。 8.1.14 動的フィルターの定義ログが二重に記録されてしまうため、いずれか一方だけ`pass-log`なり`syslog=on`すればよいが、動的フィルタなら新たにフローが追加されたときだけログに記録されるため、実際の"開き戸"の状態を表している一方、静的フィルタならTCP/SYN`tcpsyn`が許可されればログに記録されるため、既に開放された"開き戸"を通過したときも含まれる。本来TCPは2時間4分待つべきだが、"開き戸"の開放は最小限にしたい。VLAN越えのホストに限りKeep-Alive`ServerAliveInterval 5`に設定し、タイムアウト`timeout=6`もそれに合わせた。 TCPKeepAlive yes Host hoge User fuga HostName 192.168.102.2 IdentityFile ~/.ssh/ssh_id_ed25519 ServerAliveInterval 5 ssh - What do options `ServerAliveInterval` and `ClientAliveInterval` in sshd_config do exactly? - Unix & Linux Stack Exchange 動的フィルタの状態は下記コマンドで確認できる。ちょうど`netstat`のように。 `> show ip connection detail lan1 LAN1[in] ID FILTER T APPS P INITIATOR D RESPONDER S 61495 222222 T 192.168.100.2:59385 > 192.168.102.2:22 E 61570 222222 T 192.168.100.2:59384 > 192.168.100.1:22 E > show ip connection detail lan1/2 LAN1/2[in] inspecting no sessions LAN1/2[out] ID FILTER T APPS P INITIATOR D RESPONDER S 61537 222222 T 192.168.100.2:59385 > 192.168.102.2:22 E` 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	`lan1`, `lan1/1`から`lan1/2`のプリンタを使えるようにする例。LPR (RFC 1179 準拠)`515/tcp`, 標準ポートモニター`9100/tcp` TCP/IP の標準ポートモニター - Windows Server \| Microsoft Learn LPRプロトコルと標準TCP/IPポート・モニタの違い：Tech TIPS - ＠IT TCPやUDPにおけるポート番号の一覧 - Wikipedia プリンターの接続方法（LPD/RAW） - Canon - Satera LBP6600 - ユーザーズガイド Standard TCP/IPポートの追加方法 : 富士通アイソテック管理VLAN内の端末から`lan1 secure filter in`(不要)に入り`lan1/2 secure filter out`からプリンタへ出ていく。その戻りパケットは動的フィルタが通す。家族VLAN内の端末から`lan1/1 secure filter in`に入り`lan1/2 secure filter out`からプリンタへ出ていく。その戻りパケットは動的フィルタが通す。
# # 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のみだから`lan1/1-3`がGUAを持つことはない。しかしIPv4シングルスタックなVLANに居る端末も基本的にはIPv6に対応しており、IPv6は複数のユニキャストアドレスを持てるため、`/64`より広い範囲のULAを使うとIPv6でのVLAN越え通信が不可能ではない。 `> show ipv6 route detail \| grep implicit Searching ... 2001:db8:b0ba:10ee::/64 - LAN1 implicit - LAN2 implicit fdca::/64 - LAN1 implicit` 57.6 IPv6 の経路情報の表示 DHCPv6-PD環境ではすべてのVLANをIPv4/IPv6デュアルスタックにできるので、有効活用したい。設定例6：タグVLAN併用 DHCPv6-PD IPv6 IPoE対応機能 VLAN間通信を破棄するのはIPv4と同じくBogonフィルタでよい。IPv4のDHCP`57-58/udp`に相当するNDP(ICMPv6 Type 133-136)やDHCPv6(546-547/udp)を許可するフィルタは、ちょうどRAプロキシのWAN側パケットフィルタと同様になるはずだ。 Outbound方向の`ipv6 lan1/N secure filter in`に適用されている62100番にRA(ICMPv6 Type 134)がないのが重要だ。L2分離されていれば、`lan1/N`内から発せられる不正なRAに他の端末が惑わされることはない。 Cisco IOS リリース 15.2(7)Ex（Catalyst 1000 スイッチ）セキュリティコンフィギュレーションガイド - IPv6 RA ガードの設定 [Support] - Cisco

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の書き方（我流ｗ） - 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設定の変更箇所説明

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	11.1 相手の名前とパスワードの設定 L2TPではVJC圧縮とCCP圧縮が使える。 11.9.1 Van Jacobson Compressed TCP/IP 使用の設定 11.11.1 全パケットの圧縮タイプの設定 `ip pp remote address pool`をDHCPスコープの範囲に被せてしまうと、セキュリティホールになり得るProxy ARP`ip lan1/N proxyarp on`が必要なので、範囲からずらしてある`192.168.100.128-192.168.100.159`。つまり、DHCPスコープからアドレスを選びIPCPで自動設定する`dhcp`, `dhcpc lan1/N`指定はあまりよくない。DHCPスコープの`bind-only`も無視されるので使いどころがない。 8.1.28 代理 ARP の設定 DHCPRTX830はVPN対地数20, アドレスプール最大設定可能数32(IPv4 over IPv6で1消費？)を超えて設定できない。 8.2.2 リモート IP アドレスプールの設定トンネルの数(VPNの対地数)に制限はありますか？ documents for Security Gateway and IPsec リモートアクセスVPNでは、通信経路上にNAT/CGNATがない状況はまず考えられないため、NAT越え`nat-traversal`を常に有効にする。 IPsec NATトラバーサル外部仕様書 15.47.5 IPsec NAT トラバーサルを利用するための設定 TunnelインターフェースMTUは、フレッツIPv4 PPPoEのオーバーヘッドで1454bytes、NATトラバーサルや暗号/認証アルゴリズムなどのオーバーヘッドを引く。 8.1.4 インタフェースの MTU の設定 RTXで指定できる中で最も強力な暗号/認証アルゴリズムに変更し、 15.47.2 SA のポリシーの定義 NATトラバーサルも加味すると`ip pp mtu 1354`になると思うが、 `1454 - 16(SHA256) - 16(AES256) - 8(ESP) - 8(NAT-T) - 20(IPv4) = 1386` `( 1386 / 16 の整数部) x 16 - 2 = 1374`bytes IPsec 備忘録 \| KUSONEKOの見る世界 IPsec/IKE : FAQ : UNIVERGE IXシリーズ \| NEC MTU / MSS を最適化する \| yabe.jp ESPのトンネルモードで暗号化したときにIPパケットは何バイト長くなりますか？ documents for Security Gateway and IPsec しかし、iPhoneはIPsecインターフェースMTUが1280らしいので、結局デフォルト値のままとする。 Win10でNVR500 L2TP/IPsec VPNへ接続した時のMTUを確認 - rabbit51 IKEキープアライブの間隔や試行回数が大きいと、移動体で再試行が遅れるため小さめに設定している。 IPsec の手始めに IKE Keepalive を理解しましょ - インフラまわりのプロになりたい 15.19 IKE キープアライブ機能の設定 16.3 L2TP トンネルの切断タイマの設定
# # 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	L3 VPN接続からの通信はIPパケットフィルタで管理できる。 IPパケット・フィルタリング機能のインタフェースへの適用位置 7. セキュリティゲートウェイ機能とIPパケットフィルタの適用位置(Rev.4系以降) FAQ for YAMAHA RT Series / IP Packet Filter `ip pp secure filter in/out`はVLAN間パケットフィルタとほぼ同一で、IPCPが配布しうる範囲`192.168.100.128/27`からの同一セグメントのSSH`22/tcp`, EpgTimer`5510/tcp`のみ許可している。VLANを切っているなら、VLANインターフェースに限らずVPNのインターフェースからもVLAN越え通信が発生しうることをお忘れなきよう。 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 拡張`ppp ipcp msext`, `dns notice order msext`でDNSリカーシブサーバを通知する。 11.9.8 IPCP の MS 拡張オプションを使うか否かの設定 24.6 DHCP/DHCPv6/IPCP MS 拡張で DNS サーバーを通知する順序の設定
# # 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	L2TP/IPsecには少なくとも`500/udp`, `4500/udp`を使用するため、IPv4 over IPv6(動的IP)は使えない。任意のポート番号が使える固定IP契約に変更するか、IPv4 PPPoEとのマルチセッションが必要。ロードバランスとも共存可。 iOS/AndroidはIPv6でのリモートアクセスに対応していないようだ。IPv4 PPPoEのスループットに問題があるなら、NTEガチャを試してみよう。 SoftEther VPNによるVPN環境構築(14) L2TP/IPsecにおけるIPv6対応 \| Solomonレビュー[redémarrage] UDPの500番はIKEを通すために必要で、 UDPの4500番もNATトラバーサルで発生するパケットを通すために必要です。 NATトラバーサルを使う限り、ESPパケットは発生しないので、ESPの設定は不要です。 IPsec NATトラバーサル外部仕様書 `500/udp`, `4500/udp`はwell-known portsなのでそれなりにスキャンが来る。接続元アドレス`203.0.113.0/24`が限られているなら絞ったほうがよい。 `ipsec transport 2 1 udp 1701` L2TP制御メッセージおよびL2TPデータパケットはESPパケットとして受信するため、ヤマハルーターのインターネット接続しているインタフェースにNATが設定されている場合でも、静的IPマスカレードでESPのポート番号を自身のIPアドレスに割り当てておけば、L2TPで使用するポート番号(1701など)を静的IPマスカレードで自身のIPアドレスに割り当てる必要はありません。ただし、L2TPパケットを送信する場合にはトランスポートモードのESPで暗号化する必要があるため、L2TPで使用するポート番号をトランスポートモードで処理する設定を追加する必要があります。 L2TP/IPsec 15.49.1 トランスポートモードの定義 Web GUIでリモートアクセスVPNを設定した際、マルチホーム環境の静的経路`ip route default gateway`はケアされない。パケットフィルタで接続元アドレス`203.0.113.0/24`を絞っているなら、デフォルトゲートウェイの`filter`句を使わなくとも、接続元への静的経路を設定すればよい。 `console info on`なターミナルに`[IKE] respond ISAKMP phase`が繰り返されるときは、クライアントからのパケットはRTXに届いているので、NAT越えや戻りパケットの静的経路を見直そう。一時的に`sysylog debug on`すると詳細がわかる。 VPN(L2TP/IPsec)接続ができない FAQ for YAMAHA RT Series / 障害切り分け手順

#
# 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

11.1 相手の名前とパスワードの設定

L2TPではVJC圧縮とCCP圧縮が使える。
11.9.1 Van Jacobson Compressed TCP/IP 使用の設定
 11.11.1 全パケットの圧縮タイプの設定
ip pp remote address poolをDHCPスコープの範囲に被せてしまうと、セキュリティホールになり得るProxy ARPip lan1/N proxyarp onが必要なので、範囲からずらしてある192.168.100.128-192.168.100.159。つまり、DHCPスコープからアドレスを選びIPCPで自動設定するdhcp, dhcpc lan1/N指定はあまりよくない。DHCPスコープのbind-onlyも無視されるので使いどころがない。
8.1.28 代理 ARP の設定
DHCPRTX830はVPN対地数20, アドレスプール最大設定可能数32(IPv4 over IPv6で1消費？)を超えて設定できない。
8.2.2 リモート IP アドレスプールの設定
 トンネルの数(VPNの対地数)に制限はありますか？ documents for Security Gateway and IPsec
リモートアクセスVPNでは、通信経路上にNAT/CGNATがない状況はまず考えられないため、NAT越えnat-traversalを常に有効にする。
IPsec NATトラバーサル外部仕様書
 15.47.5 IPsec NAT トラバーサルを利用するための設定
TunnelインターフェースMTUは、フレッツIPv4 PPPoEのオーバーヘッドで1454bytes、NATトラバーサルや暗号/認証アルゴリズムなどのオーバーヘッドを引く。
8.1.4 インタフェースの MTU の設定
RTXで指定できる中で最も強力な暗号/認証アルゴリズムに変更し、
15.47.2 SA のポリシーの定義
NATトラバーサルも加味するとip pp mtu 1354になると思うが、
1454 - 16(SHA256) - 16(AES256) - 8(ESP) - 8(NAT-T) - 20(IPv4) = 1386
( 1386 / 16 の整数部) x 16 - 2 = 1374bytes
IPsec 備忘録 | KUSONEKOの見る世界 IPsec/IKE : FAQ : UNIVERGE IXシリーズ | NEC
MTU / MSS を最適化する | yabe.jp
ESPのトンネルモードで暗号化したときにIPパケットは何バイト長くなりますか？ documents for Security Gateway and IPsec
しかし、iPhoneはIPsecインターフェースMTUが1280らしいので、結局デフォルト値のままとする。
Win10でNVR500 L2TP/IPsec VPNへ接続した時のMTUを確認 - rabbit51
IKEキープアライブの間隔や試行回数が大きいと、移動体で再試行が遅れるため小さめに設定している。
IPsec の手始めに IKE Keepalive を理解しましょ - インフラまわりのプロになりたい
 15.19 IKE キープアライブ機能の設定

16.3 L2TP トンネルの切断タイマの設定

#
# 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

L3 VPN接続からの通信はIPパケットフィルタで管理できる。
IPパケット・フィルタリング機能のインタフェースへの適用位置 7. セキュリティゲートウェイ機能とIPパケットフィルタの適用位置(Rev.4系以降) FAQ for YAMAHA RT Series / IP Packet Filter
ip pp secure filter in/outはVLAN間パケットフィルタとほぼ同一で、IPCPが配布しうる範囲192.168.100.128/27からの同一セグメントのSSH22/tcp, EpgTimer5510/tcpのみ許可している。VLANを切っているなら、VLANインターフェースに限らずVPNのインターフェースからもVLAN越え通信が発生しうることをお忘れなきよう。

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 拡張ppp ipcp msext, dns notice order msextでDNSリカーシブサーバを通知する。
11.9.8 IPCP の MS 拡張オプションを使うか否かの設定
 24.6 DHCP/DHCPv6/IPCP MS 拡張で DNS サーバーを通知する順序の設定

#
# 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

L2TP/IPsecには少なくとも500/udp, 4500/udpを使用するため、IPv4 over IPv6(動的IP)は使えない。任意のポート番号が使える固定IP契約に変更するか、IPv4 PPPoEとのマルチセッションが必要。ロードバランスとも共存可。
iOS/AndroidはIPv6でのリモートアクセスに対応していないようだ。IPv4 PPPoEのスループットに問題があるなら、NTEガチャを試してみよう。
SoftEther VPNによるVPN環境構築(14) L2TP/IPsecにおけるIPv6対応 | Solomonレビュー[redémarrage]

UDPの500番はIKEを通すために必要で、 UDPの4500番もNATトラバーサルで発生するパケットを通すために必要です。 NATトラバーサルを使う限り、ESPパケットは発生しないので、ESPの設定は不要です。
IPsec NATトラバーサル外部仕様書

500/udp, 4500/udpはwell-known portsなのでそれなりにスキャンが来る。接続元アドレス203.0.113.0/24が限られているなら絞ったほうがよい。

ipsec transport 2 1 udp 1701

L2TP制御メッセージおよびL2TPデータパケットはESPパケットとして受信するため、ヤマハルーターのインターネット接続しているインタフェースにNATが設定されている場合でも、静的IPマスカレードでESPのポート番号を自身のIPアドレスに割り当てておけば、L2TPで使用するポート番号(1701など)を静的IPマスカレードで自身のIPアドレスに割り当てる必要はありません。ただし、L2TPパケットを送信する場合にはトランスポートモードのESPで暗号化する必要があるため、L2TPで使用するポート番号をトランスポートモードで処理する設定を追加する必要があります。 L2TP/IPsec

15.49.1 トランスポートモードの定義

Web GUIでリモートアクセスVPNを設定した際、マルチホーム環境の静的経路ip route default gatewayはケアされない。
パケットフィルタで接続元アドレス203.0.113.0/24を絞っているなら、デフォルトゲートウェイのfilter句を使わなくとも、接続元への静的経路を設定すればよい。
console info onなターミナルに[IKE] respond ISAKMP phaseが繰り返されるときは、クライアントからのパケットはRTXに届いているので、NAT越えや戻りパケットの静的経路を見直そう。一時的にsysylog debug onすると詳細がわかる。
VPN(L2TP/IPsec)接続ができない
 FAQ for YAMAHA RT Series / 障害切り分け手順

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>	`UserDefinedName` VPN設定の名前(必須) `PayloadDisplayName` `PayloadOrganization` `PayloadIdentifier` `PayloadUUID` ユニークなPayloadUUIDを指定する。構成プロファイルを更新するとき、同一であれば上書きされる。 `VPNType` L2TP
	`IPSec` VPN.IPsec \| Apple Developer Documentation `AuthenticationMethod` `ipsec ike pre-shared-key`で指定した事前共有鍵を使う`SharedSecret` `PPP` VPN.PPP \| Apple Developer Documentation `pp auth username`で指定した`AuthName`と`AuthPassword`を設定 `CommRemoteAddress` Netvolante DDNSで取得したアドレスを指定 `DisconnectOnIdle`, `DisconnectOnIdleTimer` 無通信時に切断する
	`IPv4` VPN.IPv4 \| Apple Developer Documentation `OverridePrimary` すべての通信をVPN経由で送る VPN.VPN VPN.VPN \| Apple Developer Documentation `EnforceRoutes`, `ExcludeLocalNetworks`, `IncludeAllNetworks` 外出先からプライベートIPアドレスのサーバにSSHしたり、DNSシンクホールを利用したいため、全ての通信をVPNに含める。ローカルネットワークを除外できるようだが、通常のインターネットを除外するAndroidでいうところの転送ルート、Windowsの`Add-VpnConnectionRoute`相当の動作はできなさそう。DHCPを使わないので、Classless Static Routes Option 121を渡すこともできない。【Windows】指定した宛先の通信のみVPN経由にする - Qiita `OnDemandEnabled` OnDemand VPNを設定すると、家のWi-Fiに繋いでいるときだけVPNを切り、モバイルデータ通信や公衆Wi-Fiを使用するときに自動的にVPNに繋がるようになる。 `OnDemandRules` 複数の自動接続/切断ルールを定義できる。 VPN.VPN.OnDemandRulesElement \| Apple Developer Documentation `InterfaceTypeMatch` 有線`Ethernet`, `WiFi`, モバイルデータ通信`Cellular` 接続時に `SSIDMatch` `WiFi`のSSIDが一致したときに `Action` 接続`Connect`, 切断`Disconnect`, VPN.VPN.OnDemandRulesElement.ActionParameters(AndroidのVPN設定における"DNS検索ドメイン"動作に近い？)を都度評価して接続`EvaluateConnection`, 接続/切断状態をそのままにする`Ignore`

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を使わないかマルチホーミングすることで軽減可能だ。
24.1 DNS を利用するか否かの設定
オープンリゾルバにならないよう、パケットフィルタ側で設定が必要。念のためインターフェースも絞っておく。
VLAN環境ではlan1をlanなどに変更する。
24.13 DNS サーバーへアクセスできるホストの設定
 オープンリゾルバー(Open Resolver)に対する注意喚起について FAQ for YAMAHA RT Series / Security
24.16 DNS フォールバック動作をルーター全体で統一するか否かの設定
キャッシュポイズニング対策のソースポートランダマイズに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,...

24.11 静的 DNS レコードの登録
 静的DNSレコード
24.10 DNS 問い合わせの内容に応じた DNS サーバーの選択
 iOS 14/macOS 11対応
内部データベース参照型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	普段利用しているウェブサイトが、どれだけトラッカーを芋づる式に読み込んでいるのかを視覚化してくれるサービス。 1ページ見るためにどれだけストーカーされれば良いんじゃｗ FouAnalytics - Ads By Domainhttps://t.co/SnZshONa43 pic.twitter.com/5mKC3P64qL — しばにゃん (@shibanyan_1) January 26, 2022
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プライバシーレポート見出しにジャンプ

iOS 15.2で使える Appプライバシーレポートで 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 cache55.4.11 DNS キャッシュのクリア
- iOS, Android: 端末の再起動
- Windows: ipconfig /flushdns
- Firefox: about:networking#dns -> DNSキャッシュを削除
- Chromium Edge: edge://net-internals/#dns -> Clear host cache
セキュアでない接続を示すは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のDoHhttps://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
えぇ…
確かにTwitterはAnycastもECSも対応していない場合が多くて、そりゃCDNガチャの効果あるわけだなという感想https://t.co/nbVriNxVwx
— しばにゃん (@shibanyan_1) September 28, 2022

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!

iOS 14/macOS 11 のスタブリゾルバが HTTPS RR や CNAME を名前解決する様子を Wireshark でパケットキャプチャした — Apple iOS のスタブリゾルバが HTTPS RR や CNAME を再度問い合わせる様子を Wireshark でパケットキャプチャした

Apple iOSのスタブリゾルバはRFC 2181に倣って、CNAMEに付随するAAAA/Aレコードを再問い合わせする。ここでのClientはキャッシュDNS(フルリゾルバ)を指すと思うが、Appleはそれに近い実装を取り入れているようだ。

浸透いうな先生にRFC 2181を教えて頂いて、信頼次第でCNAMEを再検索する概念を知る
> 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/c9aaORfrKP https://t.co/G2J3u17dSA
— しばにゃん (@shibanyan_1) May 17, 2022

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機能)
優先制御のふるまい

制御できるのは出力トラフィックだけです。入力トラフィックを制御することはできません
帯域制御のふるまい

優先制御
 インターネットVPNと適応型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	NTPとICMPを最優先するために、クラス8(IP Precedence 7相当)に分類する。実際に機能させるには、併せて優先制御や帯域制御の設定が必要。 (帯域制御向け)パケット量はごく少ない
# # 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	Discordのボイスチャットをクラス7に分類。実際には50000番台を連番で使うことが多い。 DiscordさんはTwitterを使っています: 「@ghostcans891 You have to open port 443 TCP for textchat. For voice, it is a random UDP port between 50.000 - 65.535.」 / Twitter Discord使用時、パケットはやや多い
# # 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	TCPの3-way handshake(SYN, SYN-ACK, ACK)のうち、OutboundのSYNをクラス7に分類これにより、HTTP`80/tcp`やHTTPS`443/tcp`に限らず全てのTCPコネクションの開始が前倒しされ、RTTやサーバの応答時間待ちを有効活用できる。 mnemonic tableにないTCP Flagはtcpflagを用いて表現する。 INFS 3450 – Number Representation - Flags 2 TCP パケット量はあまり多くないが、`queue lan2 class filter list`が前から評価される際に、できる限り早く処理されてほしいので前の方へ。
# # 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	Minecraft Java Editionのマルチプレイをパケットキャプチャしたところ、プレイヤー入力と同時にPSH/ACKパケットが増加していたため、Outboundのそれらのパケット優先度を上げることで快適なプレイを実現する。 Minecraftサーバからの下りトラヒックはベストエフォートとなる。 `Flags: 0x018 (PSH, ACK) 000. .... .... = Reserved: Not set ...0 .... .... = Accurate ECN: Not set .... 0... .... = Congestion Window Reduced: Not set .... .0.. .... = ECN-Echo: Not set .... ..0. .... = Urgent: Not set .... ...1 .... = Acknowledgment: Set .... .... 1... = Push: Set .... .... .0.. = Reset: Not set .... .... ..0. = Syn: Not set .... .... ...0 = Fin: Not set [TCP Flags: ·······AP···]` Javaの仕様で、クライアント・サーバ共にIPv4/IPv6デュアルスタックでもIPv4が優先される以上、一般的にIPv6でMinecraftサーバが公開されることがないため、クラス分けフィルタは用意するものの使用していない`queue class filter 36`。 [MCL-15589] -Djava.net.preferIPv6Addresses=true is not default - Jira [MC-3776] IPv6 Does Not Work - Jira
# # 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	YouTube Liveの通信を優先する RTMP: `a.rtmp.youtube.com`, `b.rtmp.youtube.com` `1935/tcp` RTMPS: `a.rtmps.youtube.com`, `b.rtmps.youtube.com` `443/tcp` HLS: `a.upload.youtube.com`, `b.upload.youtube.com` `443/tcp` パケット量が多いので、ネットワークドロップが発生していないか配信ソフトで確認した方がよい。キュー長`queue lan2 length 200`が足りない場合は最後に調整しよう。
# # 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	非暗号化DNS`53/udp`の名前解決を優先する帯域は少ないが、それなりのパケット数がバーストしてくるので優先しすぎない。元々3-way handshakeより前に流れてくるパケットを常に優先して、他の通信を遅延させるメリットはない。 IPv4の宛先アドレスは通常Any`*`指定するが、HTTPS RRとDNSベンチマーク対応の設定を行った環境で範囲を絞るなら`1.1.1.1`
# # 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	TCP ACKをクラス3に分類し、輻輳時に帯域制御によりパケロスを期待する。 `Flags: 0x010 (ACK) 000. .... .... = Reserved: Not set ...0 .... .... = Accurate ECN: Not set .... 0... .... = Congestion Window Reduced: Not set .... .0.. .... = ECN-Echo: Not set .... ..0. .... = Urgent: Not set .... ...1 .... = Acknowledgment: Set .... .... 0... = Push: Not set .... .... .0.. = Reset: Not set .... .... ..0. = Syn: Not set .... .... ...0 = Fin: Not set [TCP Flags: ·······A····]` キューにたまったパケットの数がqueue interface length コマンドで指定した値を越えた場合、キューの最後尾、つまり最後に到着したパケットが破棄される 21.3 キューイングアルゴリズムタイプの選択 RTXをCPEとして利用する🤔場合、多少のパケロスは許容されるから、TCP ACKのパケットバッファ減らして輻輳時にパケットを落とすといったお行儀の悪い施策が可能だ。 D. TCP ACK Filtering TCP ACK filtering is an optimisation that has seen somepopularity in highly asymmetrical networks [19], and es-pecially in cable modem deployments [20]. Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways 1804.07617.pdf 注意点として、バッファに留まるパケットが多くなるほどレイテンシが大きくなります。そのため、バッファ容量を大きく持っていれば良いわけではないといえます。たとえば、コアスイッチではドロップさせないように深いバッファ容量を持った機器を設置し、アクセススイッチではレイテンシを考慮して過度にバッファ容量の大きくない機器を設置する第2回なぜデータセンタースイッチでないといけないのか？～支えます！サーバ、ストレージ～ \| ネットワンシステムズシーケンスが崩れるだけなので、優先制御には適用すべきでない。
# # 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 * *	`queue class filter 84 precedence ip`すべてのパケットのIP Precedence値をみる。Wi-Fiは無線QoS(WMM-EDCA)が前提の規格なので、RTX側でもL3マーキングを解釈する必要があるためだ。RTX830はDSCPに対応していないが、DSCPはIP Precedenceと下位互換性があるから問題ない。RTX1300, RTX1220, RTX1210は`dscp`指定可能なため、より正確なクラス分けが可能だ。無線のQoS(WMM)が効かない : WLX313 上記の`queue class filter`のクラス(IP Precedence +1)もまた、WMMに沿った割り当てになっている。 BRKEWN-2003.pdf - Cisco Live P.101 QoS – Working with IETF and Vendors QoS - DSCP（Differentiated Services Code Point）とは Type of Service (ToS) and DSCP Values - LinuxReviews AppleデバイスはCisco Fastlaneに対応しているが、WLXなど他社のAPに接続した場合にL2(CoS値)およびL3マーキング(IP Precedence, ToS, DSCP)がなされるか不明だ。 802.11eのWMM-EDCAは、このL3マーキングをみてアクセスカテゴリに分類するため、スマートデバイスでのVoIPの難しさ 1.NWでのQoSについて \| ネットワンシステムズ WiFi.QoSMarkingPolicyのQoSMarkingEnabledを有効(L3マーキングを無効化, Cisco Fastlane仕様にする)にも無効(Fastlaneでないとしか書かれていない、、、)にもしない(既定値)のが得策だろう。 A dictionary that contains the list of apps that are allowed to benefit from L2 and L3 marking. When this dictionary isn't present, all apps are allowed to use L2 and L3 marking when the Wi-Fi network supports Cisco QoS fast lane. WiFi.QoSMarkingPolicy \| Apple Developer Documentation `queue class filter`に該当しなかったベストエフォートは`queue lan2 class property 2`の影響を受ける。デフォルトクラスの設定を忘れると、デフォルトクラスに 100% の帯域が割り振られるため、対象とするクラスは常にデフォルトクラスより狭い帯域を割り当てられることになる。 26.10 クラスの属性の設定 `queue lan2 length`はむやみやたらに大きくすればよいというものではない。ピークが増大する中で、キュー長を闇雲に長くしてもBufferbloatが発生するだけだ。下記コマンドで確認しながら、優先されるべきパケットを"ある程度"優先しつつ、間に優先度の低いパケットもしっかり送出してキューが溜まりすぎないようにしつつ、TCP ACKで吸収しよう。 57.47 QoS ステータスの表示 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 キューを長くしたとき、パケットバッファの割り当てを超えてはならない。もし超えるなら設定変更が必要だ。多対地QoSの注意事項 57.46 パケットバッファの状態の表示 4.79 パケットバッファのパラメータを変更する YAMAHA RTX系統計グラフから機器固有の癖を読む - sidetech

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

次世代ネットワークインタフェース資料次世代ネットワークインタフェース資料 (IP通信網) - アプリケーションサーバ・網インタフェース (SNI) - 本編第 1.0 版 - NTT東日本 sni_1.0.pdf

	最優先クラス	高優先クラス	優先クラス	ﾍﾞｽﾄｴﾌｫｰﾄｸﾗｽ
ｻｰﾋﾞｽﾀｲﾌﾟﾌｨｰﾙﾄﾞ(IPv4)に設定する DSCP 値	101110	100000	001000	000000

	最優先クラス	高優先クラス	優先クラス	ﾍﾞｽﾄｴﾌｫｰﾄｸﾗｽ
ﾄﾗﾋｯｸｸﾗｽﾌｨｰﾙﾄﾞ(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
    ...

フレッツ光回線でscpが遅かった話 - Qiita

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

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 スーパーファウンダーズエディショングラフィックスカード

YAMAHA RTX830 をSSHで設定する

更新履歴 #見出しにジャンプ

RTX830を選んだ理由 #見出しにジャンプ

用意するもの #見出しにジャンプ

接続 #見出しにジャンプ

インターフェースの状態・リンク速度の表示 #見出しにジャンプ

CPUやメモリ使用率の表示 #見出しにジャンプ

Web GUI #見出しにジャンプ

ユーザーの設定 #見出しにジャンプ

Web GUIでconfigのエクスポート #見出しにジャンプ

SSH #見出しにジャンプ

パスワード認証でSSH #見出しにジャンプ

文字化け #見出しにジャンプ

コンソール表示文字数の設定 #見出しにジャンプ

コンソールにsyslogを表示 #見出しにジャンプ

ログレベル #見出しにジャンプ

エラー: このコマンドは管理レベルでのみ使用できます #見出しにジャンプ

設定の保存 #見出しにジャンプ

SSHの鍵認証 #見出しにジャンプ

telnet・Web GUIの無効化 #見出しにジャンプ

シャットダウン・再起動 #見出しにジャンプ

configの変更履歴 #見出しにジャンプ

外部メモリ #見出しにジャンプ

configやsyslogをsftpでバックアップ #見出しにジャンプ

RTXをWLXのsyslogサーバにするLuaスクリプト #見出しにジャンプ

インターネット接続 #見出しにジャンプ

IPv6 IPoE #見出しにジャンプ

ステートフルDHCPv6, ステートレスDHCPv6, SLAAC RDNSS #見出しにジャンプ

IPv4 over IPv6 #見出しにジャンプ

IPv4 PPPoE #見出しにジャンプ

マルチセッション #見出しにジャンプ

プッシュ通知はPPPoEで #見出しにジャンプ

ロードバランス #見出しにジャンプ

Luaで自動NNI/NTEガチャ #見出しにジャンプ

サービス情報サイト #見出しにジャンプ

PADIタイムアウト #見出しにジャンプ

DHCP #見出しにジャンプ

Wake On LAN #見出しにジャンプ

NTP #見出しにジャンプ

ntpsec-ntpdateでNTPのベンチマーク #見出しにジャンプ

定期的にNTPで時刻合わせ #見出しにジャンプ

NTPの時刻合わせの精度を向上させるLuaスクリプト #見出しにジャンプ

RTXをSNTPサーバにする #見出しにジャンプ

WindowsでRTXのSNTPを利用する #見出しにジャンプ

NAT #見出しにジャンプ

NAPT #見出しにジャンプ

ポート開放 #見出しにジャンプ

逆NAT #見出しにジャンプ

パケットフィルタ #見出しにジャンプ

重複したconfigの統合 #見出しにジャンプ

動的フィルタ #見出しにジャンプ

BCP38/84 #見出しにジャンプ

ICMP #見出しにジャンプ

IPIPとマップルール #見出しにジャンプ

NetBIOS #見出しにジャンプ

VLAN #見出しにジャンプ

タグVLAN #見出しにジャンプ

LAN分割機能 #見出しにジャンプ

リモートアクセスVPN #見出しにジャンプ

構成プロファイルでiPhoneを自動VPN接続 #見出しにジャンプ

Netvolante無料DDNS #見出しにジャンプ

STATUS LEDが消えない #見出しにジャンプ

DNSリカーシブサーバ #見出しにジャンプ

DNSシンクホール #見出しにジャンプ

トラッカーの調査 #見出しにジャンプ

Appプライバシーレポート #見出しにジャンプ

Firefox DevTools #見出しにジャンプ

静的DNSレコード #見出しにジャンプ

自動CDNガチャ #見出しにジャンプ

クエリ内容でDNSサーバを変える #見出しにジャンプ

フィッシングに使われるDDNSを一括拒否 #見出しにジャンプ

EDNS0とClient Subnet #見出しにジャンプ

iOS 14/macOS 11対応 #見出しにジャンプ

ホストによって参照するDNSサーバを変える #見出しにジャンプ

_dns.resolver.arpa #見出しにジャンプ

Luaで最速のDNSサーバに切り替える #見出しにジャンプ

QoS #見出しにジャンプ

帯域制御 #見出しにジャンプ

Dynamic Traffic Control #見出しにジャンプ

クラス分け #見出しにジャンプ