Day 20 已經有一張很清楚的圖：

Routing Table
→ 決定怎麼走

ACL
→ 決定准不准走

例如：

GUEST VLAN
192.168.20.0/24

SERVER VLAN
192.168.30.0/24

就算 Layer 3 Switch 有 Route，ACL 仍然可以擋：

Guest → Server
Deny

那問題來了：

ACL 已經能 Permit / Deny，為什麼企業網路還要 Firewall？

我以前會把它們想成：

ACL
=
小型 Firewall

方向不算完全錯，但會漏掉一個很重要的差別：

設備只看「這一個封包」，還是會記得「這個封包屬於哪一條連線」？

這就是今天要拆的：

Stateless
vs
Stateful

先說清楚範圍。

這篇講的 ACL，是 Day 20 那種 CCNA 常見的 Standard / Extended IPv4 ACL。

Cisco 還有其他更進階的機制，所以不要把：

所有叫 ACL 的功能
=
一定全部 Stateless

硬背成絕對規則。

今天只先建立最常用的腦內模型。

先從一條 HTTPS 連線開始

假設使用者電腦：

192.168.10.10

要開一台 Web Server：

192.168.30.10
TCP 443

實際的 TCP 連線不只是：

Client
→ Server:443

Client 自己還會使用一個暫時的來源 Port。

例如：

192.168.10.10:53000
        ↓
192.168.30.10:443

Server 回覆時方向會反過來：

192.168.30.10:443
        ↓
192.168.10.10:53000

所以其實至少有兩個方向：

去程
Client:53000 → Server:443

回程
Server:443 → Client:53000

這時 Stateful / Stateless 的差別就開始出現了。

Stateless 到底是什麼？

先不要背翻譯。

Stateless 可以先想成：

我只看現在眼前這一個封包，不記得你上一個封包做過什麼。

例如一般 Extended ACL 收到：

192.168.10.10:53000
→
192.168.30.10:443

它會看：

Source IP
Destination IP
Protocol
Source / Destination Port

然後依 ACL Rule 決定：

Permit
或
Deny

下一個封包來時，再重新 Match 一次。

它不會因為剛剛已經 Permit：

Client → Server

就自動推論：

喔，等一下 Server 回 Client 的封包，是剛才那條連線的回覆，我幫你放行。

在這個基本模型裡：

去程
要符合去程規則

回程
也要符合回程規則

這就是 Stateless 最重要的畫面。

Stateful 又是什麼？

Stateful 可以先想成：

設備會記得這條連線的狀態。

例如 Client 主動建立：

192.168.10.10:53000
→
192.168.30.10:443

Stateful Firewall 如果允許這條連線建立，會在內部記住類似：

TCP
192.168.10.10:53000
↔
192.168.30.10:443

後面 Server 回：

192.168.30.10:443
→
192.168.10.10:53000

Firewall 不只看到一個孤立的封包。

它還知道：

這是剛才已允許連線的 Return Traffic。

所以腦袋可以先畫：

Stateless
每個 Packet 各看各的

Stateful
Packet
↓
屬於哪一條 Connection？
↓
Connection State
↓
決定是否允許

Firewall 跟 ACL 到底差在哪？

最簡化先這樣看。

CCNA 常見 Standard / Extended ACL：

Packet
↓
按照條件 Match
↓
Permit / Deny

Stateful Firewall：

Packet
↓
Rule
+
Connection State
↓
Permit / Deny

所以 Firewall 的價值不只是：

規則比 ACL 多。

更重要的是它通常可以建立一個「連線上下文」。

例如：

Inside Client
主動連 Internet HTTPS
↓
Firewall 允許建立連線
↓
Internet Server 回覆
↓
Firewall 認得是 Return Traffic
↓
允許回來

這就是為什麼只看：

Port 443

還不夠。

真正的問題常常是：

誰先建立連線？這個封包是不是既有 Session 的一部分？

那 Firewall 是不是永遠比 ACL 高級？

不要這樣背。

ACL 很適合做：

簡單
明確
高速
靠近 Interface 的封包過濾

例如：

Guest VLAN
不能進 Management Network

這種需求用 Extended ACL 就很合理。

Firewall 則常出現在更明確的 Security Boundary：

Internet
   ↓
Firewall
   ↓
Internal Network

或者：

Users
↓
Firewall
↓
Server Zone

因為除了基本 Permit / Deny 之外，Firewall 常常還需要處理：

