はじめに
最近弊社は4月5月と新人のJOINラッシュです。
この機会に乗じて、検証環境のパブリックサブネットにNATインスタンスを構築して、パブリックサブネットに直にEC2を構築しなくてもいいようにしていこうと思います。
【参考】
・NAT ゲートウェイと NAT インスタンスの比較
構成図
ハンズオン
構築のながれ
1.EC2(NAT)インスタンス構築（マネジメントコンソール）
2.EC2(NAT)インスタンスの設定（SSH接続）
3.EC2（クライアント）インスタンス構築（マネジメントコンソール）
4.プライベートサブネットでの設定（マネジメントコンソール）
1. EC2(NAT)インスタンス構築（マネジメントコンソール）
1.1.NATインスタンスをセットアップ
Amazon Web Services (AWS) アカウントにログインし、下記設定値のEC2インスタンスを作成。
| 項目 | 設定値 |
|---|---|
| インスタンスタイプ | t2.micro |
| AMI ID | ami-0df2ca8a354185e1e(Amazon Linux) |
| サブネット | パブリックサブネット |
| パブリック IP の自動割り当て | ◯ |
1.2. セキュリティグループの設定
インスタンス作成時にセキュリティグループを設定し、プライベートサブネットのCIDRとポート22（SSH）を、自身のIPアドレスからのアクセスに開放。
【インバウンド】
| タイプ | プロトコル | ポート範囲 | ソース | CIDR |
|---|---|---|---|---|
| すべてのトラフィック | すべて | すべて | カスタム | 【プライベートサブネットCIDR】 |
| SSH | TCP | 22 | マイIP | 【自身のIP】 |
【アウトバウンド】
| タイプ | プロトコル | ポート範囲 | ソース | CIDR |
|---|---|---|---|---|
| すべてのトラフィック | すべて | すべて | カスタム | 0.0.0.0/0 |
1.3. IAMロールの設定
SSMよるフリートマネージャよりアクセスも出来るように作成
| 許可ポリシー | タイプ |
|---|---|
| AmazonSSMManagedInstanceCore | AWS 管理 |
1.4. 送信元/送信先チェックを無効設定
1.4.1.及び1.2の設定後、EC2インスタンス作成。
1.4.2. 『作成されたEC2をチェック』 → 『アクション』 → 『ネットワーキング』 → 『ソース/宛先チェック変更』
1.4.3.送信元/送信先チェックを無効
送信元/送信先チェックが有効な場合、NATインスタンスは自身のIPアドレス以外のIPアドレスを持つトラフィックを転送することが出来ない(破棄してしまう)。
NATインスタンスは、プライベートサブネットのインスタンスからのトラフィックを転送する機能のため、チェックを無効にして正しく機能するようにするための設定。
2.EC2(NAT)インスタンスの設定（SSH接続）
2.1.IP フォワーディングを有効化
IPフォワーディングとは、ネットワークインターフェイスを通じて受信したパケットを、別のネットワークインターフェイスに転送を許可すること。
sudo sysctl -w net.ipv4.ip_forward=12.1.2.設定を永続化するために、/etc/sysctl.conf ファイルに以下行を追加
echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.conf2.1.3.Iptablesの設定を変更して、NATを有効化
sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE2.1.4.Iptablesの設定を永続化するため、以下のコマンドを実行
sudo sh -c 'iptables-save > /etc/sysconfig/iptables'2.1.5.インスタンスを再起動して、設定が正しく適用されていることを確認
sudo reboot2.1.6.Iptablesの中身を確認
・IPフォワーディングが有効になっているかの確認
sysctl -n net.ipv4.ip_forward
#下記レスポンスが返ってくるなら有効
1
POSTROUTING チェーン(Iptablesの適用ルールの1つ)に MASQUERADE ターゲット(送信元IPをNATインスタンスのパブリックIPに変更するという意味)が設定されていることで、NAT機能が実現されている。
sudo iptables -t nat --list
#下記レスポンスが返ってくるなら有効
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE all -- anywhere anywhere
3.EC2（クライアント）インスタンス構築（マネジメントコンソール）
3.1. EC2インスタンス作成
Amazon Web Services (AWS) アカウントにログインし、下記設定値のEC2インスタンスを作成。
| 項目 | 設定値 |
|---|---|
| インスタンスタイプ | t2.micro |
| AMI ID | ami-0f6816cbdffbdde6c(windows) |
| サブネット | プライベートサブネット |
3.2. セキュリティグループの設定
インスタンス作成時にセキュリティグループを設定し、インバウンドはなしとする。
【インバウンド】
| タイプ | プロトコル | ポート範囲 | ソース | CIDR |
|---|---|---|---|---|
| すべてのトラフィック | すべて | すべて | カスタム | 【自身のVPC CIDR】 |
【アウトバウンド】
| タイプ | プロトコル | ポート範囲 | ソース | CIDR |
|---|---|---|---|---|
| すべてのトラフィック | すべて | すべて | カスタム | 0.0.0.0/0 |
3.3. IAMロール(既に1.3.で作成しているものをEC2にアタッチする)
SSMよるフリートマネージャよりアクセスも出来るように作成
| 許可ポリシー | タイプ |
|---|---|
| AmazonSSMManagedInstanceCore | AWS 管理 |
4.プライベートサブネットでの設定（マネジメントコンソール）
4.1.ルートテーブルの関連付けを編集
『VPC』 → 『ルート』 → 『ルートを編集』
4.2.ルートを編集
送信先を『0.0.0.0/0』 → 『手順1.で作成したインスタンス』をターゲットにして保存
挙動の確認
1. AWS SystemsManager の フリートマネージャーからアクセス
1.1.フリートマネージャーからリモートデスクトップ(RDP)を選択
『AWS SystemsManager』 → 『フリートマネージャー』 → 『ノードアクション』 → 『リモートデスクトップ（RDP）との接続』を押下
※個人の環境の影響になるかと思いますが、自分はフリートマネージャーの画面にEC2が反映されるまで10分程度かかりました。
1.2.フリートマネージャーからリモートデスクトップ(RDP)でアクセス
1.3.リモートデスクトップ(RDP)先から、インターネットへアクセスできる
さいごに
新入社員のためという出汁をもとに、こってり構築させてもらいました。
t2.microにしてしまったのは失敗だったかもしれません、スムーズな検証をするとなるとサイズを変えないと実際には耐えられないですね。
GW中に再調整して、GW明けてから利用できるような感じに整えていこうかと思います。