経緯

EC2上にSquidを導入してフォワードプロキシサーバとして運用しているのですが、可用性向上／運用負担軽減を目的にAppRunner上でSquidのDockerイメージが動作可能か試してみました。

結論

AppRuuner上でフォワードプロキシは動作不可。(Fargateでは動作可）

リバースプロキシとフォワードプロキシの違い

リバースプロキシとフォワードプロキシはhttp(s)通信を中継する点では役割同じですが、リバースプロキシをフォワードプロキシとして使ってしまうと、
- 外部送信を避けたい組織内の情報（X-Forwarded-forに個別端末のIPアドレスが付与される等）が転送される。
- 送信先のURLとリバースプロキシのURLが分離されない。

というとわかりやすくなるかもしれません。

送信先URLの指定方法のイメージ(yahooにアクセスする場合を想定）


 # フォワードプロキシの場合（プロキシサーバのURLと送信先URLは分離されている）
 curl https://www.yahoo.co.jp -x forward-proxy-url:3128
 
 # リバースプロキシの場合（プロキシサーバのURLと送信先URLは分離されていない）
 # 構築方法でURL(含むクエリストリング)の組み方は変えられる
 curl https://reverse-proxy-url?dest_url=www.yahoo.co.jp
 curl https://reverse-proxy-url/www.yahoo.co.jp

比較表を作ると以下のような感じですが、双方http(s)通信を中継する役割は同じなので少しわかりにくいかもしれず、上記解説にて補足したものです。

特徴	リバースプロキシ	フォワードプロキシ
役割	クライアントからのリクエストを受け取り、適切なサーバーに転送する。	クライアントの代理として外部のリソースにアクセスする。
主な目的	負荷分散、キャッシング、セキュリティ	インターネットアクセスの制御、匿名化、キャッシング
主な用途	- ウェブサーバーの負荷分散 - SSL終端 - キャッシング	- 社内ネットワークのインターネットアクセス制御 - 匿名ブラウジング - コンテンツフィルタリング
設置場所	サーバーの前面	クライアントの前面
接続の方向	インバウンドトラフィック（クライアント→サーバー）	アウトバウンドトラフィック（クライアント→インターネット）
IPアドレス	クライアントにはリバースプロキシのIPアドレスが見える	外部サイトにはフォワードプロキシのIPアドレスが見える
セキュリティ機能	Webアプリケーションファイアウォール（WAF）、DoS攻撃の緩和	フィルタリング、アクセス制御、匿名化
クライアントからサーバに送信するデータの取り扱い	極力サーバに転送しようとする	必要最小限にとどめる
有名なソフトウェア	Squid	Apache、Nginx

ざっくり手順

squidのコンテナイメージを作成するDockerfile

Dockerfile-squid

# 使用するベースイメージ
FROM ubuntu/squid:latest

# デフォルトのSquid設定ファイルをバックアップ
RUN mv /etc/squid/squid.conf /etc/squid/squid.conf.original

# Squid設定を直接書き込み
RUN echo "\
# Allow local machine to access\n\
http_access allow localhost\n\
\n\
# IPアドレスによるアクセス制限の設定\n\
acl allowed_ips src xxx.xxx.xxx.xxx \n\
http_access allow allowed_ips\n\
\n\
# Squid の設定\n\
acl Safe_ports port 1-65535          # all ports\n\
acl SSL_ports port 443\n\
acl CONNECT method CONNECT\n\
\n\
http_access allow Safe_ports\n\
http_access allow CONNECT SSL_ports\n\
http_access deny all\n\
\n\
# デフォルトのポート\n\
http_port 3128\n\
\n\
# キャッシュを無効にする設定\n\
cache deny all\n\
cache_mem 0 MB\n\
maximum_object_size_in_memory 0 KB\n\
cache_dir null /tmp\n\
\n\
# ログファイルの場所\n\
access_log /var/log/squid/access.log\n\
cache_log /var/log/squid/cache.log\n\
\n\
# その他のオプション\n\
coredump_dir /var/spool/squid" > /etc/squid/squid.conf

# 必要なログファイルとキャッシュディレクトリの作成
RUN mkdir -p /var/spool/squid \
    && chown -R proxy:proxy /var/spool/squid \
    && mkdir -p /var/log/squid \
    && chown -R proxy:proxy /var/log/squid \
    && squid -z

# Squidサーバーを起動
CMD ["squid", "-N", "-d", "1"]

squidのDockerイメージをECRにプッシュ（ your-account-id を適宜変更）

# Dockerfile-squidを使ってSquidのDockerイメージをビルドし、イメージ名をhogehoge-squidにタグ付けする
docker build -f Dockerfile-squid -t hogehoge-squid .

# AWS ECRにログインするためのパスワードを取得し、Dockerにログインする
aws ecr get-login-password --region ap-northeast-1 | docker login --username AWS --password-stdin <your-account-id>.dkr.ecr.ap-northeast-1.amazonaws.com

# hogehoge-squidイメージに最新タグを付け、AWS ECRリポジトリのsquid:latestとしてタグ付けする
docker tag hogehoge-squid:latest your-id.dkr.ecr.ap-northeast-1.amazonaws.com/squid:latest

# 最新タグが付いたSquidイメージをAWS ECRリポジトリにプッシュする
docker push <your-account-id>.dkr.ecr.ap-northeast-1.amazonaws.com/squid:latest

AWSマネジメントコンソールからAppRunnerを選択して、プッシュしたイメージを元にサービスを起動。（実際の手順は公式に委ねますが、体感して簡単に設定可能でした。）

検証結果

上記コンテナをAppRunnerにデプロイすると標準出力にログ出力されることになるが、端末からデプロイしたサービス経由で接続してもタイムアウトになり、サービス上のログもヘルスチェック用のログしか記録されない。

通信シーケンスまで確認できていないですが、フォワードプロキシの場合、通信開始する際にHTTPのCONNECTメソッド（送信元がプロキシサーバーに送信先とTCP接続を確立するよう要求する役割）を使うのですが、AppRunnerの目的からして当然ではありますがAppRunnerはこのメソッドをサポートしていないからだと思われます。

07-15-2024 12:15:45 AM 1720970144.822      0 169.254.175.249 NONE_NONE/000 0 - error:transaction-end-before-headers - HIER_NONE/- -
07-15-2024 12:15:55 AM 1720970154.823      0 169.254.175.249 NONE_NONE/000 0 - error:transaction-end-before-headers - HIER_NONE/- -
07-15-2024 12:16:05 AM 1720970164.823      0 169.254.175.249 NONE_NONE/000 0 - error:transaction-end-before-headers - HIER_NONE/- -

AppRunner上にデプロイしても、以下のようなSquidのエラーページは表示されました。（以下は検証時と全く同じものではないです）

補足

AWS上でフォワードプロキシを構築する際は、踏み台にならないように必ず送信元制限はかけましょう。（AWSの規約違反になります）
上記は厳密に検証／整理したわけではありませんので、その点割り引いてお読みください。