スマート家電はスマホのVPN接続で見えなくなる

ランプは自宅ではアプリから動くが、スマホのVPNが接続された瞬間に応答をやめ、トンネルが切れると戻る。ランプに問題はない。スマホはいま、通信の一部または全部を別の経路で送っており、スマートホームアプリはその経路が運ばない検出方法を使っている可能性がある。何かをリセットする前に、失敗した操作を特定する。

二つの経路、トンネルが触れるのは一つだけ

スマートホームのコマンドは二通りに進める。ローカルネットワーク経由で近くの機器に直接届くか、ベンダーのクラウドサービス経由で機器が自分の接続で到達されるかだ。スマホのVPNはスマホの経路を変えるだけで、ハブ、電球、スピーカーをトンネルの中へ移すわけではない。設定、制御、通知はそれぞれ別の仕組みを使えるため、部分的に失敗すると一貫性がないように見える。

したがって最初の切り分けはVPNの設定ではなく、失敗した操作だ。ローカル設定とクラウド制御が同時に失敗するなら、原因はまったく別の場所にある。

ローカル検出を切り分けて試す

ローカル検出は通常、リンクローカルマルチキャストに依存しており、ルーティングされたトンネルはこれを拡張しない。アプリを使わずに名前が解決するか、アドレスに到達できるかを確認する。

avahi-resolve -n lamp.local
ip route get 192.168.1.50
ping -c 3 192.168.1.50

リゾルバの呼び出しでmDNSが応答するかが分かり、経路の照会でどのインターフェースが機器への通信を運ぶかが分かり、pingでローカル経路がそもそも動くかが分かる。機器のサブネットをトンネルへ送る経路があれば、インターネットが動いたまま検出だけが失敗する理由を説明できる。名前が解決しても応答がない場合は、VPNではなくアクセスポイント側の分離を示す。例の名前とアドレスは自分のネットワークの値に置き換える。

クラウド経路だけが壊れる場合

ローカルのコマンドは動き、遠隔のコマンドが動かないなら、スマホのトンネルは検出ではなくクラウドセッションに干渉している可能性がある。新しい出口アドレスはアカウント確認を促したり、固定されたセッションを切ったり、地域チェックに失敗したりする。アプリとネットワークをそれ以外は変えずに、対応する操作を一つ比較し、証明書の検証は維持する。サービスの復旧フローが正しい道具であり、ログインを通すためにセキュリティ検査を切るのは正しくない。

DNSも確認する。アプリはベンダーのエンドポイントを、想定された地域からしか正しく応答しないホスト名に解決することがある。

遠隔アクセスは第三の設計

外出先から自宅の機器に届くのは、スマホをVPN経由でルーティングするのとは別のプロジェクトだ。プライベートなゲートウェイ、定義された経路、狭いアクセス規則が必要で、インターネット出口のVPNを契約しても作られるものではない。説明のつかないルーティング問題を補うための広いポート転送は、そのために設計されていない機器を露出させる。変更のたびに、検出、ローカル制御、クラウド制御を一つずつ試す。アプリにローカルネットワークの例外を追加したなら、スマホの他の通信が意図したトンネルに従っていることを確認する。

どの経路が失敗し、どの変更で直ったかを記録する。スマートホームの失敗は通常、ルーティングか権限の境界であり、次の機器も同じ境界にぶつかる。