社内VPNに接続した瞬間、デバッグ用プロキシが沈黙する
プロキシ側の設定は何も変わっていません。トンネルの接続エントリが独自の設定を持ち、管理されたPACが復活し、システムプロキシをまったく読まないクライアントもあります。
キャプチャツールは午前中ずっと動いていたのに、トンネルが繋がった途端に沈黙する。切断すればまた動き出す。VPNがプロキシを壊したと考えがちだが、プロキシの設定は実際には何も変わっていない。変わったのは、アプリケーションがどの設定を読むかだ。トンネルのエントリは独自のプロキシ設定を持てるし、管理されたプロファイルが自動構成を再有効化することもあり、一部のランタイムはOSが提供する設定の一部しか読まない。グローバルの値を触る前に、接続ごとの値を読んでほしい。
Windowsは接続ごとにプロキシを保持する
インターネットオプションには、ダイアログ上では同じに見える二つの層がある。LANの設定は通常のローカル接続に適用され、ダイヤルアップやVPNのエントリは HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections の下に独自のコピーをバイナリ値として保持している。よく知られたグローバルのレジストリ値を書き込んでも、そのコピーは更新されない。
ツールが接続前は正しく、接続後は誤って動くのは、まさにこのためで、設定のどこにも見える変化はない。見つめていたダイアログはLANのパネルだった。それは正しく、そして無関係だった。Windowsが実際に使っていたのは、トンネル用に作られたエントリのほうだ。
一つのエントリを変更する正式な方法はWinINETの接続オプションAPIだ。INTERNET_PER_CONN_OPTION_LIST に接続名、フラグ、プロキシサーバー、バイパス一覧を入れて適用し、そのあと更新する。手早く確認するなら、トンネルのエントリ自身の設定ダイアログを開き、そのプロキシパネルをLANのパネルと比べればよい。どこを見るべきか分かっていれば、違いはたいてい一目で分かる。
管理されたPACは勝手に復活する
macOSでは、自動プロキシ構成スクリプトとプロキシ自動検出はネットワークサービスの属性であり、マシンの属性ではない。構成プロファイルがそれらを必須にできるため、チェックを外しても再び現れ、そのあとはスクリプトが選ぶプロキシへすべてのリクエストが送られる。
点検し、権限があるなら、通信を担うサービスについてその二つのスイッチを切る。
networksetup -setautoproxystate "Wi-Fi" off
networksetup -setproxyautodiscovery "Wi-Fi" off
scutil --proxy推測ではなく実際のサービス名を使うこと。Wi-FiとUSB Ethernetアダプタの両方があるノートPCには二つあり、通信を担っているのは片方だけだ。scutil --proxy は現在のプライマリサービスの値を出力する。プロファイルが勝ったと結論づける前に、その出力と自分が編集した内容を比べる。
ツールを本当の上流に向ける
スクリプトに社内プロキシが含まれているなら、それを読み、同じアドレスをキャプチャツールの外部プロキシとして入力する。するとツールは本当の上流へ転送する。社内プロキシが期待しているのはこれで、ポリシーと戦う代わりにリクエスト経路に留まれる。
これが、再設定ではなくデバッグを続けられるようにする一手だ。
プロキシをトンネルの中へ押し込む
OpenVPN ベースのクライアントは、トンネルが上がったあとに有効になるプロキシオプションを受け付けられる。ルートをクライアントが持っている場合には便利だ。
dhcp-option HTTPPROXY 127.0.0.1:8888
dhcp-option HTTPSPROXY 127.0.0.1:8888このオプションを尊重するクライアントだけが使い、しかも待ち受けポートをプロファイルに固定して書き込む。配備の標準ではなく実験室の便宜として扱うべきで、次のプロファイル配信で消える。
システムプロキシをまったく読まないクライアントもある
Firefoxは独自のプロキシ設定を持つので、システムプロキシを使うブラウザが止まっても、こちらはキャプチャを続けることがある。自動構成を理解しない古い.NETクライアントは、どこで動いていても直接接続するので、トンネルのエントリ経由で読み込んだページでもアプリ内部では失敗しうる。
ネットワークツールにも固有の原因がある。トンネルやテザリング越しに固まるFTPセッションは、クライアントが折衝するアクティブ対パッシブの問題であることが多く、プロキシ設定では変わらない。
設定を読む、トグルを見るのではなく
この順で進める。トンネルのエントリ自身のプロキシ値、サービスごとのPACと自動検出の状態、そしてアプリ自身のプロキシ処理。想定と違った最初のところで止める。
ここでの事例はどれも設定の優先順位の問題だ。トンネルがツールを壊しているわけではない。