MacのVPNとPACプロキシ：設定はひとつではなく、二つの判断

お使いのMacはポリシースクリプトをダウンロードし、そのスクリプトにリクエストがどの仲介役を使うべきかを問い合わせますが、一方でトンネルが決めるのは選ばれたホップへの到達方法だけです。どちらの答えも同じソケットに着地するため、両方が成功した後に失敗するリクエストは、実際には二つの障害でありながら一つに見えます。ダウンロードと選択、選択と経路を切り分けることが、このチケットの作業の大半です。以下の順序はmacOSが実際に行うことをたどり、各段階を可視化する確認を添えています。

PACアドレスとプロキシが分かれる場所

https://config.corp.example/proxy.pacのようなアドレスはダウンロードする文書を指し、その文書はトラフィックを送る先のサーバーを指します。URLをプロキシのホスト欄に貼り付けると、クライアントは決して待ち受けていないファイルサーバーへプロキシ接続を開くよう求められます。ファイルの中にはクライアントがリクエストごとに呼ぶ関数があり、その戻り値がその単一の宛先に対する次のホップです。この間接性が、同じネットワークサービス上の二台が、どちらも正しいURLを持ちながら異なる挙動を示す理由です。また、誰もプロキシ自体に触れずにポリシー変更が有効になる理由でもあります。

下流を解釈する前にスクリプトを読みましょう、中のルールが組織の例外とその適用順序を運んでいるからです。早い段階の広い範囲は後の内部サフィックスを覆い隠すことがあり、明らかにプロキシを迂回すべきホストが使い続けます。ポリシーが間違っていると誰かが主張したとき、その主張が決着する唯一の場所がスクリプトです。

スクリプトは何かを決める前に取得されなければならない

ポリシーのダウンロードには、名前の解決とファイルを提供する先への経路が必要であり、接続されたトンネルはどちらも保証しません。ホストがプライベートDNSでのみ解決される場合、その時点で使われているリゾルバーがダウンロードを開始できるかを決めます。ホストがプライベート範囲にある場合、経路は同僚のノートPCではなくこのマシンから存在しなければなりません。以前のセッションでキャッシュされたコピーは、キャッシュが切れるかマシンが再起動するまで、これをすべて隠します。

以下の三つの確認を順番に実行し、最初の失敗で止めてください。段階は原因を共有しておらず、合わせてポリシーが構成されているか、到達できるか、何を返すかを示します。

scutil --proxy
networksetup -getautoproxyurl "Wi-Fi"
curl -sS -o /dev/null -w "%{http_code}\n" https://config.corp.example/proxy.pac

最初のコマンドは、システムが保持している自動構成URLを含め、アクティブなサービスのプロキシ辞書を出力します。二つ目は、Wi-FiとEthernetの間を移動するノートPCで重要な、名前付きサービスに紐づくURLを報告します。三つ目はファイルを描画せずに取得するので、404、タイムアウト、リゾルバーの失敗を区別したままにできます。最後のコマンドがスクリプトを返すのにアプリがまだ失敗するなら、問題はすでに取得を過ぎています。

DIRECTの答えが実際に飛ばすもの

PAC仕様はクライアントに小さな語彙を与え、DIRECTはその一語です。その語はクライアントにそのリクエストでプロキシを飛ばすよう伝え、その後ソケットがどのインターフェースを使うかについては何も言いません。完全なトンネル上の直接ソケットも依然としてVPNから出て、依然としてトンネルの出口アドレスを宛先に見せます。

DIRECTをVPNの外と読むのが、人々を間違った設定パネルへ送る誤りです。鏡像も同じくらいよくあり、プライベートプロキシには分割ルートで到達できる一方、マシンの残りはトンネルの外に留まります。そのとき宛先が報告するのはプロキシ自身の出口に属し、それは別の国にあるかもしれません。内部ホスト一つと公開ホスト一つについて期待を書くと、スクリプトはしばしば両者に違う答えを返すため、すぐに露見します。どのホップがアドレスを生んだか分かれば、報告は謎ではなくなります。

一つのエラーページとして現れる三つの失敗

ポリシーのダウンロードに失敗することがあり、選ばれたプロキシに到達できないことがあり、サービスに届いたリクエストがそこで拒否されることもあります。三つともタイムアウトや一般的なエラーページとして現れ、どれも壊れた段階を名指ししません。エラーの隣で判断を記録することが、それらを分けます。以下の二つのプローブはスクリプトが選んだホップを試し、返しうる各分岐に一つずつ対応します。

curl -v --max-time 8 http://proxy.corp.example:8080/
curl -v --max-time 8 https://intranet.corp.example/

プロキシへの接続が完了すると、問いは認証やプロキシ自身のポリシーへ移り、そちらは別の担当です。経路にプロキシがない内部ホストへの接続が完了すれば、経路が除外されポリシーが疑われます。どちらのコマンドも、シェルがプロキシ変数をエクスポートしない限りmacOSのプロキシ辞書を無視するので、先にそれらを消してください。どちらのプローブも他方を証明しないので、一つのエラーページがこれほど長く誤解させるのです。

チケットと一緒に何を渡すか

アクティブなネットワークサービス、PACのURL、失敗するホストの評価結果、エラーが現れた段階を送ってください。この四つがあれば、次に担当する人はどの層が関与したかを推測せずに判断を再現できます。テスト時点のトンネル状態も加えてください、再接続前に取得した結果は古いからです。スクリプトのリビジョンも残してください、ポリシーファイルは予告なく変わり、昨日の答えがもう有効でないことがあります。

スクリプトを取得できないときにクライアントがどう振る舞うか、実装がさまざまでプロキシの判断がデバイス全体のキルスイッチではないことを記録してください。直接接続に戻るものもあれば、閉じたまま失敗するものもあり、その違いが障害が壊れたプロキシに見えるか、機能しているポリシーに見えるかを変えます。インシデントの最中に頼る前に、正確なクライアントとバージョンで挙動を確認してください。