プロキシを入れると通信はどう変わる？｜SWG・CONNECT・送信元IP

社内のプロキシをクラウド型へ変えるだけなのに、取引先サイトへ入れなくなるのはなぜでしょうか。接続先から見える送信元IPや、途中で検査できる内容が変わるためです。変更前後の経路を並べて確かめましょう。

事例：取引先のIP制限に合わなくなった

C社は社内プロキシを経由して、送信元IPを制限する取引先サイトへ接続しています。旧経路の外向きIPは198.51.100.10、新しいクラウド型SWGの外向きIPは203.0.113.20です。取引先は旧IPだけを許可したままです。

SWGはSecure Web Gatewayの略で、Webアクセスを中継・検査するサービスや製品を指します。URLやカテゴリの判定、利用者認証、マルウェア検査などの機能は製品と構成で異なります。

取引先でIP拒否が記録されているなら、資格情報だけを何度も変えても原因は解消しません。送信元IPが変わる構成では、接続先の許可規則も変更対象です。

フォワードとリバースは、誰の代理？

フォワードプロキシは利用者側のアクセスを代理し、端末から外部への経路を集中させます。リバースプロキシはサイト側で要求を受け、内部のアプリへ中継します。どちらも中継ですが、守る側と規則の設置場所が異なります。

NATはIPやポートを変換する仕組みで、利用者認証やURL判定を必ず行うわけではありません。プロキシも外向きIPがさらにNATされる構成があります。名前だけで送信元を決めず、接続区間ごとに追います。

HTTPSでも、URLの全部が見える？

通常の明示的なHTTPSプロキシでは、端末がCONNECTで接続先ホストとポートを指定します。トンネルを作った後のTLS通信をそのまま中継する場合、プロキシは暗号化された本文やURLのパスを復号していません。

CONNECT portal.partner.example:443 HTTP/1.1
Host: portal.partner.example:443

その後のHTTPS要求：
GET /orders/123
※ /orders/123はトンネル内の暗号化対象

図の端末からサイトへの矢印は論理的なTLSの相手を表します。実際のバイト列はプロキシを通ります。CONNECTの宛先が分かっても、その中の全パスやフォーム内容を見られるとは言えません。

TLS検査では中継点がTLSを終端し、端末側とサイト側を別のTLS接続にします。端末が信頼する証明書、サイト側の証明書検証、対象・除外条件が必要です。クライアント証明書や証明書固定等のアプリでは互換性にも注意します。

検査を外すことと、サイト証明書の検証を無効にすることは別です。例外を作る場合は対象を限定し、代わりの管理策と期限を決めます。検査で扱う情報の範囲と、閲覧・保存の権限も管理します。

導入時の規則は、どこを変える？

PACは宛先などの条件からプロキシ利用を選ぶ設定スクリプトです。設定にDIRECTが残る、端末が設定を外す、別プロトコルを使うなど、プロキシを迂回する条件があれば検査を通りません。所定経路を使わせるには、出口側の制御も確かめます。

通信の例外は業務ごとに整理し、更新配布、認証、名前解決などの依存先も試します。SWGの外向きIPが固定か複数か、共有されるか、自社専用かを確認します。許可IPを増やせば個々の利用者まで認証できた、という意味にはなりません。

送信元IPと転送ヘッダを、どう信頼する？

サイトのTCP接続元は、中継やNAT後のIPです。ForwardedやX-Forwarded-For等のヘッダに元の利用者情報が入る構成もありますが、どの製品も必ず同じ値を付けるわけではありません。

外部利用者が自由に付けたヘッダをそのままアクセス制限へ使うと、信頼できない値で判断します。信頼する中継点から届いた要求だけを受け、その中継点が値を置き換える・付加する規則を決めます。

事例の取引先がネットワーク層でIP制限するなら、ヘッダを変えてもTCP接続元のIPは変わりません。認証、ネットワーク許可、アプリのログでどの値を使うかを明確にします。

接続失敗を、どの記録で切り分ける？

1. 端末→SWG

   接続先、認証結果、CONNECTの応答を確認します。407はプロキシ認証を求める応答です。

2. SWG→サイト

   SWGの許可・拒否理由、接続結果、外向きIPを確認します。

3. TLS

   証明書の名前・期限・信頼、検査の対象と例外を確かめます。

4. サイト

   受信した接続元、IP拒否、アプリ認証と処理結果を確認します。

200のCONNECT応答はトンネル作成の成功で、ログインや業務処理の成功ではありません。端末とSWG、SWGとサイト、TLS、アプリの順に対応付けます。要求IDや時刻をそろえ、製品固有の記録名を通信の段階へ読み替えます。

演習1：変更された接続元

条件：旧IP198.51.100.10だけを取引先が許可。SWGからは203.0.113.20で接続する。

問い：導入時に取引先へ確認する設定は何か。

解答例：新しい外向きIP203.0.113.20を受け入れる送信元IP制限。

根拠：取引先が実際に見るTCP接続元が変わる。

誤答の理由：『端末の10.xのIPを許可する』は取引先から見える接続元と合わない。

演習2：見えるURL

条件：CONNECTで作ったトンネル内のTLSを、プロキシは復号しない。

問い：URLのパス単位の検査が必ずできるか。

解答例：できるとは言えない。パスはTLSの暗号化対象である。

根拠：CONNECTが示すホストとポートと、内部のHTTP要求は別である。

誤答の理由：『プロキシを通れば全内容が見える』は暗号化と終端位置を確認していない。

演習3：検査の迂回

条件：PACにDIRECTがあり、端末から直接外部へ出る通信も出口で許可している。

問い：SWGの検査を必ず通すために不足する対策は何か。

解答例：不要な直接経路を制限し、必要な業務通信が所定のSWG経路を使うようにする。

根拠：中継されない通信にはSWGの判定が適用されない。

誤答の理由：『SWGのURL規則を増やす』だけでは迂回した通信を制御できない。

演習4：転送された値

条件：サイトは外部から届くX-Forwarded-Forを無条件に信頼している。

問い：アクセス制限の問題点を述べる。

解答例：利用者が偽装できる値を元に接続元を判断する可能性がある。

根拠：ヘッダ値の信頼は中継経路と書換え規則で確保する必要がある。

誤答の理由：『ヘッダなので必ずネットワーク装置が設定した』は根拠がない。

演習5：407の段階

条件：端末がCONNECTを送ると407が返り、サイトへのTLSは開始していない。

問い：先に調べる段階はどこか。

解答例：端末からプロキシへの利用者認証。

根拠：407はプロキシの認証要求で、サイトの業務ログインとは別である。

誤答の理由：『サイトのパスワードを変える』では失敗している接続段階に対応しない。

演習6：200の意味

条件：CONNECTへ200が返るが、続くHTTPS要求でサイトは403を返す。

問い：業務利用まで成功したと言えるか。

解答例：言えない。トンネル作成後のサイト側の許可や処理を確認する。

根拠：CONNECTの成功と、トンネル内のHTTP応答は別の結果である。

誤答の理由：『200があったのでサイトは正常』はどの応答かを取り違えている。

出典と仕様を確認する

IPA：APシラバス Ver.7.2

RFC 9110：HTTPとCONNECT

RFC 7239：Forwardedヘッダ

RFC 8446：TLS 1.3

NIST SP 800-41 Rev.1：FWとプロキシ

関連テーマを続けて学ぶ

経路とNAT

TLSと証明書の検証