AWS LightsailにProxyを立ててみた

AWSのVPSサービスであるLightsailにSquidでProxyサーバを試験的に導入してみました。
AWSのLightsailは、OSの設定やアプリケーションのテンプレートを簡単に導入できるサービスとなります。

PoCの目的
構築環境
インスタンス作成
固定IP設定
DNSレコードの作成
FWルール作成
スナップショット作成
Squidの導入
Squidの設定
Squidコンフィグ
実測
まとめ

PoCの目的

今回のPoCの目的ですが、以下の目的でPoCを行いたいと思います。

AWS Lightsailの使用感を確かめてみる
Proxyの有無で回線速度の差異を確かめる
外部のProxyを建ててみたくなった(←これに尽きる)

企業等では、Proxyは外接の出口付近に置き、クライアントなどの通信ログを記録し、監視する。のが主だと思われますが、個人で通信ログをとっても面白くない(というか、fortigateでできている)ので、単純に外部に安全にProxyを建ててProxyの有無で回線速度がどの程度落ちるのかを確認したかったです。

構築環境

今回は、Proxyサーバの典型であるSquidをLightsailに導入します。
Lightsailは月額固定金額でOSを作成・管理ができるサービスとなります。
EC2だとEBSやVPC等の構成をある程度自由に設定することができますが、Lightsailでは選択肢が狭まり取れる構成が限られます。(逆に言えば、選択肢が狭まっているため、複雑な構成を取らずにシンプルな運用ができる。)

本環境で使用したLightsailのインスタンスは以下の通りとなります。

プラットフォーム : Linux/Unix
OS : Amazon Linux2
インスタンスプラン : $3.5 USD
CPU : 1vCPU
MEM : 512MB
Disk : 20GB SSD
Transfer : 1TB

検証目的のため、選択できる最低料金のインスタンスを選定しました。
EC2でいうところのT2.Micro的なインスタンスとなります。
OSについては、UbuntuやCentOS、BSD系も選べますが、Amazon基盤に最適化されているであろうAmazon Linuxを選択しました。

インスタンス作成

以下のリンクより、AWSのページに移動し、ログインします。
AWS Top : https://aws.amazon.com/jp/

サービスより、[コンピューティング]-[Lightsail]を選択します。

[インスタンス]-[インスタンスの作成]を選択します。

[リージョン]及び[アベイラビリティゾーン]を選択します。
本環境では、以下のリージョン及びAZを選択しました。

リージョン : 東京(ap-northeast-1)
AZ : ゾーンC(ap-northeast-1c)

[プラットフォームの選択]及び[設計図の選択]を選択します。
プラットフォームの選択では、Windows系かLinux/Unix系を選択できます。
設計図については、OS+アプリケーションのセット及び、OS単体を選択できます。
Squidについては、AWS側で用意がないアプリケーションのため、OSのみを選択することで自由にアプリケーションを構築できます。
本環境では、以下の選択をしました。

プラットフォーム : Linux/Unix
設計図の選択 : OSのみ
OS : Amazon Linux2 (2.0.20200917.0)

インスタンスの初回起動時のスクリプトは設定していません。
SSHキーペアマネージャーより、[新規作成]を選択します。(既存のキーペアと共有で問題がない場合は、既存で作成したキーペアで問題ありません。)

[SSHキーペアリージョン]では、東京の全てのゾーンで利用可能なキーペアが作成されます。

[新規SSHキーペアの作成]より、キーペアの名前を入力し、[キーペアの生成]を選択します。

[キーペアが作成されました]より、[キーのダウンロード]を選択し、キーをダウンロードします。
本キーペアは一度のみダウンロード可能であり、このキーペアがなくなるとSSHができなくなるため、大切に保管するのと外部に流出しないように適切なアクセス権限を設定してください。

[インスタンスプランの作成]より、作成するインスタンスを選択します。
本環境は検証環境のため、一番安い$3.5USDのインスタンスを選択しています。
また、このインスタンスは720時間分の料金は無料となっております。

[インスタンスを確認]より、インスタンスの名前を設定します。
本環境では、[willsv_proxy]と設定しました。
インスタンスの名前は完全に自由に設定できるわけではなく、特定のワードのみのインスタンス名は作成できませんでした。
(Proxyなので、proxyと名前を入力したところ、弾かれました。)
インスタンスの名前を入力したら[インスタンスの作成]を選択します。

インスタンスより、作成したインスタンスが[実行中]となっていいれば、インスタンスの作成は完了です。

固定IP設定

インスタンスの作成が完了したため、インスタンスのネットワーク周りの設定を行っていきます。
作成したインスタンスには、グローバルIPがついており、このグローバルIPに対するDNSレコードを作成することで、FQDNでサーバの名前解決ができます。
しかし、このインスタンスについているグローバルIPは、再起動やインスタンスを削除する際に変更されてしまう可能性があるため、グローバルIPを持つネットワークアダプタを作成し、インスタンスに紐づける作業を行うことで、グローバルIPを固定化することができます。(EC2でいうところのElastic IP)