Session State
Zone Policy
Logging
NAT
更進一步的安全檢查

但不同 Firewall 產品能力差很多。

所以不要背成：

只要名字叫 Firewall
→ 一定所有功能都有

今天真正要記的是：

ACL 比較像規則表；Stateful Firewall 還多了一層「我記得這條連線」。

一個最容易誤會的地方：回程流量

假設需求：

PC
192.168.10.10

可以主動連
Server
192.168.30.10:443

但 Server 不應該隨便主動連 PC。

用人話講就是：

PC 可以去找 Server，但不代表 Server 可以任意從零開始打進 PC。

Stateful Firewall 可以區分：

A.
PC 主動發起
Server 回覆
→ 同一條 Connection

B.
Server 自己主動發起新連線到 PC
→ 新 Connection

A 可以被允許。

B 可以被拒絕。

這就是「只看 IP / Port」和「看 Connection State」最大的差別之一。

把 AWS 放進同一張圖

前面 knowledge/network/README.md 一直想做一件事：

先看實體世界怎麼解，再看 AWS 怎麼抽象。

AWS VPC 裡最容易一起搞混的兩個東西就是：

Security Group
Network ACL

第一次看真的很像：

兩個都是防火牆規則
為什麼要兩套？

其實它們最重要的差別可以先抓四件事：

Security Group
→ Resource / ENI 層級
→ Allow Rule
→ Stateful
→ 不靠第一條 Match 的順序做決策

Network ACL
→ Subnet 邊界
→ Allow + Deny
→ Stateless
→ 按 Rule Number 由小到大 Match

看到這裡，Day 20 的 ACL 感覺就回來了。

Security Group 為什麼叫 Stateful？

假設 EC2：

10.0.1.10

Security Group 允許：

Inbound
TCP 443
from Internet

Internet Client：

203.0.113.50:53000
→
10.0.1.10:443

這個請求被允許進入。

EC2 回：

10.0.1.10:443
→
203.0.113.50:53000

因為 Security Group 是 Stateful，所以這個回程流量會被視為既有允許連線的 Response Traffic。

腦袋可以先記：

SG 允許一條連線
↓
回程不用另外用一條反向 Rule
去重新證明一次

注意：

這不是說 Security Group：

Inbound Allow 443
=
Internet 可以主動連 EC2 的所有 Port

它仍然只允許你定義的流量建立連線。

Stateful 處理的是：

已經允許的連線，回程怎麼判斷。

NACL 為什麼叫 Stateless？

Network ACL 是放在 Subnet 邊界的規則。

假設：

Internet Client
203.0.113.50:53000

        ↓

Public Subnet
10.0.1.0/24

        ↓

EC2
10.0.1.10:443

NACL 看到去程：

203.0.113.50:53000
→
10.0.1.10:443

會用 Inbound Rules 判斷。

Server 回程：

10.0.1.10:443
→
203.0.113.50:53000

又會用 Outbound Rules 重新判斷。

因為它不記得：

剛才這是我放進去的那條連線。

所以：

Inbound 放行
≠
Return Traffic 自動放行

這就是 Stateless。

實際設計 NACL 時，回程常會牽涉 Client 使用的 Ephemeral Port。

所以如果只想著：

Web Server = TCP 443

很容易只放 443，卻忘記反向流量的目的 Port 已經變成 Client 的暫時 Port。

Security Group 跟 NACL 不是二選一

不要把它想成：

用了 SG
就不需要 NACL

或：

NACL 比 SG 更高級

它們控制的位置不同。

可以先畫：

Internet
   ↓
Route Table / IGW
   ↓
Subnet Boundary
   ↓
Network ACL
   ↓
EC2 ENI
   ↓
Security Group
   ↓
Operating System
   ↓
Nginx / App

這不是說每一個封包在所有 AWS 架構裡都一定用這個固定順序理解。

但當第一張腦內地圖很好用。

你可以先問：

Route 有嗎？
↓
NACL 放嗎？
↓
Security Group 放嗎？
↓
OS Firewall 放嗎？
↓
Service 有在 Listen 嗎？

Cisco ACL 跟 AWS NACL 是不是一樣？

不是。

但它們有一個很好用的共同概念：

都是偏 Stateless 的封包過濾思維。

Cisco Extended ACL 常用：

Source
Destination
Protocol
Port
Permit / Deny

