プロキシ機能その1 明示型プロキシ(Explicit Proxy)

PAN-OS 11.0以降でPAシリーズにプロキシ機能が実装されましたので紹介します。明示型プロキシ(Explicit Proxy)と透過型プロキシ(Transparent Proxy)どちらも利用可能です。今回は明示型プロキシの設定方法について記載します。

Configure a Web Proxy
If your network uses a proxy device, learn how to configurea web proxy as either an explicit proxy or a transparent prox...

プロキシ機能の利用条件

プロキシ機能の利用条件は以下の様になっています。

  • PAN-OS 11.0以上
  • PA-1400、PA-3400、PA-5400、PA-VMシリーズ(4コア以上)でサポート
  • WebProxyライセンスが必要(VSYSと同様、買い切りのライセンス)

明示型プロキシ(Explicit Proxy)の設定

以下の構成で検証を行なっていきます。
明示型プロキシは、クライアントPC側に明示的にプロキシサーバのアドレスを設定することで、クライアントPCにインターネット向けのルートがない環境でも、WEBアクセスを行うことができます。(現在、それ以外の場合は、敢えてプロキシ構成を取る必要はなくなってきている印象です。)

ネットワーク設定

関係するインターフェイスとゾーンの設定を行なっていきます。設定するのは以下の3つで、すべて同じ仮想ルータに設定します。

インターフェイスゾーン備考
ethernet 1/1WAN
ethernet 1/2LANListenning Interface
(PCから見たプロキシIP)
loopback.1PROXYWebプロキシ、DNSプロキシで利用

【NETWORKタブ】→【インターフェイス】に移動します。

  • Ethernet インターフェイス設定
  • ループバック インターフェイス設定

DNSプロキシの設定

DNSプロキシの設定を行います。Webプロキシは、このDNSプロキシを使用して名前解決を行います。

【NETWORKタブ】→【DNSプロキシ】に移動し、画面下の「追加」をクリックします。

  • 「OK」をクリックします。

明示型プロキシ(Explicit Proxy)の設定

今回の本題である明示型プロキシの設定を行います。

【NETWORKタブ】→【プロキシ】に移動します。

  • 【プロキシの有効化】の右上の「歯車アイコン」をクリックします。
  • プロキシタイプを「明示型プロキシ(Explicit Proxy)」に変更します。
  • 「OK」をクリックします。

【明示的なプロキシ構成】ウィンドウが表示されるようになるので、右上の「歯車アイコン」をクリックして以下の設定を行います。

  • 接続タイムアウト(デフォルト値)
  • リスニングインターフェイス:ethernet1/2 (LAN側のIF)
  • アップストリームインターフェイス:loopback.1 (プロキシが使用するIF)
  • プロキシIP:リスニングインターフェイスのIP(PCのプロキシに設定するIP)
  • DNSプロキシ:先ほど作成したDNSプロキシ
  • CONNECTとSNIのドメインが同じであることを確認するにチェック(デフォルト値)
  • 認証サービスの種類:認証なし
明示的なプロキシのポート番号は「8080固定」です。8080以外のポートを利用したい場合は、宛先NATを利用してください。
認証サービス(認証方式)について、PAN-OS11.1以降で「認証なし」が選択できるようになりました。今回は説明しませんが、SAML/CAS方式を利用する場合は、PanoramaとPrisma AccessのMUライセンスが必要です。そのため、認証プロキシを構成する場合はKerberosを利用した方が安価かつシンプルに構築できると思います。

ポリシーの設定

オブジェクトの作成

まず、以下のオブジェクトを作成します。

  • アドレスオブジェクト(見た目の話なのでオプション)
  • プロキシ用のTCP_8080 を通すためのサービスオブジェクト

セキュリティポリシーの作成

セキュリティポリシーの設定を行います。今回は以下3つのポリシーを設定します。

  • クライアントPC → プロキシIP へのプロキシ通信 (TCP:8080)
  • 明示型プロキシ → インターネットへの通信
  • DNSプロキシ → 外部DNSサーバ へのDNS通信

プロキシIPはethernet1/2に設定されているので、LANゾーン to LANゾーンの通信になります。また、今回はプロキシ通信のみを確認するため1行目のインターネット向けのポリシーは無効化しています。

