Android: Always-On と VPN なしのブロック、正しい組み合わせを選ぶ

Always-On と VPN なしのブロックは別々の設定で、片方を有効にしてももう片方は有効になりません。必要な組み合わせは、端末の所有者、トンネルが覆うアプリ、ロック解除前の挙動という三つの条件で決まります。

異なる約束をする二つのスイッチ

Always-On は持続の約束で、サービスが落ちれば再起動します。ブロックは封じ込めの約束で、トンネルが使えない間、対象の通信には外へ出る道がありません。

三つ目の要素はアプリごとの範囲で、これはクライアントや管理ポリシーに属し、二つのシステムスイッチにはありません。範囲を決めずにブロックすると、要件より広いか狭いポリシーになります。

判断その一: 管理端末か、利用者の設定か

管理端末ではポリシーが Always-On とロックを保持し、ローカルのスイッチが無い、灰色、または次のポリシー更新で戻ることがあります。これはポリシーが機能している状態で、回避すべき不具合ではありません。要件は端末ではなくポリシーで変えます。

個人端末では利用者が選びます。正直な問いは、トンネルが使えないときにオフラインを受け入れるかです。ブロックは可用性の交換であり、そう説明すべきです。スイッチが無いことは root 化や管理解除の口実になりません。

範囲は端末ではなくプロファイル単位です。個人と仕事のプロファイルは別の文脈で、Android はユーザープロファイルごとに一つの VPN しか有効にできません。

仕事プロファイルのブロックは個人側について何も語らず、一方の検証は他方を保証しません。

判断その二: すべてブロックか、一部アプリを除外か

ブロックモードのアプリ別除外は逆に理解されがちです。Android の文書では、アプリ別 VPN から除外されたアプリはブロックモードで接続を失うことがあり、通常のネットワークを黙って使うわけではありません。除外はインターネットの許可証ではないのです。

意識して選びます。対象の通信をすべてブロックし、除外したアプリが暗くなるのを受け入れるか、ブロックを切って迂回路を受け入れるかです。一つのアプリが常に接続すべきなら、その端末にブロックは適切な道具ではありません。

判断その三: ロック解除前とポータルでは何が起きるか

多くのクライアントでは、利用者がロックを解除するまでトンネルは上がりません。起動直後の数瞬は空白であり、故障ではありません。導入するクライアントで確認してください。

キャプティブポータルはもう一方の端です。ホテルや空港のネットワークは認証前のブラウザーセッションを必要とし、強いブロックはサインインを不可能にします。支持される答えは承認済みの復旧手順で、トリガー、最長期間、誰が許可するか、事後に強制が自動で戻ることの確認を定めます。

Android の VPN クライアントに関する公式文書は、Always-On とブロック、アプリ別除外、プロファイルごとに一つの VPN という規則を扱っています。古い記憶で設計する前に読んでください。

オフライン状態を試し、受け入れ条件を書く

無害な通信とクライアントが対応する障害テストを使います。通常の接続、トンネルの損失、復旧、ロック解除前の再起動を確認し、対象アプリが接続したか、意図どおりブロックされたか、別の経路を取ったかを記録します。

状態アイコンではなく、リソースとリゾルバーを検証します。VPN インターフェースがあっても有用な経路が使えないことはあります。テザリングした端末も別に試します。スマートフォンのポリシーはホットスポットのクライアントに転送を設定しないからです。

受け入れ条件は具体的で検証可能です。意図したプロファイルの意図したアプリが承認されたトンネルに到達し、到達できないときは必要なブロック状態にとどまること。署名の前に:

• Always-On とブロックは、プラットフォームが対応する場所で設定され、各設定の所有者が分かっている。
• アプリの範囲は意図的で、ブロックモードで除外アプリがどうなるかを確認済みである。
• ロック解除前の空白とキャプティブポータルの手順は、発見ではなく決定済みである。
• 障害テストは実際に導入する端末クラスで実施した。