我已在預設 VPC 中建立了一個 AWS 實例，並封鎖了網路 ACL 中的所有 UDP 流量。我的出站規則如下：
| 規則編號 | 類型 | 協定 | 連接埠範圍 | 目的地 | 允許否認 |
|---|---|---|---|---|---|
| 99 | 所有UDP | UDP (17) | 全部 | 0.0.0.0/0 | 否定 |
| 100 | 全TCP | TCP (6) | 全部 | 0.0.0.0/0 | 允許 |
| * | 所有流量 | 全部 | 全部 | 0.0.0.0/0 | 否定 |
如果我使用traceroute，我什麼也得不到，正如預期的那樣：
[ec2-user@ip-172-31-32-169 ~]$ traceroute 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
...
但是，如果我使用nc，我做得到一個意想不到的回覆：
[ec2-user@ip-172-31-32-169 ~]$ nc -vzu 1.1.1.1 53
Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: Connected to 1.1.1.1:53.
Ncat: UDP packet sent successfully
Ncat: 1 bytes sent, 0 bytes received in 2.01 seconds.
為什麼會發生這種情況？而且，總是需要 2 秒才能得到回應。為什麼是2秒？
答案1
TL;DR - UDP 被 NACL 規則阻止。您收到的回覆nc具有欺騙性，我相信（但尚未證實）2.01 秒的時間是超時。
Netcat 聲稱它發送了一個資料包，確實如此。但您的 NACL 充當 EC2 執行個體所連接的子網路的第 3/4 層防火牆。封包正在從主機發送，但 NACL 阻止它（並丟棄它）。由於您正在使用該-z標誌，因此它會立即斷開連接，並且會出現兩秒鐘的逾時。我假設兩秒是超時，因為它始終是回傳值。 （我沒有時間在原始程式碼中運行它）
我在 VPC 中重新建立了您的 NACL，並經歷了與上述相同的結果，包括確切的「收到」值。但是，當我嘗試使用該網站進行查找時，dig當拒絕到位時，它會超時。
Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: Connected to 1.1.1.1:53.
Ncat: UDP packet sent successfully
Ncat: 1 bytes sent, 0 bytes received in 2.01 seconds.
[root@ip-10-99-0-198 centos]# dig +short @1.1.1.1 www.google.com
;; connection timed out; no servers could be reached
當拒絕未到位時，dig將按預期工作。最後一點是，如果您nmap在該 UDP 連接埠上執行掃描，您將得到「開啟|過濾」回應。
不幸的是，防火牆和過濾設備也會丟棄資料包而不做出回應。因此，當Nmap多次嘗試都沒有收到回應時，它無法確定連接埠是開放的還是被過濾的。
答案2
您有一條編號較小的規則，該規則在允許 UDP 的規則 99 之前處理。規則按升序評估。
“規則編號。從編號最小的規則開始評估規則。一旦規則與流量匹配，就會應用該規則，無論任何編號較高的規則可能與其相矛盾。”
https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html#nacl-rules