NATポリシーの作成

DNSプロキシと明示型プロキシ(loopback.1=10.10.10.10)からインターネットにアクセスする際に利用するNAPT用のポリシーを以下のように作成します。

セキュリティポリシーと同じく1行目のポリシーは無効化しています。これで設定自体は完了です。

通信確認

Windows端末でプロキシの設定を行います。

  • プロキシのIPはリスニングインターフェイスで設定した「192.168.45.20」です。

curl コマンドを利用してHTTP通信でアクセス確認を行います。

curl --proxy 192.168.45.20:8080 -v http://httpvshttps.com -I
*   Trying 192.168.45.20:8080...
* Connected to 192.168.45.20 (192.168.45.20) port 8080
* using HTTP/1.x
> HEAD http://httpvshttps.com/ HTTP/1.1
> Host: httpvshttps.com
> User-Agent: curl/8.13.0
> Accept: */*
> Proxy-Connection: Keep-Alive
>
* Request completely sent off
< HTTP/1.1 301 Moved Permanently
HTTP/1.1 301 Moved Permanently
< server: nginx
server: nginx
< date: Mon, 01 Sep 2025 21:28:43 GMT
date: Mon, 01 Sep 2025 21:28:43 GMT
< content-type: text/html
content-type: text/html
< content-length: 162
content-length: 162
< location: http://www.httpvshttps.com/
location: http://www.httpvshttps.com/
<

* Connection #0 to host 192.168.45.20 left intact

HTTPS通信の確認も行います。HTTPS通信はCONNECTメソッドで接続されていることが分かります。

curl --proxy 192.168.45.20:8080 -v https://httpvshttps.com -I
*   Trying 192.168.45.20:8080...
* CONNECT tunnel: HTTP/1.1 negotiated
* allocate connect buffer
* Establish HTTP proxy tunnel to httpvshttps.com:443
> CONNECT httpvshttps.com:443 HTTP/1.1
> Host: httpvshttps.com:443
> User-Agent: curl/8.13.0
> Proxy-Connection: Keep-Alive
>
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
<

* CONNECT phase completed
* CONNECT tunnel established, response 200
* schannel: disabled automatic use of client certificate
* ALPN: curl offers http/1.1
* ALPN: server accepted http/1.1
* Connected to 192.168.45.20 (192.168.45.20) port 8080
* using HTTP/1.x
> HEAD / HTTP/1.1
> Host: httpvshttps.com
> User-Agent: curl/8.13.0
> Accept: */*
>* Request completely sent off
< HTTP/1.1 301 Moved Permanently
HTTP/1.1 301 Moved Permanently
< Server: nginx
Server: nginx
< Date: Mon, 01 Sep 2025 21:51:39 GMT
Date: Mon, 01 Sep 2025 21:51:39 GMT
< Content-Type: text/html
Content-Type: text/html
< Content-Length: 162
Content-Length: 162
< Connection: keep-alive
Connection: keep-alive
< Location: https://www.httpvshttps.com/
Location: https://www.httpvshttps.com/
<

(OS側でプロキシ設定を実施した上で)ブラウザでアクセスしてみます。問題なくアクセスできているようです。

ログの確認

HTTPとHTTPSそれぞれの通信を行った場合のTraffic logの出力を確認します。

トラフィックログ

HTTP通信のトラフィックログ

HTTP通信のログを確認してみます。セッション終了時のログが生成されているため順序がズレていますが、セッションIDを見るとセッションが生成された順番が分かります。HTTP通信の場合、以下の3種類のログが出力されていることがわかります。

  1. クライアントPC(192.168.45.132) → リスニングインターフェイス(192.168.45.20:8080)へのプロキシ通信
    クライアントPCによるプロキシ通信です。暗号化されていないHTTP通信であるためクライアントPCはプロキシに対してGETリクエストを送信します。
    明示型プロキシではリスニングインターフェイスのIPが、PCに設定するプロキシのIPになるので、LANゾーン→LANゾーンのログが生成されています。
  1. プロキシ(10.10.10.10) → 外部DNSサーバへのDNS通信
    クライアントからのプロキシ通信を受信した明示型プロキシはそのURLにアクセスするためにDNSによる名前解決を行います。この際の送信元IPはDNSプロキシで設定したloopback.1(10.10.10.10)となりNAPTされてehernet1/1のIPでNAPTされて外部に送信されます。
  1. クライアントPC(192.168.45.132) → インターネットアクセス
    クライアントPCがインターネットにアクセスする際の通信です。一般的なプロキシの構成ではログの送信元IPはプロキシのIPとなるためクライアントPCの特定が面倒な場合がありますが、PAシリーズの明示型プロキシでは送信元IPがクライアントIPアドレスになっているため、クライアントの特定が容易です。(少し分かりにくいですが送信元ゾーンはPROXYのままです。)

