Microsoft Edge 153以降で、PACファイルのmyIpAddress()またはmyIpAddressEx()が想定外のIPv6アドレスを返す場合は、PacMyIpAddressIPv6ProbeAddressポリシーでIPv6の検出先を指定します。
設定するのは、実際に通信したいサーバーのアドレスではありません。そのIPv6アドレスまでの経路を調べたときに、PAC判定へ使わせたいネットワークインターフェースが選ばれるアドレスを指定します。
ただし、ポリシーを配布するだけでは不十分です。Edgeを完全に再起動したうえで、社内LAN、社外Wi-Fi、VPN接続中などの状態ごとに、OSが選択する経路、PAC関数の戻り値、最終的なプロキシ選択を確認する必要があります。
PacMyIpAddressIPv6ProbeAddressでEdgeのIPv6 PAC判定を制御
PacMyIpAddressIPv6ProbeAddressは、PACスクリプト内の次の関数がローカルIPアドレスを調べる際に使用する、IPv6の経路確認先を指定するMicrosoft Edgeの企業向けポリシーです。
myIpAddress()myIpAddressEx()
このポリシーはMicrosoft Edge 153以降のWindowsとmacOSで利用できます。AndroidとiOSには対応していません。
| 項目 | 内容 |
|---|---|
| ポリシー名 | PacMyIpAddressIPv6ProbeAddress |
| 対応バージョン | Microsoft Edge 153以降 |
| 対応OS | Windows、macOS |
| 設定値 | IPv6アドレスリテラル |
| 対象機能 | PACのmyIpAddress()、myIpAddressEx() |
| 動的更新 | 非対応 |
| Edge再起動 | 必要 |
| 推奨ポリシー | 非対応 |
| レジストリ値の種類 | REG_SZ |
| レジストリパス | SOFTWARE\Policies\Microsoft\Edge |
未設定または空文字列の場合、Edgeに組み込まれた既定のIPv6検出先が使用されます。この既定値は、Edgeのバージョンによって変更される可能性があります。(Microsoft Learn)
このポリシーで変わるのは「自端末のIPv6アドレス」ではない
PacMyIpAddressIPv6ProbeAddressを設定しても、端末に新しいIPv6アドレスが割り当てられるわけではありません。また、指定したアドレスへ通常のアプリケーション通信を行う設定でもありません。
Edgeは指定されたIPv6アドレスを宛先としてUDPソケットの接続処理を行い、OSがどの経路と送信元アドレスを選択するかを確認します。その結果として選ばれたローカルアドレスを、PAC関数の結果に利用します。
この処理では指定先へアプリケーションデータは送信されません。したがって、probe address側でWebサーバーやUDPサービスを待ち受ける必要はありません。重要なのは、指定先に対するルーティングです。(Microsoft Learn)
イメージすると、次のような流れです。
PACがmyIpAddress()を実行
↓
Edgeがprobe addressへの経路をOSへ問い合わせる
↓
OSが送信インターフェースと送信元IPv6アドレスを選ぶ
↓
選ばれたローカルIPアドレスをPACへ返す
↓
PACがDIRECTまたはPROXYを決定
Edge 153でPACの判定結果が変わる可能性がある理由
Edge 153では、myIpAddress()とmyIpAddressEx()の経路確認に使われる既定の宛先が、Chromiumの既定値に合わせて変更されます。
| アドレス種別 | 従来のEdge既定値 | Edge 153以降の既定値 |
|---|---|---|
| IPv4 | 20.76.201.171 | 8.8.8.8 |
| IPv6 | 2603:1020:201:10::10f | 2001:4860:4860::8888 |
これらのアドレスは、接続確認を行うサーバーとしてではなく、OSの経路選択に使用する目印として扱われます。Microsoftは、この変更だけを理由にファイアウォールで当該アドレスへの通信を許可する必要はないと説明しています。(Microsoft Learn)
問題になるのは、旧宛先と新宛先で選択される経路が異なる環境です。
例えば、端末に次のインターフェースが同時に存在するとします。
- 社内有線LAN
- Wi-Fi
- VPNアダプター
- 仮想マシン用の仮想アダプター
- セキュリティ製品が作成したトンネルアダプター
旧IPv6検出先への経路がVPNを通り、新しい検出先への経路がWi-Fiへ向いている場合、Edge 153への更新後にPACへ返されるアドレスが変わる可能性があります。
その結果、PACの処理が次のように変化することがあります。
if (isInNetEx(myIpAddress(), "fd12:3456:789a::/48")) {
return "PROXY proxy-internal.example.jp:8080";
}
return "PROXY proxy-external.example.jp:8080";
更新前は社内IPv6アドレスが返っていたものの、更新後はWi-Fi側のアドレスが返ると、同じPACファイルでも異なるプロキシが選択されます。
dual-stack環境ではIPv6ポリシーを設定してもIPv6が返るとは限らない
IPv4とIPv6の両方を利用できるdual-stack環境では、PacMyIpAddressIPv6ProbeAddressを設定しても、myIpAddress()が必ずIPv6アドレスを返すわけではありません。
Chromiumの組み込みプロキシリゾルバーでは、myIpAddress()によるアドレス検出時にIPv4側の経路確認が先に行われます。そのため、利用可能なIPv4アドレスが見つかった場合は、IPv6のprobe addressを設定していてもIPv4が返ることがあります。
一方、myIpAddressEx()は複数のアドレスをセミコロン区切りで返せます。ただし、端末上のすべてのネットワークインターフェースを完全に列挙する関数ではありません。(Chromium)
| 関数 | 主な特徴 | dual-stack環境での注意点 |
|---|---|---|
myIpAddress() | 1つのIPアドレスを返す | IPv4が優先され、IPv6が返らないことがある |
myIpAddressEx() | 複数アドレスをセミコロン区切りで返す | すべてのインターフェースが含まれるとは限らない |
PacMyIpAddressIPv6ProbeAddress | IPv6経路確認先を変更する | IPv6を強制的に返すポリシーではない |
したがって、検証時には「IPv6ポリシーを設定したのにmyIpAddress()がIPv4のままだから失敗」と判断してはいけません。
確認すべきなのは次の3点です。
- IPv6経路の確認が必要になったとき、意図したインターフェースが選ばれるか
myIpAddressEx()に必要なIPv6アドレスが含まれるか- PAC全体として正しいプロキシが選択されるか
PacMyIpAddressIPv6ProbeAddressを設定すべき環境
このポリシーは、すべての組織で必ず設定するものではありません。
次の条件に該当する場合に、設定を検討します。
| 環境・PACの状態 | 設定の必要性 |
|---|---|
PACでmyIpAddress()またはmyIpAddressEx()を使用していない | 原則不要 |
| PACの分岐がIPv4アドレスだけに依存している | IPv6ポリシーの効果は限定的 |
| PACがIPv6プレフィックスで社内・社外を判定している | 設定を検討 |
| VPNとWi-Fiが同時に有効になる | 優先的に検証 |
| Edge 153への更新後に選択プロキシが変わった | 旧・新probe addressの経路を比較 |
| 複数拠点でIPv6ルーティングが異なる | 拠点別の検証が必要 |
| PAC判定が端末のネットワーク状態に依存しない | 原則不要 |
まずPACファイルを検索し、次の文字列が使われているか確認してください。
myIpAddress(
myIpAddressEx(
isInNet(
isInNetEx(
myIpAddress()やmyIpAddressEx()が存在しなければ、今回のprobe address変更がPACの判定へ直接影響する可能性は低くなります。
企業ネットワークに適したprobe addressの選び方
設定値には、ホスト名ではなくIPv6アドレスそのものを指定します。
適切なprobe addressは、「到達可能なサーバー」ではなく、企業が経路を管理でき、OSに目的のインターフェースを選ばせられるIPv6アドレスです。
選定時に満たしたい条件
- 企業がルーティングを管理できるIPv6アドレスである
- 社内LANやVPN接続時に、意図した企業側インターフェースへ経路が向く
- 経路が頻繁に変更されない
- 全拠点または対象拠点で同じ意味を持つ
- 端末から
Find-NetRouteで経路を確認できる - IPv6アドレスリテラルとして正しい形式である
- PAC判定に使用するネットワーク状態と経路選択が一致する
グローバルユニキャストアドレスだけでなく、企業内で管理されているULAなどのプライベートIPv6アドレスも利用できます。Microsoftのポリシー仕様では、プライベートアドレスの設定がサポートされています。(Microsoft Learn)
設定できないアドレス
Microsoft Edgeは、次のような値を受け付けません。
- ホスト名
- IPv4アドレス
- 書式が不正なIPv6アドレス
- ループバックアドレス
- リンクローカルアドレス
- マルチキャストアドレス
- IPv4射影IPv6アドレス
- 未指定アドレス
具体的には、次のような値を設定しないでください。
proxy.example.jp
192.0.2.10
::1
fe80::1
ff02::1
::
::ffff:192.0.2.10
IPv6アドレスの後ろにプレフィックス長を付ける形式も避けます。
fd12:3456:789a::1/128
設定するのはプレフィックスではなく、単一のIPv6アドレスです。(Microsoft Learn)
2001:db8::1をそのまま本番設定へコピーしない
Microsoftの設定例には2001:db8::1が掲載されていますが、2001:db8::/32は文書や設定例で使用するために予約されたプレフィックスです。(RFCエディタ)
自社で当該アドレスへの明示的な経路を作成し、検証用のルーティング目印として利用する場合を除き、Microsoftの例示値をそのまま本番環境へ配布するのは適切ではありません。
Windowsのグループポリシーで設定する手順
最新のEdge管理用テンプレートを準備する
Edge 153に対応していない古いMSEdge.admxを使用している場合、グループポリシー管理エディターに設定項目が表示されません。
Microsoft Edgeの最新の管理用テンプレートを取得し、環境に応じて次のいずれかへ配置します。
ローカル端末:
C:\Windows\PolicyDefinitions
Active Directoryのセントラルストア:
\\ドメイン名\SYSVOL\ドメイン名\Policies\PolicyDefinitions
MSEdge.admxだけでなく、日本語用のMSEdge.admlも適切な言語フォルダーへ配置します。Microsoftは、ポリシー設定後の確認方法としてedge://policyの使用を案内しています。(Microsoft Learn)
グループポリシーを構成する
- グループポリシー管理コンソールを開きます。
- 対象端末またはユーザーへ適用するGPOを編集します。
- 次の場所を開きます。
管理用テンプレート
└ Microsoft Edge
└ プロキシ サーバー
- 「PACスクリプトのIPv6ルートプローブアドレスを設定する」に相当するポリシーを開きます。
- ポリシーを「有効」にします。
- 企業ネットワーク用に選定したIPv6アドレスを入力します。
- GPOを対象端末へ適用します。
- Edgeを完全に終了してから再起動します。
管理用テンプレートの言語や配信時期によって、表示名が英語のままの場合があります。その場合は、次の英語名を確認してください。
Set the IPv6 route-probe address for PAC scripts
ポリシーの内部名は次のとおりです。
PacMyIpAddressIPv6ProbeAddress
ポリシーの場所、設定形式、Edge再起動が必要であることはMicrosoftのポリシー仕様に明記されています。(Microsoft Learn)
レジストリで設定する場合
端末単位で設定する場合は、次のレジストリ値を使用できます。
| 項目 | 値 |
|---|---|
| キー | HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Edge |
| 値の名前 | PacMyIpAddressIPv6ProbeAddress |
| 種類 | REG_SZ |
| データ | 選定したIPv6アドレス |
PowerShellで設定する場合は、山括弧部分を実際のIPv6アドレスへ置き換えます。
$edgePolicyPath = "HKLM:\SOFTWARE\Policies\Microsoft\Edge"
$probeAddress = "<企業ネットワークで経路を管理するIPv6アドレス>"
New-Item -Path $edgePolicyPath -Force | Out-Null
New-ItemProperty `
-Path $edgePolicyPath `
-Name "PacMyIpAddressIPv6ProbeAddress" `
-PropertyType String `
-Value $probeAddress `
-Force
設定を削除してEdgeの既定動作へ戻す場合は、次のコマンドを実行します。
Remove-ItemProperty `
-Path "HKLM:\SOFTWARE\Policies\Microsoft\Edge" `
-Name "PacMyIpAddressIPv6ProbeAddress" `
-ErrorAction SilentlyContinue
設定または削除後は、Edgeの再起動が必要です。単にウィンドウを閉じるだけではプロセスが残ることがあるため、作業中の内容を保存したうえで、タスクマネージャーからmsedge.exeが終了していることを確認すると確実です。
ポリシーがEdgeへ反映されたか確認する
Edgeを再起動したら、アドレスバーへ次のURLを入力します。
edge://policy
一覧から次のポリシーを探します。
PacMyIpAddressIPv6ProbeAddress
確認する項目は次のとおりです。
- ポリシー名が表示されている
- 設定したIPv6アドレスが値として表示されている
- エラー欄に警告が表示されていない
- 適用元が想定したGPOまたはプラットフォームポリシーになっている
edge://policyに値が表示されても、PACの動作がすぐに切り替わるとは限りません。このポリシーは動的更新に対応していないため、実際の動作確認前にEdgeを完全に再起動してください。(Microsoft Learn)
Windowsのプロキシリゾルバーを使用していないか確認する
PacMyIpAddressIPv6ProbeAddressは、Edge内蔵のプロキシリゾルバーがPACを評価するときだけ有効です。
次のポリシーが有効になっている場合、EdgeではなくWindowsのプロキシリゾルバーが使用されます。
WinHttpProxyResolverEnabled
WinHttpProxyResolverEnabledが有効な環境では、PacMyIpAddressIPv6ProbeAddressを設定しても、PACのアドレス検出に適用されません。無効または未構成の場合は、Edge内蔵のプロキシリゾルバーが使用されます。(Microsoft Learn)
edge://policyで、次の2つを合わせて確認してください。
PacMyIpAddressIPv6ProbeAddress
WinHttpProxyResolverEnabled
ポリシーの値は表示されているのにPACの戻り値が変わらない場合、プロキシリゾルバーの違いが原因になっていないかを最初に確認すると、切り分けが早くなります。
probe addressへの経路をFind-NetRouteで確認する
ポリシーを配布する前に、Windowsがprobe addressに対してどのローカルIPアドレスと経路を選ぶか確認します。
管理者権限のPowerShellを開き、次のコマンドを実行します。
Find-NetRoute -RemoteIPAddress "<設定予定のIPv6アドレス>" |
Format-List *
Find-NetRouteは、指定したリモートアドレスに対する最適な経路とローカルIPアドレスを調べるコマンドです。(Microsoft Learn)
出力では、主に次の情報を確認します。
- 選択されたローカルIPv6アドレス
InterfaceAliasInterfaceIndexDestinationPrefixNextHopRouteMetric
Edge 153への移行影響を調べる場合は、旧既定値、新既定値、設定予定値の3つを比較します。
# Edgeの従来のIPv6検出先
Find-NetRoute -RemoteIPAddress "2603:1020:201:10::10f" |
Format-List *
# Edge 153以降の既定IPv6検出先
Find-NetRoute -RemoteIPAddress "2001:4860:4860::8888" |
Format-List *
# 企業で設定予定のIPv6検出先
Find-NetRoute -RemoteIPAddress "<設定予定のIPv6アドレス>" |
Format-List *
旧値と新値でInterfaceAliasやローカルIPv6アドレスが異なる場合は、Edge 153への更新によってPACの判定結果が変わる可能性があります。
必要に応じて、IPv6のルーティングテーブル全体も確認します。
Get-NetRoute -AddressFamily IPv6 |
Sort-Object InterfaceIndex, DestinationPrefix |
Format-Table -AutoSize
Get-NetRouteでは、IPv6の宛先プレフィックス、インターフェース、ネクストホップ、メトリックなどを確認できます。(Microsoft Learn)
dual-stack環境でPACの出力を検証する手順
検証では、ポリシー値だけでなく、実際のPAC関数の戻り値を記録します。
検証用のPACログを一時的に追加する
検証用ホストへのアクセス時だけ、PACの戻り値をNetLogへ出力するコードを一時的に追加します。
if (host === "pac-ip-check.corp.example") {
alert("myIpAddress=" + myIpAddress());
alert("myIpAddressEx=" + myIpAddressEx());
}
pac-ip-check.corp.exampleは、自社で管理している検証用ホスト名へ置き換えてください。
PAC内のalert()は、通常のJavaScriptのように画面へダイアログを表示する用途ではありません。Chromium系ブラウザーでは、PACのalert()メッセージがPAC_JAVASCRIPT_ALERTイベントとしてNetLogへ記録されます。(Chromium)
EdgeのNetLogを取得する
- Edgeで次のページを開きます。
edge://net-export
- ログ記録を開始します。
- 検証用ホストへアクセスします。
- ログ記録を停止します。
- 出力されたJSONファイルで
PAC_JAVASCRIPT_ALERTを検索します。 myIpAddressとmyIpAddressExの値を記録します。- 実際に選択されたプロキシとアクセス結果も確認します。
NetLogにはアクセス先のURLやホスト名などが含まれる場合があります。検証ログは組織の情報管理ルールに従って保管し、外部へ不用意に共有しないでください。
検証用のalert()は、確認後にPACファイルから削除します。
ネットワーク状態ごとに結果を記録する
1つのネットワーク状態だけで正常だったとしても、本番展開の判断材料としては不十分です。
最低でも次の組み合わせを確認します。
| 端末の状態 | 確認する内容 | 期待結果の例 |
|---|---|---|
| 社内有線LAN | probe addressへの経路、PAC出力 | 社内側IPv6を認識し、社内プロキシを選択 |
| 社内Wi-Fi | 有線LANとの差 | Wi-Fiでも想定した社内判定になる |
| 社外Wi-Fi、VPNなし | 経路不在時の動作 | 社外用プロキシまたは定義済みのフォールバック |
| split tunnel VPN | VPN経由とローカル経由の競合 | PAC設計で想定したインターフェースを選択 |
| full tunnel VPN | IPv6経路がVPNへ入るか | VPN用または社内用プロキシを選択 |
| IPv4のみ利用可能 | IPv6検出が使えない場合 | IPv4判定または既存のフォールバックが動作 |
| 有線LANとWi-Fiを同時接続 | 複数経路の優先順位 | 意図したインターフェースのアドレスを使用 |
| VPN切断直後 | 古い経路が残っていないか | 社外用の判定へ正しく戻る |
各状態について、次の4項目をセットで記録すると比較しやすくなります。
1. Find-NetRouteの結果
2. myIpAddress()の結果
3. myIpAddressEx()の結果
4. PACが最終的に返したDIRECTまたはPROXY
myIpAddressExの結果はアドレスごとに判定する
myIpAddressEx()は、複数のIPアドレスをセミコロン区切りで返すことがあります。
例:
192.0.2.25;fd12:3456:789a:1::25
IPv6プレフィックスに属するアドレスが含まれているか確認する場合は、戻り値を分割し、アドレスごとにisInNetEx()で判定すると安全です。
function anyLocalIpInPrefix(prefix) {
var result = myIpAddressEx();
if (!result) {
return false;
}
var addresses = result.split(";");
for (var i = 0; i < addresses.length; i++) {
if (isInNetEx(addresses[i], prefix)) {
return true;
}
}
return false;
}
PACの分岐では、次のように使用できます。
function FindProxyForURL(url, host) {
if (anyLocalIpInPrefix("fd12:3456:789a::/48")) {
return "PROXY proxy-internal.example.jp:8080";
}
return "PROXY proxy-external.example.jp:8080";
}
プレフィックス、プロキシ名、ポート番号は実際の環境へ置き換えてください。
myIpAddressEx()の結果を1つの文字列として扱うより、個別のアドレスに分解した方が、IPv4とIPv6が混在する環境で意図を明確にできます。(Chromium)
よくある失敗と確認ポイント
| 症状 | 主な原因 | 対処 |
|---|---|---|
| GPOにポリシーが表示されない | Edge管理用テンプレートが古い | Edge 153対応の最新ADMX・ADMLへ更新 |
edge://policyに値が表示されない | GPOの適用対象、フィルター、レジストリが不正 | gpresultやレジストリを確認 |
| 値がエラーになる | ホスト名、IPv4、リンクローカルなどを設定 | 有効なIPv6アドレスリテラルへ変更 |
| 値は表示されるが動作が変わらない | Edgeを完全に再起動していない | 全Edgeプロセスを終了して再起動 |
| 値は表示されるがPACへ反映されない | WinHttpProxyResolverEnabledが有効 | 使用中のプロキシリゾルバーを確認 |
myIpAddress()がIPv4のまま | dual-stackでIPv4が先に選ばれている | myIpAddressEx()と最終的なPAC分岐を確認 |
| 社内LANでは正常だがVPNで失敗する | probe addressへの経路がVPN状態で異なる | VPN接続中のFind-NetRouteを取得 |
| Microsoftの例示値を設定して判定が安定しない | 文書用IPv6アドレスをそのまま使用 | 自社でルーティングを管理するアドレスへ変更 |
| PACの戻り値は正しいがWebへ接続できない | プロキシサーバー、認証、名前解決など別の問題 | PAC判定後の接続経路を個別に調査 |
| 検証端末では正常だが他拠点で失敗する | 拠点ごとにIPv6ルーティングが異なる | 拠点別に経路とPAC出力を確認 |
probe addressの設定だけで解決しないケース
PacMyIpAddressIPv6ProbeAddressは、経路選択を安定させるためのポリシーです。端末が本当に社内ネットワークへ接続しているかを保証する機能ではありません。
例えば、PACで知りたいことが次のような状態だったとします。
この端末は社内ネットワークにいるか
一方、myIpAddress()が実際に調べているのは、より限定的な内容です。
指定された宛先へ向かうとき、OSはどの送信元アドレスを選ぶか
この2つは必ずしも一致しません。
仮想アダプター、split tunnel VPN、複雑なポリシールーティングが存在する環境では、ローカルIPアドレスだけで社内・社外を判定するPACは壊れやすくなります。
社内ネットワークへの接続状態を判定したい場合は、長期的には次のような設計も検討します。
- 社内DNSでのみ特定結果を返す検証用ホスト名を用意する
dnsResolve()またはdnsResolveEx()で判定する- VPN接続時にのみ解決できる内部ドメインを利用する
- 単一のインターフェースアドレスに依存しすぎない
- 判定不能時のプロキシ動作を明示する
Chromiumのプロキシ関連ドキュメントでも、複数インターフェース環境ではmyIpAddress()による判定に曖昧さがあり、管理されたテスト用ドメインを名前解決する方法が、より信頼できる場合があると説明されています。(Chromium)
PacMyIpAddressIPv6ProbeAddressは、Edge 153への移行時に既存PACの動作を維持したり、企業ネットワークに合わせて経路選択を調整したりする手段として有効です。ただし、脆弱なネットワーク判定ロジックを恒久的に補うものではありません。
Edge 153への展開前に実施すること
最初にPACファイル内のmyIpAddress()とmyIpAddressEx()の利用箇所を洗い出します。そのうえで、旧既定値、新既定値、設定候補のprobe addressについて、Find-NetRouteの結果を比較してください。
設定候補が決まったら、少数の検証端末へポリシーを適用し、Edgeを完全に再起動します。edge://policyだけで完了とせず、社内LAN、社外Wi-Fi、VPN接続中の各状態で、PAC関数の戻り値と最終的なプロキシ選択まで確認します。
問題がなければ、拠点や端末グループごとに段階的に展開します。異常が発生した場合にすぐ戻せるよう、ポリシー削除とEdge再起動によるロールバック手順も、事前に用意しておくことが重要です。

コメント