Plumeで一部サイトが開かない症状を調べてみた

monaf 2023年1月4日 0 Comments

12月ごろに症状があることは知っていたものの、少し気になっていたので調査してみました。
ほとんど調査メモのような物になるが、需要があればもう少し踏み込んで調べてみても面白そうではあるかと考えている。
※現状は簡易的な考察エントリなので、キャプチャや図表などはあまり差し込んでいないが、どこかで正式に差し込む予定。

経緯・症状

Pulumeと呼ばれるJ:COM系などで提供されているコンセントに差すだけな
メッシュWi-Fiシステムがある。
※厳密には一つはLANケーブルをつなぐ必要がある

いつからかは明確ではないものの、Plumeのバージョンアップに伴い、
いくつかのHTTPSなサイトでサイト表示ができない(HTTP 400)で表示できなくなる。

ただし症状が必ず出るサイトが人や時によってまちまちである点は確認されている。
現時点でつながらないサイトとして見かけるのは、下記サイト。

Qiita
https://qiita.com/
CampFire
https://camp-fire.jp/

対処法

現時点でいわれている対処法はプライバシーモードを有効化する方法。

①Plume アプリを立ち上げた直後の画面下部右側の四角が6つ並んだところをタップ
②その中のGuardをタップ
③ポップアップしてきたスクリーンを下にスワイプ(スクロール)していく
④最下部にプライバシーモードを有効化するトグルがあるのでこれを有効化する

原因(らしきもの?)

少なくともこれはPlumeによるWEBアクセスプロテクションによるブロック
の結果であるということはわかっている。
手元で少し試せる環境を用意できたので実験してみたが、camp-fire.jpについては、
ブロックされた旨がログとして残っていた。
(Qiitaはこちらでは再現せず)
※アプリ上のログは下記だった
　camp-fire.jp(カテゴリ:マルウェアまたはフィッシング)

おそらくこの400で表示できない画面は、本来ブロックされた旨を表示する画面
ではないかと考えている。
つまり、HTTPSではTLSのネゴを行うが、このネゴが本来の通信先との間でネゴが
成立した物をジャックしているためにBAD Rquestとなっていると推測される。
これに対する解として単純にブロック機能を無効化するのが先のプライバシーモード
ということになる。
よって、この事象はPlumeのブロックリストに記載があるサイトで起こることになる。

検証

蛇足的に何を基準にブロック動作が行われているかを切り分けてみる。
まずは、異常時のDNS応答IPは下記だった。
camp-fire.jp　　18.204.152.241

一方、プライバシーモードを有効化した時の応答IPは下記だった。
camp-fire.jp　　13.249.158.24

よってここから、PlumeはDNSベースでアクセス制御を行っていると仮定できる。
となれば、通常時はPlumeがOKなドメインはそのまま上から返ってきた回答を渡しているが、
NGなDNSドメイン名の正引き結果が着たときは専用サイトのIPに差し替えて下側のクライアントに回答していることになる。

この裏をとるために、Google Public DNS(8.8.8.8)にクエリを投げるようにした時の結果は下記の通りだた。
camp-fire.jp　　13.249.158.24

予想通りといえば予想通りだが、ブロック用のIPへのクエリ応答の書き換えは実施されていなかった。

さらにPlume上位の通信および本体からの通信をプライバシーモード:無効、PlumeAPへDNS問い合わせという状態でパケットキャプチャでクエリログを覗き見てみたところ、それぞれ下記の通りだった。

上位DNS⇔Plume間クエリ回答
camp-fire.jp　　13.249.158.24


Plume⇔端末間クエリ回答
camp-fire.jp　　18.204.152.241

見事に応答結果が書き換えが行われていた。

その後再調査したところ、PublicDNS宛てでもクエリ回答が書き換わっている可能性があるため、
一旦上記斜線部分は(クエリ自体は確認できているもののその他DNS含め検証するため)一旦保留。

根本的な原因

さらに追加で18.204.152.241について調査してみた。

通常通りHTTPのアクセスとした場合、下記のようにPlumeでブロックされた旨のサイトが表示された。

一方、HTTPSアクセスとした場合、見覚えのある400に伴うエラーページが表示された。

よって最初のネゴが失敗しているではなく、根本的にはPlule APがDNSクエリでリダイレクトする先のサーバーがHTTPSリクエストでの待ち受けに対応していない(HTTPしか待ち受けできない？)状態であることが原因であると推測される。

最終的な結論

よって、問題が出ている端末の対処としては下記3つが取り得る対策となる。

　①プライバシーモードを有効化し保護を無効化する
　②フィルタを無効化したい端末だけ、Plume AP以外のDNS参照先へ切り替える
　　(手元では有効に機能した)
　③Guardにてドメインへのアクセスを承認を個別で出す


塩梅としては②がお手軽だが、これはいわば家庭内フィルタリングにこれを当てにしている場合は無効化の手段が存在することの裏返しでもある。
また、①はお守り程度かもしれないが、保護機能を無効化する物なので家族が使う物にはなかなかとりづらい。
現実問題③の許可を個別に出していく程度にとどめておくのが通常の利用者には勧められる範囲かと考える。
ウイルス通信のブロックといってもDNSベースであるため、おそらくIPベースでの通信は通るのではと推測している。

これらの対策機能を過信せず、基本的に端末の更新は滞りなく行いつつ、Plume自身のウイルス対策とは別途で端末にウイルス対策を実施しておくに超したことはないと考えている。

2023/1/4 21:08 追記
フィルタリングについて一部動作に追加検証が必要な箇所があったため一部修正。