macOSのサービス順序はVPNのルートを制御しない

Webサイトで何かが失敗すると、同僚がサービス順序の存在を思い出し、Wi-FiがEthernetの上へドラッグされる。何も変わらない。その一覧はVPNの宛先がどこへ行くかを一度も決めていないからだ。AppleはVPN接続を通常の接続より優先し、この並べ替えの対象外に置いている。だからこのスイッチが答えるのは、尋ねられた問いより狭い問いだ。必要なのは選択されたルートとリゾルバであり、新しい順位ではない。

サービス順序が変えるもの、決して触れないもの

「サービスの順序を設定」はシステム設定のネットワーク、アクションメニューにあり、二つ以上の通常接続が有効なときにそれらを順位付けする。その順位が主サービスを選び、既定のルートとリゾルバの挙動の一部を決める。これは対等な接続間のタイブレークであり、トンネルの向こうのプライベートな宛先のためのスイッチではない。Wi-FiとUSB Ethernetアダプタを備えたノートブックは、もっともな問いに答えるためにこれを使うが、その問いはトンネルについてではない。

VPNプロファイルは、含めるルート、除外する宛先、ときにアプリごとの規則を保持し、トンネルに入るものを決める。順序メニューはそれらを編集しない。だから分割トンネルのプロファイルでは、VPNがすべての物理インターフェイスより上位のままで、公開トラフィックを外に置ける。Wi-Fiを最上部へドラッグしてもプライベート範囲に到達できるようにはならず、プロファイルがすでに含む宛先を止めることもできない。一覧が動かすのはインターフェイス、プロファイルが動かすのはプレフィックスだ。Appleはこの優先順位をネットワークサービス順序のページで説明しており、何かを並べ替える前に一度読む価値がある。

マシンが実際に選んだルートを読む

特定のアドレスがどこへ行くかをroute get 10.20.4.10でマシンに尋ね、IPv6についてはroute -n get -inet6 2001:db8::10で繰り返す。二つのファミリーは別々の判断なので、動くIPv4ルートはv6について何も語らない。直接接続されたサブネットやより具体的なプレフィックスは、いずれにせよ一般的な接続ラベルに勝つ。だからこそそのラベルは人を誤解させ続けるのだ。

出力がトンネルのインターフェイスを名指しすれば、プロファイルが宛先を捉えており、順序は無関係だ。物理インターフェイスを名指しすればプロファイルは捉えておらず、どれだけドラッグしてもプレフィックスの表は変わらない。どちらの出力もマシンが使う送信元アドレスを名指しする。二回の実行を比べるときに引用すべきはそのフィールドだ。何かを変える前に出力を保存しておくこと。後で残る唯一の証拠になる。

DNSはインターフェイスではなく名前で解決する

スコープ付きおよびドメイン固有のリゾルバは、答えがインターフェイスごとではなく名前ごとに異なりうることを意味する。scutil --dnsはシステムが実際に使っているリゾルバ設定を、スコープ付きの項目も含めて出力する。サービス順序は既定のリゾルバをどのサービスが提供するかに影響するが、名前固有のスコープがそれでも勝つことがある。

だからアドレスへのpingは通るのにホスト名が失敗する、あるいはその逆が起きる。犯人を決める前に両方の出力を読むこと。

プロファイルを変え、それから両方の出力を読み直す

宛先ポリシーを変える必要があるとき、所有者はVPNプロファイルだ。含めるルート、除外するルート、ベンダーが対応する分割トンネルの規則である。代わりにインターフェイスを変えても論争が移るだけだ。リモート管理のMacでは、まず現在のネットワーク状態を保存すること。到達できないマシンでトンネルを失うのは、切り戻しではなく出張になる。

失敗を再現し、ルートを読み、リゾルバを読み、一つだけ変えて、それから同じ二つの出力をもう一度読む。複数のサービスとプロファイルを一度にいじると、直した本人にも説明できないマシンが残る。意図した変更に両方の出力が一致したとき、テストは終わる。まだ食い違うなら、プロファイルとマシンは別々のポリシーを語っており、変えるべきはプロファイルだ。