自宅のネット環境をYAMAHAのルータRTX830に入れ替え

今まで、自宅のネット環境は

のような形でした。

1台の物理マシンに、サーバとIPv6ルータの仮想マシンが2台共存し、一つのNICを使っていたので、IPv6の経路は輻輳していました。

最初は、IPv6でのサーバ公開を試すために使っていましたが、それがうまく動くようになったので、物足りなくなってきました。

そこで、今回、新しくヤマハのRTX830を購入です。

ヤマハのルータは1990年代にRTA50iという、ISDNルータを使ったことがあります。それで、NTTのフレッツの前のOCNエコノミーというISDNの常時接続サービスに使っていました。(ちなみに初めて買ったルータはAscend社製Pipeline25、これはISDN対応だったけどnatすらなかった)

RTA50i以降、お高いルータしか販売しなくなっちゃって、なかなか手が出なかったんですよね。

その後、サーバ自身にルータ機能をもたせたり、そのうち家庭用のルータの機能が上がってきたので、それで十分になったりして、ヤマハをルータを購入を検討することはありませんでした。

今回、IPv6を使うに当たって、家庭用ルータではまだまだ力不足なので、RTX830を購入することにしました。

RTX830はIPv&&IPv4ルータとして、このように配置します。今まで使っていた家庭用無線LANルータはブリッジモードにして、LANにぶら下げます。

RTX830の初期設定

RTX830にはシリアルコンソールがついているので、昔のようにシリアルケーブルでつないでTeratermからシリアル→COM1でつなげても良かったけど、Windowsパソコンにドライバをインストールするのが面倒だったので、IPアドレス192.168.100.1にwebでつなげて、設定です。

とりあえず、telnetとsshを使えるようにしておきます。

IPアドレスも変更しておきました。

> show config
# RTX830 Rev.15.02.14 (Thu Dec 19 10:43:21 2019)

早速つなげて、show configコマンドを打ってみると、ファームウェアのバージョンが古い!(画面では15.02.14ですが、当時は15.02.09でした。)

公式サイトから、ファームウェアをダウンロード、USBメモリに書き込んで

GUI画面からファームウェア更新です。

ファームウェア更新が無事に済んだら、細かい設定を入れておきます。

login user zeke *
user attribute zeke connection=serial,telnet,remote,ssh,sftp,http gui-page=dash board,lan-map,config login-timer=86400
console character ja.utf8
console lines infinity
console prompt [gw]
description lan1 LAN
ip lan1 address 192.168.1.254/24
description lan2 WAN
ip lan2 address 192.168.10.1/24
dns service fallback on
dns server 8.8.8.8 edns=on 8.8.4.4 edns=on
schedule at 1 */Sun 03:00:00 * ntpdate ntp.nict.jp syslog
pppoe pass-through member lan1 lan2
telnetd host lan1
httpd host lan1
sshd service on
sshd host lan1
sshd host key generate *
switch control mode off
  • ログインユーザを作成します。ログインタイマーは5分じゃ短いので、24時間にしておきました。
  • コンソールの漢字コードはUTFに、行数24行だと24行ごとに表示が止まるので無限に、プロンプトはホスト名と同じ[gw]にしておきます。
  • LAN1及びLAN2のIPアドレスの設定をします。LAN2はLAN内からホームゲートウェイと通信するために必要です。家庭用ルータだとWAN側にアドレスを振れないのでRTXの良いとこですよね。
  • dnsサーバはgoogleのものを指定します。LAN内のDNSサーバに障害があっても疎通確認できるように。
    2020/ 9/11追記 コメントでご指摘を受けたので、dnsサーバのオプションに「edns=on」を追加しました。
  • 時刻同期も外部のntp.nict.jpから行います。
  • pppoeパススルーは移行時に必要だったので、入れています。最初にIPv4ルータと入れ替え、次にIPv6ルータと入れ替えと行ったので。特に消す必要もないので、そのままです。
  • telnetd,httpd,sshdを有効にしてRTXの操作を行います。ただし、lan1からだけ接続可にしておきます。
  • L2MS(Layer2 Management Service)って、ヤマハのよさげなネットワーク機器管理機能みたいですけど、ルータ1台しかないので、switch control mode offとし、無効にしておきます。