HTTPSのトラフィックログ

続いてHTTPSのトラフィックについて確認します。SSL復号を行わない場合、プロキシは通信の中身をチェックすることができず、プロキシ先のWebサーバの情報を取得することができません。そこで、クライアントPCはCONNECTメソッドと呼ばれるHTTP通信で宛先のドメイン情報を伝えます。

FWのログを確認したところ、CONNECTメソッド(HTTP)の通信とその後のプロキシ(HTTPS)通信が同一セッションになっているようです。(セッション終了時のログには残らないため、セッション開始時のログも取得する設定にしています。「タイプ」がstartになっている部分がセッション開始時のログです。)赤枠はセッションIDが同じなので同一セッションですので、結果的にセッション終了時のログは3種類のログが出力されています。

  1. クライアントPC(192.168.45.132) → リスニングインターフェイス(192.168.45.20:8080)へのプロキシ通信
    • この通信は4種類のログに分かれています。
    • 1行目は「web-browsing」となっているので、HTTP通信が開始されたことを示しています。
    • 2行目は「http-proxy」となっているので、プロキシ通信(CONNECTメソッド)で、アクセス先のドメイン情報をプロキシに伝達しています。
    • 3行目では「ssl」となっており、HTTPS通信にCONECTメソッド後に同一セッション内でClient Helloを送信して通信をTLS(SSL)化しています。
    • 4行目は、この「ssl」通信のセッションが終了したことを示しています。(通常、このログだけが出力されます。)
  1. プロキシ(10.10.10.10) → 外部DNSサーバへのDNS通信
    CONNECTメソッドで受け取ったドメイン情報の名前解決を行います。
  1. クライアントPC(192.168.45.132) → インターネットアクセス
    こちらも本来はプロキシIP(10.10.10.10)が送信元になるはずですが、送信元IPがクライアントPCになっており、端末特定やフィルタリングが容易に実行できるようになっています。

URLフィルタリングログ

今度はURLフィルタリングのログを確認してみます。

HTTP通信のURLフィルタリングログ

HTTP通信の場合、URLフィルタリングログは、クライアントPCからプロキシサーバへの通信と、クライアントPC(プロキシ経由)→インターネット通信の2行出力されます。(セッションIDの順)
また、HTTP通信の場合は平文のHTTPヘッダを参照できるため、URLのパス名まで表示できます。(制御も可能)

HTTPS通信

HTTPS通信の場合は、3行のログが出力されます。ただ、下2行は「HTTPSのトラフィックログ」の項で説明したとおり同じセッションIDの通信ですので、実質同一セッションです。(URLフィルタリングなどの脅威ログは、セッション開始時/終了時ではなく、脅威を検出したタイミングでログが出力されるため。)

プロキシ通信のログを確認する場合は、PROXYゾーン→WANゾーンの通信を確認するのがよさそうです。

セキュリティポリシーによる制御

セキュリティポリシーはPROXYゾーン→WANゾーンで作成することで、プロキシを意識することなくクライアントPCからインターネット通信を制御できます。

URLフィルタリングでブロックした際のログの例です。

SSL復号

LANゾーン→LANゾーンを対象にSSL復号を有効にすることで、詳細なログの取得と制御が可能になります。

  • ポリシーの例
  • URLログ出力

PAシリーズの明示型プロキシ(Explicit Proxy)では、クライアントPCのIPを利用したフィルタリングが直感的に設定できるので、利用しやすいのではないかと思います。ただし、通常のトラフィックに比べて負荷は高めになりますので、サイジングは十分に行うようにしましょう。

コメント欄 質問や感想、追加してほしい記事のリクエストをお待ちしてます!

タイトルとURLをコピーしました