[ネットワーキング]-[静的IPの作成]を選択します。

[静的IPロケーション]では、[東京、すべてのゾーン(a–northeast-1)]とします。
[インスタンスへのアタッチ]より、作成したインスタンスを選択します。

[静的IPの指定]より、静的IPを持たせるネットワークアダプタの名前を入力し、[作成]を選択します。
Lightsailでは、5IPまでインスタンスにアタッチしている間は無料となります。
また、このネットワークアダプタを別のインスタンスに付け替えることで、DNSの変更を行わずに、待機系や別の系統のシステムに切り替えることができます。

作成が完了すると、割り当てられたグローバルIPアドレスと、アタッチしたインスタンスが表示されます。

DNSレコードの作成

本作業は必須ではないですが、固定のグローバルIPを設定したついでに、DNSのレコードも作成し、FQDNでProxyを引けるように設定します。
本設定を行うには、ドメインを取得する必要があります。また、本環境ではAWSのR53でDNSのレコードを設定します。(ドメインのレコードについては、取得したドメインを管理するレジストラにより設定が異なります。)

[AWSコンソール]より、[Route 53]-[ホストゾーン]-[レコードを作成]を選択します。

[ルーティングポリシー]より、[シンプルルーティング]を選択します。
本環境は検証のProxy環境のためシンプルルーティングを選択しています。Webサーバやアプリケーションサーバで作成する場合は、トラフィック量やルーティングポリシーにより最適な構成を選択してください。

[レコードを設定]-[シンプルなレコードを定義]を選択します。

レコード設定は以下の通り設定しました。

レコード名 : proxy
値 : レコードタイプに応じたIPアドレスまたは別の値
トラフィックのルーティング先 : インスタンスで設定したグローバルIPアドレス
レコードタイプ : A – IPv4アドレスと一部のAWSリソースにトラフィックをルーティングします。
TTL : 300秒

レコードの定義が完了したら、[レコードを作成]を選択します。

Route 53のホストソーンより、作成したレコードが作成されていることを確認します。
DNSレコードは、レジストラのネームサーバ次第ですが、基本的に24時間から48時間で末端まで伝達すると思われます。(AWSのRoute53は伝達が早いので30分もかからず伝達します。)

クライアント端末より、nslookupなどで、名前解決ができることを確認します。
自宅内のDNSサーバへ伝達するのに時間がかかっていたため、1.1.1.1のDNSサーバに問い合わせを行いました。

FWルール作成

現時点で、インスタンスの作成とDNSの名前解決ができました。
次に、インスタンスの接続とProxyが利用できるようにFirewallの設定を行います。
Lightsailでは、インスタンスを作成すると、デフォルトでSSHやHTTP、RDPなどのポートが開いています。
デフォルトのルールは甘いので、必要なFirewallルールを作成します。
[インスタンス]-[ファイアウォール]より、デフォルトのルールを削除します。

[ルールの追加]より、以下のルールを設定します。(Firewallルールについては、必要に応じて設定してください。)

アプリケーション : ICMP
- プロトコル : ICMP
- 制限 : 任意のアドレス
アプリケーション : SSH
- プロトコル : TCP
- ポート : 22
- 制限 : 自宅環境のグローバルIPアドレス
アプリケーション : カスタム
- プロトコル : TCP
- ポート : 3128
- 制限 : 自宅環境のグローバルIPアドレス

制限の部分については、接続元のIPアドレスを確認し、設定してください。
また、本環境ではProxyがデフォルトポートの3128を使用するため、TCP/3128も開けてください。
Proxyが使用するポートの制限では、必ず接続元のIPアドレスを制限しいてください。
制限を行わない設定を行うと、オープンなProxyサーバとなり不特定多数の方から勝手に利用される恐れがあります。

スナップショット作成

インスタンスに手を加える前にインスタンスのスナップショットを取得して、構築や変更作業に失敗した場合のバックアップを取得しておきます。
スナップショットを取得する際は、インスタンスを停止して完全な静止点をもってスナップショットを取得するのが理想ですが、デフォルトから手を加えていないため、今回は稼働中のスナップショットを取得します。

[インスタンス]-[スナップショット]-[手動スナップショット]-[スナップショットの作成]より、スナップショット名を入力します。今回はデフォルトの名前にして取得しました。

スナップショットが作成されました。
AWSのスナップショットは、タスクがPendingになったら取得ができているため、元のインスタンスに変更を加えても問題ありません。

Squidの導入

Lightsailでのインスタンス作成と諸々設定が完了したため、本編に戻り、Proxyサーバを構築していきたいと思います。
インスタンスのグローバルIPに対し、SSHを行います。
AWSのインスタンスにSSHをする際は、公開鍵認証を使用します。
前項でダウンロードした秘密鍵を使用し、以下のユーザでログインします。
ユーザ : ec2-uuser