基本的な設定は以上です。

RTX830でPPPoE(IPv4)の設定

次に、公式サイトを参考に、PPPoEの設定を行い、IPv4ルータと入れ替えです。

pp select 2
pp name "Interlink IPv4 PPPoE"
description pp "Interlink IPv4 PPPoE"
pp always-on on
pppoe use lan2
pppoe auto disconnect off
pp auth accept pap chap
pp auth myname ID PASSWORD
ppp lcp mru on 1454
ppp ipcp ipaddress on
ppp ipcp msext on
ppp ccp type none
ip pp mtu 1454
ip pp nat descriptor 10
pp enable 2
ip route default gateway pp 2
nat descriptor type 10 masquerade

名前とか、”pp always-on on”,”pppoe auto disconnect off”とかつけていますが、基本的に公式サイトと同じです。

サンプルによってはfilter(Firewall)を入れているのもありますが、natがあれば外部からLAN内に接続することはできないので、あえて入れていません。

ただし、サーバを外部に公開するために

nat descriptor masquerade static 10 201 192.168.1.4 tcp domain
nat descriptor masquerade static 10 202 192.168.1.4 udp domain
nat descriptor masquerade static 10 301 192.168.1.4 tcp smtp
nat descriptor masquerade static 10 302 192.168.1.4 tcp 465
nat descriptor masquerade static 10 303 192.168.1.4 tcp pop3
nat descriptor masquerade static 10 304 192.168.1.4 tcp 995
nat descriptor masquerade static 10 305 192.168.1.4 tcp imap2
nat descriptor masquerade static 10 306 192.168.1.4 tcp 993
nat descriptor masquerade static 10 307 192.168.1.4 tcp submission
nat descriptor masquerade static 10 401 192.168.1.4 tcp www
nat descriptor masquerade static 10 402 192.168.1.4 tcp https
nat descriptor masquerade static 10 501 192.168.1.4 tcp 21
nat descriptor masquerade static 10 502 192.168.1.4 tcp ftpdata
nat descriptor masquerade static 10 601 192.168.1.4 tcp 22
nat descriptor masquerade static 10 701 192.168.1.4 tcp 6667
nat descriptor masquerade static 10 801 192.168.1.4 tcp 5500-5501

サーバの特定ポートのみ、外部から接続できるように通過させます。

dhcp service server
dhcp server rfc2131 compliant except remain-silent
dhcp scope 1 192.168.1.64-192.168.1.79/24 gateway 192.168.1.254 expire 24:00 maxexpire 24:00
dhcp scope option 1 domain=lo.zeke.ne.jp dns=192.168.1.4 wins_server=192.168.1.4

DHCPサーバの設定も入れておきます。ポイントとして、デフォルトゲートウェイはルータのIPアドレス、DNSサーバはLAN内のサーバのIPアドレスを設定しておきます。(ルータ自身が参照するDNSサーバと別のものを指定できます)

RTX830でPPPoE(IPv6)の設定

次に、IPv6のPPPoE設定を公式サイトを参考に入れていきます。

ipv6 prefix 1 dhcp-prefix@pp1::1/64
ipv6 lan1 address dhcp-prefix@pp1::254/64
ipv6 lan1 rtadv send 1 o_flag=on mtu=1454
ipv6 lan1 dhcp service off

pp select 1
 pp name "Interlink IPv6 PPPoE"
 description pp "Interlink IPv6 PPPoE"
 pp always-on on
 pppoe auto disconnect off
 pppoe use lan2
 pp auth accept pap chap
 pp auth myname ID PASSWORD
 ppp ccp type none
 ppp ipv6cp use on
 ipv6 pp rip send off
 ipv6 pp dhcp service client
 ipv6 pp mtu 1454
 pp enable 1
ipv6 route default gateway pp 1

