Android の VPN は完全なホスト名を解決するが短い名前は解決しない

ターミナルエミュレーターにfilesと入力しても何も返ってこない。ではfiles.corp.exampleと入力すると同じサーバーがすぐに応答します。VPN の認証情報は何も変わっておらず、プライベート DNS サーバーが壊れていたわけでもありません。Android では短いラベルと完全な名前がリゾルバーの中で別の経路を通り、その一方はトンネルの所有者が用意しなければならない設定に依存します。目の前の判断は、どの DNS サーバーを変えるかではなく、アプリが実際に使っているネットワークを誰が管理しているかです。

検索ドメインはアドレスではありません。リゾルバーが裸のラベルに付けてから諦める接尾辞のリストです。

検索サフィックスと DNS サーバーは別のフィールド

リゾルバーのアドレスは、どこに問い合わせるかを Android に伝えます。検索サフィックスは、左端のラベルだけを渡したときに何を問い合わせるかを伝えます。どちらも同じネットワークオブジェクト上にあり、それぞれ単独で欠けることがあります。

その独立性こそが、完全なホスト名が機能する理由です。完全修飾名にはサフィックスは不要です。すでにサーバーへ送る文字列そのものだからです。

Android はこの分離をLinkPropertiesで公開しています。DNS サーバーの一覧とドメイン検索の一覧は同じオブジェクトに載っており、前者が完全に埋まっていても後者は空のことがよくあります。リゾルバーはあるがドメインがないネットワークは、サフィックスが一度も適用されなかったネットワークであって、短い名前を拒否したサーバーではありません。

何かを変える前に実際のネットワークを読む

Wi-Fi、モバイル回線、VPN インターフェースは三つの別々のネットワークで、トンネルは上がった時点で既定になります。したがって、社内 Wi-Fi で機能したサフィックスが、トンネル稼働中に有効なサフィックスとは限りません。先週設定したネットワークではなく、アプリが実際に選択されているネットワークを調べてください。

端末のターミナルシェルはここでは頼りになりません。そのresolv.confはリゾルバーの一つの見方を反映するだけで、すべてのアプリの見方ではないからです。

ブラウザーのアドレスバーはさらに層を重ねます。裸の語は検索クエリとして扱われることも、ブラウザー自身の暗号化 DNS ポリシーによって解決されることもあるため、Chrome でページが開いてもシステムの名前解決の証明にはなりません。プラットフォームのリゾルバーを使い、何が返ったかを表示するもので試してください。そのうえで短い形式と完全な形式を同じセッション、同じネットワークで実行し、どちらが応答したかを記録します。

VPN アプリを作る側なら、ビルダーでサフィックスを付ける

アプリがVpnServiceを介してインターフェースを確立するとき、addSearchDomainがそのためのサポートされた入力です。corp.exampleのようなドメイン文字列を受け取り、サーバーアドレスを渡す別の方法ではありません。

この呼び出しはサフィックスを構築中のネットワークに結び付けるので、後から切り替えるグローバル設定はありません。アプリがインターフェースを破棄し、再接続時に作り直す場合、新しいビルダーにもう一度サフィックスを追加する必要があります。そうしなければ、差し替わったネットワークはサフィックスなしで立ち上がります。

デスクトップのプロファイル取り込みがこのフィールドを落とすのはここです。エクスポーターはドメインを独自のモデルに書き、Android のフロントエンドは知っているオプションだけをマッピングするので、出来上がったインターフェースは他の点では正しく見えます。ノート PC で動きスマートフォンで失敗するプロファイルは、ふつうプロトコルの問題ではなくマッピングの抜けです。

VPN を使うだけなら、これを設定するのはあなたではありません

サフィックスを追加するクライアント側の編集はなく、偽装するために変えられるグローバルプロパティもありません。値を渡すのはトンネルの所有者です。管理クライアントのプロファイル、プラットフォームごとのマッピング、あるいはサーバーが送るものを通じて届きます。どのプラットフォームでどの名前が失敗するかを伝えてください。デスクトップとモバイルのフロントエンドはまさにこのフィールドで異なります。

デスクトップのプロファイルを再度取り込んでも、モバイルのマッピングについては何も証明できません。

三つの条件が、それが不具合か想定された制限かを決めます。第一に、組織が短いラベルをそもそもサポートされた名前として扱っているのか、それとも社内 Wi-Fi でしか機能しなかった便宜的なものなのか。第二に、失敗する問い合わせはシステムのリゾルバーを完全に迂回しうるブラウザーから来ていないか。第三に、短い名前はトンネル経由で届くべきものか、それとも LAN からだけか。最後の答えが LAN 限定なら、サフィックスを足すと社外で解決され、そのあとルーティングできない名前ができてしまいます。

サフィックスがあり、それでも短い名前が失敗する場合

ドメイン検索の一覧にすでにcorp.exampleが表示されているなら、サフィックスのせいにしないでください。リゾルバーが拡張後の名前にそもそも応答するかを確認してください。サフィックスは問い合わせ内容を変えるだけです。ホストしていないゾーンの権威をサーバーに与えることはありません。

次に経路を確認します。解決はされるがトンネルが運ばないアドレスは接続時に失敗し、これは黙って諦めるブラウザーでの名前解決失敗と見分けがつきません。

証明書には独自の言及が必要です。HTTPS の検証は実際に入力したホスト名を使うため、正しく展開される短い名前でもハンドシェイクではfilesを提示します。files.corp.exampleに対して発行された証明書はそれでは検証されません。このエラーは正しい動作であって、最初の DNS 問題の症状ではありません。

次に何をするか

何も触る前に分離を確認します。完全な名前は解決し、短い名前は解決しない、同じアプリ、同じセッション。そのうえで選択中のネットワークを見つけ、そのドメイン検索一覧をリゾルバー一覧と並べて読みます。どちらが空かで、誰が動くべきかがわかります。アプリを持っているならあなた、そうでなければトンネルの運用者です。

最後に、可搬性が重要な場面ではブックマークとクライアント設定に完全なサービスホスト名を使ってください。ネットワークの切り替えを越えて生き残り、モバイルのフロントエンドが実装していないかもしれないマッピングに依存せず、証明書が発行された名前と一致します。