らくらくPACファイルの自動更新の裏側

はじめに

今回は先日プレスリリースしたプロキシサーバ環境下でもローカルブレイクアウトを実現する機能(※)の裏側についてご紹介します。
※ 本記事ではこの機能のことを「らくらくPACファイル」と記載します。正式名称じゃありません！筆者が勝手に呼んでいるだけです。

らくらくPACファイルはPACファイルの作成、自動更新機能を備えており、情報システム担当者の負担を大きく軽減します。
他にも機能はありますが本記事ではPACファイルの自動更新について掘り下げていきます。

らくらくPACファイルでできることや登場した背景などは、プレスリリースやコラムサイトにて詳細が書かれています。
ここでは要点だけを簡単に書いておきます。

• 支社・支店などの拠点オフィスからのインターネットアクセス環境で、SaaSへのアクセスなど、本社・DC向けのVPNを通したくない通信を除外するための機能 (ローカルブレイクアウト)
• プロキシサーバを通過するかどうかを制御するPACファイルを自動生成することで、プロキシを使う環境でもローカルブレイクアウトを実現。
• Microsoft365やGoogle Workspace、Zoomなど、有名SaaSの情報をIIJが自動追跡

らくらくPACファイルの自動更新の裏側

PACファイルを自動更新するにはクラウドサービスが公開しているネットワーク要件の変更を検知する必要があります。
これを手動で実行しようとするととにかく大変で、こんな三重苦が待ち受けています。

• 公開情報から必要なIPアドレス、FQDNを抽出しないといけない。
• 公開情報はいつ更新されるかわからない。
• 更新差分をPACファイルに反映しないといけない。

これがPACファイルに記載しているクラウドサービスの数だけ発生するため、手動でPACファイルを運用している方には頭があがりません。

PACファイル更新を自動化しよう

自動化といっても簡単な道のりではなくセクション冒頭に挙げた三重苦が襲い掛かってきます。

この中で最初の壁となるのが、「公開情報から必要なIPアドレス、FQDNを抽出しないといけない。」になります。
IPアドレス、FQDNはクラウドサービスの接続先となり、これをPACファイルに含めないと環境によっては適切に通信をすることができません。
そのため適切に情報を抽出できなければ、PACファイル更新自動化の第一歩を踏み出すことができません。
クラウドサービスによってはjsonやtxtで記載されていて、これを単純に取り込むだけというケースもありますが、そうはいかないのがWebページに記載されているケースです。

Webページの場合、どこにIPアドレス、FQDNが記載されているかわかりません。これに加え複数ページに分散している場合もあります。
さらにページによってIPアドレス、FQDNの記載ルールが違うなんてことも。
（箇条書きされていたり、表にまとまっていたり。）

らくらくPACファイルではこれをWebページへスクレイピングしIPアドレス、FQDNを抽出することで自動化しています。

IPアドレス、FQDNをWebページから抽出しよう

Webページからの抽出はIPアドレス、FQDNそれぞれを判別する正規表現を用いて行っています。
対象のWebサイトに含まれる特定のタグに含まれるテキストから、正規表現にマッチした部分を抽出し保存します。

例えば正規表現を使うと下記のような一覧から赤字のみ抽出でき、多少の表記揺れは問題ありません。

ただWebページによってはFQDNの記載が特殊だったり、ピンポイントでの抽出が必要となるため一筋縄ではいきません。これについては多種多様となるため割愛します。

最後に保存した結果とWebページに記載されている内容を確認し、過不足なければ完了です！
これだけは目で確認する必要があります。

抽出できたからといって完了ではなく、IPアドレス、FQDNの変化を追っていく必要があります。

公開情報はいつ更新されるかわからない

クラウドサービスが公開している情報は常に変化する可能性があり、いつ更新されるかわかりません。

Webページ内のIPアドレスが増加したり、FQDNが減少したり。新しいtxt、json、APIが増えたり。
はたまたWebページが引っ越ししたり、サービス終了になって抽出する必要が無くなったり。

特にIPアドレス、FQDNの大幅な増減があった場合には何かしらの変化が起きています。
そしてそれは突然やってきて、内容によっては「え？これだけの量を本当に取り込むの？」となるほど増えることもありました。
（とあるサービスで100件程度しかなかったIPアドレスが10倍以上に増えた時は目が飛び出るかと思いました。。）

そんな時はむやみやたらに取り込むのではなく、一度立ち止まってプロジェクトメンバー内で協議し、取り込むかどうかを決めています。

このような変化を監視し、必要に応じてスクレイピングのルールを改修することでPACファイルの更新を自動で行えるようにしています。

更新差分をPACファイルに反映する

IPアドレス、FQDNの抽出が完了し、いつ更新されても問題ないようになりました。
あとは更新差分をPACファイルに反映するのみです。

ここで最後の壁としてPACファイルは手書きで運用可能であるという性質上、フリーで記載できるエリアが必要となります。
フリーで記載されている内容は様々ですが、固有の環境などが含まれます。
どんなにクラウドサービスの変化に追従できるようになっても、これらの記載が取り込めなければ運用できません。

らくらくPACファイルでは、プロキシの振り分け条件となるアクセス先として、各種クラウドサービスに加えて、お客様が手動で定義したIPアドレス、FQDNのリストを使用することもできます。
上図における自社サイトなどは手動で定義しPACファイルに取り込むことができます。

これに加え手動でスクリプトを記載するエリアを用意することで、PACファイルとして運用可能にしています。
手動でスクリプトを記載できるということは、構文エラーなどが含まれる可能性がありますが、この点はESLintでチェックすることでカバーしています。

function FindProxyForURL(url, host) {
    /***************************************
    *
    * クラウドサービスエリア
    *
    ***************************************/
    /***************************************
    *
    * 自社サイトエリア
    *
    ***************************************/
    /***************************************
    *
    * 手書きスクリプトエリア
    *
    ***************************************/
     
    // いずれの通信にも該当しない場合
    return "PROXY example.com:8080";
}

サービス運用の裏側

最後に開発だけではなく、サービス運用の裏側を少しご紹介します。
らくらくPACファイルの今後もあり続ける課題として、予期せぬWebページの変更により誤ったデータが抽出され、そのデータがPACファイルに混ざってしまうリスクがあります。
これが起きてしまうとそのPACファイルを利用している環境でネットワーク障害が発生してしまいます。
この障害が起きないよう常に変化を追い、障害が発生するリスクを最小限に抑えるよう取り組んでいます。

最後に

クラウド上やお客様環境にあるプロキシで、クラウドサービス宛の通信を効率よく振り分け、ネットワーク負荷を軽減する 「IIJクラウドプロキシサービス クラウドバイパス」や「IIJクラウドプロキシサービス 外部プロキシ連携」に、今回加わったローカルブレイクアウトのためのらくらくPACファイル。

3つのサービスを使い分けることで、企業ネットワークはさらに柔軟で効率的に！
IIJの提供するサービスを利用して、快適なクラウド通信環境を手に入れましょう。