ipv6 filter 301 pass * * icmp6 * *
ipv6 filter 302 pass * fe80::/10 udp * 546
ipv6 filter 311 pass * dhcp-prefix@pp1::4 * * domain,smtp,465,pop3,995,imap2,993,submission,www,https,21,22,6667
ipv6 filter 398 reject * * * * *
ipv6 filter 399 pass * * * * *
ipv6 filter dynamic 401 * * ftp syslog=off
ipv6 filter dynamic 402 * * domain syslog=off
ipv6 filter dynamic 403 * * tcp syslog=off
ipv6 filter dynamic 404 * * udp syslog=off
pp select 1
 ipv6 pp secure filter in 301 302 311 398 dynamic 401 402
 ipv6 pp secure filter out 399 dynamic 401 402 403 404
 pp enable 1
syslog notice on

公式サイトから変えたところは

  • RTXのDHCPv6サーバは、DNSサーバを個別に設定できない(上位プロバイダの情報をそのままリレーするだけ)なので使えない。よって無効にする。
  • フレッツのPPPoE接続のMTUはIPv4と同じ、最大1454バイトなので、明示的に指定する。
  • フィルタのポート546はDHCPクライアントとして、プレフィックスなど受けるとき。その際、リンクローカルアドレスでやりとするので、相手アドレスをfe80::/10と制限しておく。
  • フィルタのidentポート(ユーザ情報問い合せ)は、今更使っていない。たとえ使ったとしても、問題になるのは、ident問い合わせをして何も返事をしない場合。(相手サーバがタイムアウト5秒間待ってしまう)フィルタでrejectをすぐに返せば問題なし。
  • 動的フィルタのwww,smtp,pop3は特殊な処理をしていないので、tcpに置き換え可能。
  • 自宅サーバを公開するために、サーバ宛の公開しているポートを通すようにする。また、内向けの動的フィルタを追加した。特にftpフィルタはテータ転送ポートを開くために必要。
  • syslogでnotice(filterのログ)を出す。syslog=off及びpassのところはlogが出ないので、”ipv6 filter 398 reject”に引っかかったものだけ記録する。

と、いったところです。

MTUを1454byteに設定

IPv6のPPPoE接続はIPv4と同様にMTUの長さは1454byteになります。

参考: IP通信網サービスのインタフェース
      2.4.2.2 PPPoE接続におけるIPv6仕様
       2.4.2.2.5 最大転送単位(MTU)

“ipv6 pp mtu 1454″でPPPoE接続のMTUを、”ipv6 lan1 rtadv send 1 o_flag=on mtu=1454″でLANつながっているパソコンのMTUを変更します。

だからパソコン側は、何もしなくてもMTUが1454に変更します。

上記画面は、パソコンのコマンドプロンプトで、
netsh interface ipv6 show interface
コマンドを打って、ローカルエリア接続のMTUの長さが、1500から1454に自動的に変わったことを確認しています。

フィルタの動作をチェック

“syslog notice on”でフィルタのログを有効にしています。

passのフィルタはログを出さず、動的フィルタも明示的にログを出さないようにしているので、

“ipv6 filter 398 reject * * * * *”

のところで引っかかったものだけ、ログが出ます。

[gw]# show log | grep (398)
Searching ...
:
省略
:
2020/04/24 12:32:21: PP[01] Rejected at IN(398) filter: TCP 240e:f7:4f01:c::2.21647 > 2001:2c0:cd03:ca01::c4ed:d1ce.www
2020/04/24 12:32:21: PP[01] Rejected at IN(398) filter: TCP 240e:f7:4f01:c::2.34166 > 2001:2c0:cd03:ca01::eb5a:13c5.www
2020/04/24 12:32:21: PP[01] Rejected at IN(398) filter: TCP 240e:f7:4f01:c::2.59678 > 2001:2c0:cd03:ca01::b81f:10c0.www
2020/04/24 12:32:21: PP[01] Rejected at IN(398) filter: TCP 240e:f7:4f01:c::2.55727 > 2001:2c0:cd03:ca01::9e81:8e9b.www
2020/04/24 12:32:21: PP[01] Rejected at IN(398) filter: TCP 240e:f7:4f01:c::2.7718 > 2001:2c0:cd03:ca01::1e6e:899f.www
2020/04/24 12:32:21: PP[01] Rejected at IN(398) filter: TCP 240e:f7:4f01:c::2.10071 > 2001:2c0:cd03:ca01::91b3:5193.www
2020/04/24 12:32:21: PP[01] Rejected at IN(398) filter: TCP 240e:f7:4f01:c::2.25200 > 2001:2c0:cd03:ca01::1e6e:809f.www
2020/04/24 12:32:21: PP[01] Rejected at IN(398) filter: TCP 240e:f7:4f01:c::2.28774 > 2001:2c0:cd03:ca01::91b3:4893.www
:
省略
:

