當請求想進出在 Private Subnet 內的 EC2 時,會遇到 Subnet 階層的保護工具 NACL(Network Access Control List),它用於規範何種請求可以進出此Subnet,如下圖。
當成功通過 NACL 的規範之後,請求可以繼續往裡面走,但在碰到EC2前,還會遇到 EC2 Instance 階層的保護 SG(Security Group),是一類似防火牆規範的工具,請求必須通過此規範,才能進到EC2。而當請求要離開 EC2 時,會再次受到 SG 的驗證,再原路返回送出此請求的來源。
然而實際上,請求離開 SG 時不需再驗證一次。因為 SG 是一個 stateful 的工具,所以它記得該請求從哪來且自己允許過該請求進來,離開時便不會再驗證一次,是一個重要的特性,須謹記。
相反地,若從「EC2 發出請求」的角度來看,當網路請求要從EC2出去時,第一層會遇到 SG,只有獲得 SG 允許,請求才能順利通過,再來第二層會遇到 NACL,一樣必須獲得 NACL 允許,才能真的出去,最後到達目的地 IP(如下圖橘色實線所示)。
之後原路返回時, 先遇到 NACL,還是需要通過驗證才能進入,但當再碰到 SG,就不必再進行驗證(如下圖橘色虛線所示)。因為 SG 為 stateful,記得此請求曾經在自己允許下出去過,回來時就可以直接進到 EC2。
那這次,我們了解了 AWS VPC 的網路流通方式,透過 Route Table 的設定並搭配 NAT 與 IGW 來連通內外網。此外,我們也學會了其安全設定的各種階層,含有 NACL 以及 Security Group,讓我們能有效的管理網路安全。
明天,我們將接著介紹「【Lab】VPC外網 Public Subnet to the Internet (IGW)」!
請問(圖一)這樣理解對嗎? a/b/d 需要驗證; c 不需再驗證
a) In 符合 NACL 的規範才能進入Subnet
b) In 符合 SG 的規範才能進入 EC2
c) Out -> SG 是一個 stateful,離開不需再驗證
d) Out -> 符合 NACL 的規範才能離開Subnet
完全正確!