インスタンスにSSHができたら、以下コマンドでOSのアップデートを実施します。

sudo yum -y update

OSのアップデートが完了したら、ProxyサーバであるSquidを以下のコマンドでインストールしていきます。

sudo yum -y install squid

YUMでインストールされたSquidのバージョンは以下のコマンドで確認できます。
2020年11月時点で以下のバージョンでした。

yum list | grep squid
squid.x86_64                           7:3.5.20-17.amzn2.4.1         @amzn2-core

Squidの設定

Proxyサーバの目的ですが、出口をAWS上に向けるだけなので、設定自体はシンプルです。
Squidの設定ファイルは以下のパスにあるため、オリジナルの設定をバックアップをして、編集しましょう。
Squid設定ファイル : /etc/squid/squid.conf

sudo cp -a /etc/squid/squid.conf /etc/squid/squid.conf.org

Amazon LinuxでEC2-UserでSSHすると一般ユーザでログインされるため、root権限が必要な操作にはsudoをつけましょう。
通常のProxyとして動作させるため、最低限の設定をしていきます。

ACLでネットワークの定義
ルールの設定
ポートの設定

sudo vi /etc/squid/squid.conf

初めに、ACLでネットワークを定義します。
ACLでの定義方法は以下のような形式になります。

acl <ACL名> src/dst/domain/port xxx.xxx.xxx.xxx/32

ACL名の部分はACLを識別するための任意の名前を設定します。
src/dst/domain/portについては、送信元NW/宛先/NW/宛先ドメイン名/ポート番号の識別子を指定します。
そして、制御を行うネットワークアドレスやドメイン名、ポート番号を記載します。

次に、ルールを記載します。

http_access allow/deny <ACL名>

ルールについては、前述したACLを許可するか、拒否するのか？を記載します。
Squidについては、設定の上位から評価を行い、ルールに合致したら評価が終わります。

最後にポートの指定をします。

# Squid normally listens to port 3128
http_port 3128

ここのポート番号を変更することで、Squidで使用するポートを変更できます。
Proxyのポートだと8080ポートを使用する企業様が多いような気がします。
また、このポートを変更した場合、AWS側のFirewallルールの変更もお願いします。
設定が完了したら、以下のコマンドでSquidサービスを再起動し、コンフィグを適用させます。
ついでに、サービスの自動起動も設定しておきます。

sudo systemctl restart squid
sudo systemctl enable squid

Squidコンフィグ

今回、使用したコンフィグファイルをここに記載しておきます。
一部IPアドレスなどが入っているため、IPアドレスの部分については、伏せてあります。

#
# 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
#外部からのアクセスのため、クライアント側のグローバルIPアドレスを設定しています。
acl 117_Network src 117.xxx.xxx.xxx/32
acl 203_Network src 203.xxx.xxx.xxx/32

acl SSL_ports port 443
acl Safe_ports port 80          # http
#acl Safe_ports port 21         # ftp
acl Safe_ports port 443         # https
#acl Safe_ports port 70         # gopher
#acl Safe_ports port 210                # wais
acl Safe_ports port 1025-65535  # unregistered ports
#acl Safe_ports port 280                # http-mgmt
#acl Safe_ports port 488                # gss-http
#acl Safe_ports port 591                # filemaker
#acl Safe_ports port 777                # multiling http
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

#My rule
#今回定義したルール
http_access allow 117_Network
http_access allow 203_Network


# And finally deny all other access to this proxy
#すべてのアクセス拒否ルール
http_access deny all

# Squid normally listens to port 3128
#Squidで使用するポート番号
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

実測

クライアントマシンにProxyの設定を行い、Speed Testを実施しました。

Squid設定前

こちらは、エンドの出口が自宅のグローバルIPアドレスとなっており、700Mbps程度速度が出ています。

Squid設定後

Squidの設定後は、アクセスしたIPアドレスがAWS側のアドレスとなっており、クライアント→GW→Proxyサーバ経由でアクセスできていることが確認できます。
また、Proxy経由でアクセスすると、回線速度が1/9程度になっていることが確認できました。
これについては、Lightsail側のどの要素でボトルネックになっているかまでは確認できていませんが、少なくとも簡易的なProxyを経由するとかなり速度が落ちることが確認できました。

まとめ

外部にProxyを経由されるとインターネットの回線速度が大幅に低下した。
主な原因としては、Proxyを外部に設置していること、インスタンスタイプが小さいことなどがあげられます。
しかし、AWSのEC2とは違い、簡単にOSや設定ができるLightsailは検証に非常に便利であることが確認できた。
EC2やVPCの設定をするとどうしてもコストが多くなることから、簡易的な検証であればEC2ではなくLightsailを用いることで検証の敷居を下げることが可能になると思われる。