Mac Mail、二つのアカウント、分けられない一つの VPN ルール

Mail を開くと仕事の受信箱は同期し、個人用はタイムアウトし始める。あるいは両方が同期しても、仕事のサーバーはトンネルが上がっている間しか応答せず、Mail はどちらのアカウントがどちらか分からない。症状はいつも同じ形だ：一つのアプリ、二つのアカウント、そしてアプリを識別するルール。修正は、アプリが境界ではなく入れ物だと認めることから始まる。

ここには三つのセレクターがあり、互いに置き換えられない。一つは接続を作るプロセス、もう一つは到達するホスト、三つ目はそのホスト経由のサインインに使われる ID だ。ポリシーが名指しできるものが、実際に築ける境界になる。

アプリが誤った単位である理由

Mail は設定されたすべてのアカウントを扱う単一のプロセスだ。アプリに対して書かれたルールはその接続をすべて捕捉するため、個人用アカウントは仕事のトンネルとその既定ルートを引き継ぐ。それが許容できる場合もあるが、それは判断であって、検証せずに放置できる副作用ではない。

何かを直す前に、利用者が実際に何を訴えているかを確認する。同期はするが送信できない受信箱は、通常は受信箱ではなく送信サーバーを指し、どちらも同じプライベート範囲の別アドレスに置かれ得る。不具合が受信か送信か両方かを尋ねる。その答えでルールが覆うべき端点が決まり、サーバー管理者との往復を一度節約できる。

二つのアカウントが別のサーバーを使う場合

仕事のメールが社内範囲のホストと通信し、個人のメールが公開プロバイダーと通信するなら、宛先ベースの構成で要件を表現できる。メールサーバーの実際のアドレス、それを解決する DNS、同じサービスに伴う送信や認証の端点が必要だ。ポリシーを書く前に三つとも集めるのは、受信箱だけを覆うルールが最初の送信で失敗するからだ。

使うのはアドレスであり、@ 記号より後の部分ではない。メールアドレスのドメインはルーティングの表明ではなく、そう扱うと誤ったホストで発火するか、まったく発火しないルールになる。実際の端点はアカウント設定か管理者に確認する。

二つのアカウントが一つのサーバーを共有する場合

同じホストアドレス上の二つのアカウントは、宛先ベースの選択を完全に無効にする。そのアドレスへの経路は接続する誰にでも提供され、後からどのメールボックスがサインインするかは検査できない。経路を移せば両方のアカウントの道が移り、それは利用者が避けようとしていた結果そのものだ。

その時点で正直な選択肢は、プラットフォームとクライアントが対応していればアカウントを意識したポリシー、アプリの境界を実際のものにするために仕事用アカウント専用の承認済みメールクライアント、または両方のアカウントが一緒に移動することを受け入れることだ。意図的に一つを選び、どれを選んだかを言う。

トンネルを起動することは、それを覆うことではない

Apple の App Layer VPN ペイロードは MailDomains 設定を文書化している：一覧のドメインは、対応する管理対象の展開で Mail に VPN 接続を起動させる。有用な機能だが、聞こえるより狭い。Mail がそれらのドメインと通信するときにトンネルを開始するだけで、すべての経路、すべてのアプリの関連付け、トンネルが下がっている間の挙動を記述するものではない。

これは管理対象の機能でもあり、Mail の画面にあるアカウントごとのチェックボックスではない。展開が管理対象でなければ、その設定は利用できず、プロファイルをどれだけ編集しても生まれない。

キャッシュされた受信箱ではなく、新規同期で試す

受け入れテストは、意図したポリシー下での各アカウントの新規同期と、保護対象の利用不可状態だ。キャッシュされた受信箱は次の要求について何も証明せず、接続中の VPN アイコンは何らかのトンネルがあることしか示さない。

管理者に仕事用アカウントの端点と個人メールに望む挙動を渡し、対応しているアカウント意識型・ドメインベース・アプリケーションポリシーのどれで実装するかを尋ねる。両方のアカウントが各条件で同期するのを見ることが、設計した境界が機械の強制する境界である唯一の証拠だ。