AWS NACL 也會用：

Source / Destination
Protocol
Port
Allow / Deny
Rule Number

所以學過 ACL 之後，再看 NACL 不會完全陌生。

但不能直接把：

Cisco ACL 指令
=
AWS NACL 規則

硬套。

設備位置、規則模型、預設行為與管理方式都不同。

Security Group 可以理解成 Cloud Firewall 嗎？

第一層可以。

但更精確一點：

Security Group 是 AWS VPC 裡，綁在 ENI / Resource 附近的 Stateful 虛擬防火牆規則。

這句比：

Security Group
=
Cisco ACL

更接近正確畫面。

它最大的記憶點不是 Cisco 指令長什麼樣。

而是：

Resource Level
+
Allow Only
+
Stateful

NACL 最值得記的不是「另一個 Firewall」

而是：

Subnet Level
+
Allow / Deny
+
Stateless
+
Rule Number Order

這四個放在一起，就比較不容易跟 Security Group 混掉。

用一個故障案例把它們串起來

假設 EC2 Web Server：

10.0.1.10
TCP 443

使用者說：

瀏覽器連不上。

以前可能直接去改 Security Group。

現在先照層次查。

1. Route

Public Subnet
有沒有到 Internet Gateway 的 Route？

如果 Route 根本不存在：

Security Group 再寬
也不會自己生出路

2. NACL

Inbound
有沒有允許 Client → 443？

Outbound
有沒有允許 Return Traffic？

因為 NACL 是 Stateless。

3. Security Group

有沒有允許需要的 Inbound 443？

已允許連線的 Response Traffic 會依 Stateful 行為處理。

4. Host

OS Firewall
有沒有擋？

5. Application

Nginx / App
真的有 Listen 443 嗎？

所以：

「連不上」不是一看到 Security Group 就改成 0.0.0.0/0。

先定位是哪一層。

把 Day 20 與 Day 21 接起來

Day 20：

Route 已經存在
↓
ACL 還可以決定 Permit / Deny

Day 21：

ACL / Packet Filter
↓
如果只看每個 Packet
→ Stateless

Firewall / Security Group 類型的 Stateful 控制
↓
還會把 Packet 放回 Connection Context

所以現在腦袋可以多一層：

Routing
→ 我要往哪裡走？

Stateless Filter
→ 這一個 Packet 准不准？

Stateful Filter
→ 這個 Packet 屬於哪一條 Connection？
   這條 Connection 現在准不准？

先別往下看，想四題

1.

Client：

192.168.10.10:53000

連：

192.168.30.10:443

Server 回覆時，Destination Port 還是 443 嗎？

2.

Security Group 允許一條 Inbound HTTPS Connection 後，回程 Response Traffic 是否還需要另外建立一條反向 Inbound / Outbound Rule 才能被視為同一條連線？

3.

NACL 允許：

Inbound TCP 443

是不是就代表 HTTPS 回程一定能出去？

4.

Route Table 有正確 Route、Security Group 也允許 443，但網站仍打不開，還有哪些層要查？

1. 不是。回程通常是 Server 的 443 回到 Client 當初使用的暫時來源 Port，例如 53000。
2. 不需要用一條反向規則重新證明同一條已允許連線的 Response Traffic；Security Group 是 Stateful。
3. 不一定。NACL 是 Stateless，Outbound Return Traffic 仍要符合規則。
4. 至少還要檢查 NACL、作業系統 Firewall、服務是否真的 Listen，以及整體 Route / Gateway / Internet path 是否正確。

如果今天只記得三件事

第一件：

Stateless 是每個 Packet 各自判斷；Stateful 會記得 Connection State。

第二件：

Security Group
→ Resource / ENI
→ Allow
→ Stateful

第三件：

Network ACL
→ Subnet
→ Allow + Deny
→ Stateless
→ Rule Number Order

最後不要忘記 Day 20：

Routing 決定路徑，Security Rule 決定能不能過。

下一個「為什麼」

現在已經知道：

Route
ACL
Firewall
Stateful
Stateless
Security Group
NACL

下一個問題剛好會回到家裡最常見的一台 Router。

家裡可能有：

192.168.1.10
192.168.1.20
192.168.1.30

這些都是 Private IP。

Internet 上卻只看到家裡一個 Public IP。

那三台裝置一起上網時，Router 到底怎麼知道回來的封包要交給哪一台？

oh~