【AWS】用語を整理しながら学ぶAWS - part4 VPC構築編-2

# はじめに

この記事では AWS Cloud Tech を通して VPC を学習して実践していく記事です。
主な内容としては実践したときのメモを中心に書きます。（忘れやすいことなど）
誤りなどがあれば書き直していく予定です。

## 前回のまでの VPC

[【AWS】用語を整理しながら学ぶ AWS - part4 VPC 構築編-1](https://qiita.com/ymd65536/items/8b1310b8d7a27dce9402)

VPC とはなにか、IP アドレスの計算方法、パブリックサブネットをハンズオンで構築までやりました。

## プライベートサブネット を構築しよう

前回同様に
コンソール画面の左側から サブネット を選択する。

![console_menu.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/527543/1aff0625-1c1c-9269-7d25-528f4678b520.jpeg)

## サブネットを切ろう

「PrivateSubnetA」という名前でプライベートサブネットを切ろう。

![private_subnet_1.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/527543/fe827727-ed62-48e3-be6a-d94780faa921.jpeg)

サブネット名：PrivateSubnetA
アベイラビリティゾーン：ap-northeast-1a
IPv4 CIDR ブロック：10.0.2.0/24

同様に 1c も作成

![private_subnet_2.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/527543/155b2012-33d1-5d8e-e5c1-b238f64d0dcb.jpeg)

サブネット名：PrivateSubnetC
アベイラビリティゾーン：ap-northeast-1C
IPv4 CIDR ブロック：10.0.4.0/24

※ファシリティやアベイラビリティゾーンの説明は[ここに書きました](https://qiita.com/ymd65536/items/506a0aa34f5fbc87c2c3)

※サブネットは VPC の範囲内で作成すること。

## プライベートサブネットの用途

基本的にはインターネットにさらしたくない情報をここに置く。
オンプレミスな環境だと社内 Web や DB を置く場所

ただ、インターネットに接続できないと各種ミドルウェア
DB サーバを構築するにはソフトウェアをインストールする必要がある。

サーバを納品していた時代はキッティングのタイミングで
インターネットに接続して必要なソフトウェアをすべてインストールして
お客様先に納品する。

この場合だと納品時の最新バージョンしかインストールされない為

- レガシー化待ったなし
- 調達時のリードタイム増加
- 納品後のメンテナンス工数の増加

などなどリスクや非効率なことが待ち受ける。

## プライベートサブネットをインターネットに接続するには

前述の欠点を補う為には
IP アドレスを変換する NAT を活用することで
プライベートサブネット上の装置をインターネットに接続できる。

## NAT とは

[【AWS】用語を整理しながら学ぶ AWS - part3](https://qiita.com/ymd65536/items/8e3d75c98f0630090281) で解説済みですが復習です。

> NetworkAddressTranslation の略です。
> 要はアドレスの読み替えです。
> よく、インフラエンジニアのお姉さんに
> NAPT のことを NAT だと注意されましたが
> 実際のところ、近年ではどちらでも構わないということ

> ただし、参考図書にもあるように
> ポート変換も含めてアドレスを変換する場合は
> NAPT(IP マスカレード)と呼んだほうが正確です。

## VPC 上で NAT を使うには

ざっくり
NAT ゲートウェイと NAT インスタンスのどちらか一方を利用することで NAT が実現できます。

## NAT インスタンス

NAT をかけてくれる EC インスタンスです。
性能は EC2 インスタンスの性能に依存します。

## NAT ゲートウェイ

NAT 専用に構築された仮想的なコンポーネント
（ん？なにやら難しいカタカナが出てきた）
利用料金は
時間当たりと転送バイトの転送量(ギガバイトあたり)で決まる。

## インスタンスとゲートウェイの違い

[細かいところはこちらに書いてあります。](https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/vpc-nat-comparison.html)

## どちらの NAT を使うべきか

今回は 1 時的な利用であるため
NAT ゲートウェイのほうが良い。

NAT インスタンスの実態は EC2 になる為
EC2 インスタンスの数が 1 つ増えりことと変わらないので
その分、管理工数がかかる。


## NAT ゲートウェイを利用

### ElasticIP アドレスを取得

NAT ゲートウェイを構築するには ElasticIP アドレスが必要
VPC の画面を開き、左のコンソールから ElasticIP を選択

![console_menu2.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/527543/50811e55-fedd-9844-4030-c3eb06ce8840.jpeg)

オレンジのボタン「Elastic IP アドレスの割り当て」をクリック

![elastic_ip_1.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/527543/5854741c-c173-f53e-4446-7e40b6662108.jpeg)

「割り当て」をクリック

![elastic_ip_2.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/527543/f5c0e1bf-db63-4802-ce7a-c6a2bfde5c86.jpeg)

### NAT ゲートウェイを構築

Elastic IP を構築したので NAT ゲートウェイを構築

![nat_gw.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/527543/500bfa94-4d30-ebf6-42cb-818245158882.jpeg)


### 内部ネットワークにサーバを構築

今回は NAT を体感してもらう為に
内部ネットワークに EC2 でサーバを構築してサーバに SSH でログインする。

サーバの仕様
インスタンスタイプ：t2.micro
プライベート IP アドレス：10.0.2.108

秘密鍵を作成したらパブリックサブネットにある Web サーバに秘密鍵を SFTP や SCP で送る。

### チョットしたポイント

今回は秘密鍵利用の SSH を利用して EC2 に接続を行いますが
AWS には「AWS SSM」というサービスがあり
AWS コンソール上で SSH のようなことができるというモノがある。

今回の場合はそもそも SSM を利用してあげれば
秘密鍵の作成は一切不要になり、鍵の管理から解放される。

### Web サーバを利用して内部ネットワークサーバに SSH 接続

今回は Web サーバを踏み台にして 内部ネットワークのサーバに秘密鍵を用いた SSH 接続を行い
実際に NAT でサーバをインターネットに接続できているかを確認する。

まず、転送した秘密鍵のアクセス権限を変更する。
今回は秘密鍵作成時に鍵の名前を rails-db01 とした。

```shell

[ec2-user@ip-10-0-1-206 ~]$ ls
rails-db01.pem
[ec2-user@ip-10-0-1-206 ~]$ ls -la
total 16
drwx------ 3 ec2-user ec2-user   96 Feb 17 11:07 .
drwxr-xr-x 3 root     root       22 Feb 17 10:51 ..
-rw-r--r-- 1 ec2-user ec2-user   18 Jul 15  2020 .bash_logout
-rw-r--r-- 1 ec2-user ec2-user  193 Jul 15  2020 .bash_profile
-rw-r--r-- 1 ec2-user ec2-user  231 Jul 15  2020 .bashrc
-rw-r--r-- 1 ec2-user ec2-user 1674 Feb 14 04:41 rails-db01.pem
drwx------ 2 ec2-user ec2-user   29 Feb 17 10:51 .ssh
[ec2-user@ip-10-0-1-206 ~]$ chmod 400 rails-db01.pem
[ec2-user@ip-10-0-1-206 ~]$
[ec2-user@ip-10-0-1-206 ~]$
[ec2-user@ip-10-0-1-206 ~]$ ls -la
total 16
drwx------ 3 ec2-user ec2-user   96 Feb 17 11:07 .
drwxr-xr-x 3 root     root       22 Feb 17 10:51 ..
-rw-r--r-- 1 ec2-user ec2-user   18 Jul 15  2020 .bash_logout
-rw-r--r-- 1 ec2-user ec2-user  193 Jul 15  2020 .bash_profile
-rw-r--r-- 1 ec2-user ec2-user  231 Jul 15  2020 .bashrc
-r-------- 1 ec2-user ec2-user 1674 Feb 14 04:41 rails-db01.pem
drwx------ 2 ec2-user ec2-user   29 Feb 17 10:51 .ssh
[ec2-user@ip-10-0-1-206 ~]$

```

秘密鍵の権限を変更したので
この秘密鍵を利用して実際に SSH 接続を行う。

```shell
[ec2-user@ip-10-0-1-206 ~]$
[ec2-user@ip-10-0-1-206 ~]$ ssh -i rails-db01.pem ec2-user@10.0.2.108
The authenticity of host '10.0.2.108 (10.0.2.108)' can't be established.
ECDSA key fingerprint is SHA256:oVaNlTdsZJrOxihBSCWilDrn5troffqKRxel6hQGCSQ.
ECDSA key fingerprint is MD5:eb:2a:e4:10:10:aa:95:d5:ae:fa:e2:aa:44:aa:a7:86.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.0.2.108' (ECDSA) to the list of known hosts.

       __|  __|_  )
       _|  (     /   Amazon Linux 2 AMI
      ___|\___|___|

https://aws.amazon.com/amazon-linux-2/
[ec2-user@ip-10-0-2-108 ~]$

```

### NAT ゲートウェイの検証その前に

内部ネットワークのサーバが意図して外部に接続されていないか
PC から SSH で接続を試みてみよう。
この時点で接続できるようであれば、内部ネットワークの EC2 に紐づいている
セキュリティグループにポート 22 番で 0.0.0.0/0 のアドレスが記録されていないか確認しましょう。

### NAT ゲートウェイの検証

内部サーバから外部に向かって通信してみる。
手っ取り早い確認方法としては nslookup でよく知るインターネット上のサーバドメインをひっかけてみる。

```shell

[ec2-user@ip-10-0-2-108 ~]$ nslookup kddi.com
Server:         10.0.0.2
Address:        10.0.0.2#53

Non-authoritative answer:
Name:   kddi.com
Address: 175.129.0.103
Name:   kddi.com
Address: 2001:268:fa03:500:175:129:0:103

[ec2-user@ip-10-0-2-108 ~]$
[ec2-user@ip-10-0-2-108 ~]$ nslookup google.com
Server:         10.0.0.2
Address:        10.0.0.2#53

Non-authoritative answer:
Name:   google.com
Address: 172.217.26.14
Name:   google.com
Address: 2404:6800:4004:812::200e

[ec2-user@ip-10-0-2-108 ~]$

```

どうやら問題なく接続できているみたい。

## 今回の大事なところ

外部ネットワークからはデータのダウンロードを行うが
外部ネットワークから PrivateSubnetA にあるサーバへの SSH ログインは許可しない。

Web サーバを踏み台にして SSH ログインする場合は VPC 内のネットワークから SSH ログインすることになるので
外部ネットワークからの SSH ログインにはならない。

ここで踏み台を利用して SSH ログインできない場合は

- 内部ネットワークのセキュリティグループの設定
- 異なるキーペアで接続を試みようとしている
- NAT が作成できていない

上記の 3 点を見直してみることでおおよそ解決する。

## おわり