VPNなしでメールがサーバーに届く：ルールをどこで強制するか

メールは問い合わせを続け、VPNは落ちているのに、アカウントはまだ同期している。アプリは設定されたとおりに動いており、通常のメールプロファイルには、サーバーがトンネル経由でしか届かないとはどこにも書かれていない。そこには「サービスが直接クライアントを拒否する」か「Macが決して試みない」かという二つの異なる要件が残り、両者は混同しやすい。

製品を選ぶ前に要件を選ぶ。サーバー側のルールとクライアント側のルールは異なる場所で失敗し、異なる証拠を生み、異なる担当者に属する。両方を適用することは、両方の命題が真である場合に妥当だが、一方が他方を置き換えるものではない。どちらの要件も正当だが、ただ同じ制御ではない。

症状はMacに見えるが、漏えいはサーバーかもしれない

メールがトンネルの外で同期するときは、サーバーが何を受け入れるかから始める。メールリスナーがインターネットからの直接接続に応答するなら、クライアント側のどんな利便設定もその事実を変えない。Macはまだ開いているサービスに対して普通に振る舞っている。

メール管理者に、サービスがどの送信元アドレスを見ているかを尋ねる。VPNゲートウェイ、リバースプロキシ、ロードバランサーはクライアントのアドレスを変換することがあるため、VPN設定のアドレスプールがメールプロセスに届くものと一致しない場合がある。誤った送信元に対して書かれたルールは、全員を遮断するか誰も遮断しないかのどちらかになる。

その答えは、サービスがVPNクライアントをそもそも区別できるかも教えてくれる。すべてのクライアントが同じプロキシアドレス経由で届くなら、送信元に基づく受け入れでは区別できず、要件は認証かクライアント側へ移さなければならない。

サーバー側の受け入れ：アプリではなく送信元を拒否する

ホストまたはネットワークのファイアウォールは、認証とTLSを変えずに、メールリスナーを承認済みの送信元範囲に制限できる。リモートアドレス、サブネット、範囲に一致するルール条件が通常の構成要素であり、正確な構文はサーバーのファイアウォール製品に属し、メールアプリには属さない。

「サービスは直接クライアントに応じてはならない」という要件では、これが最も強い境界である。利用者が別のメールクライアントを入れても、拒否が認証の前に行われるため保たれる。VPNポリシーを無視するMacにも耐える。

その限界も同じくらい重要である。拒否された接続はサービスがセッションを断ったことを示すが、Macが試みなかったことは示さない。DNS解決、以前のロードバランサーへのTCP SYN、失敗後の再試行は、すべてサーバーのルールに届く前に起こりうる。要件がアクセスではなく試行の開示に関するものなら、サーバー側の受け入れは制御の半分にすぎない。

クライアント側の強制：トンネルだけでなく試行を遮断する

クライアント側のルールは、メールを開いたときにトンネルを起動するだけでなく、通信を禁止しなければならない。メールドメインの起動トリガーは適切な瞬間にVPNを立ち上げられるが、トンネルが落ちている間や失敗した後に何が起きるかは定義しない。

エンドポイント製品がサポートするブロックポリシーを使い、その範囲を意図的に定める。アプリ単位のルールはそのメールアプリの全アカウントを対象とし、個人用アカウントも含む。宛先単位のルールは、業務アカウントのIMAP、送信、認証のエンドポイントを名指しし、それらのアドレスが変わっても機能し続けなければならない。

両方のアドレスファミリーと既存のセッションを対象にする。新しいIPv4接続を遮断しつつIPv6や確立済みソケットを放置するポリシーは、不規則に見える断続的な同期を生む。ネットワークの変更とスリープの周期は同じテストの一部である。

アプリ単位と宛先単位のルールでは影響範囲が異なる

アプリ単位のブロックは筋が通っており、トンネルなしではメールから通信が出ない。同時に、同じアプリにポリシーと無関係な個人用アカウントが入っていることもあるため粗い。利用者はまずそれに気づき、壊れたメールアプリとして報告する。

宛先単位のブロックはより狭く、維持が難しい。アカウントが使うエンドポイント一式、発見と認証のサービスを含めて必要とし、それらを更新する手順も要る。一つ漏れればアカウントは半分しか動かず、入れすぎれば無関係なメールが止まる。

要件の文言で選ぶ。「この業務アカウントは直接接続してはならない」は宛先の範囲を指す。「このMacはVPNの外でメールを動かしてはならない」はより広いアプリのルールを正当化するが、所有者が個人用アカウントへの副作用を受け入れることが条件だ。

拒否と不在を別々に試す

専用のテストアカウントでVPN経由で接続し、通常動作を確認する。次に切断し、一度はサーバーがログインを拒否するか、もう一度はMacが接続を試みるかどうかを見るために二度試す。これらは別の観察であり、別のログに属する。

切断中はSYNやDNSクエリについてクライアント側の証拠を、拒否または受け入れられたセッションについてはサーバー側のログを見る。サーバーが拒否してもクライアントがまだ試みるなら、サーバーのルールは働いており、クライアントのルールが欠けている。クライアントが試みずサーバーが他のクライアントを受け入れ続けるなら、境界はまさに置いた場所にある。

強制の担当者、サーバーが実際に見る送信元アドレス、使用したテストアカウントを記録する。次のネットワークやプロキシの変更でその送信元は動きうるため、観測した値を名指ししたメモはもう一巡の推測より速く確認できる。