正常な通信をブロックしていないかを、確かめるためにログをチェックしていたのですが、中国からのwebサーバスキャンが見つかりました。

プレフィックスは自分のところのものですが、該当するホストはないので空振りです。しかし、膨大なIPv6アドレスの海の中でwebサーバを探すなんて気の遠くなるような話です。

DNSサーバにDHCPv6サーバを立てる

RTXでは、DHCPv6サーバにローカルなDNSサーバを指定できないのはいただけませんね。

また、RDNSSにも対応していないので、ルータ広告レベルでもローカルDNSサーバを設定できません。

以下の方法でDNSサーバにDHCPv6サーバを立てて、RDNSSにしか対応していないAndroidの対応は諦めました。(IPv4のDNSサーバを参照するので、表面上は問題なしです)

現行のDNSサーバはCentOS7で動いています。CentOS8でも同じだと思いますが、以下の手順で構築しました。

[root@myhome zeke]# yum install dhcp

  インストール中          : 12:dhcp-4.2.5-77.el7.centos.x86_64              1/1
  検証中                  : 12:dhcp-4.2.5-77.el7.centos.x86_64              1/1

インストール:
  dhcp.x86_64 12:4.2.5-77.el7.centos

完了しました!
[root@myhome zeke]#

インストールはdhcpパッケージです。

[root@myhome zeke]# vi /etc/dhcp/dhcpd6.conf
[root@myhome zeke]# cat /etc/dhcp/dhcpd6.conf
#
# DHCPv6 Server Configuration file.
#   see /usr/share/doc/dhcp*/dhcpd6.conf.example
#   see dhcpd.conf(5) man page
#
subnet6 2001:2c0:cd03:ca00::/64 {
        option dhcp6.name-servers 2001:2c0:cd03:ca00::4;
        option dhcp6.domain-search "lo.zeke.ne.jp";
}

[root@myhome zeke]#

設定ファイルは /etc/dhcp/dhcpd6.conf でDNSサーバのアドレスと、検索ドメインだけ書いておきます。

[root@myhome zeke]# systemctl start dhcpd6
[root@myhome zeke]# systemctl status dhcpd6
● dhcpd6.service - DHCPv6 Server Daemon
   Loaded: loaded (/usr/lib/systemd/system/dhcpd6.service; disabled; vendor preset: disabled)
   Active: active (running) since 火 2020-04-14 15:29:29 JST; 19s ago
     Docs: man:dhcpd(8)
           man:dhcpd.conf(5)
 Main PID: 10278 (dhcpd)
   Status: "Dispatching packets..."
   CGroup: /system.slice/dhcpd6.service
           mq10278 /usr/sbin/dhcpd -f -6 -cf /etc/dhcp/dhcpd6.conf -user dhcp...
 4月 14 15:29:29 myhome.lo.zeke.ne.jp dhcpd[10278]: Internet Systems Consort...
 4月 14 15:29:29 myhome.lo.zeke.ne.jp dhcpd[10278]: Copyright 2004-2013 Inte...
 4月 14 15:29:29 myhome.lo.zeke.ne.jp dhcpd[10278]: All rights reserved.
 4月 14 15:29:29 myhome.lo.zeke.ne.jp dhcpd[10278]: For info, please visit h...
 4月 14 15:29:29 myhome.lo.zeke.ne.jp dhcpd[10278]: Not searching LDAP since...
 4月 14 15:29:29 myhome.lo.zeke.ne.jp dhcpd[10278]: Wrote 0 leases to leases...
 4月 14 15:29:29 myhome.lo.zeke.ne.jp dhcpd[10278]: Bound to *:547
 4月 14 15:29:29 myhome.lo.zeke.ne.jp dhcpd[10278]: Listening on Socket/5/en...
 4月 14 15:29:29 myhome.lo.zeke.ne.jp systemd[1]: Started DHCPv6 Server Daemon.
 4月 14 15:29:29 myhome.lo.zeke.ne.jp dhcpd[10278]: Sending on   Socket/5/en...
