Mac の VPN・コンテンツフィルタ・Private Relay、どれが有効か
Mac の三つのネットワーク層は「設定」で同じに見えます。出口の経路、フローのポリシー、閲覧の範囲で VPN、コンテンツフィルタ、Private Relay を見分けます。
Mac では VPN トンネル、コンテンツフィルタ、iCloud Private Relay が同時にインストールされていることがあり、どれが特定の接続を形作っているかを名乗るものはありません。設定パネルも似ており、アイコンも似ており、ほとんどすべてのベンダーが自社製品をネットワークセキュリティと呼びます。三つの事実がそれらを分けます。トラフィックが名前を挙げられる遠隔の終端から出るかどうか、ポリシーエンジンが個々のフローに許可か遮断かを判断しているかどうか、保護が Safari で止まるかどうかです。この三つを整理すれば、私の VPN は有効かという問いの大半は自ずと答えが出ます。
コンポーネントを識別する三つの条件
第一の条件は出口です。トンネルプロバイダはパケットを遠隔のゲートウェイに渡すため、公開アドレスが変わり、プロファイルがそう定めていればそのゲートウェイ背後のホストに到達できるようになります。アドレスが決して変わらず、プライベートサブネットも開かないなら、メニューバーが何と言おうと、それは動作するトンネルではありません。
第二の条件は判断です。コンテンツフィルタはフローを評価し、許可か遮断かを返します。カテゴリのブロック、アプリごとの規則、雇用主が配布したポリシーを適用でき、判定を記録できます。単独ではできないのは、トラフィックに行き先を与えることです。
第三の条件は範囲です。Private Relay はデバイス全体ではなく閲覧の一定の部分を守り、その役割は、あなたが誰かということと訪問先とを切り離すことであって、別のネットワークに置くことではありません。
三つを並べれば、境界は見落としにくくなります。
| Layer | Question it answers | Evidence to look for | What it does not do |
|---|---|---|---|
| VPN tunnel provider | Where does my traffic emerge, and which private networks can I reach? | Changed public address, a connected service, a default route through a utun interface | Enforce per-app content policy |
| Content filter | May this flow proceed, and who decided? | A filter extension in Network Extensions, drop verdicts, an MDM profile | Supply a different public exit |
| iCloud Private Relay | Can the local network see which sites Safari loads? | A relay egress address in Safari only, the relay toggle in iCloud settings | Cover other apps or grant access to a private subnet |
コンテンツフィルタはポリシーエンジンであり、出口ではありません
macOS ではフィルタは Network Extension として届き、Apple のフィルタデータプロバイダクラス NEFilterDataProvider の上に構築されます。管理された配備では MDM が配布し、システム拡張としてインストールされ、システム設定 > 一般 > ログイン項目と拡張機能で一度承認されます。以後は TCP フローを、構成によっては UDP も見て、それぞれに判定を返します。
人を混乱させるのは障害の現れ方です。フローを遮断するフィルタは、タイムアウト、止まった TLS ハンドシェイク、リセットを生み、これは上がったもののトラフィックを通せないトンネルとまったく同じに見えます。公開アドレスは変わっていません。変えるべき出口がそもそもなかったからです。
商用クライアントはしばしば両方の役割を同梱します。一つのインストーラがトンネルプロバイダとフィルタを配り、遮断はフィルタが、経路はトンネルが担います。したがってアプリ名からは、どちらのコンポーネントが接続を拒んだのか分かりません。拡張機能の一覧、次に接続中のサービス、次にクライアントのログ、この順で確認します。
Private Relay が覆うのは Safari であり、マシン全体ではありません
Private Relay は対象の閲覧を、別々の主体が運用する二つの中継を経て送るため、単一の事業者があなたの身元と行き先の両方を握ることはありません。これはプライバシーの設計であり、トンネルではありません。入っていけるゲートウェイも、プライベートサブネットも、選んだ国の出口アドレスを固定する手段もありません。
その範囲は意図的に狭く、Safari の閲覧とそれに伴う DNS 問い合わせ、安全でない HTTP の読み込みを覆います。ターミナルのセッション、メールクライアント、チャットアプリ、ゲームランチャーは対象外です。ターミナルでの確認がまだアクセス網のアドレスを示し、Safari が中継のアドレスを示すなら、それは想定どおりの結果で、壊れたインストールではありません。
可用性には条件があります。iCloud+ のプランが必要で、すべての地域で提供されるわけではなく、管理されたネットワークが中継へのアクセスを遮断することもあり、その場合 Safari は直接接続に戻ります。現在の範囲については Apple の Private Relay の概要 が参照先です。VPN プロファイルが接続されてそのトラフィックを運んでいる場合、中継がその上に重なるのではなく、プロファイルが経路を決めます。
証拠は正しい順に読みます
まずサービスの状態から始めます。最も安価な手がかりだからです。scutil --nc list は構成済みの VPN サービスと、それぞれが接続されているかを表示します。プロファイルは一度も接続されないまま何年も居座ることがあり、人はそれをしばしばトンネルと数えます。
次にインターフェースと経路を見ます。ifconfig は utun インターフェースを示しますが、その存在だけではほとんど証明になりません。macOS は VPN 以外にも utun をいくつもの用途で使うからです。重要なのは既定の経路がそのどれかに入っているかで、route -n get default がそれを報告します。
名前解決については、scutil --dns がシステムが実際に使うリゾルバを列挙し、DNS プロキシプロバイダもそこに現れます。dig +short example.com と dig +short example.com @1.1.1.1 を比べれば、応答しているリゾルバと横取りされているリゾルバを切り分けられます。
拡張機能の活動は統合ログに届きます。log show --predicate 'subsystem == "com.apple.networkextension"' --last 5m です。探すのは、どの拡張が起動したか、気にしているフローについてフィルタが判定を報告したかであり、暗記する行ではありません。
何かを無効にする前に症状を絞り込みます
まず障害を分類します。解決しない名前、即座に拒否される接続、タイムアウトまでぶら下がる接続は、三つの異なる観察であり、責任者も三つに分かれます。解決はリゾルバか DNS プロキシを指します。即時の拒否はフィルタの規則を指します。沈黙はたいてい経路、あるいは上がっているが転送していないトンネルを指します。
管理された Mac では、フィルタは組織のものとみなします。VPN を試すために切ると、観察したいコンポーネントそのものを外すことになり、MDM は次のチェックインでしばしば元に戻します。何かを変える前に管理者にポリシー名を尋ね、システム全体ではなく失敗した特定のアプリで試します。
もう一つの落とし穴。VPN を試すために Private Relay を切っても、海外のトラフィックについては何も分かりません。中継はそもそもそのトラフィックを覆っていないからです。各層は、それが実際に統べるアプリで試さなければなりません。
この一覧をたどり、最初に失敗した項目で止まります。
scutil --nc listは期待するサービスを接続済みとして示していますか。- ターミナルから見える公開アドレスは、アクセス網が割り当てたアドレスと異なりますか。
- フィルタ拡張はインストールされており、失敗するフローについて判定を記録しましたか。
- 障害は Safari だけですか。そうなら、トンネルを責める前に中継の範囲を確認します。
四つすべてが通り、それでもアプリが失敗するなら、問題はネットワーク層の上にあります。プロキシ設定、証明書の信頼、あるいはアプリ単位の許可リストです。