#はじめに
AWSの通信制御の仕組みとして「NACL (Network ACL)」と「セキュリティグループ」がありますが、自分の中で両者を混同しがちであったため、今一度整理すると共に、「ステートレス」、「ステートフル」の違いについて、実際に体験してみました。
#前提
まずはNACLとセキュリティグループの違いをまとめた表と検証を実施したAWSの構成図を以下に記載します。
| - | NACL | セキュリティグループ |
| 適用範囲 | サブネット単位 | インスタンス単位 |
| State | ステートレス(往路の通信は手動で制御) | ステートフル(往路の通信は動的に許可) |
| ルール | IN/OUTの通信に対し、許可/拒否のいずれも制御可能 | IN/OUTの通信に対し、許可のみ制御可能 |
#ping疎通確認によるステートレス/フルの違いについて
上記の構成でEC2インスタンスを2台構築し、双方のping疎通確認を通して、ステートレス/フルの違いを体験しました。以下の2パターンで検証をしましたのでひとつずつ整理していきます。
| パターン | 内容 |
| １ | セキュリティグループによるICMPの制御 ( NACLはIN／OUT共にすべてのトラフィックを許可 ) |
| ２ | NACLによるICMPの制御 ( セキュリティグループはIN／OUT共にすべてのトラフィックを許可 ) |
※ VPC内の通信において、NACLとセキュリティグループの双方で許可されたものが疎通可能になりますので、違いが分かりやすくなるよう、パターン1の場合はNACLを全許可、パターン2の場合はセキュリティグループを全許可しました。
###パターン1
NACL#1、2の設定を全許可し、Security group#1、2の設定でICMPの制御をした場合、EC2#1、2間のping疎通確認の結果は次の通りになりました。
No.1ではSecurity group#1、#2共にICMPの受信許可をしていないため、EC2#1からEC2#2に対してpingを打っても、EC2#2からEC2#1に対してpingを打っても応答はありませんでした。
順番が前後しますが、No.4ではSecurity group#1、2共に受信、送信でICMPの許可設定をしているため、EC2#1からEC2#2に対してpingを打っても、EC2#2からEC2#1に対してpingを打っても応答がありました。
セキュリティグループでの設定がステートフルであることが体験できたのはNo.2とNo.3の赤丸のところです。
No.2でEC2#1からEC2#2にpingを打った場合、Security group#1ではICMPの受信許可をしていないため、pingの戻りの通信は届かないかと思いましたが、結果は応答ありの○となりました。以上よりセキュティグループはステートフルであり、戻りの通信は動的に許可されることが体験できました。(No.3の赤丸も同様です。)
参考としてNo.2の場合のセキュリティグループの設定画面を置きます。
【Security group#1】
端末からのssh接続用のルールのみ設定
【Security group#2】
端末からのssh接続用のルールと、ping疎通用のルールを設定
###パターン2
セキュリティグループの設定を全許可し、NACL#1、2の設定でICMPの制御をした場合、EC2#1、2間のping疎通確認の結果は次の通りになりました。
NACLでの設定がステートレスであることが体験できたのはNo.2とNo.3の赤い×のところです。
No.2でEC2#1からEC2#2にpingを打った場合、NACL#1ではICMPの送信の許可はしているが、受信の許可をしていないため、pingの戻りの通信は届きませんでした。以上よりNACLはステートレスであり、往復の通信を許可するためにはNo.4のようにIN/OUT双方に許可設定をいれる必要があることが体験できました。
参考としてNo.2の場合のNACLの設定画面を置きます。
【NACL#1】
端末からのssh接続用のルールのみ設定
【NACL#2】
端末からのssh接続用のルールと、ping疎通用のルールを設定
#まとめ
今回、EC2インスタンス間のping疎通確認を通して、ステートレス/フルの違いを体験しました。最後に、実際に手を動かしてみて得られたことをまとめて終わります。
- セキュリティグループはステートフルであり、ping疎通確認の際、戻りの通信を許可していなくても応答を受け取れる。
- NACLはステートレスであり、ping疎通確認の際、戻りの通信も許可しないと応答は受け取れない。
以上、最後まで読んで頂きありがとうございました！