この記事で扱うこと
問題の原因調査、および異なるアプローチでの解決・ワークアラウンド
TL;DR
第1世代Google Nest HubがYAMAHA RTX810のDNSリカーシブサーバに問い合わせるクエリをパケットフィルタで拒否することで、「ネットワーク障害」が解消し、使用可能な状態に戻った。
※Google Nest Hubのアップデートにより、今後このワークアラウンドが不要になるだけでなく、これが原因で繋がらなくなる可能性もあります。あくまで一時的なワークアラウンドであることをご認識ください。
他の解決方法としては、DHCPで配るDNSサーバ（リゾルバ）をISPの提供するものやPublic DNS、LAN内に別途立ち上げたサーバなど、適当なものに変更する方法がある。
以下、詳細
問題の発生
第1世代Google Nest Hubの内部で使われているOSが、Fuchsiaというものになったとのニュースが最近（2021年8月頃）ありましたが、どうやらその少し前あたりから、YAMAHA RTX1200やRTX810、NVR500などを使ったネットワークで、Google Nest Hubが「ネットワーク障害」や「インターネット接続をご確認ください」とのエラーでネットワークに繋がらない事例が増えているようでした。
上記以外にも、同様にブログやTwitterでのツイート「Nest Hub ネットワーク障害」が見つかりました。
原因の調査のため、手持ちの機器を使って問題を再現してみることにしました。
世代の古いYAMAHAルーターではEDNS対応がされておらず、Format Errorになることは知っていたため、そこにあたりをつけてさらに調査を進めます。
再現
特に複雑な条件もなく、すぐに再現しました。
- Google Nest Hub（第1世代）
- システムのファームウェア バージョン: 1.20210119.2.1390060
- キャスト デバイスのファームウェア バージョン: 1.52.260996
- YAMAHA RTX810
- ファームウェア: Rev.11.01.34
- 工場出荷状態で、何も追加設定を行っていない状態を想定
原因
192.168.100.1 がRTX810、 192.168.100.6 がGoogle Nest Hubの状態でパケットキャプチャをしてみました。
DHCPではDNSサーバ（リゾルバ）としてRTX810のDNSリカーシブサーバ 192.168.100.1 しか通知していないにも関わらず、Google Nest Hubが 192.168.100.1 と 8.8.8.8 に名前解決をしているのが観測できました。外部のサーバを追加している挙動は私としては意図しておらず謎ですが、ある意味Google製品らしい動きとも言えます。
RTX810は即座にFormat Error（FORMERR）を返していますが、あとから 8.8.8.8 による、エラーではない応答も見えます。なぜ 8.8.8.8 の応答は使われないのでしょうか。
答えとしては、RTX810が先にFormat Errorの応答を返してしまっているからです。エラーであっても、今のGoogle Nest Hubは先に得られた応答を採用するのでしょう。
インターネット越しの 8.8.8.8 よりも、RTX810が速く応答するのは当然と言えます。つまり、RTX810がFormat Errorを返しているのが邪魔になってしまいました。
ワークアラウンド
RTX810のDNSリカーシブサーバに応答させたくないので、パケットフィルタにてGoogle Nest Hubからの名前解決を無視してしまうことにします。RTX810に設定を行います。
dhcp scope bind 1 192.168.100.6 1c:f2:9a:00:00:00
ip filter 1000 reject 192.168.100.6 192.168.100.1 udp * domain
ip lan1 secure filter in 1000 1010991c:f2:9a:00:00:00 はお使いのGoogle Nest HubのMACアドレスに置き換えてください。
ここではDHCPでのIPアドレス割り当てを 192.168.100.6 に固定した上で、 192.168.100.6 から 192.168.100.1 への名前解決のクエリを拒否しました。
ip filter 101099はデフォルトで設定されていた、以下のような全PASSのフィルタです。適当な別の番号を振っても良いでしょう。ip filter 101099 pass * * * * *
今回追加したip filter 1000なども、適当に既存の設定と被らない番号に調整してください。
この設定を入れることで、Google Nest Hubは 8.8.8.8 からの応答のみで動作するようになり、ひとまず2021/09/19現在は、試した限りでは動くようになりました。
あえてややこしいこのワークアラウンドを実施するメリットは、DHCPでLAN内の他の端末に配られるDNSサーバ（リゾルバ）を変更せずに済むことにあります。
RTX810などYAMAHAルーターをお使いの方であれば、そこに静的DNSレコードを設定している可能性もあり、このワークアラウンドであれば両立させることができます。もちろん、この設定をしたGoogle Nest Hubだけはその静的DNSレコードを参照できませんけども。
あと、単純に別のワークアラウンドをやってみたかった。
ところで
EDNSを有効にした名前解決にYAMAHAルーターがエラーを返すのは、最初からではないそうです。かなり前は無視されていたものが、ファームウェアの更新によってエラーを返すようになったようでした。未対応でエラーになるのが挙動として良いとは思いつつも、以前のままであれば、この問題は発生しなかったのだろうと思います。
また、YAMAHAルーターの世代によってもEDNS対応・非対応が分かれます。
リリースノートや公式マニュアルを検索した限り、 RTX1220 / RTX1210 / RTX830 / NVR700W / NVR510あたりなら対応しているようです。2020年時点で現行製品であったものなら大丈夫でしょう。
※Google Nest Hubのアップデートにより、今後このワークアラウンドが不要になるだけでなく、これが原因で繋がらなくなる可能性もあります。あくまで一時的なワークアラウンドであることをご認識ください。
不要になったら、設定を元に戻すことをお忘れなく。