「プロキシ自動設定」の版間の差分
編集の要約なし |
|||
33行目: | 33行目: | ||
PACファイルの非常に単純な例を示す: |
PACファイルの非常に単純な例を示す: |
||
< |
<syntaxhighlight lang="javascript"> |
||
function FindProxyForURL(url, host) |
function FindProxyForURL(url, host) |
||
{ |
{ |
||
return "PROXY proxy.example.com:8080; DIRECT"; |
return "PROXY proxy.example.com:8080; DIRECT"; |
||
} |
} |
||
</syntaxhighlight> |
|||
</source> |
|||
この関数は、<code>proxy.example.com</code>サーバの[[ポート番号]]8080上のプロキシを通じて全てのページを取得するようブラウザに指示する。このプロキシが応答に失敗した場合、ブラウザはプロキシを使わず目的のウェブサイトに直接接続する。後者の直接接続は[[ファイアウォール]]あるいはその他の中間的なネットワーク装置が、プロキシ以外を発信元とする要求を拒否する設定になっている場合には失敗する(このような設定は法人組織内のネットワークでは一般的である)。 |
この関数は、<code>proxy.example.com</code>サーバの[[ポート番号]]8080上のプロキシを通じて全てのページを取得するようブラウザに指示する。このプロキシが応答に失敗した場合、ブラウザはプロキシを使わず目的のウェブサイトに直接接続する。後者の直接接続は[[ファイアウォール]]あるいはその他の中間的なネットワーク装置が、プロキシ以外を発信元とする要求を拒否する設定になっている場合には失敗する(このような設定は法人組織内のネットワークでは一般的である)。 |
||
44行目: | 44行目: | ||
利用できるJavaScript関数をFindProxyForURL関数の中で幾つか使った、より複雑な例を示す: |
利用できるJavaScript関数をFindProxyForURL関数の中で幾つか使った、より複雑な例を示す: |
||
< |
<syntaxhighlight lang="javascript"> |
||
function FindProxyForURL(url, host) { |
function FindProxyForURL(url, host) { |
||
// example.com以下のドメインにある我々のローカルなURLに対してはプロキシ不要: |
// example.com以下のドメインにある我々のローカルなURLに対してはプロキシ不要: |
||
62行目: | 62行目: | ||
return "PROXY proxy.example.com:8080; DIRECT"; |
return "PROXY proxy.example.com:8080; DIRECT"; |
||
} |
} |
||
</syntaxhighlight> |
|||
</source> |
|||
=== 制約 === |
=== 制約 === |
||
75行目: | 75行目: | ||
Internet ExprolerのPAC設定を使用する[[.NET Framework|.NET 2.0 Framework]]などの他のWindowsコンポーネントとの互換性のために、<code>isInNet</code>関数内では、ホストのドメイン名ではなく、常に[[IPアドレス]]を用いることが推奨される。たとえば次のように書く: |
Internet ExprolerのPAC設定を使用する[[.NET Framework|.NET 2.0 Framework]]などの他のWindowsコンポーネントとの互換性のために、<code>isInNet</code>関数内では、ホストのドメイン名ではなく、常に[[IPアドレス]]を用いることが推奨される。たとえば次のように書く: |
||
< |
<syntaxhighlight lang="javascript"> |
||
if (isInNet(host, dnsResolve(sampledomain), "255.255.248.0")) // .NET 2.0 は適切にプロキシを解決するだろう |
if (isInNet(host, dnsResolve(sampledomain), "255.255.248.0")) // .NET 2.0 は適切にプロキシを解決するだろう |
||
if (isInNet(host, sampledomain, "255.255.248.0")) // .NET 2.0 はプロキシを適切に解決できないだろう |
if (isInNet(host, sampledomain, "255.255.248.0")) // .NET 2.0 はプロキシを適切に解決できないだろう |
||
</syntaxhighlight> |
|||
</source> |
|||
PACファイルが利用できない場合は直接接続に[[フェイルオーバー]]するのが現在の慣例である。 |
PACファイルが利用できない場合は直接接続に[[フェイルオーバー]]するのが現在の慣例である。 |
||
109行目: | 109行目: | ||
より発展したPACファイルは、リクエストがネットワークへ送られる前に、プロキシの負荷を減らし、負荷分散、フェイルオーバーを行い、更には[[ブラックリスト]]/[[ホワイトリスト]]の作成まで行うことができる。複数のプロキシを返すこともできる: |
より発展したPACファイルは、リクエストがネットワークへ送られる前に、プロキシの負荷を減らし、負荷分散、フェイルオーバーを行い、更には[[ブラックリスト]]/[[ホワイトリスト]]の作成まで行うことができる。複数のプロキシを返すこともできる: |
||
< |
<syntaxhighlight lang="javascript"> |
||
return "PROXY proxy1.example.com:80; PROXY proxy2.example.com:8080"; |
return "PROXY proxy1.example.com:80; PROXY proxy2.example.com:8080"; |
||
</syntaxhighlight> |
|||
</source> |
|||
== 発展学習 == |
== 発展学習 == |
2020年7月5日 (日) 23:07時点における版
プロキシ自動設定(プロキシじどうせってい、proxy auto-config、略してPAC)ファイルは、ウェブブラウザやその他のユーザーエージェントが、与えられたURLを取得するための適切なプロキシサーバ(アクセスメソッド)を自動選択する方法を定義する。
DNA
PACファイルにはJavaScriptの関数“FindProxyForURL(url, host)
”が書かれている。この関数は一つあるいは複数のアクセスメソッド指定を含む文字列を返す。これらの指定によりユーザーエージェントは特定のプロキシサーバを使って接続するか、または直接に接続する。
アクセスメソッドを複数指定しておくことにより、一つのプロキシが反応しない場合のフォールバック(代替手段)を提供できる。ブラウザは他のURLにリクエストを送る前に、このPACファイルを取得する。PACファイルのURLは手動で設定しておくか、あるいはWeb Proxy Auto-Discovery Protocolにより自動的に決定される。
プロキシ設定手法の概要
現代的なウェブブラウザはいくつかのレベルの自動化を実装している。ユーザは必要に応じてそのレベルを選ぶことができる。一般的に次のレベルが実装される:
- 自動プロキシ選択:全てのURLに対して用いられるホスト名とポート番号を指定する。多くのブラウザは、このプロキシを通さないで繋ぐドメイン(
localhost
など)のリストを指定することを許容している - プロキシ自動設定 (Proxy Auto Configration = PAC):各URLに対する適切なプロキシを決定するためのJavaScript関数を記述したPACファイルのURLを指定する。この手法は幾つかの異なるプロキシ設定を必要とする小型携帯端末のユーザ、あるいは法人組織の中で多くの異なるプロキシを使った複雑な設定を必要とするユーザに適している。
- Web Proxy Auto-Discovery Protocol (WPAD = ウェブプロキシ自動検出プロトコル):DHCPおよびDNSルックアップを通じて、ブラウザにPACファイルの場所を探させる。
プロキシ設定
コンピュータがインターネット通信をするためには、 オペレーティングシステム (例:Microsoft Windows, macOS, Linux)に多くの設定をする必要がある。これらの設定はインターネットサービスプロバイダ(ISP)から与えられるのが普通である。ネットワークに接続するためには匿名(プロキシサーバを使うための代理)あるいは実際の設定のいずれかを使うことができる。
PAC ファイル
プロキシ自動設定ファイル(PACファイル)は、1996年にNetscape Navigator 2.0 のためにNetscapeによって最初に設計され
[1]、それは最低限一つのJavaScript関数FindProxyForURL(url, host)
を定義したテキストファイルであった。この関数の二つの引数の意味は:url
が目的のURLで、host
がそのURLから得られるホスト名である。慣例として、PACファイルの名前はproxy.pac
とする。WPAD標準はwpad.dat
を使う。
PACファイルを使うには、まずPACファイルをHTTPサーバに公開しておき、クライアントのユーザーエージェントは、ブラウザのプロキシ接続設定にPACファイルのURLを入力しておくか、またはWPADプロトコルを通じてのいずれかにより、そのPACファイルを使うよう指示される。
多くのクライアントは、完全性のために、また互換性を高めるために、HTTPリプライで返されたMIMEタイプが何であれ、PACファイルのスクリプトを処理するが、HTTPサーバはPACファイルのMIMEタイプとしてapplication/x-ns-proxy-autoconfig
または application/x-javascript-config
のいずれかを宣言しておくべきである。
これらのMIMEタイプのどちらを使った方がよいという根拠はほとんどないが、application/x-ns-proxy-autoconfig
がapplication/x-javascript-config
よりも多くのクライアントでサポートされていると想定するのは妥当だろう。なぜなら前者は最初のNetscapeの仕様で定義されたものであり、後者はもっと最近になってから使われるようになったものだからだ。
PACファイルの非常に単純な例を示す:
function FindProxyForURL(url, host)
{
return "PROXY proxy.example.com:8080; DIRECT";
}
この関数は、proxy.example.com
サーバのポート番号8080上のプロキシを通じて全てのページを取得するようブラウザに指示する。このプロキシが応答に失敗した場合、ブラウザはプロキシを使わず目的のウェブサイトに直接接続する。後者の直接接続はファイアウォールあるいはその他の中間的なネットワーク装置が、プロキシ以外を発信元とする要求を拒否する設定になっている場合には失敗する(このような設定は法人組織内のネットワークでは一般的である)。
利用できるJavaScript関数をFindProxyForURL関数の中で幾つか使った、より複雑な例を示す:
function FindProxyForURL(url, host) {
// example.com以下のドメインにある我々のローカルなURLに対してはプロキシ不要:
if (shExpMatch(host, "*.example.com"))
{
return "DIRECT";
}
// 下記のネットワーク内のURLには
// fastproxy.example.comのポート8080を通じてアクセスする:
if (isInNet(host, "10.0.0.0", "255.255.248.0"))
{
return "PROXY fastproxy.example.com:8080";
}
// その他のリクエストはproxy.example.comのポート8080を通じて出る。
// 応答がなければ、直接WWWに出る:
return "PROXY proxy.example.com:8080; DIRECT";
}
制約
PAC 文字エンコード
Mozilla FirefoxやInternet Explorerなどのブラウザはシステムのデフォルトの文字コードのPACファイルしかサポートしない[要出典]ので、UTF-8などのUnicodeでエンコードされたものはサポートできない[要出典]。
dnsResolve
dnsResolve
関数(および他の類似の関数)はDNSルックアップを実行するが、DNSサーバが応答しない場合、ブラウザを長時間ブロックすることがある。
Microsoft Internet Explorer 5.5以上でドメイン名によりプロキシ自動設定結果をキャッシュすることは、PAC標準の柔軟性を制限してしまう。実質的に、URLのパスに基づいてではなく、ドメイン名に基づいてプロキシを選ぶことになる。それを回避するにはレジストリを編集してプロキシ自動設定結果のキャッシュを無効にする必要がある(詳しくは発展学習のBoyne Pollardの記事を参照)。
Internet ExprolerのPAC設定を使用する.NET 2.0 Frameworkなどの他のWindowsコンポーネントとの互換性のために、isInNet
関数内では、ホストのドメイン名ではなく、常にIPアドレスを用いることが推奨される。たとえば次のように書く:
if (isInNet(host, dnsResolve(sampledomain), "255.255.248.0")) // .NET 2.0 は適切にプロキシを解決するだろう
if (isInNet(host, sampledomain, "255.255.248.0")) // .NET 2.0 はプロキシを適切に解決できないだろう
PACファイルが利用できない場合は直接接続にフェイルオーバーするのが現在の慣例である。
ネットワーク設定を切り替えた少し後(例:VPNに入るとき、あるいは出るとき)、dnsResolve
がDNSキャッシュによる古い結果を返すことがある。
たとえば、Firefoxは通常20個のドメインのエントリーを60秒キャッシュしている。これは設定変数network.dnsCacheEntries
およびnetwork.dnsCacheExpiration
で設定できる。システムのDNSキャッシュを捨てることも役に立つ場合がある、これは例えばLinuxではsudo service dns-clean startで実行できる。
myIpAddress
myIpAddress
関数は不正確であったり使えない結果(例えば、ローカルホストのIPアドレス127.0.0.1
)を返すことがしばしば報告されてきた。システムのホストファイル(たとえばLinuxでは/etc/hosts
)で当該マシンのホスト名を参照する行をすべて削除する一方、127.0.0.1 localhost
の行はそのままにしておくことが役に立つ場合がある。
Internet Explorer 9では、isInNet("localHostName", "second.ip", "255.255.255.255")
がtrue
を返すので、これが回避策として使える。
myIpAddress
関数は、その装置が一つのIPv4アドレスを持つと想定している。その装置が複数のIPv4アドレスあるいはIPv6アドレスを持つ場合、その結果は未定義となる。
セキュリティ
2013年、研究者らはプロキシ自動設定のセキュリティ上の危険性を警告し始めた[2] 。その脅威とは、PACを使って被害者のブラウザの通信先を攻撃者が支配しているサーバにすり替えてしまうというものなどである。
その他
その他の制約は、JavaScriptエンジンのローカルマシンに対する制約と関係したものである。
発展機能
より発展したPACファイルは、リクエストがネットワークへ送られる前に、プロキシの負荷を減らし、負荷分散、フェイルオーバーを行い、更にはブラックリスト/ホワイトリストの作成まで行うことができる。複数のプロキシを返すこともできる:
return "PROXY proxy1.example.com:80; PROXY proxy2.example.com:8080";
発展学習
Jonathan de Boyne Pollard (2004年). “Automatic proxy HTTP server configuration in web browsers”. Frequently Given Answers. 2013年7月5日閲覧。
脚注
- ^ “Navigator Proxy Auto-Config File Format”. Netscape Navigator Documentation (March 1996). 2007年6月2日時点のオリジナルよりアーカイブ。2013年7月5日閲覧。
- ^ Lemos, Robert (2013年3月6日). “Cybercriminals Likely To Expand Use Of Browser Proxies”. 2013年7月5日閲覧。
外部リンク
- “Using the Client Autoconfiguration File”. Netscape Proxy Server Administrator's Guide: Chapter 11 (1998年2月25日). 2004年8月10日時点のオリジナルよりアーカイブ。2015年10月17日閲覧。
- “Chapter 26 - Using Automatic Configuration, Automatic Proxy, and Automatic Detection”. Microsoft TechNet. 2013年7月5日閲覧。
- “Proxy Auto Config for Firefox (PAC). Fully working examples including anti-ad and anti-adult filter rules” (2012年5月12日). 2015年10月17日閲覧。