（元）社内SEの徒然なる日記

proxy.pac（プロキシパック）対応　No.10　pac作成（DNS）

2014-01-06（Mon）

■　DNS

前回（proxy.pac（プロキシパック）対応　No.9　pac作成（基本））の最後に書いた通り、今回はDNSを利用する関数を使ってみます。

紹介するのは、名前解決ができる事を確認するisResolvable関数、実際に名前解決をするdnsResolve関数、IPアドレスとサブネットのパターンマッチングをするisInNet関数の３つです。

■　名前解決

isResolvable関数、dnsResolve関数は、共にホスト名を引数として受け取り、名前解決の成否、又は、名前解決の結果（IPアドレス）を返却する関数です。

下記の処理を記述して、動作を確認しました。


function FindProxyForURL(url, host) {

    if (isResolvable(host)) {
        alert('EXISTS dnsResolve(host)=[' + dnsResolve(host) + ']');
    } else {
        alert('NOT EXISTS dnsResolve(host)=[' + dnsResolve(host) + ']');
    }

    return "DIRECT";
}

isResolvable関数は、名前解決ができれば真（True）、できなければ偽（False）を返却します。
名前解決っていうか、IPアドレスが取得できるかっていう判断方法らしく、引数のhostがIPアドレスだった場合も真（True）になります。当然、hostsファイルで名前解決出来ても真（True）になったりします。

dnsResolve関数も似たようなもので、返すのがIPアドレスになるだけです。

一見便利なんですが、クライアントやDNSサーバーの設定によって動作が変わる点が気持ち悪いです。

例として、それまでは社外への名前解決（yahoo.co.jpとか）を出来なくしていたとします。
この場合、通常のインターネットの使用では、isResolvable関数は偽（False）を返すはずです。これを前提として、真（True）が返された場合は、社内システムへはプロキシサーバーを使用しない、という処理を書いていたとします。

この条件で、ある日DNSサーバーが変更され、社外のホームページに対する名前解決も出来るようになったとすると、どう動くでしょうか？

■　isInNet関数（サブネットによる切り分け）

あまり使う条件も思いつかなかったのですが、使えない訳ではなさそうです。
例えば、ある特定のセグメントの場合は直接接続するっていうのはどうでしょうか？

下記は、接続先のIPアドレスが、192.168.1で始まる場合は直接接続する方法です。


function FindProxyForURL(url, host) {

    // 名前解決が出来ない場合は直接接続
    if (!isResolvable(host)) {
        return "DIRECT";
    }

    // 名前解決。IPアドレスを変数に設定。
    var myIp = dnsResolve(host);

    // IPアドレスが、192.168.1で始まる場合は直接接続
    if (isInNet(myIp, "192.168.1.0", "255.255.255.0")) {
        return "DIRECT";
    }

    // 上記以外の場合は、プロキシサーバーを使用する
    return "PROXY 192.168.1.100:80";
}

先頭で、isResolvable関数（の否定）をすることで、名前解決できない場合は直接接続させます。
後は、IPアドレスを取得して、isInNet関数でパターンマッチングしています。

isInNet関数の構文は、isInNet(host, pattern, mask) となります。

hostは、チェックするIPアドレス。patternは、IPアドレスのパターンで、maskがpatternのマッチングをするかしないかを設定するものです。マッチすれば真（True）、しなければ偽（False）が返却されます。

まぁ、何を言っているか分らないと思うので、上のサンプルを解説してみます。

まず、hostですが。これは分ると思います。今回は変換されたIPアドレスを設定していますが、ホスト名を指定した場合は名前解決をしてIPアドレスに変換するらしいです。

一つ飛ばしてmaskですが、これはオクテット毎にマッチングをするかしないかの指定で、0はしない、255はする、となります。

上記のサンプルの場合、第１オクテット～第３オクテットのみマッチングの判定をしています。言い方を変えると、hostで指定したIPアドレスの第４オクテットの値が何であれ、真（True）が返却されることになります。

これで、マッチングする箇所（オクテット）の指定は終わりです。後は、実際にマッチングする値の指定です。これが、patternになる訳です。maskで0（マッチングしない）とした箇所は、意味が無いので無視です。まぁ、適当に0でも突っ込んでおけば良いかと。

んで、maskで255（マッチングする）とした、第１オクテット～第３オクテットには、マッチングさせたいパターンを書いておくわけです。サンプルは、「192.168.1.0」と書いているので、IPアドレスが「192.168.1」で始まる場合は真（True）、始まらない場合は偽（False）が返却される訳です。

■　後書き

散々けなしておいてなんですが、条件によっては面白い使い方が出来そうです。もっとも、挙動が怪しいので、個人的には使いたくないですね。

このシリーズの始め（proxy.pac（プロキシパック）対応　No.1　始まり）で、proxy.pacの書き方が気に入らないって書いたのは、今回紹介した関数を大量に使用していたからです。必要性があれば良いのですが、shExpMatch関数だけで十分に書ける内容だったりして．．．

さて、次回、最後にちょっとした事を書いて、本シリーズは終了したいと思います。

前回：proxy.pac（プロキシパック）対応　No.9　pac作成（基本）
次回：proxy.pac（プロキシパック）対応　No.11　追記

投稿記事の一覧：http://harikofu.web.fc2.com/

--- blog end ---