CloudFront+ELB+EC2+RDSのスケーラブルなシステム構成構築 – 2.NAT構築編

プライベートサブネットからインターネットへ出るために

アプリケーションサーバ(EC2)をプライベートサブネットに置くと、yum updateや、パッケージのダウンロード等でインターネットに出ていくことができません。
そこで、プライベートサブネットのEC2インスタンスをインターネットと通信させるために、NATインスタンスをパブリックサブネットに設置し、NAT経由で外部でに出れるようにします。

NAT用セキュリティグループの設定

踏み台・NATサーバ用(sg-ssh-nat)セキュリティグループに以下を追加します。

Inbound

Type Protocol Port Source
HTTP(80) TCP(6) 80 ap server のセキュリティグループ
HTTPS(443) TCP(6) 443 ap server のセキュリティグループ
全てのICMP -IPv4 ICMP(1) 全て ap server のセキュリティグループ
カスタムTCPルール* TCP(6) 587 ap server のセキュリティグループ

ここで注意することとして、サイトからお問い合わせフォーム入力時などのメール送信する場合は、ポート587(又は465)もNATしてあげる必要があります。その場合は踏み台・NATサーバは常時立ち上げておく必要があります。

 NATインスタンスの作成

AMIからインスタンスを立ち上げる

AWSのサイトによると、以下のようにNATインスタンスとして設定されたAMIが用意されているようです。

Amazon では、NAT インスタンスとして実行されるように設定された Amazon Linux AMI を提供しています。これらの AMI の名前には文字列 amzn-ami-vpc-nat が含まれているので、Amazon EC2 コンソールで検索できます。NAT AMI からインスタンスを起動すると、次の設定がインスタンスで発生します。

  • IPv4 転送が有効になり、ICMP リダイレクトが /etc/sysctl.d/10-nat-settings.conf で無効になります
  • /usr/sbin/configure-pat.sh にあるスクリプトが起動時に実行され、iptables IP マスカレードが設定されます

このAMIでNATインスタンスを作成します。また、このインスタンスは踏み台サーバとしても利用します。
AMI選択画面で「amzn-ami-vpc-nat 2017(現在の西暦)」を検索して一番新しいAMIを選択して、インスタンスを立ち上げます。

今回作成したVPCを設定し、サブネットは Availability Zone ap-northeast-1a のパブリックサブネット「public-subnet-front1」を指定します。

送信元/送信先チェックを無効にする

AWSのサイトによると、以下の理由によりインスタンスの「送信元/送信先チェック」を無効にする必要があります。

EC2 インスタンスは、送信元/送信先チェックをデフォルトで実行します。つまり、そのインスタンスは、そのインスタンスが送受信する任意のトラフィックの送信元または送信先である必要があります。しかし、NAT インスタンスは、送信元または送信先がそのインスタンスでないときにも、トラフィックを送受信できなければなりません。したがって、NAT インスタンスでは送信元/送信先チェックを無効にする必要があります。

このNATインスタンスには、外部からアクセスしますのでEIPを割り当て、Route53のDNSレコードに追加しておきます。

アプリケーションサブネット用 Route Table への追加設定

アプリケーションサブネット用 Route Table へ、インターネット向け通信(0.0.0.0/0)をNATサーバのインスタンスへ向ける「ルート」を追加します。

NAT接続する側のインスタンス(アプリケーションサーバ)作成

NATサーバに接続する側のアプリケーションサーバのインスタンスを作成します。
今回作成したVPCを設定し、サブネットは Availability Zone ap-northeast-1a のプライベートサブネット「private-subnet-ap1」を指定します。

アプリケーションサーバは「KUSANAGI」で構築しますが、ここでは構築手順は割愛します。以下の記事にてKUSANAGIでアプリケーションサーバ構築の手順を記載しています。

超高速WordPress仮想マシンKUSANAGI環境構築

WordPressをKUSANAGIに移設し併せて常時SSL化する

NAT経由での外部接続の確認

アプリケーションサーバのインスタンスが作成できたら、NATインスタンスを経由して外部のインターネットにアクセスができるか確認します。

ここで、アプリケーションサーバはプライベートサブネットに設置しているため、ローカルPCから直接ログインできません。
AWSコンソール画面で発行したキーペア( *****.pem )をWinSCP等で踏み台/NATサーバに転送し、以下のコマンドでアプリケーションサーバへログインします。(pemファイルのパーミッションは600にしておく)