Hint: Some lines were ellipsized, use -l to show in full.
[root@myhome zeke]# 

[root@myhome zeke]# systemctl enable dhcpd6
Created symlink from /etc/systemd/system/multi-user.target.wants/dhcpd6.service to /usr/lib/systemd/system/dhcpd6.service.
[root@myhome zeke]#

DHCPv6サーバの起動と自動起動の設定です。

最後に

流石に専用ハードだけあって、処理が速い気がします!

空いている時間帯なら、ダウンロードやアップロードが1.5倍早くなっているけど、コロナウィルス禍のため、みんなネットを使っているせいか、日中はいつもより重くなっています。

余った、SEIL/x86もなにかうまい使いみちはないかな?

フィルタの見直し!!

※4月28日追記

フィルタの動作確認で、必要な通信をブロックしていないかを確認していました。数日間続けて、まずいところがあったので、フィルタの見直しです。

2020/04/28 01:00:25: PP[01] Rejected at IN(398) filter: TCP 2001:500:a8::e.domain > 2001:2c0:cd03:ca00::4.35077
2020/04/28 01:00:33: same message repeated 3 times
2020/04/28 01:00:33: PP[01] Rejected at IN(398) filter: TCP 2001:500:a8::e.domain > 2001:2c0:cd03:ca00::4.34331
2020/04/28 01:00:33: PP[01] Rejected at IN(398) filter: TCP 2001:500:2f::f.domain > 2001:2c0:cd03:ca00::4.47824
2020/04/28 01:00:33: PP[01] Rejected at IN(398) filter: TCP 2001:500:2f::f.domain > 2001:2c0:cd03:ca00::4.37247
2020/04/28 01:00:33: PP[01] Rejected at IN(398) filter: TCP 2001:500:2f::f.domain > 2001:2c0:cd03:ca00::4.41293
2020/04/28 01:00:33: PP[01] Rejected at IN(398) filter: TCP 2001:500:2f::f.domain > 2001:2c0:cd03:ca00::4.53005
2020/04/28 01:00:33: PP[01] Rejected at IN(398) filter: TCP 2001:500:2f::f.domain > 2001:2c0:cd03:ca00::4.41290
2020/04/28 01:00:33: PP[01] Rejected at IN(398) filter: TCP 2001:500:2f::f.domain > 2001:2c0:cd03:ca00::4.53528
2020/04/28 01:00:48: PP[01] Rejected at IN(398) filter: TCP 2001:500:2f::f.domain > 2001:2c0:cd03:ca00::4.47824
2020/04/28 01:00:48: PP[01] Rejected at IN(398) filter: TCP 2001:500:a8::e.domain > 2001:2c0:cd03:ca00::4.34331
2020/04/28 01:00:49: PP[01] Rejected at IN(398) filter: TCP 2001:500:2f::f.domain > 2001:2c0:cd03:ca00::4.37247
2020/04/28 01:00:49: PP[01] Rejected at IN(398) filter: TCP 2001:500:2f::f.domain > 2001:2c0:cd03:ca00::4.41293
2020/04/28 01:00:49: PP[01] Rejected at IN(398) filter: TCP 2001:500:2f::f.domain > 2001:2c0:cd03:ca00::4.53005
2020/04/28 01:00:49: PP[01] Rejected at IN(398) filter: TCP 2001:500:2f::f.domain > 2001:2c0:cd03:ca00::4.41290
2020/04/28 01:00:49: PP[01] Rejected at IN(398) filter: TCP 2001:500:2f::f.domain > 2001:2c0:cd03:ca00::4.53528
2020/04/28 01:00:55: PP[01] Rejected at IN(398) filter: TCP 2001:500:a8::e.domain > 2001:2c0:cd03:ca00::4.34331

