Android で VPN 経由のファイル共有が開けない理由

端末は VPN に接続しており、ファイルサーバーは ping に応答するのに、ファイルアプリは接続できないと報告する。あるいは接続はできても、端末上のどのエディタも一覧のファイルを開けない。これは二つの別の障害であり、どちらもトンネルが壊れていることを意味しない。VPN が提供するのはプライベートネットワークへの経路だけであり、共有を閲覧すること、共有に対して認証すること、文書を別のアプリに渡すことは、それぞれ別の失敗の仕方を持つ別の手順である。以下では私が確認する順序と、推測で進めるのをやめる地点を示す。

トンネルを疑う前にサービスを確認する

ping の応答や NAS の Web ページが証明するのは経路だけである。実際に必要なサービス、すなわち 445 番の SMB、22 番の SFTP、443 番の WebDAV は、無効化されているか、ファイアウォールで遮断されているか、VPN サブネットから到達できないインターフェースに束縛されているかもしれない。端末からは、一般的なネットワークの警告ではなく実際のエラーを表示するクライアントで、そのポートを直接試す。ポートがフィルタされているなら、サービスかファイアウォール規則を直すべきで、閉じたポートをファイルアプリ側で回避することはできない。

サーバーから見える送信元アドレスも確認する。共有のサブネットを除外したスプリットトンネルや、ファイルアプリを VPN の外に置くアプリ単位トンネルは、まさに接続済みなのに到達できないという症状を生む。

一つのクライアントが認証できないからといって、ゲストアクセスや SMB1 を有効にする近道に走らないこと。そうした変更はネットワーク上のすべての端末に対してサーバーが受け付ける範囲を広げるだけで、根本原因が経路や名前解決なら何も直らない。共有に特定のアカウントが必要なら、サーバーが期待するドメインやワークグループの接頭辞も含めてそれを使う。

プロトコルを自分で話せるファイルアプリを使う

Android にはネットワーク共有のためのブラウザが標準で入っていないため、クライアントアプリは細部ではなく実際の依存関係である。実際に運用しているプロトコルを実装し、今も保守されているものを選ぶこと。使わなくなった Android の版向けに作られたクライアントは、ネットワーク障害に見える形で失敗する。検出がサブネットを越えない場合は、アプリが見つけてくれるのを待たず、ホストを明示的に入力する。

DNS と経路を切り分けるために、一度サーバーを IP で試す。IP では通り、名前では通らないなら、端末はプライベートゾーンを見られない DNS サーバーで解決している。

受け取るアプリに渡るのは URI でありパスではないと知る

ファイルアプリが DocumentsProvider を実装していれば、Android の Storage Access Framework はその内容をシステムのピッカーに表示でき、そこから選んだアプリは content:// URI と権限の付与を受け取る。その付与はファイルシステムのパスではないため、生のパス名に固執するエディタは、ピッカーに一覧が出ていても文書を開けない。Android の文書アクセスガイドがそのモデルを説明している。バイト列を所有するのはプロバイダーであり、利用側はシステムを通じてそれを読む。URI を受け付けるアプリは動作し、パスに対して open() を呼ぶアプリは動作しない。ファイルアプリでは共有が使えるのに、他のどこでも失敗する最もよくある理由がこれである。

別の方法は意図的なコピーである。ファイルをエディタ自身のストレージに取り込み、編集してから書き戻す。それ自体は妥当な流れだが、二つ目のコピーと競合の判断が生じるので、電車の中で編集を始める前にどちらを正とするかを決めておく。

ここではアプリ単位の VPN ポリシーにも目を向けるべきだ。ネットワークの読み取りを行うパッケージはエディタではなくプロバイダーアプリであることが多いので、タップしたアイコンで判断せず、正しいパッケージをトンネルに含める。

読み取り・書き込み・権限の永続性を分けて試す

ディレクトリの一覧が証明するのは読み取り経路だけである。無害なテストファイルを使い、一覧、開く、編集、保存、そして同じファイルをデスクトップのクライアントから開き直す、という一連の流れをすべてたどる。

再起動後の権限の永続性にも注意する。アプリが永続的に取得しない限りストレージの付与は一時的であり、起動のたびに再要求するエディタもあれば、静かに失敗して古いコピーを見せるエディタもある。保存が成功したように見えたら、更新時刻を確認するか別のマシンから開き直して、サーバー側で確かめる。保存の途中で切断する場合も試すこと。アップロード中の VPN 切断は、クライアントが部分的なファイルや同期されないローカルの変更を残す最も起きやすい瞬間だからである。

Android の URI 権限とサーバー側の認可は分けて考える。文書を開くことを許されているからといって、その背後にある SMB アカウントについては何も言えない。

マウント共有は必要な場合に限る

root 権限での CIFS マウントやカーネルのファイルシステムモジュールは今も存在し、すべてのアプリにローカルディレクトリの錯覚を与える。だが root が必要で、カーネルの変更で壊れ、ネットワークの失敗をファイルシステム層の内側に隠して診断を難しくする。端末で文書を編集する用途なら、プロバイダーかコピーの流れで実際に必要なことのほとんどは足りる。

その上に作業の流れを組む前に、マウントがネットワークの変化に耐えるかを確認する。机の上のノート PC からマウントした共有は、Wi-Fi と携帯回線を行き来する端末とは振る舞いが異なり、古びたマウントはアプリをきれいに失敗させるのではなく固まらせることがある。

それでも行き詰まるなら、次の一覧を順にたどり、最初に失敗した手順で止める。ポートに到達できるか、プロトコルのクライアントが入っているか、共有に対して認証できたか、ピッカーにファイルが出るか、エディタが URI を受け付けるか、保存がサーバーに届くか。その手順が直すべき部品を教えてくれる。そしてそれはトンネルであることはほとんどない。