$ ssh -i *****.pem centos@10.0.100.214

__ ____ _______ ___ _ _____ __________
/ //_/ / / / ___// | / | / / | / ____/ _/
/ ,< / / / /\__ \/ /| | / |/ / /| |/ / __ / /
/ /| / /_/ /___/ / ___ |/ /| / ___ / /_/ // /
/_/ |_\____//____/_/ |_/_/ |_/_/ |_\____/___/

Version 7.8.3, Powered by Prime Strategy.

[centos@ip-10-0-100-214 ~]$

踏み台サーバから無事アプリケーションサーバにログインできました。

では、プライベートサブネットに設置されたアプリケーションサーバから、外部インターネットへアクセスできるか確かめます。

ping を打ってみます。


$ ping google.co.jp
PING google.co.jp (172.217.24.131) 56(84) bytes of data.
64 bytes from nrt20s01-in-f3.1e100.net (172.217.24.131): icmp_seq=1 ttl=52 time=1.88 ms
64 bytes from nrt20s01-in-f131.1e100.net (172.217.24.131): icmp_seq=2 ttl=52 time=2.08 ms
64 bytes from syd09s06-in-f3.1e100.net (172.217.24.131): icmp_seq=3 ttl=52 time=2.10 ms
^C
--- google.co.jp ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 1.883/2.025/2.107/0.100 ms

ping通りました。次に curl で Webページを取得します。


$ curl https://kusanagi.tokyo/character/
<!DOCTYPE html>
<html lang="ja" class="no-js">
<head>
<meta charset="UTF-8" />;
<meta name="viewport" content="width=device-width,initial-scale=1.0" />
<link rel="profile" href="http://gmpg.org/xfn/11" //>
<link rel="pingback" href="https://kusanagi.tokyo/xmlrpc.php" //>
<!--[if lte IE 9]/>
<script type="text/javascript" src="https://kusanagi.tokyo/wp-content/themes/kusanagi/js/ie-polyfill.min.js"&gt;&lt;/script/>
<link rel="stylesheet" id="ie-style-css" href="https://kusanagi.tokyo/wp-content/themes/kusanagi/ie-style.css" type="text/css" media="all" //>
<![endif]--/>
<meta property="og:type" content="website" //>
<meta property="og:site_name" content="KUSANAGI" //>
<meta property="og:description" content="超高速WordPress仮想マシン [高速化チューニング済みWordPressサーバ]" //>
(以下略)

curl で Webページも取得できました。プライベートサブネットに設置されたアプリケーションサーバから、NATインスタンスを経由して外部のインターネットにアクセスができるか確認するこができました。

踏み台サーバからのパスフレーズなしログイン

AWSコンソール画面で発行したキーペア( *****.pem )をサーバに置いておくのは気になるので、ログイン方法を変更します。

まず、SSH接続元サーバにて以下のコマンドで秘密鍵と公開鍵を生成します。


$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/ec2-user/.ssh/id_rsa): ←(エンターだけ)
Enter passphrase (empty for no passphrase): ←(エンターだけ)
Enter same passphrase again: ←(エンターだけ)
Your identification has been saved in /home/ec2-user/.ssh/id_rsa.
Your public key has been saved in /home/ec2-user/.ssh/id_rsa.pub.
The key fingerprint is:
(省略)
The key's randomart image is:
+--[ RSA 2048]----+
(省略)

SSH接続元(踏み台サーバ)の~/.ssh に秘密鍵「id_rsa」と公開鍵「id_rsa.pub」が作成されましたので、公開鍵「id_rsa.pub」の内容をSSH接続先(アプリケーションサーバ)アカウントの~/.sshにある「authorized_keys」ファイルにコピーします。
これで、パスフレーズなしに踏み台サーバからアプリケーションサーバへパスフレーズなしにログインが可能になりました。

アプリケーションサーバにSSH接続するコマンドを簡単にするには、~/.ssh/config というファイルを下記の内容で作成しておきます。ファイルのパーミッションは「600」にしておいてください。


Host ap-a
Hostname 10.0.xxx.xxx
User centos
IdentityFile ~/.ssh/id_rsa

この設定により「ssh ap-a」を打つだけでアプリケーションサーバに接続できるようになります。

以下の記事に続きます。

CloudFront+ELB+EC2+RDSのスケーラブルなシステム構成構築 – 3.ELB構築編

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

  • ad