この、2001:500:a8::eや2001:500:2f::fはルートネームサーバです。このルートネームサーバからのドメイン情報の応答を拒否しています。

なぜこんな事が起こっているのか、詳細に調べたところ

2020/04/28 01:03:57: [INSPECT] PP[01][out][402] TCP 2001:2c0:cd03:ca00::4.50978 > 2001:500:2f::f.53 (2020/04/28 01:03:51)
2020/04/28 01:04:06: PP[01] Rejected at IN(398) filter: TCP 2001:500:2f::f.domain > 2001:2c0:cd03:ca00::4.50978
2020/04/28 01:04:12: PP[01] Rejected at IN(398) filter: TCP 2001:500:2f::f.domain > 2001:2c0:cd03:ca00::4.50978
2020/04/28 01:04:16: same message repeated 3 times
  1. domainの動的フィルタにしたがって、応答を待っていたが、5秒間応答がなかったので、フィルタを閉じた。
  2. 問い合わせから、15秒後、ルートネームサーバから応答があったが、フィルタが閉じられていたため、拒否された。
  3. ルートネームサーバは通信が完了しないため、その後4回再送した。

と、こんな状態になっていました。

最近はDNSSECやDKIMなどDNSサーバで扱う情報量が多くなっているので、タイムアウト5秒は短すぎると思います。

また、お忙しいルートネームサーバ様に再送のお手間をかかせるなんて、まずすぎます!!

対策として

ip filter dynamic timer dns-timeout=30

このコマンドでタイムアウトを伸ばそうとしましたが、IPv4のパラメータなのか効きませんでした。

また、

ipv6 filter dynamic 402 * * domain syslog=on

のdnsの動的フィルタを外して、udp&tcpの動的フィルタにまかせてみましたが、タイムアウト5秒は変わりませんでした。

結局

pp select 1
 ipv6 pp secure filter in 301 302 311 397 398 dynamic 401 402
 ipv6 pp secure filter out 399 dynamic 401 402 403 404

ipv6 filter 301 pass * * icmp6 * *
ipv6 filter 302 pass * fe80::/10 udp * 546
ipv6 filter 311 pass * dhcp-prefix@pp1::4 * * domain,smtp,465,pop3,995,imap2,993,submission,www,https,21,22,6667
ipv6 filter 397 pass * * established * *
ipv6 filter 398 reject * * * * *
ipv6 filter 399 pass * * * * *
ipv6 filter dynamic 401 * * ftp syslog=off
ipv6 filter dynamic 402 * * domain syslog=off
ipv6 filter dynamic 403 * * tcp syslog=off
ipv6 filter dynamic 404 * * udp syslog=off
syslog notice on

(フィルタ関係を抜粋)

通信中のパケット(フィルタ番号397のestablished)の入力を許可して、ルートネームサーバから応答を弾かれないようにしました。

セキュリティ的には低くなるかもしれないけど、必要な通信を通すほうが重要ですからね。

フィルタ見直し後のDNSパケの送受信

フィルタによって、どんなデータを落としていたのか、気になってDNSサーバのやり取りをtcpdumpコマンドを使ってみてみました。

19:08:20.124683 IP6 2001:2c0:cd03:ca00::4.51956 > 2001:500:2f::f.domain: 64079% [1au] A? b.dns.br. (37)
19:08:20.142675 IP6 2001:500:2f::f.domain > 2001:2c0:cd03:ca00::4.51956: 64079-| 0/8/3 (510)

19時8分20秒、UDPによる問い合わせですね。512byteを超えているため、TCPに切り替わります。

