Mac PF VPNロック:配布できる機能ではなく、現場のポリシー
Packet Filterは配布製品向けのサポート対象APIではありません。ルールセットにオーナーを定め、すべての例外を名指しし、遷移をテストしてください。
あなたのMacでは動くので、ユーザーに渡せるものに見えます。その想定をまず捨ててください。AppleのTN3165は、Packet Filterが一般に配布される製品向けのサポート対象APIではないと明言し、特権的で管理されたサイト運営を妥当なケースと位置づけています。したがってPFで作ったVPNロックは、オーナーを持つローカルな運用ポリシーであり、アプリに同梱して配布できる機能ではありません。
PFはパッケージングの面ではない
この区別は観念的ではありません。PFに依存する配布製品は、Appleが加えるあらゆる変更を引き継ぎ、ルールを書く別のツールとの衝突もすべて引き継ぎ、その構成が動き続けるというサポートの約束も得られません。自前のマシンを管理するサイトは関係が異なります。依存関係を文書化し、各OSリリースに対して検証し、保守を受け入れられます。
一部のインストール手順は、名指しする価値のある一線を越えています。一つのアンカーを読み込ませるためにシステムのルールセット全体を上書きする、Appleのシステム起動構成を編集する、System Integrity Protectionを無効化する、といった要求は再利用可能な手順として受け入れられません。公開されたガイドがそのいずれかを必要とするなら、それは実験室の説明であって、配備できるポリシーではありません。
構文より先に出口の意図を書く
キーワードをひとつ選ぶ前に、何を許可するかを決めます。通常は三つの経路が必要です。VPNクライアント自身のサーバーへの通信、トンネル内の保護対象アプリのトラフィック、そして設定やローカルサービスが本当に必要とする直接経路です。
提案する例外には、宛先、通信方式、オーナーを与えます。一つの端点に全ポートを許可すると、トンネルが使う一つの通信方式よりはるかに多くを許すことになり、余分な露出は誰も決めないまま生まれます。公開リゾルバーを許可するのは、より親しみやすい装いの同じ罠です。トンネルが落ちている間も直接のDNS経路を作るので、名前解決は依然として漏れます。
| Path | Destination | Owner |
|---|---|---|
| VPN transport | Gateway address, one UDP port | Network team |
| Tunnel traffic | Internal prefixes | Application owner |
| Resolver exception | Named internal resolver | Security team |
例外の有用なテストは、それを求めた人と、それが防ぐ障害を名指しできるかどうかです。どちらの答えもないなら、そのルールはおそらく、放置すれば見えないままになる設定ミスの回避策です。
utun番号は身元ではない
MacOSはトンネルインターフェースをutunデバイスとして作成します。そしてVPNに割り当てられる番号は安定していません。再起動、再接続、別クライアントの存在によって変わります。推測した複数の番号を並べたルールはポリシーではなく、ある午後のスナップショットです。
ルールは、意図したプロバイダーを識別する何かに固定します。トンネルが割り当てるアドレス計画、インターフェースを所有するプロセス、VPNクライアント自身が維持する設定のいずれかです。そのうえで識別の仕組みを記録してください。一年後にルールを見直す人には、あなたのシェル履歴は残っていません。
読み込まれたポリシーを帰属可能にする
アンカー名はルールを整理するもので、実際に効いているポリシーが意図どおりだとは証明しません。アンカー間の優先順位、他のソフトが読み込んだルール、既存の状態が結果を変え得ます。そのマシンでPFを所有する他の人と一緒に実効セットを確認し、設定と同じ場所に所有関係を文書化してください。二人のオーナーが異なる前提で別々のアンカーを編集するのが、ロックに穴が開く普通の経路です。
ルールセットはサイトのサポート対象の設定パスに置き、バージョン管理し、どのmacOSリリースで検証したかを記録します。手作業で適用し、一人が覚えているだけの変更は、ファイルのヘッダーが何と言おうと、保守されたインフラではありません。
接続状態ではなく遷移をテストする
トンネルが上がっている間に撮ったスクリーンショットは、ほとんど何も証明しません。代わりに状態をたどります。接続前の起動、動作中のトンネル、警告なしに落ちるトンネル、意図的な切断、Wi-Fiからテザリングへの移動です。各状態にはそれぞれの答えがあり、興味深いのは正常経路ではなく失敗です。
各状態で、意図的に到達できるものを記録します。IPv4とIPv6を別々に確認し、名前解決を試し、遷移前に確立済みだったフローも含めます。既存の接続は新しいポリシーに従うとは限りません。トンネルが落ちている間に失敗するブラウザは一つのデータ点であり、他のすべての経路が遮断されている証拠ではありません。
最後に、変更しているネットワーク経路に依存しない復旧手段を用意します。ローカルストレージ上の既知の良好な設定と、それを読み込む文書化された手順があれば、ロックはポリシーになります。それがなければ、一つの悪いリビジョンが、保護されるはずだったマシンから管理者を締め出します。