zoom や、teams と並んで、webex もリモート会議等によく使われます。今回は、プロキシ＆SSL 可視化システムにおいて、webex がうまく動いてくれないときの対策について、検証結果を書き留めておきます。

webex プロキシ で検索すると、結構な数の情報を読むことが出来ます。結果、Windows の場合はシステムのプロキシ設定（手動）を ON にして、そのプロキシ除外設定に *.webex.com を入力することで、プロキシ経由で発生する障害を回避することができます。これだけであれば、わざわざブログの記事にする内容ではないのですが、プロキシ設定には 自動設定 という項目があって、これを ON にすることで、文字通りクライアントPC のプロキシ設定を手動で設定する必要がなくなります。これは、通称 WPAD と言われて、この関連情報もネットでは多数拾うことができます。

しかし、webex に関連する WPAD の設定情報については、ピンポイントで記述している情報は見つけることが出来なかったので、簡単な検証環境を構築して、週末に調べてみました。

　考察と結論

webex は、システムで設定したプロキシ情報を読み込むのですが、少々変わった動作をするので、現場で運用するには注意が必要です。

*.webex.com をプロキシ利用の除外項目として設定するのであれば…

このような感じで wpad.dat に記載すれば良いと思いますが、実はこの設定では十分ではないというか、実機では不思議な現象が発生します。

例えば、Windowsシステムのプロキシ設定において、設定を自動的に検出する を ON、手動プロキシセットアップ で プロキシサーバを使う を ON にして、アドレスには proxy.sample.com を、ポートに 8080 を設定します。その上で、プロキシの除外設定 次のエントリで始まるアドレス以外にプロキシサーバを使います の指定は、空（から）、つまり何も設定しない とします。

プロキシの動作設定の優先順位は、プロキシの自動設定→スクリプト設定→手動設定の筈なのですが、手動のプロキシ除外に *.webex.com を設定しないと、指定のプロキシサーバに webex 関連の通信が流れます。つまり、wpad で設定したにもかかわらず プロキシ除外設定が無効 という状況になります。

もちろん、手動プロキシの設定を OFF にすれば、wpad.dat で設定した通りにプロキシ除外が有効となります。

わかってしまえば、何と言うことはないのですが、プロキシ除外設定が動いたり、動かなかったりという不思議な挙動について、原因に気がつくのに随分時間がかかりました。クライアントPC が多数になると、各PC のプロキシ設定は多種多様となっているので…

それではこのような運用の問題を解決する方法の一例を挙げます。

  1. プロキシの自動設定は ON とし、wpad.dat は以下の様に設定し、かつ、プロキシの手動設定の除外項目に *.webex.com を設定する。
    function FindProxyForURL(url, host)
{
  if (isPlainHostName(host) || isInNet(host,"192.168.0.0","255.255.0.0")) {
                return "DIRECT";
        }
        else if (shExpMatch(host, "*.webex.com")) {
                return "DIRECT";
        }
        else {
                return "PROXY proxy.sample.com:8080";
        }
}
  2. プロキシの自動設定は ON とし、wpad.dat の内容を以下の様に設定する。
    function FindProxyForURL(url, host)
{
  if (isPlainHostName(host) || isInNet(host,"192.168.0.0","255.255.0.0")) {
                return "DIRECT";
        }
        else if (shExpMatch(host, "*.webex.com") || shExpMatch(host, "*.wbx2.com")) {
                return "DIRECT";
        }
        else {
                return "PROXY proxy.sample.com:8080";
        }
}

    このように設定しておくと、プロキシの手動設定の内容に影響を受けず、webex 関連の通信はプロキシ除外となるので、個人的にはこちらがお勧めです。

結果だけを見ると不思議（ wbx2.comって何？）に見えますが、検証環境を造り、時間をかけてクライアントPC の設定をいろいろ変更して、プロキシやルータのログを解析すると、なぜこのような設定にすると問題が解消されるか理解出来ます。

どちらの設定にしても、社内の Windows が AD 環境であれば、グリープポリシーで強制的に設定しておくのが良いと思います。

もちろん、webex のソースを読んだ訳では無いので、外から見える動作を解析しただけですから、webex のバージョンが変わると、この辺の仕様も変更になるかもしれないので、あくまで参考としてください。

最後になりましたが、wpad.dat の内容を変更した場合には、クライアントPC は必ずシステム再起動を行って下さい。ブラウザの再起動だけでは、新しい wpad の内容が有効になりません。

　検証環境

  1. wpad 稼働機
    debian 11 bullseye 5.10.0-18-amd64
    apache2 2.4.54-1
  2. webex 5.10.0-18-amd64
  3. プロキシサーバ
    debian 11 bullseye 5.10.0-18-amd64
    squid 4.13-10

　wpad.dat のテストツール

wpad がどのように設定されているか？　クライアント PC から調べるのは難しいので、以下のテストツールを使うと、設定内容のチェックができます。

https://learn.microsoft.com/ja-jp/troubleshoot/developer/browsers/connectivity-navigation/optimize-pac-performance
このページに書かれている、Autoprox.exe というテストツール（Microsoft純正？）が、便利です。

Linux上で使うのであれば、このツールも簡単ですが重宝します。
https://github.com/manugarg/pactester
普通に apt でインストールできるようで、ここに情報があります。
https://laramatic.com/how-to-install-pactester/

投稿タグ
, ,