19:08:20.142851 IP6 2001:2c0:cd03:ca00::4.38215 > 2001:500:2f::f.domain: Flags [S], seq 619152292, win 24400, options [mss 1220,sackOK,TS val 279617360 ecr 0,nop,wscale 7], length 0
19:08:20.159346 IP6 2001:500:2f::f.domain > 2001:2c0:cd03:ca00::4.38215: Flags [S.], seq 2673112013, ack 619152293, win 65535, options [mss 1360,nop,nop,sackOK,nop,wscale 10], length 0
19:08:20.159355 IP6 2001:2c0:cd03:ca00::4.38215 > 2001:500:2f::f.domain: Flags [.], ack 1, win 191, length 0

3ウェイハンドシェークによるTCP通信開始です。

19:08:20.159723 IP6 2001:2c0:cd03:ca00::4.38215 > 2001:500:2f::f.domain: Flags [P.], seq 1:40, ack 1, win 191, length 3925061% [1au] A? b.dns.br. (37)
19:08:20.177026 IP6 2001:500:2f::f.domain > 2001:2c0:cd03:ca00::4.38215: Flags [.], ack 40, win 64, length 0
19:08:20.177661 IP6 2001:500:2f::f.domain > 2001:2c0:cd03:ca00::4.38215: Flags [P.], seq 1:733, ack 40, win 64, length 73225061- 0/8/13 (730)
19:08:20.177669 IP6 2001:2c0:cd03:ca00::4.38215 > 2001:500:2f::f.domain: Flags [.], ack 733, win 203, length 0
19:08:20.178538 IP6 2001:2c0:cd03:ca00::4.38215 > 2001:500:2f::f.domain: Flags [F.], seq 40, ack 733, win 203, length 0
19:08:20.238195 IP6 2001:500:2f::f.domain > 2001:2c0:cd03:ca00::4.38215: Flags [.], ack 41, win 64, length 0

TCPによるDNSサーバへの問い合わせと、その回答です。回答は733byteだったようですね。

19:08:35.659193 IP6 2001:500:2f::f.domain > 2001:2c0:cd03:ca00::4.38215: Flags [.], ack 41, win 64, length 0
19:08:35.659207 IP6 2001:2c0:cd03:ca00::4.38215 > 2001:500:2f::f.domain: Flags [.], ack 733, win 203, length 0

19:08:51.006173 IP6 2001:500:2f::f.domain > 2001:2c0:cd03:ca00::4.38215: Flags [.], ack 41, win 64, length 0
19:08:51.006179 IP6 2001:2c0:cd03:ca00::4.38215 > 2001:500:2f::f.domain: Flags [.], ack 733, win 203, length 0

19:09:06.365280 IP6 2001:500:2f::f.domain > 2001:2c0:cd03:ca00::4.38215: Flags [.], ack 41, win 64, length 0
19:09:06.365338 IP6 2001:2c0:cd03:ca00::4.38215 > 2001:500:2f::f.domain: Flags [.], ack 733, win 203, length 0

19:09:21.726169 IP6 2001:500:2f::f.domain > 2001:2c0:cd03:ca00::4.38215: Flags [.], ack 41, win 64, length 0
19:09:21.726186 IP6 2001:2c0:cd03:ca00::4.38215 > 2001:500:2f::f.domain: Flags [R], seq 619152333, win 0, length 0

その後、19時8分35秒、8分51秒、9分6秒、9分21秒にルートネームサーバからパケットが飛んできて、ローカルネームサーバが応答しています。

このやり取りが、ルータのフィルタで拒否されていたようですね。でも、0byteのデータなので問題なかったのかもしれません。

ここでまた疑問が??

  1. UDPからTCPにフォールバックしているが、今どきのDNSサーバはEDNS0によって、512byteを超えるUDP通信にも対応できるはず。なぜフォールバックしているのか?
  2. TCPセッションの終了まで時間がかかりすぎ。なんで通信が終わってから1分後にセッション終了しているのか?

DNSサーバは、インターネットの中でもスピードに関わる超重要なサーバなので、調査継続ですね。

Kindle Unlimited入会で無料で読めます!

