PacMyIpAddressIPv6ProbeAddressの設定方法|Edge 153のPAC IPv6判定を制御

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以降
対応OSWindows、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以降の既定値
IPv420.76.201.1718.8.8.8
IPv62603:1020:201:10::10f2001: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()複数アドレスをセミコロン区切りで返すすべてのインターフェースが含まれるとは限らない
PacMyIpAddressIPv6ProbeAddressIPv6経路確認先を変更するIPv6を強制的に返すポリシーではない

したがって、検証時には「IPv6ポリシーを設定したのにmyIpAddress()がIPv4のままだから失敗」と判断してはいけません。

確認すべきなのは次の3点です。

  1. IPv6経路の確認が必要になったとき、意図したインターフェースが選ばれるか
  2. myIpAddressEx()に必要なIPv6アドレスが含まれるか
  3. 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)

グループポリシーを構成する

  1. グループポリシー管理コンソールを開きます。
  2. 対象端末またはユーザーへ適用するGPOを編集します。
  3. 次の場所を開きます。
管理用テンプレート
  └ Microsoft Edge
      └ プロキシ サーバー
  1. 「PACスクリプトのIPv6ルートプローブアドレスを設定する」に相当するポリシーを開きます。
  2. ポリシーを「有効」にします。
  3. 企業ネットワーク用に選定したIPv6アドレスを入力します。
  4. GPOを対象端末へ適用します。
  5. 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アドレス
  • InterfaceAlias
  • InterfaceIndex
  • DestinationPrefix
  • NextHop
  • RouteMetric

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を取得する

  1. Edgeで次のページを開きます。
edge://net-export
  1. ログ記録を開始します。
  2. 検証用ホストへアクセスします。
  3. ログ記録を停止します。
  4. 出力されたJSONファイルでPAC_JAVASCRIPT_ALERTを検索します。
  5. myIpAddressmyIpAddressExの値を記録します。
  6. 実際に選択されたプロキシとアクセス結果も確認します。

NetLogにはアクセス先のURLやホスト名などが含まれる場合があります。検証ログは組織の情報管理ルールに従って保管し、外部へ不用意に共有しないでください。

検証用のalert()は、確認後にPACファイルから削除します。

ネットワーク状態ごとに結果を記録する

1つのネットワーク状態だけで正常だったとしても、本番展開の判断材料としては不十分です。

最低でも次の組み合わせを確認します。

端末の状態確認する内容期待結果の例
社内有線LANprobe addressへの経路、PAC出力社内側IPv6を認識し、社内プロキシを選択
社内Wi-Fi有線LANとの差Wi-Fiでも想定した社内判定になる
社外Wi-Fi、VPNなし経路不在時の動作社外用プロキシまたは定義済みのフォールバック
split tunnel VPNVPN経由とローカル経由の競合PAC設計で想定したインターフェースを選択
full tunnel VPNIPv6経路が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再起動によるロールバック手順も、事前に用意しておくことが重要です。

この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次