#はじめに
前回の記事でWorkSpacesを使ったテレワーク環境の構築方法を紹介しました。
今回は、WorkSpacesから安全なインターネットアクセスを行うため、前回構築した環境に
SquidでHA構成のプロキシを導入したいと思います。
###プロキシについて
WorkSpacesのWebブラウザでインターネットにアクセスする際、プロキシを経由することで、プロキシがクライアントの代理でリクエスト先のWebサーバと通信を行ってくれます。
リクエストを受けるWebサーバからすると、接続元がプロキシとなるため、クライアントのIPアドレスを隠蔽することができます。
また、プロキシではアクセス制御やユーザ認証、URLフィルタリングなどを利用することで、よりセキュアなインターネット利用環境を実現できます。
クライアントからのアクセスログを取得できる点もメリットです。
#対象者
- WorkSpacesでプロキシを使いたい方
- AWSの環境にSquidを導入したい方
- Auto Scalingの使い方を知りたい方
#実現したいこと
前回の記事で作成した環境をベースとし、Auto Scalingを活用したHA構成のプロキシを構築します。
運用の手間がかからないよう、Squidの設定ファイル（squid.conf）はS3バケットに格納します。
そうすることで、設定ファイルを後で変更した時に、その都度AMIの登録や起動テンプレートの作成を行わずにすみます。
プロキシを構築したら、WorkSpaces上でプロキシの設定(※)を行い、プロキシ経由でインターネットに接続できることを確認します。
※ADのグループポリシーでも設定できますが、今回はWorkSpacesでの設定の仕方を説明したいので手動で行います
#構成
赤枠内が今回の構築範囲です。
#注意点
- 2020年9月時点の情報です。
- AWSマネジメントコンソールを使用します。ルートユーザもしくは権限を満たすIAMユーザを利用できる前提で進めます。
- AWS利用料にご注意ください。利用料については、AWSの公式ページをご参照ください。
環境構築
１．ネットワーク設定（サブネット作成、ルーティング設定）
２．S3バケット作成、Squid.conf配置
３．Network Load Balancer作成
４．セキュリティグループ作成
５．Auto Scaling設定
６．WorkSpacesプロキシ設定、動作確認
##１．ネットワーク設定（サブネット作成、ルーティング設定）
前回作成したVPCに、プロキシを配置するためのパブリックサブネットを作成します。
サブネットはAZ-aとAZ-cにそれぞれ作成し、パブリックサブネット用のルートテーブルを割り当てます。
以下は上記の作業を行った後のサブネットの一覧を表示した状態です。
（わかりやすくするため、WorkSpacesの作成先サブネットのNameを「telework-workspaces-subnet-x」に変更しています）
##２．S3バケット作成、squid.conf格納
まず、squid.confを格納するためのS3バケットを作成します。
このバケットはAuto Scalingで起動するEC2インスタンスからのアクセスしか発生しないため、パブリックアクセスは「すべてブロック」とします。その他の設定はデフォルトのままで問題ありません。
以下は作成時の確認画面です。
バケットが作成されたことを確認します。
次に、ローカルでsquidの設定ファイル(squid.conf)を作成します。
テキストエディタを開き、以下を貼り付けて「squid.conf」として保存してください。
※以下は最小限のコンフィグです。80、443以外の検証で不要なポートは閉じていますので、必要に応じて編集してください。
（参考リンク：https://qiita.com/tosier/items/30297afb6ffbd4567eb5）
#
# Recommended minimum configuration:
# Example rule allowing access from your local networks.
# Adapt to list your (internal) IP networks from where browsing
# should be allowed
acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
acl localnet src fc00::/7 # RFC 4193 local private network range
acl localnet src fe80::/10 # RFC 4291 link-local (directly plugged) machines
acl SSL_ports port 443
acl Safe_ports port 80 # http
acl Safe_ports port 443 # https
acl CONNECT method CONNECT
#
# Recommended minimum Access Permission configuration:
#
# Deny requests to certain unsafe ports
http_access deny !Safe_ports
# Deny CONNECT to other than secure SSL ports
http_access deny CONNECT !SSL_ports
# Only allow cachemgr access from localhost
http_access allow localhost manager
http_access deny manager
# We strongly recommend the following be uncommented to protect innocent
# web applications running on the proxy server who think the only
# one who can access services on "localhost" is a local user
#http_access deny to_localhost
#
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
#
# Example rule allowing access from your local networks.
# Adapt localnet in the ACL section to list your (internal) IP networks
# from where browsing should be allowed
http_access allow localnet
http_access allow localhost
# And finally deny all other access to this proxy
http_access deny all
# Squid normally listens to port 3128
http_port 3128
# Uncomment and adjust the following to add a disk cache directory.
#cache_dir ufs /var/spool/squid 100 16 256
# Leave coredumps in the first cache dir
coredump_dir /var/spool/squid
#
# Add any of your own refresh_pattern entries above these.
#
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
refresh_pattern . 0 20% 4320
squid.confを作成したら、ファイルをバケットに保存します。
AWSのマネジメントコンソールでバケットを開き、ファイルをドラッグ&ドロップして[アップロード]をクリックしてください。
##３．Network Load Balancer作成
AWSのマネジメントコンソールでEC2の画面を開き、左のメニューから[ロードバランサー]を選択し、[ロードバランサーの作成]をクリックします。
作成画面が開いたら、中央のNetwork Load Balancerの[作成]をクリックします。
任意の名前を設定し、スキームは「内部」を選択します。
リスナーに設定するポートには、squid.confで設定したhttp_portを設定してください。
デフォルトのままであれば「3128」です。
アベイラビリティーゾーンでは、使用しているVPCと「１．ネットワーク設定」で作成したパブリックサブネットを選択します。
手順2は何もせずにそのまま次に進んでください。
手順3でターゲットグループを作成します。
こちらもポートには、squid.confで設定したhttp_portを設定してください。
手順4ではターゲットの登録ができますが、まだターゲットがないため、この時点では何も設定せずに次に進んでください。
手順5で設定内容を確認し、問題なければ[作成]をクリックします。
##４．セキュリティグループ作成
プロキシに設定するセキュリティグループを作成します。
インバウンドルールでSSHとプロキシの設定ポートを許可してください。
セキュリティの面から、SSHは現在自分が使用しているグローバルIPのみを許可します（グローバルIPの確認）
以下は作成後の画面です。
##５．Auto Scaling設定
プロキシ用の起動テンプレートとAuto Scalingグループを作成します。
マネジメントコンソールでEC2の画面を開き、左のメニューから[Auto Scaling グループ]を選択し、[Auto Scaling グループを作成する]をクリックします。
作成画面が開くので、任意の名前を選択し、[起動テンプレートを作成する]をクリックします。
起動テンプレートの設定については、以下の画面を参考にしてください。
AMIはAmazon Linuxを使用していますが、別のものでも大丈夫です。
その場合はOSに合わせてユーザーデータを変更してください。
インスタンスタイプはお好みのものを設定してください。
キーペアの設定は必須ではありませんが、後ほどSSH接続してアクセスログを確認したいため、設定しておきました。
サブネットは冒頭で作成したパブリックサブネットを選択します。
パブリックIPの自動割り当ては有効化し、先ほど作成したセキュリティグループを設定してください。
IAMインスタンスプロフィールには、EC2用のIAMロールを作成して割り当ててください。
ロールには以下のIAMポリシーを作成してアタッチしています。
AMIがAmazon Linuxの場合、ユーザーデータには以下を設定します。
#!/bin/bash
sudo yum update -y
sudo yum -y install squid
chkconfig squid on
aws s3 cp s3://＜バケット名＞/squid.conf /etc/squid/squid.conf
sudo service squid restart
Auto Scalingグループの作成画面に戻り、作成した起動テンプレートをセットします。
次の画面に進み、設定の構成を行います。
ステップ3、5、6については、特になにも設定せずにそのままでも問題ありません。
ステップ4でグループサイズを決められるので以下を設定します。
・希望する容量…2
・最小キャパシティ…2
・最大キャパシティ…2
これで常時2台プロキシが稼働します。
※後でプロキシの台数を調整したい時は、この値を変更してください。上から全部0にするとプロキシは停止状態となります。
##６．WorkSpacesプロキシ設定、動作確認
WorkSpaces上でプロキシ設定を行います。
左下のWindowsアイコンをクリックして[設定]を開き、[ネットワークとインターネット]をクリックします。
左のメニューから[プロキシ]をクリックし、手動プロキシ セットアップでプロキシの設定を行います。
・プロキシ サーバーを使う：オン
・アドレス：NLBのパブリックDNS
・ポート： プロキシの設定ポート
設定後、Webブラウザを開き、インターネットにアクセスできることを確認します。
Auto Scalingによって起動したEC2インスタンスにログインし、Squidのアクセスログ（/var/log/squid/access.log）を確認すると、WorkSpacesからのWebアクセスのログを確認できます。
構築手順は以上です。
#参考元
Forward Proxy と Reverse Proxy の決定的な違い
Squidでホワイトリストプロキシを作成する
HA構成プロキシ環境をNLBを使って構築してみる
#さいごに
Auto Scalingを使ったHA構成のプロキシの構築方法を紹介しました。
プロキシはWorkSpacesに限らず、インターネットアクセスが必要なインスタンスやコンテナを
運用するシーンでも役立ちますので、上手く活用していただければと思います。
今回はプロキシとしてSquidを使いましたが、BIG-IPやFortigateなどのネットワーク仮想アプライアンスを利用することも可能です。このあたりについては、次回以降の記事で取り上げたいと思います。