コメント

  1. 通りすがり より:

    ipv6 filter dynamic 402 * * domain syslog=off timeout=60
    で、どうでしょ?

    • zekezeke より:

      コメントありがとうございます!
      ちょっと調べてみたところ、timeoutのデフォルト値は60秒なので、効果があるか微妙ですが、念のため試してみたいと思います。
      http://www.rtpro.yamaha.co.jp/RT/manual/rt-common/ipv6/ipv6_filter_dynamic.html

      • zekezeke より:

        早速試してみました!
        こんな感じで、「ipv6 filter 397 pass * * established * *」を無効化し、タイムアウトを120秒に設定してみました。

        pp select 1
        ipv6 pp secure filter in 301 302 340 311 398 dynamic 401 402
        ipv6 filter dynamic 402 * * domain syslog=on timeout=120

        で、ログを確認すると、

        2020/07/01 00:59:07: [INSPECT] PP[01][out][402] TCP 2001:2c0:cd03:ca00::4.49042 > 2001:500:2f::f.53 (2020/07/01 00:59:02)
        2020/07/01 00:59:17: PP[01] Rejected at IN(398) filter: TCP 2001:500:2f::f.domain > 2001:2c0:cd03:ca00::4.49042
        2020/07/01 00:59:33: PP[01] Rejected at IN(398) filter: TCP 2001:500:2f::f.domain > 2001:2c0:cd03:ca00::4.49042
        2020/07/01 00:59:48: PP[01] Rejected at IN(398) filter: TCP 2001:500:2f::f.domain > 2001:2c0:cd03:ca00::4.49042
        2020/07/01 01:00:03: PP[01] Rejected at IN(398) filter: TCP 2001:500:2f::f.domain > 2001:2c0:cd03:ca00::4.49042
        2020/07/01 01:00:19: PP[01] Rejected at IN(398) filter: TCP 2001:500:2f::f.domain > 2001:2c0:cd03:ca00::4.49042
        2020/07/01 01:00:34: PP[01] Rejected at IN(398) filter: TCP 2001:500:2f::f.domain > 2001:2c0:cd03:ca00::4.49042

        と、やはりRejectされてしまいました。残念!

  2. 通りすがり より:

    10秒後にrejectされてるので、TCPコネクションが終了した後で何かが送られてきているみたいです。
    ルーターの問題なのかどうかは、パケットキャプチャで確認してみるしかなさそうですね。

    • zekezeke より:

      はい、そうですね。
      本文にも書きましたが、本来ならEDNS0が働いて、TCPにフォールバックせずにUDPのまま通信が行われるはずです。
      それを踏まえて、キャプチャしてみないといけませんね。

  3. 通りすがり より:

    別の検索でこの記事が引っかかったので・・・。

    ちょっと古い記事だけど解決してますか?

    YAMAHAのRTXは、デフォルトではEDNS0がOFFになってます。
    DNSサーバー指定で edns=on をいちいち指定しないと、EDNS0が有効にならないので、フォールバックします。

    dns server 8.8.8.8 edns=on 8.8.4.4 edns=on

    • zekezeke より:

      コメントありがとうございます!
      今回は、内部のDNSサーバとルートサーバの間の通信なので、RTXのDNS設定は絡まないのです…しかし、bindのEDNS0の有効であることを改めて確認できました!
      また、RTX自身は、自分のDNSサーバを使っているので、ご指摘のとおり、設定を変更しておきました。(192.168.1.254はRTX830のアドレスです)
      [zeke@ace ~]$ dig @192.168.1.254 jp. DNSKEY

      ; <<>> DiG 9.11.13-RedHat-9.11.13-5.el8_2 <<>> @192.168.1.254 jp. DNSKEY



      ;; OPT PSEUDOSECTION:
      ; EDNS: version: 0, flags:; udp: 4096
      ;; QUESTION SECTION:
      ;jp. IN DNSKEY



      ;; Query time: 0 msec
      ;; SERVER: 192.168.1.254#53(192.168.1.254)
      ;; WHEN: 金 9月 11 01:25:19 JST 2020
      ;; MSG SIZE rcvd: 603

      [zeke@ace ~]$
      で、EDNS0が有効になってようです。
      ありがとうございました。